# Re-learning FreeBSD!



## Savagedlight (Apr 28, 2013)

I've used FreeBSD since about year 2000, in the early 4.x days. I've never taken a course on FreeBSD, everything has been self-taught, and I've tried to stay up to date on changes, but I've probably missed out on some of what has been added or changed between 4.x and 8.0, or maybe even something which has been there from the start.

I've been re-researching FreeBSD as much as I could the past two months, ignoring my assumptions and digging through man pages, hand book and Google on (almost) everything I've done, to make sure I have up-to-date knowledge.

However, I'm now trying to find subsystems, features, configurations and other things that I haven't already retouched my knowledge on. Since I can't ask you to suggest things I don't know, as that would require a comprehensive list of everything that I *do* know, I'm going to ask this instead: *What subsystems, feature or tip do you think is a must-know or good-to-know for an all-around FreeBSD administrator?* 

It would be awesome if you could also add information about use cases to your reply, as I think that would increase the benefit for future readers.


----------



## noobster (Apr 28, 2013)

Learn about ZFS if you haven't done so already.


----------



## fonz (Apr 28, 2013)

Savagedlight said:
			
		

> What subsystems, feature or tip do you think is a must-know or good-to-know for an all-around FreeBSD administrator?


Jails, hands down. If you build from ports and/or track -STABLE I recommend at least a build jail, but on servers pretty much every service can be run inside its own jail.


----------



## cpm@ (Apr 28, 2013)

Primitive Tip 

Sometimes the root account is shared by a lot of users, and sometimes it's very useful knowing which of these users has, for example, made a _modification_. But by default, when we do `% su` or `% sudo -s` we can't know which user did it. If you want to track each user's commands, there is a way to do it.

First of all you have to be sure our root shell is bash(1). Now have to create the directory where we will save each user's logs `# mkdir /root/.history && chmod 600 /root/.history`. And finally, edit the root's .bashrc file adding the following lines:

```
export HISTSIZE=1000000
export HISTFILESIZE=1000000
export HISTTIMEFORMAT="%F %T: "
export HISTFILE=/root/.history/root_history-$(who am i | awk '{print $1}';exit).log
export PROMPT_COMMAND='history -a'
```

Next time a user becomes root, it will create a log file with all his commands:

```
[CMD]# ls /root/.history[/CMD]
root_history-user1.log
root_history-user2.log
root_history-user3.log
```

Also, here you have the FreeBSD Network Administrators Guide (a bit outdated)


----------



## DutchDaemon (Apr 28, 2013)

A root user can make this setup disappear immediately. And do we _have_ to keep advising against changing the root user's shell, especially one so prone to gettext upgrade disasters as bash?


----------



## Savagedlight (Apr 28, 2013)

If you want to track executed commands, set up auditd to log successful command executions by root, and make the audit directory append-only.


----------



## cpm@ (Apr 28, 2013)

DutchDaemon said:
			
		

> A root user can make this setup disappear immediately. And do we _have_ to keep advising against changing the root user's shell, especially one so prone to gettext upgrade disasters as bash?



@DutchDaemon,

You are right :beer 

If you don't prevent, e.g. using chflags(1), that users modifying their .bash_history to avoid redefine HISTFILE as /dev/null, telling the shell to write it's history to this file:

```
HISTFILE=/dev/null
```

This is just one example of a bunch... to disable the user's log.

To not allow users (or even root) to modify, move, or delete their .bash_history you need to set an attribute to append only `# chflags sappnd /home/username/.bash_history`



			
				Savagedlight said:
			
		

> If you want to track executed commands, set up auditd to log successful command executions by root, and make the audit directory append-only.



@Savagedlight,

I'll take a look to `% man auditd`


----------



## wblock@ (Apr 28, 2013)

less(1) is underutilized.  It can do an amazing number of things, and is well worth learning in detail.


----------



## Sfynx (Apr 29, 2013)

GEOM in general. It's awesome.


----------



## bkouhi (Apr 29, 2013)

One important thing in my opinion: make(1)(), PMake Tutorial.


----------



## kpa (Apr 29, 2013)

PKGNG and Poudriere. It won't be long till PKGNG will be the default packaging system for FreeBSD, good time to learn now.


----------



## estrabd (Apr 29, 2013)

I would recommend anything related to SMP or many-core machines, particularly the schedulers and utilities like cpuset(1).


----------



## ta0kira (Apr 29, 2013)

I would highly recommend looking at:

login.conf and rctl, both of which allow you to impose resource limits. The former applies to processes and the latter can be applied to processes, users, jails, and login classes.
OpenPAM, since it's the core of authentication in FreeBSD.
MAC and its various modules, just to get an idea of how you can compartmentalize a system. I don't think the majority use MAC, but you can do some very useful things with it. For example, you can use it to hide processes that monitor your server and to block access to certain files, even if a process is running as root. (There are some additional considerations when dealing with root, however.)
pf and ipfw, for firewalls, redirection, and NAT. The last two are relevant for jails even if you don't run a LAN.
Jails, as was mentioned by someone else.
nullfs, which allows you to mount a directory.
audit and auditd, which allow you to monitor various system calls, as well as programs that voluntarily log events. This can be tricky to work with in conjuction with jails or when you want to monitor the activities of sudoers, though.
Kevin Barry


----------



## ShelLuser (May 3, 2013)

Savagedlight said:
			
		

> What subsystems, feature or tip do you think is a must-know or good-to-know for an all-around FreeBSD administrator?


As clichÃ©d as it most likely sounds my answer would be the FreeBSD handbook, and for the sole reason that this book has really helped me in the past weeks to get up to speed.

That could have something to do with my background (dated Solaris experience and in-depth Linux experience) but even so; its a source of documentation which I consider to be extremely useful and invaluable for administrators.


----------

