Decoupling settings from /etc/rc.conf in FreeBSD
The rc.conf file can have a lot of settings that quite important. In fact, I would say it has so many settings that it often gets very bloated. Have you ever made a huge mistake and wiped out the rc.conf when it is huge and full of many settings. Or have you ever had a system crash that wiped out the rc.conf? I have! A large rc.conf can be difficult to recover without a backup. On a production server, I will have such a backup but in my lab and on my PC-BSD desktop, I don’t.
My personal experiences of erasing the rc.conf are silly but they happened. Feel free to laugh but I have been using FreeBSD since 2001 (11 years as of the writing of this post) and each of these happened in lab environments or on my personal laptop where I was less careful and none of them ever happened on a production server.
- I accidentally ran a command that wiped it because I used > which overwrites the file, instead of >>, which appends to the file.
$ sudo echo ‘someapp_enable=”yes”‘ > /etc/rc.conf - PC-BSD wireless settings are written to the /etc/rc.conf file and once while managing my wireless settings, the system crashed, rebooted, and my /etc/rc.conf was empty.
- I once was going to delete the hosts file and add a new one and I am so used to typing /etc/rc.conf that I typed that instead of /etc/hosts. Oops!
$ rm -f /etc/rc.conf - While writing a script to update a setting in /etc/rc.conf, my script wiped it. Maybe the reason was similar to #1, maybe it was different, I don’t remember.
How to store settings in separate files on FreeBSD
If you do a quick read of the man 5 rc.conf, it will tell you that you can put setting in rc.conf, rc.conf.local, or in any filename residing in a folder called /etc/rc.conf.d and all these files can store settings.
Moving all your settings to rc.conf.local just moves the problem I described above, it doesn’t actually fix it, so I am not going to use that solution. However, using a separate file per setting in the /etc/rc.conf.d directory is quite a great idea.
Step 1 – Create the /etc/rc.conf.d directory
- Create a /etc/rc.conf.d directory:
# sudo mkdir /etc/rc.conf.d
Step 2 – Create a file to hold a setting
Example 1 – Hostname
- Create a file in /etc/rc.conf.d and name it hostname.
- Add the hostname=”SystemName.domain.tld” setting to the file.
Note: You can do both steps at the same time with one command:
# sudo echo ‘hostname=”SystemName.domain.tld”‘ > /etc/rc.conf.d/hostname
Example 2 – SSH
- Create a file in /etc/rc.conf.d and name it ssh.
- Add the sshd_enable=”YES” setting to the file.
Note: You can do both steps at the same time with one command:
# sudo echo ‘sshd_enable=”YES””‘ > /etc/rc.conf.d/ssh
Example 3 – Default Gateway
Yes, on FreeBSD the default route setting is called defaultrouter, not gateway or defaultroute as one would expect.
- Create a file in /etc/rc.conf.d and name it defaultrouter, or if you want to name it gateway or defaultroute.
- Add the defaultrouter=”192.168.0.1″ setting to the file.
Note: You can do both steps at the same time with one command:
# sudo echo ‘defaultrouter=”192.168.0.1″‘ > /etc/rc.conf.d/defaultroute
Conclusion
If you use the /etc/rc.conf.d file, then if you ever accidentally overwrite a file, it is not that hard to deal with because every setting is decoupled in its own file. You only lose one setting.
From now on, in my posts, I will tell likely suggest adding settings using a separate file in /etc/rc.conf.d.
Is was not working for me (FBSD 10.2), nothing under /etc/rc.conf.d was gets parsed
I tried to override the rc_conf_files variable on /etc/rc.conf without luck so I tried changing it on /etc/defaults/rc.conf (something that you never supposed to do)
Anyhow, the new value for rc_conf_files is:
rc_conf_files="/etc/rc.conf /etc/rc.conf.d/* /etc/rc.conf.local"
risky but it worked!!!
The idea of separating your settings into a directory as file-names gives me that warm fuzzy feeling of isolation which FreeBSD does such a good job at! Thanks for the idea I am going to give this a try instead of having on big bloated file readily available for removal by epic failure or user error. 🙂
Great post and idea. Keep up the great work.