Wisdom of automating upgrades

[Bill Moran]

Peter Risdon <peter at circlesquared.com> wrote:

> Bill Moran wrote:
> 
> >Peter Risdon <peter at 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