[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Savannah-hackers-public] Savannah VM system upgrades
From: |
Bob Proulx |
Subject: |
Re: [Savannah-hackers-public] Savannah VM system upgrades |
Date: |
Sun, 10 Mar 2013 18:19:49 -0600 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
Karl Berry wrote in the other message:
> I think mgt might be the closest to savannah-hackers and the furthest
> from the public and therefore I propose that we upgrade it first.
>
> Also sounds good to me.
Sounds good. Will upgrade mgt first and then decide what to do next.
> When would be a good time to perform this upgrade?
>
> I don't think it really matters, assuming downtime is basically a matter
> of a reboot. (Especially for mgt.)
A VM should boot very quickly. As a risk management I will coordinate
with sysadmin just in case something goes really bad and it needs a
rescue. I don't expect that to be needed. But just in case.
> I would suggest posting a news item so users have a chance of knowing
> what is going on. https://savannah.gnu.org/news/?group=administration
Okay. I see that there hasn't been a news posting there since May 2012.
> How long of a waiting time for major events such as this should we
> have between posting a proposal for action and then performing the
> action?
>
> Once Michael confirms, you're good :). Otherwise ... a few days
> at least?
I would want to do this during daylight sysadmin hours too. Same
thing with the firewall rule changes too. Just in case.
> Other comments?
>
> Do you have any sense of what breakage might ensue from the upgrade?
I don't expect any breakage. But examples of past breakage would be
those /etc/init.d/* scripts that I just posted about fixing because
they were locally added but didn't have LSB headers. Without those
the system tool 'insserv' could not determine how to make the symlinks
and order the boot. Since we hit those a couple of times already
there might be another VM or two with a problem like that lurking. If
the machine hasn't been rebooted since those were installed then the
reboot path for them won't have been tested. And we all know the
truism of untested code. It is why I like to reboot first before
making major changes.
I already fixed mgt for these. But I can't predict any other problems
beyond those similar to the past ones. I can only do my best looking
at things going in and react to them as they occur.
I will also look for packages that contain obsolete conffiles
especially any leaving files behind in /etc/init.d since those can be
troublesome due to missing LSB headers. And will look for held
packages and try to understand why and to clean them up if I see them
too. Plus I will look for old/new conffiles '*.dpkg-*' and '*.ucf-*'
in /etc and clean those up both before to start clean so that any left
are from this upgrade. And then look afterward to leave it clean for
next time.
But since I expect that the Savannah Hackers all do reasonable things
then I don't expect any breakage. :-) Missing LSB headers in init
scripts is kind'a a common gotcha that I have seen everywhere since
those have newly appeared on the scene as required. Minor in the
grand scheme of things.
But not expecting any breakage doesn't mean there won't be any. Must
plan for problems regardless.
I always worry about the possibility that someone has compiled in
custom Apache modules that might be disconnected by the Apache upgrade
and need to be rebuilt. But so far haven't hit any. (No Rails
Phusion installed that I can see for example.)
> What will the new version be?
The current Debian Stable "Squeeze" point release version is 6.0.7.
> Is there a super-high-top-level NEWS-ish list for each Debian
> release?
Since the latest on the VMs is 6.0.2 it means we have missed the last
five point releases and if you are interested in the changes then all
of those would need to be examined. And for frontend the first two
point releases as well.
Remember that there isn't any change in functionality. These are all
considered Debian 6.0. These are security patches for the most part.
Along with other things that are considered safe but important enough
to backport into the release branch. We will be picking up the last
two year's of security upgrades all at once. Here are the individual
release notes for the ones we will be getting.
http://www.debian.org/News/2013/20130223 6.0.7 released
http://www.debian.org/News/2012/20120929 6.0.6 released
http://www.debian.org/News/2012/20120512 6.0.5 released
http://www.debian.org/News/2012/20120128 6.0.4 released
http://www.debian.org/News/2011/20111008 6.0.3 released
http://www.debian.org/News/2011/20110625 6.0.2 released
http://www.debian.org/News/2011/20110319 6.0.1 released
Bob