FreeBSD is plain and simple my all time favorite Unix operating system. And yes: technically speaking it’s Unix-like but that’s mostly due to licensing concerns. If you look at the backwards compatibility aspects (see /usr/src/sys/amd64/conf/GENERIC, the COMPAT_FREEBSDxx options), the slow pace of changes (we don’t get “exciting” and “OS changing” features with every update) and the display of high respect for current standards (this is just me, but I think that pkg_add (old) vs.
pkg add (current) is a good example and also extremely well thought off)… so if you look at all that then I think you can agree that when solely looking at the environment then FreeBSD has everything it needs to be considered a true Unix operating system.
Another thing is that the system is like elastic. You can bend and shape it in any way you want. In both good and bad ways. So I figured.. why not a small collection of very general things which you might want to pay attention to while working with this system?
#1 Don’t mix ports and binary packages
This is an aspect which has confused many people and I’m sure it will continue to do so for many more in the future. In short: either install your software through the ports collection (so building it using /usr/ports, either using the regular build commands or a utility of some sort) or install your software using merely pkg. So, for example:
pkg install mystuff.
Don’t do both!
Why? Because it has the potential to seriously disrupt your entire system. If you upgrade your system and suddenly see packages which you wanted to keep get automatically deinstalled then this could be a clear sign of trouble. If you have upgraded your system and a program you’re using suddenly spits out error messages about missing libraries or missing functions, library symbols or whatever more. That too could be a clear signal that you broke things. The reason this is happening is because binary packages were build with default settings and the expectation of the same thing for all their dependencies.
What do you think could happen if you installed a notepad system using the package manager while you installed a required database library using the ports collection, while alsoexchanging MySQL for PostgreSQL? The application itself might still work. But all automated backups are likely to fail miserably because chances are high that it would depend on mysqldump for that, a program which is no longer available on your system. So the next time you experience a crash and figure that you came fully prepared then you might be in for a very nasty surprise.
#2 Don’t edit ‘default’ files
Have you ever wondered which processes FreeBSD would start on its own? Or maybe what about the boot stage: would FreeBSD automatically load any kernel modules? These questions can be easily answered by taking a closer look at /etc/defaults/rc.conf and /boot/defaults/loader.conf.
Whatever you do: do not edit these files!
First, the most obvious reason: this is a file which is a part of the base system. Therefor it could get updated at any given time, fully overwriting whatever changes you made. If something suddenly stopped starting after you upgraded your system then… maybe this is why.
But the other reason is because there is no need. Any changes which you want to make should be applied to the main official file instead. So /etc/rc.conf and /boot/loader.confrespectfully. The default files are at their best as research material. It’s not merely to tell FreeBSD what to do by default, it can even help us out!
Example: maybe you don’t enjoy Sendmail and wish to use another MTA. I don’t know, maybe mail/postfix? As you probably know Sendmail is a part of the base system, so it would also have set up several settings to cater for that. But which ones….
peter@unicron:/etc/defaults $ grep sendmail rc.conf
# Settings for /etc/rc.sendmail and /etc/rc.d/sendmail:
sendmail_enable="NO" # Run the sendmail inbound daemon (YES/NO).
sendmail_pidfile="/var/run/sendmail.pid" # sendmail pid file
sendmail_procname="/usr/sbin/sendmail" # sendmail process name
sendmail_flags="-L sm-mta -bd -q30m" # Flags to sendmail (as a server)
sendmail_cert_create="YES" # Create a server certificate if none (YES/NO)
#sendmail_cert_cn="CN" # CN of the generate certificate
sendmail_submit_enable="YES" # Start a localhost-only MTA for mail submission
sendmail_submit_flags="-L sm-mta -bd -q30m -ODaemonPortOptions=Addr=localhost"
sendmail_outbound_enable="YES" # Dequeue stuck mail (YES/NO).
sendmail_outbound_flags="-L sm-queue -q30m" # Flags to sendmail (outbound only)
sendmail_msp_queue_enable="YES" # Dequeue stuck clientmqueue mail (YES/NO).
sendmail_msp_queue_flags="-L sm-msp-queue -Ac -q30m"
# Flags for sendmail_msp_queue daemon.
sendmail_rebuild_aliases="NO" # Run newaliases if necessary (YES/NO).
Everything you might wanted to know about FreeBSD’s default Sendmail usage but were too afraid to ask Of course an easier way to grep only the entries we need would be:
grep -e "^sendmail.*=\"YES" rc.conf.
So basically: these default files should only be used to look up specific settings and/or behavior. And they can truly be an invaluable source for that. When I set up my own private SSL certificates for Sendmail I didn’t want it to continuesly try to build its own useless stuff in /etc/mail/certs. And this is how I found out to stop that behavior.
#3 Don’t mess with /etc/crontab
As you might know /etc/crontab is the main Cron configuration file so it would be the obvious place to set up our own entries for it, right? Well… not so much. Although not necessarily wrong there are some risks involved. Just like with most other files in /etc you’re basically messing with a system file which could undergo changes during upgrades.
But the most compelling reason is that any changes you make would not be immediately picked up by the system. You’d have to reload the crontab as well. Why all the extra bother if you don’t have to?
Instead it is advised to use the crontab command. Do you need some jobs run as the bind user? Just use
# crontab -u bind -e and done. Do you need some specific system settings? Install those as root:
# crontab -e and done. You only need to worry about the 5 time fields (m h dom m dow) and the command(s) to run and that’s it.
After you’re done editing the crontab will be automatically installed and activated. No need to manually mess with service reloading. And as an added bonus: this way you also don’t have to worry about accidentally removing important system entries whenever you no longer need certain jobs and want to remove those.
#4 Don’t mess with /etc/passwd and /etc/groups either!
Since we’re focusing ourselves on /etc a little here is another one I’ll be perfectly honest: I sometimes also do this myself, but fortunately very seldomly.
If you insist on editing these files manually at the very least rely on
vipw and/or vigr. There are many advantages for that. First it will apply a lock on the file so that you can’t accidentally mess things up (for example: if another process would try to change a password and you finish making your changes after that you’d effectively undo the password change, which could lead to very nasty results). And another aspect is that any made changes will be automatically processed if they have to. Better yet: vipw will also apply some syntax checking so if you’re at risk of trashing your entire login process because of a messed up edit then this would save you from that.
What’s that? You don’t like using vipw because it always uses vi? So change that! All it does is honor the EDITOR environment variable. Just point that to something else and you’ll be home free.
But there are more reasons not to do this:
Which entry was the home directory again? Wait, I know! I think it was the empty entry between those two colons, let’s change that…
# chpass operator (note: chsh also works):
#Changing user information for operator.
Uid [#]: 2
Gid [# or name]: 5
Change [month day year]:
Expire [month day year]:
Home directory: /
Full Name: System &
Everything you might want to edit in an impossible to miss way. This is how you edit /etc/passwd without the risks of making any accidentally dumb mistakes (like the one I hinted at above). For more information check out chpass(1). This is also the best way to change your own settings, even as a regular user. Don’t like your current shell?
chsh to the rescue!
And there’s something even better: pw. I’ll admit: the sheer complexity of this command also set me back many times. I mean, just look at the massive sea of entries when you check pw(8). Honestly: I have opened that manual page many times in the past only to glance at it, quickly close it and then run either vipw and/or vigr and left it at that.
If you’re new to pw it is very easy to get totally overwhelmed and/or confused at first, and that is definitely not your fault.
But despite its difficult appearance it’s actually extremely easy to use. Want to delete a user?
# pw userdel unwanteduser, and done. Or what about a group? Fortunately logic is heavily applied here as well, so you can simply swap out userdel for groupdel.
Need to add someone to the wheel group? This means you need to modify a group: groupmod. So:
pw groupmod wheel -d currentmember -m newmember. This would delete currentmember and add newmember.
Bottom line: there really is no need to manually edit /etc/passwd and/or /etc/group at all. At the very least rely on vipwd.
#5 Reconsider the removal of any options from your customized kernel configuration
Before you wonder… I’m doing the same thing myself, even made a sport out of this. Here is the top of /root/kernels/unicron.conf which is the symlink target for /usr/src/sys/amd64/conf/UNICRON:
nodevice ahci, mvs, siis
nodevice ahc, ahd, esp, hptiop, ispfw, mps, mpr, sym
nodevice trm, adv, adw, aic, bt, isci
#nodevice ispfw, ncr
(I know that I should rename the kernel as well, but.. that’s for a later time)
This was manually edited against GENERIC, manually kept updated and before every major upgrade I carefully compare the new GENERIC with this file.
So here’s the problem: What if my current hardware would suddenly fail and as an emergency replacement I got hold of a Tekram DC395U/UW/F DC315U adapter? Well, simple: I can install the hardware but as you can see above my current kernel would totally ignore it because I manually removed support for that (notice the trm entry above?).
Basically: in order to use new hardware I’d have to rebuild a whole new kernel. Sounds like the perfect strategy for a server which hundreds of users depend on!
Now, don’t get me wrong here. These things can be fun to do. I also enjoy tinkering with my system (see above) and it also gives me a good sense of satisfaction that my kernel is pretty streamlined. Not to mention the fact that setting all of this up has taught me a lot about the kernel and the source tree itself.
But always heed the risks.
And in case you wonder… I definitely enjoy tinkering but obviously I also came prepared On my system I maintain /boot/kernel.gen as well which contains a copy of a GENERIC kernel with all the available modules (I usually rely on the latest kernel.txz). And my /boot/loader.conf contains this entry: kernels="kernel kernel.old kernel.gen". So if things do go dramatically wrong then I always have a GENERIC failsave available.
End of part I (the entire message was too long)