Date: Tue, 8 Jun 2004 12:30:02 -0400 From: Bill Moran <wmoran@potentialtech.com> To: Peter Risdon <peter@circlesquared.com> Cc: freebsd-questions@freebsd.org Subject: Re: Wisdom of automating upgrades Message-ID: <20040608123002.1619a20b.wmoran@potentialtech.com> In-Reply-To: <40C5E71F.6010702@circlesquared.com> References: <40C5BCAC.6090401@circlesquared.com> <20040608102534.63e0259b.wmoran@potentialtech.com> <40C5E71F.6010702@circlesquared.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Risdon <peter@circlesquared.com> wrote: > Bill Moran wrote: > > >Peter Risdon <peter@circlesquared.com> wrote: > > > >>cvsup'ing overnight is routine and fine. > >> > >>The make build/install stuff seems a bit more delicate. I'm happy that I > >>have figured out how to automate this, but not _whether_ I should do so. > >>I am of course only considering tracking RELENG_4 at this stage. > > > >Why not just cvsup/buildworld/buildkernel nightly, and monitor the FreeBSD > >security advisory list. When a security problem is found, you only have to > >installworld/installkernel, which is usually pretty quick. > > Yes, it is. That's a good compromise. Watching the other posts, I would suggest another compromise as well: track RELENG_4_10, not RELENG_4. Much more conservative commit policy. When (if?) 4.11 comes out, you should expect a careful, manual switch from the RELENG_4_10 branch to the RELENG_4_11 branch. I've been doing this since 4.7? and have had very few problems. But, occasionally, there are significant changes between a point release. > >>Ports are perhaps more likely to be problematic (though less likely to > >>be a blocker to remote fixing than a failure to boot). > >> > >Install portaudit, which will include nightly audits of port problems in your > >daily run email. This takes the guesswork out of when to upgrade. By cvsupping > >the ports nightly, you only have to run portupgrade to get things updated. > > > >Because of the dependencies in ports (which can get rather complex) I wouldn't > >recommend automatically doing much with ports. > > If something in the dependency tree is broken or is imperfectly handled > without manual intervention, the upgrade process stops short of > deinstalling the existing port. I _was_ going to comment on this, but you beat me to the punch ;) This is a fantastic feature of portupgrade, which makes the package an incredible tool! > A more severe problem would occur when a configuration file format > changes, or there's deprecation and replacement. This is the greater concern, and one that I doubt if portupgrade can address. This bit me not too long ago, because of the migration of a lot of ports to rcng ... without a <portname>_enable="YES" line in /etc/rc.conf, a lot of the ports I upgraded didn't start after upgrading. Not a big deal, but a subtle warning to be careful of config changes in ports! > Perhaps I should say I'm pretty sure full automation would be unwise. I agree. As I said before, big companies don't even automate the Windows Update process, because (despite Microsoft's claims) doing so has bit them in the past. > It > isn't unobvious and if it hasn't yet been done there's probably a reason > for it. I'm trying to get a handle on what that is and to what extent > solutions such as the one you suggested above can be used. Good luck. I highly recommend portaudit! At least you know when it's time to do things. -- Bill Moran Potential Technologies http://www.potentialtech.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040608123002.1619a20b.wmoran>