On 8/16/05, Will H. Backman <[EMAIL PROTECTED]> wrote:
> 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
http://openbsd.org/pkg-stable.html. 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 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.

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


--knitti

Reply via email to