On 15/06/09 16:16, Dr Andrew C Aitchison wrote:
> What do other groups do about updating applications and machines
> with long running processes ?
> 
> My users run two sorts of long running processes, with different
> problems when it comes to updates.
> 
> First, I have users who never log off. Thus applications like
> firefox and pdf viewers will be running when they are updated.
> Some time later these applications may try to load and run plugins
> which have been removed/updated.
> 
> Second, I have users with long running calculations (often weeks
> or more) which would be interrupted if the machine were rebooted into 
> an updated kernel. User-writing code often check-points, so the 
> actual calculation time lost is not significant, but calculations in
> commercial packages such as Mathematica and Maple are often less good 
> about check-pointing.
> 
> How do people balance the disruption of killing user processes
> against the need to update to the latest versions of software ?

depends to some degree to which your users are trusted (i.e. can become
"root" easily) - most updates are security fixes in SL. In general:

 * network-visible service open to attack: typically no reboot required,
and users don't tend to notice if the service has to be restarted.
Otherwise is high risk, i.e. would allow for automatic remote attacks,
so would beat the "usability" argument anytime.

 * user-assisted exploits (firefox crapping out on an "evil" page,
PDF/flash/.. exploit-once-you-get-a-bad-doc). Impact depends a lot on
you user behaviour, and impact of a compromised account, and your
ability to detect a compromised account.. but most people would not
claim that a firefox crash (i.e. if the thing is trying to load a
non-existing library) is production-critical, so in case of doubt roll
out the update. A Ubuntu-style "now would be a good time to restart your
browser"-alert would be nice but is not critical.

 * local kernel exploits - could be anything between highly critical
(lot of "untrusted" users on a machine - always consider that some of
your accounts will have been compromised!) to irrelevant (1 local user
only that has "sudo" and the root password and full console access
anyway so can root the box whenever so desired).

In doubt, I'd patch.. Especially if you are working (part-time but
officially) as a sysadmin - in that case your work responsibility might
lean more to the "keep it secure"-side than on the "make it work
(insecurely)"-direction. Of course, you want to do proper announcing and
perhaps some kind of beta-test period for really crucial services, just
to cover your^Hexposure.

just my 0.02.
jan