Tuesday 16 August 2005 10:39 am, Will H. Backman wrote:
I'm looking for comments on the care and feeding of BSD servers.
Essentially and "best practices" document for maintaining BSD
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 BSD?

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
PENBSD_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 BSD. 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 BSD 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

Forgot to cc

16/08/05, Edd Barrett <vext01 (AT) gmail (DOT) comwrote:
Upgrading packages now easier with
new pkg options, but how do you know when packages are updated?

This file contains all the package listing. Perhaps write a script
which diffs and checks to see if you have the pkg installed?

Regards

Edd

8/16/05, Will H. Backman <whb (AT) ceimaine (DOT) orgwrote:
1. Change Management: Many changes are logged by the daily insecurity
report, but not all.

in /etc/changelist you can add any file which needs to be tracked. but you
will not change very much on a production server.

2. Disaster Recovery: Dump and Restore, or make a tar file for use as
an install set?

make a release for every upgrade (-stable) you do, add your packages
to sitexx.tgz. backup your data and config files regularly.

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.

set up a cron job for those

What if XF4 was not chosen at install and
not needed?

don't set the cron job for XF4, or have a file which tells you, what
you need and wrap your cvs up in a shell script

How do we know if we need to rebuild kernel and reboot or
not?

shell script. if the cvs output contains lines which start with 'P' or
'U' (forgot one?), rebuild. if the are lines starting with 'C' you
don't want to build, of course.

personally, I want to know when my servers reboot, so I won't automate
a reboot at all. check, whether your build went fine an schedule a
reboot for the next night, or do it manually.

Upgrading packages now easier with
new pkg options, but how do you know when packages are updated?

the is a rss feed at vuxml.org. more complete, check
I do upgrades only, if I must. if
your setup has interacting packages, you rather don't want to break
anything by changed behaviour of upgraded packages. at least, while
upgrading packages manually during a complete system upgrade (3.5 ->
3.7), this happened to me. (e.g. cyrus-sasl-2.1.13 -2.1.20 changes
the configuration slightly for my ldap setup)

4. Version Upgrades: This will usually happen once a year given the life
cycle of BSD. 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.

if there are no reasons against (e.g. a.out -ELF), a binary upgrade
will be rather painless.

sorry, replying to my own posting.

you will find some interesting thoughts on server maintenance on
www.infrastructures.org.

8/17/05, knitti <knitti (AT) gmail (DOT) comwrote:
8/16/05, Will H. Backman <whb (AT) ceimaine (DOT) orgwrote:
2. Disaster Recovery: Dump and Restore, or make a tar file for use as
an install set?

make a release for every upgrade (-stable) you do, add your packages
to sitexx.tgz. backup your data and config files regularly.

forgot to say: restore via install of your release and restore your backup.

personally, I want to know when my servers reboot, so I won't automate
a reboot at all. check, whether your build went fine an schedule a
reboot for the next night, or do it manually.

this of course depends, what your servers are like, and how many you have.
if you have a couple of very different installations, it's probably
easier/safer
to do some things manually. if you have identical servers, it makes sense
to automate things. you have just to make reasonably sure, that every step
before the reboot really does yield the result you expect to proceed.

8/16/05, Will H. Backman <whb (AT) ceimaine (DOT) orgwrote:
I'm looking for comments on the care and feeding of BSD servers.
Essentially and "best practices" document for maintaining BSD
production servers. Yes, "best" is a stupid way to describe anything,
but I'm hoping that there is some consensus in the community.

0. Whenever you make a change to the system, write it what you did, and *why*.

:)
-- ach

Hello!

Tue, Aug 16, 2005 at 11:36:42AM -0400, Timothy Donahue wrote:
>[]

>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.

IIRC the kernel doesn't use anything to build not contained in
/usr/src/sys, so I think no new kernel needed for /usr/src/lib changes.

>[]

Kind regards,

Hannah.