On Tuesday 16 August 2005 10:39 am, Will H. Backman wrote: > I'm looking for comments on the care and feeding of OpenBSD servers. > Essentially and "best practices" document for maintaining OpenBSD > production servers. Yes, "best" is a stupid way to describe anything, > but I'm hoping that there is some consensus in the community. > > 1. Change Management: Many changes are logged by the daily insecurity > report, but not all. Perhaps altroot can help with backing out changes. > Does anyone have experience with cfengine on OpenBSD?
Use cvs to keep track of your configuration files or 'echo NameofFileThatNeedsToBeTracked >> /etc/changelist'. See also man 5 changelist or man 1 cvs. > > 2. Disaster Recovery: Dump and Restore, or make a tar file for use as > an install set? For our mail servers, we created a site37.tgz to get the base software packages installed. For the configuration files, we make a weekly tar backup that gets written to CD or to tape. The site37.tgz gets most of the system installed and running, then we restore the servers latest config file backup to finish the restore. > 3. Tracking Stable: I'm assuming that production servers should follow > stable patch branch. Perhaps use a make file to automate these steps? > Check out src, XF4, ports. What if XF4 was not chosen at install and > not needed? How do we know if we need to rebuild kernel and reboot or > not? Reboots should be minimized. Upgrading packages now easier with > new pkg options, but how do you know when packages are updated? I have the following line in my crontab '(/usr/src/ && cvs -q update -PAd -rOPENBSD_3_7)' If there are any updates, cron will email them to you (cron automattically emails any output to the user that owns the cron job, so setup your aliases and optionally your .forward file) As a general rule, if the update is in a library or in the /usr/src/sys folder then I build and install a new kernel then do a `make build`. If the change is in an application, then I skip the kernel. > 4. Version Upgrades: This will usually happen once a year given the life > cycle of OpenBSD. As far as I can tell, the best practice is to read > the upgrade FAQ that comes out with each release, and in general fresh > install with hand merging of old config files is preferred. FAQ 1.7. - "The OpenBSD team makes a new release every six months, with target release dates in May and November. " I use a binary upgrade, then I use mergemaster (/usr/ports/sysutils/ to merge the new changes into the old config files unless there is a good reason to just do a new install (ie. the a.out -> ELF transition). In the end, you should use which ever method you are more comfortable with? Tim Donahue
