4

I haven't really got prior *nix systems experience to draw on, although I tried to set up a GUI based Linux some years back; this time I'm jumping directly to BSD because I like its philosophy and tight attention to quality and its resulting slightly conservative approach to release development cycles, and because I've got more experience with it than other *nix.

One area I'm really not confident about is tracking the config changes I set up. Everything config is a case of "edit /path/rc.things" or "add these lines to pkg-x.conf", or "set these variables in the environment or pkg". I'm comfortable with such directions; what bothers me is maintenance and reuse - how I track exactly what I changed as I was setting it up and as I use it, and keeping it easy for myself if I want to make those changes again in future on another system without 3 months of DIFFing every file in sight and reviewing line by line. I expect at first I'll have a lot of this, because I'll be learning from experience.

My aim is that if I want to set up a 2nd server with much of the system/pkg config similar or the same settings (as is common on a single LAN), or to backup, wipe and reinstall as part of my learning curve, or just to update the system, I don't really want a txt-file list I've kept, that lists 400 files with fragmented config on them, all to be laboriously manually re-created or to have multiple lines edited in console. I also won't want to just restore all files unthinkingly, or to find there are files which did contain config or other history/activity information that I didn't know about, or missing environment data, and spend forever trying to work out where stuff might be hidden that needs to be copied or edited in on the new system.

I'm not sure there is ever a truly easy solution to this (on any major OS) - even Windows with a GUI, I'd have to consider files and entries stored in all kinds of directories, registry branches, and so on. But at least I have many years trial-and-error with Windows so I have a good idea what to grab depending how the machine has been used and I can do it fairly quickly package by package. I know which packages I use, I can just reinstate its config directory or registry settings, and which I need to do via its GUI or some other way, and where there are useful system tweaks to add.

I also know in which cases it's safe to just copy a folder to reinstate my previous config or state, and in which cases it's best not to do that as other stuff needs to be set as well, and let the system/pkg do it the long way.

I don't have that know-fu on BSD yet.

On a positive note, I feel I have enough knowledge and experience to work out roughly what I need to do, as I do it, and to get a sense of enough of the security and good practices to not make a complete disaster of it - or I hope I do anyway. So using BSD hands-on is the only real way for me to learn, at this point.

How can I approach this area of BSD use/management, and what solutions do people who know BSD tend to ultimately end up using?

Put another way, how can I track, simplify, and reinstate settings in a less laborious or time-consuming manner (with a view to selective reinstatementwithout days of console file editing and diff-ing!), as I begin to move into using BSD properly, or what knowledge or pkgs will help if it's a matter of workflow and process?

2

A lot of the work can be isolated. There are a lot of the commonly edited files in /etc which can be mirrored in /usr/local/etc. Put your local changes in those, and generally they'll be picked up. rc.conf is a bit messy, but you can put one line in there to grab stuff from elsewhere. periodic.conf works in much the same way.
rc.d files (if any) can go in /usr/local/etc/rc.d, separating them from the system ones.

You don't have to edit syslog.conf or newsyslog.conf because you can use small files in /usr/local/etc/{newsyslog,syslog}.conf.d to do what you want. Copying over these directories is much easier than editing the original single files. There are various other directories that end in .d where you can put small files that are all executed as part of the original single file. Beware of syslog.conf.d. You have to end all the filenames in there with .conf or they are ignored!

There are also (for example, in /etc and /boot) files ending in .local. These include /boot/loader.conf.local. These are not nicely detached from the main system directories, but the fact that they are named like that makes them easier to notice and maintain.

If you have kernel configuration files, keep them in (say) /root/config. Then, before a buildkernel, make symbolic links to them in /sys/i386/conf (or wherever). Otherwise, an update to /usr/src will wipe them out - it's easier to recreate the symlink than it is to recreate (or even restore) the kernel config file.

Bear in mind that not all of these useful secondary files exist by default. That's why you have to look at manual pages for the 'main' files to see what alternatives are available.

In summary
For each of the files you find yourself editing, read its man page carefully. In most cases, you can edit or create a local file or put files in a local directory. This centralises nearly all of it under /usr/local/etc.

  • That would definitely make it a load easier! I'll try that! – Stilez Jul 9 '17 at 6:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.