Networking change causes distribution headaches [LWN.net]

Networking change causes distribution headaches

Posted Oct 29, 2008 7:19 UTC (Wed) by jspaleta (subscriber, #50639) [Link]

No distributor enjoys having to deal with late breaking regressions leading up to a release.

For all the crap I give Canonical for other decisions, I'm not going to beat them up over a time-sensitive judgement call concerning a technical regression in the 11th hour 57th minute of their release cycle. I would not wish this sort of situation on distributor with a deadline to meet. They were pressed, they made a judgement call, a judgement call which hopefully insures that all installs have working network connectivity so all users can install updates as soon as the install is complete.

Distribution release processes...are painful. I think of it as akin to how child birth is depicted in older movies. Everytime the Fedora release team is in their final week during a release I feel like I need to be boiling water like you see anxious fathers being told to do by midwives... or something equally futile to stay out of releng's way (lwn posting might count). The release freeze process itself always causes a window of delay where security fixes can crop up that can't be included in the composed "release" tree without scrapping the whole compose process and starting over.

For whatever security implications the chosen quickfix has for Ubuntu users, hopefully Ubuntu will be able to put out a release day update to all users of 8.10 that addresses the issue which fixes the issue properly.

It's moot anyways, most people should be boycotting self-installing 8.10 at release anyways and purchasing it as part of a shiny new Dell pre-install to bolster pre-installed linux OEM demand statistics for this fiscal quarter. Dell will apply available updates for you as part of the pre-install.

-jef

Networking change causes distribution headaches

Posted Oct 29, 2008 7:45 UTC (Wed) by Cato (subscriber, #7643) [Link]

I agree about dealing with regressions like this - fixing the kernel in haste would probably have slipped the release date, and most people really don't need TCP timestamps, so it's fine for it to be fixed in a later update - people who do need timestamps (on long fat networks such as satellite links) can enable it quite easily after any routers have been fixed.

Most people should be running 8.04 not 8.10 in any case - as the first release after an LTS release, 8.10 is going to be more risky (hence the 'Intrepid', just like the 'Edgy' for 6.10).

I don't normally run a new Ubuntu release in production until a month or two has elapsed in any case.

Networking change causes distribution headaches

Posted Oct 29, 2008 14:56 UTC (Wed) by drag (subscriber, #31333) [Link]

THe problem is that if you install Ubuntu and your behind a buggy router then you may run into severe issues when trying to update your system.

In order to download the "fixed" kernel you need to be able to get on the Internet. If you can't get on the internet due to a "broken" kernel then how exactly are you suppose to solve your problem?

Catch-22.

The _only_ effective fix for Ubuntu, at this point, is to include the "fixed" kernel with the installer.

And I can understand if they can't pull it off. But it's going to suck for some people that they can't.

(Of course, I am fully aware that it's not Linux being broken, just the environment that Linux is expected to operate in has buggy network hardware sometimes)

Networking change causes distribution headaches

Posted Oct 29, 2008 15:00 UTC (Wed) by drag (subscriber, #31333) [Link]

*ooops*

that's what I get for not reading it to the end. They are a lot smarter then me, after all.

Networking change causes distribution headaches

Posted Oct 29, 2008 15:18 UTC (Wed) by TRS-80 (subscriber, #1804) [Link]

I disagree - the reason they had to resort to a workaround instead of applying the actual patch was because there wasn't enough time in their schedule to rebuild the kernel and installer between RC and release. In other words, the Ubuntu schedule made it impossible to fix any show-stopping kernel issue directly if found once the RC is built, which is clearly an avoidable problem.

Networking change causes distribution headaches

Posted Oct 29, 2008 15:40 UTC (Wed) by nevyn (subscriber, #33129) [Link]

For whatever security implications the chosen quickfix has for Ubuntu users, hopefully Ubuntu will be able to put out a release day update to all users of 8.10 that addresses the issue which fixes the issue properly.

Understandably you're thinking of rpm here and not dpkg, because dpkg has no was to do "installonly" type packages the kernel has the version in the name ... thus. there's no good way to say in procps "Requires: kernel >= 2.6.27-2". They might hack it by having a dep. from the fixed kernel on the newer procps, or they might release a procps later and assume noone will install that and use the GA kernel ... but they might just leave timestamps off for 8.10.

Personally it seems like they made a poor choice, but as you point out there are other more fundamental problems ... so this one is not high on the list, IMO.

Networking change causes distribution headaches

Posted Oct 29, 2008 17:06 UTC (Wed) by jspaleta (subscriber, #50639) [Link]

I'm not going to pretend that I have expert knowledge with regard to dpkg.

I can only assume that the Ubuntu release team thought this through and have the ability to push an update out that reverts the quick fix when a proper fix is available and tested.

If there are security implications for turning timestamping off, then intrepid Intrepid users should probably impress on the Ubuntu devs the importance of turning timestamping on as an update as soon as possible to limit exposure...in the appropriate Ubuntu communications channel.

I'm not going to falsely stand myself up as a network security expert and make a judgement on the validity of the security concern. Even if the security implications are a valid concern, I think its reasonable for Ubuntu to use the option of having a release day update available instead of having to restart their release process to incorporate the upstream fix. As long as a release day update addresses the security implications by turning timestamping back on and integrates the proper kernel patch for the routing regression, the exposure is mitigated to the level of any security issue which requires a post release update.

-jef

Posted Oct 29, 2008 23:43 UTC (Wed) by xoddam (subscriber, #2322) [Link]

> "Most people ... Dell pre-install".

Well yes. I did *ask* for it, but Dell for some reason still doesn't sell them in a whole heap of countries, so we simply chose a machine on which Ubuntu is sold pre-installed elsewhere, and installed it ourselves. I'd have chosen the version with Intel graphics (fully supported in free software), but that too isn't available here, so I have a fancy evil nvidia GPU, which luckily is documented to work fine with free-software drivers. And so it did, until I tried to resume after suspend-to-ram. No display.

How fortunate that Ubuntu makes it easy for me to "give up my freedom" and switch to the nasty source-free driver from the GPU maker. I intend to give some time to sorting out the suspend/resume problem with the nv developers (and/or the ubuntu xorg maintainers), but since it means a reboot every time it doesn't work, it will be a very time-consuming process and I couldn't use the machine for its intended purpose meanwhile. Which would annoy my employer, who paid for it.