http://lists.debian.org/debian-security-announce/debian-security-announce-20...
Patches available for 2.4.18
2.4.23 and 2.6.0-test6 onwards are unaffected.
On Tuesday 02 Dec 2003 9:33 pm, Wayne Stallwood wrote:
http://lists.debian.org/debian-security-announce/debian-security-announce-2 003/msg00212.html
Patches available for 2.4.18
2.4.23 and 2.6.0-test6 onwards are unaffected.
Incidently, what are people's policies in terms of rolling out software upgrades on servers? I'm admining several Debian machines in the US, and several more in the UK. Be a pain to get to the UK ones but I can be there within a few hours. The US ones I have to rely on remote hands (who are nice enough people but you never want to rely on such people under any circumstances).
I have a box on the office LAN purely to ensure software stability (named, appropriately, 'stable'), installed only last week to organise software rollouts, plus a development LAN server which was recently "sanitised" with the stable machine's software (Debian stable, plus individual newer version software compiled to /opt). Our current workload involves testing and synchronising our UK servers to our stable machine's software specs before doing so on the US ones, and the new kernel will be another step.
Just wondering what else happens "out in the field", knowing how ALUGers tend to be Debian geezers used to getting moaned at for having an "ancient PHP version" installed or something. Never a good idea to develop policies in-house without some experience from elsewhere IMHO.
Experiences welcomed.
Cheers James
James Green wrote:
On Tuesday 02 Dec 2003 9:33 pm, Wayne Stallwood wrote:
http://lists.debian.org/debian-security-announce/debian-security-announce-2 003/msg00212.html
Patches available for 2.4.18
2.4.23 and 2.6.0-test6 onwards are unaffected.
Incidently, what are people's policies in terms of rolling out software upgrades on servers? I'm admining several Debian machines in the US, and several more in the UK. Be a pain to get to the UK ones but I can be there within a few hours. The US ones I have to rely on remote hands (who are nice enough people but you never want to rely on such people under any circumstances).
At some stage you have to take a punt and go for it, but we try to keep all our servers as consistent with each other as possible. We roll out on a test-bed, and if happy/process documented, we roll out on the live boxes. Security updates take priority, of course. It's worked so far, which is just as well as our client base, whilst predominantly within 25 miles of Ipswich, is from Hampshire to Northamptonshire and lots in between...
The only time it went pear-shaped was when grub updated and on boot it failed. We didn't test a reboot... The fix was easy, didn't require a reboot, and the machine that died was in our own server room...
Let's not talk about the latest apache 1.3 update from Gentoo. Grrr...
Cheers, Laurie.
On 2003-12-02 22:48:04 +0000 James Green jg@jmkg.net wrote:
Incidently, what are people's policies in terms of rolling out software upgrades on servers?
Generally, I test them nearby and then roll them out to remote sites fairly quickly if they don't break. Most of the debian machines track stable, so it's very rare that there's a problem. Kernels are a different matter. I upgrade them as soon as possible, but when I know there's some expert near enough for physical access in reasonable time.
I think changing network settings is the only other thing I treat differently. After Paul Russell's suggestion, I generally start a process that will restore the previous settings, timed for after the changes should be completed. If it works and I still have access, then it's cancelled again. Sometimes that's even a reboot. You really don't want a trip to a machine just because you downed/blocked the network interfaces.
This seems to be an underdocumented topic. I guess it's difficult to give good advice on this. You can find the security upgrade policies of some ISPs online and what you pick as a policy depends on your situation and priorities.