[nycbug-talk] upgrading openbsd

[Okan Demirmen]

On Sun 2006.04.23 at 13:49 -0400, michael wrote:
> I frequently keep pretty up-to-date snapshots running on some of my
> OpenBSD boxes.  Even though mergemaster is not in base, I use it to
> update the etc files after an upgrade.  To make this process easier, I
> tend to trim the new tree before merging.  Example.. on two of the
> boxes I will *never* run a web server, so, I `rm -r new_etc/var/www`
> before I even start.  Anyone who upgrades OpenBSD knows this saves gobs
> of keystrokes.
> 
> Merging is usually pretty easy because I don't edit system files; e.g.
> rc.conf is a system file where rc.conf.local is mine, so mergemaster
> doesn't touch it. But, to save time (and potential fat-finger), I'm
> thinking of trimming the new tree even more before merging. Here is a
> potential list of whacks. Is there any danger in this approach?

not really - i have host-specific $MM_PRE_COMPARE_SCRIPT scripts.

one thing i do different is still update the configs/docs for services i
do not use - maybe that's a bit pedantic, but i try to keep everything
sync'd, just in case i need to enable something, somewhere...

> On some boxes where I run Postfix rather than Sendmail:
> 
> 1. rm new_etc/etc/mail/*

ok - i don't run postfix, so who knows...

> 2. rm new_etc/etc/mailer.conf

why? remember that by default, mergemaster will compare cvs tags; in the
file, or format, ever changes, you'll want to know. where's the harm in
letting mergemaster delete it for you?

> Below, should I check if some new process requires a new user, or whack
> it? I have it on this list because don't want to clobber this file by
> accident.
> 
> 3. rm new_etc/etc/master.passwd

humans are an issue, i agree ;) i delete it myself, but then again i
typically know if something changes in there from listening on the
appropriate mailing lists.

> Below, these I don't want to change or don't really need an update.
> 
> 4. rm new_etc/etc/motd
> 5. rm new_etc/etc/myname

check, check

> 6. rm new_etc/etc/pf.conf

again, cvs tag never changes, unless something really does change.
(though sometime the example are updated ;)

> 7. rm new_etc/etc/sudoers

check

> Below, like master.passwd, should I check if there are *new* cron jobs,
> or whack it?
> 
> 8. rm new_etc/var/cron/tabs/root

ok

i suspect you've made decisions on others too, e.g.
$TEMPROOT/var/mail/root

but yea, pre/post scripts are very handy, even for some of the other
things people have mention, e.g. rcs/cvs/version control

cheers,
okan