10 Do's and Don't for FreeBSD

ShelLuser

ShelLuser

Editorial

Hi gang!

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 also exchanging 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.conf respectfully. 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....

Well, easy:
Code: 
peter@unicron:/etc/defaults $ grep sendmail rc.conf
mta_start_script="/etc/rc.sendmail"
# 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:
Code: 
operator:*:2:5::0:0:System &:/:/usr/sbin/nologin
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...

vs:

# chpass operator (note: chsh also works):
Code: 
#Changing user information for operator.
Login: operator
Password: *
Uid [#]: 2
Gid [# or name]: 5
Change [month day year]:
Expire [month day year]:
Class:
Home directory: /
Shell: /usr/sbin/nologin
Full Name: System &
Office Location:
Office Phone:
Home Phone:
Other information:
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:

Code: 
include GENERIC
ident OMICRON

nooptions       QUOTA
nooptions       GEOM_RAID
nooptions       INCLUDE_CONFIG_FILE

# Floppy
nodevice        fdc

# ATA
nodevice        ahci, mvs, siis

# SCSI
nodevice        ahc, ahd, esp, hptiop, ispfw, mps, mpr, sym
nodevice        trm, adv, adw, aic, bt, isci
nooptions       AHC_REG_PRETTY_PRINT
nooptions       AHD_REG_PRETTY_PRINT
#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! :sssh:

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)
 
Part II

#6 Don't change the root shell to something else

/bin/csh is the shell for the root user while everyone else usually gets /bin/sh, and this is done for a very good reason. Although many people use the root user and its privileges extremely casually you should never underestimate the amount of damage which a small mistake as root can do to your system. Don't treat root sessions as something casual!

This is one of the reasons why using a different shell can be a very good idea: because if you don't often use this then it will force you to think about your actions:
Code: 
peter@unicron:/home/peter $ for a in a b c; do mkdir -p test/$a; done
peter@unicron:/home/peter $ file test
test: directory
peter@unicron:/home/peter $ csh
% for a in a b c; do mkdir -p test/$a; done
for: Command not found.
a: Undefined variable.
Of course there's more. The C shell also has a strong emphasis on interaction. That 'for' command I showed above? The C shell is perfectly capable of that as well, but in a much more interactive way:
Code: 
% foreach a ( a b c )
foreach? mkdir -p test2/$a
foreach? end
% file test2
test2: directory
See what I mean? Instead of simply typing out one huge command on a single line this allows you to cut the whole thing up into smaller pieces, also allowing you to check for any typoes in the single command(s) and to (re)think about each of those as well.

Sure there's also a downside here: if you have to repeat this set of commands a few times then this is obviously not the best of options. But why not write a temporary shell script and use that instead?

#7 Don't use the root user all the time

Many people claim that Unix is a very secure operating system which can hardly be affected by any nastiness such as viruses. Although there is definitely some truth to that the underlying reasons for this don't necessarily have much to do with Unix. See, under normal circumstances you wouldn't be logged on as root and as a direct result of that....
Code: 
peter@unicron:/home/peter $ rm /boot/kernel/*
override r-xr-xr-x  root/wheel uarch for /boot/kernel/agp.ko? y
rm: /boot/kernel/agp.ko: Permission denied
override r-xr-xr-x  root/wheel uarch for /boot/kernel/coretemp.ko? y
rm: /boot/kernel/coretemp.ko: Permission denied
peter@unicron:/home/peter $ rm -rf /boot/kernel/kernel
rm: /boot/kernel/kernel: Permission denied
peter@unicron:/home/peter $ echo "rm -rf ~/*" >> /etc/profile
/usr/local/bin/ksh: cannot create /etc/profile: Permission denied
peter@unicron:/home/peter $ echo "/home/peter/bin/passwordh4x >> /home/peter/ >> /root/.profile
/usr/local/bin/ksh: cannot create /root/.profile: Permission denied
Slightly offtopic, but seriously: if you want to you could achieve the exact same thing on Windows as well:

wVnWkor.png

'Toegang geweigerd' aka: 'Permission denied'

I'm actually using Windows as a regular (non-administrator) user and as a result I don't have access to most system environments. Some ransomware trying to encrypt c:\windows\system32 on my system? Best of luck with that! :p

Back to FreeBSD: part of keeping your system secure is not to use excessive options if you don't have to. And root is an extremely powerful user because it basically has little to no restrictions. A mistake as root can have much bigger consequences than those of a regular user. Stay safe...

#8 /var/backups is a thing

Now, sure, you should not rely too much on automated "out of the box" backups, but if certain problems do occur then definitely check out this location first. Did something trash your package database? You might find the solution here. Were you too quickly with that pw command and removed an important account? This might be a quick way out too.

Of course you shouldn't overly depend on this either but this system very slick. It is powered by the Periodic system and actually quite intelligent too. For example: although it can keep a "roulation backup" of your files (with this I mean that it keeps several retention copies) it won't if there is no need. For example: /var/backups/aliases.bak dates from October last year on my system. And there's also an aliases.bak2 dating from July last year. Guess what? Last time I applied changes to the /etc/aliases file were.. you might have guessed it: around July and October last year ;)

#9 Check system integrity using /etc/mtree

Did you know that FreeBSD includes a full fledged intrusion detection system out of the box called mtree? Now you do ;)

Keep in mind that the specifications in /etc/mtree only track directory permissions and not those of the individual files. So if you want to use the files in /etc/mtree then you also might want to use the -e parameter to exclude any file checks:
Code: 
peter@unicron:/# mtree -e < /etc/mtree/BSD.root.dist
./etc/autofs missing
./etc/bluetooth missing
./etc/ppp missing
Guess what? It's correct about that. If I wanted to I could tell mtree to fix these issues automatically using the -u option.

This can be the perfect way to check if no one messed with some directory permissions:

Code: 
peter@unicron:/var# mtree -e < /etc/mtree/BSD.var.dist
db/ports:
        permissions (0755, 0775)
Another very well spotted change.

I actually set this up as an extension of #7; very often I don't build ports as root but using my normal user account. This permission allows any user within the wheel group to modify the options of a port without having to elevate their permissions.

Want to learn more about mtree (it can do tons more)? Then you might enjoy my small mtree guide.

#10 What works for me doesn't have to work for you!

All these items are basically best practices but definitely not mandatory rules. Always keep in mind that every situation is most often unique and when it comes to security, configuration and an operating system there is no such thing as a "one size fits all" solution.

Sure there are risks involved when manually firing up vi to edit /etc/passwd, but not so much if you're in single user mode. Running a fully customized kernel definitely has its quirks if you need to replace hardware, but how often would you do that on a laptop anyway? It's cool to be able and check permission defaults, but what if you applied better permission settings specific for your own environment? Then you probably don't care about /etc/mtree at all.

"Your milage may vary" as the saying goes.

And there you have it, 10 regular do's and dont's for FreeBSD. Hope this was useful for some of you.
 
Curious on #1 (mixing packages & ports) since portmaster() has explicit "--packages*" options for installing dependencies from packages instead of from ports. It a lot faster if you just want to tweak some top-level package's build-options but not spend hours rebuilding dependency ports. I also understand that part of the make-a-port process actually creates a package that then gets installed via the normal pkg()-style machinery.
 
Gumnos said:
Curious on #1 (mixing packages & ports) since portmaster() has explicit "--packages*" options for installing dependencies from packages instead of from ports.
Click to expand...
I'm familiar with the option(s) and I personally consider it a bad one. It's all about how you use it though... For example: --packages-build could be useful and not too much destructive.

I wrote a more in-depth guide about the issues with mixing ports and packages, might be a good read:

https://forums.freebsd.org/threads/guide-about-ports-and-binary-packages.62126/

The problem is that it's not always too obvious that something is very wrong. The main problem is when you change build options and then install packages which rely on those changed packages. Because they rely on a package with default build options, and if you changed something which the other packages actually use... then this could turn into a disaster. Or something totally unnoticed.
 
I'm not sure I get the reasoning behind your advice #6 ... not wanting to revive an old flame here (about whether you should use a C shell at all), but there are well-known arguments against it.

What I don't understand from your text is -- what bad could actually happen if you chose a different shell for root? On my system, I even build the base system WITHOUT_TCSH=yes and use zsh for everyone, including root. I didn't have any problems with this setup? Is your point that with the same shell, you could risk to forget you're logged in as root? This is easily solved e.g. by a prompt looking very different.

And about #7 -- that's reasonable of course! But I'd qualify it a bit, thinking about my usecase on a server with jails for services, many of them only having root and some system users: You'll always log on as root on these to do administrative tasks and that's fine ;) It's a different story on a workstation of course.
 
I always combine ports and packages. If you keep track of it, and don't make it too complex, you can do it. It depends on the set of ports of course, and that they are both from the same release: quarterly or head. Certain software makes good use for package installation, like programming language dependencies, and build only dependencies if they are up to date, especially from the Vuxml database. The next time, I rebuild a port over an old package, some dependencies get stripped out from the make config menu options.

Most of the programs I use can be grep-ed from my window manager start up configuration file. That way, I install those, and not treat a former dependency as an independent package or port needing to be installed.
 
On #5, I rename one GENERIC kernconf to TRIM or something like that, that is stripped down and has no additions to it. That file is included from a CUSTOM kernconf that references much of what is displayed by typing kldstat.
 
Zirias said:
What I don't understand from your text is -- what bad could actually happen if you chose a different shell for root?
Click to expand...

It is recommended that the root user's default shell remain unchanged since shells which are not included in the base distribution are installed to /usr/local/bin. In the event of a problem, the file system where /usr/local/bin is located may not be mounted. In this case, root would not have access to its default shell, preventing root from logging in and fixing the problem.
 
So, not really a reason to use a C shell for root -- after all, /bin/sh will be used anyways if you built WITHOUT_TCSH=yes.

But, a reason to only use shells in /bin. Yes, this might be important, but it depends on the configuration of your system. I don't really see risks here when you have a single zpool, or you're inside a jail that's constructed using null-mounts, but of course this is important on a classical setup with individual filesystems on different partitions. In the original posts, it reads like root must use the C shell -- without really giving a reason for that :)
 
xavi said:
It is recommended that the root user's default shell remain unchanged since shells which are not included in the base distribution are installed to /usr/local/bin. In the event of a problem, the file system where /usr/local/bin is located may not be mounted. In this case, root would not have access to its default shell, preventing root from logging in and fixing the problem.
Click to expand...

zpool import -fR zroot && zfs mount zroot/ROOT/default and rollback/chroot from Live USB stick. Unless there is a hard disk failure, nothing can break a properly snapshot_ed FreeBSD system.
 
Great list, except for the "OMG root is so powerful -- don't use it!" advise that permeates the *nix community. Forgive the analogy, but it's like telling people guns are dangerous so they shouldn't ever touch one unless absolutely necessary. So instead of learning how to safely use root by continual practice, users end up not having the skills necessary to use it well when they have to.

I get telling new users to not use it by default, and I get telling users not to run around in an X11 session logged in as root, but the rest is just fearmongering by people that should know better.

I once worked with people that belonged not-within-100-miles of root access, but because their position required its occasional use, they would inevitably wreck entire servers. But instead of learning how to use it well, they shied away from it even more and never got better at its use. Practice makes perfect because it forces you to learn good habits and technique, and it's those good habits that prevent you from breaking the system. It's like those images you see of Special Forces: the safety is off on their weapons; it's their discipline and training (trigger finger off the trigger) that prevents accidents.
 
I've seen #1 Don't mix ports and binary packages repeated over and over with no good advice on how to cope with the common situation of one or two ports that must be build from /usr/ports instead of pkg.

In my case, I needed SASL support in svnserver. The pkg version did not have it. Everything else installed came from pkg.

What to do?

Go to Jail. Create a jail for the one or two odd ports that must be built by hand. Install all dependencies there.

I've also run into dependency problems across packages - like different versions of pgsql. Running different versions in separate jails solves this.
 
I usually mix ports and binaries anyways because I don't want to wait weeks for a package to build but I also need the latest version of some things and/or something is not available in the ports tree as a binary
 
aimeec1995 said:
I usually mix ports and binaries anyways because I don't want to wait weeks for a package to build
Click to expand...
Switch to the latest package branch. Builds happen fairly frequently nowadays. In the past it could take some time but it never took weeks. I'm betting you are looking at the quarterly packages, those are updated once every three months and only receive security and stability updates.

 
linux->bsd said:
Great list, except for the "OMG root is so powerful -- don't use it!" advise that permeates the *nix community. Forgive the analogy, but it's like telling people guns are dangerous so they shouldn't ever touch one unless absolutely necessary. So instead of learning how to safely use root by continual practice, users end up not having the skills necessary to use it well when they have to.
Click to expand...

I have never used anything but su to become root. I do a lot of file transfers that require root access to mount a USB stick so I become root in the terminal then open x11-fm/xfe to work from as root. When I'm done I unmount the media, close my file manager (which free's up the terminal if I need to do anything else) and log out from the root account back to my usr account.

When I compile ports I exit x11-wm/fluxbox to the login terminal and su to work so I can tell at a glance what's going on.

When I'm working as root I never open a browser from my usr account or do anything that might compromise the root account, much less open a browser as root. I keep 2 laptops running so I can use another if need be.

I've been advised it's not good practice but am very comfortable working as root and consider myself competent to do so. Knowing full well I won't be asked if I really want to do something I did not intend to and the possible consequences thereof, but that doesn't happen.
 
Trihexagonal said:
I have never used anything but su to become root.
...
When I'm working as root I never open a browser from my usr account or do anything that might compromise the root account, much less open a browser as root.
...
I've been advised it's not good practice but am very comfortable working as root and consider myself competent to do so. Knowing full well I won't be asked if I really want to do something I did not intend to and the possible consequences thereof, but that doesn't happen.
Click to expand...

That's pretty much my workflow, too, except I always have a tmux session running as root in a different Terminal tab. When I need root access, I do my work, then back to my non-privileged user for daily tasks. I use $PS1 to indicate which user I am: 'root' in the prompt in screaming red. Before doing any deletions or overwriting files, my pinky freezes over the Enter key for at least two seconds instinctively. good habits == good sysadmin.
 
unitrunker said:
I've seen #1 Don't mix ports and binary packages repeated over and over with no good advice on how to cope with the common situation of one or two ports that must be build from /usr/ports instead of pkg.
Click to expand...

The common advice is to build your own packages in your own repo on your own server using Poudriere. Presumably because if you make a mistake with options and dependencies, it blows up there and not in your install.

If you don't want to do that, people have developed other "wrong" ways of manually managing this, like mine.
 
msplsh said:
people have developed other "wrong" ways of manually managing this
Click to expand...
Someone also developed a "right way(TM)" of automatically managing this : the Fetch prebuilt packages option of synth(1) . It seems a lot simpler than the method you describe in your post.
 
You must log in or register to reply here.
Back
Top