[nycbug-talk] upgrading openbsd
okan at demirmen.com
Tue Apr 25 22:48:07 EDT 2006
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
> 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
> 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
> Below, like master.passwd, should I check if there are *new* cron jobs,
> or whack it?
> 8. rm new_etc/var/cron/tabs/root
i suspect you've made decisions on others too, e.g.
but yea, pre/post scripts are very handy, even for some of the other
things people have mention, e.g. rcs/cvs/version control
More information about the talk