Do we need this crap on LWN?
Do we need this crap on LWN?
Posted Feb 22, 2007 16:41 UTC (Thu) by markc (guest, #4419)In reply to: Do we need this crap on LWN? by pizza
Parent article: ESR's goodbye note
> Stick the CD in, it boots up. That's anaconda.
Great, but not on a dedicated host 10,000 miles away.
> You're confusing "The RPM tools" with "The Debian
> Packaging Guidelines as implemented using the dpkg
> tools". Get your comparison straight.
I think I'm comparing the use of any number of (unfamiliar to me) rpm
tools with apt-get where the later seems to have the edge... which is the
point that ESR seems to have finally stumbled upon in the head article.
> "RPM-based folks" are apparently missing out on a
> lot of remote exploits and possible filesystem corruption!
Some would argue it's not appropriate to have such file system checking
built in to a package management system.
http://packages.debian.org/cgi-bin/search_packages.pl?key...
> I don't give two hoots about SERVER uptime; to me
> SERVICE uptime is all-important, and I achieve
> that with redundancy and performing test upgrades
> on non-critical systems in advance.
Dare I suggest that if you used a Debian based distro you could go live
and stay live with less redundancy and pre-testing. My example of swapping
between 4 deb based distros on an el-cheapo commodity $15/month VPS
without losing any downtime was intentional. No redundancy or testing
needed, just good software, especially on the barest metal.
Posted Feb 22, 2007 17:18 UTC (Thu)
by pizza (subscriber, #46)
[Link]
>Some would argue it's not appropriate to have such file system checking
No; I was referring to the fact that you can't fsck a live filesystem, and that it's an unfortunate fact of life that filesystems are at best only as reliable as the disks they run on -- errors silently happen.
For me, periodic reboots serve two purposes -- Perform filesystem consistency checks, and install updated kernels (I am quite glad the 2.6.x.y series exists!)
It's more commonly known as scheduled preventative maintainence, and through the use of multiple physical systems, I avoid service downtime. (Even with virtualization, the host system needs occasional TLC too!)
> Dare I suggest that if you used a Debian based distro you could go live and stay live with less redundancy and pre-testing.
Been there, done that, been burnt by it. As I've alluded to many times in my posts here, it's the policies that you follow that ultimately matter. I discovered the hard way that using Debian didn't make things any simpler for me -- It just had a different set of quirks to watch out for.
Granted, this was a few years back, and Debian has addressed quite a few of the problems I had at the time... but as I've also said, if I don't see any tangible benefit to making a change, why bother?
Posted Feb 22, 2007 20:01 UTC (Thu)
by bojan (subscriber, #14302)
[Link] (3 responses)
You missed the unattended upgrade bit above. The one with kickstart.
Let me repeat again. This particular limitation (of not being able to upgrade CentOS 3 to CentOS 4 while running) has nothing to do with RPM. It has to do with the fact that CentOS 4 (i.e. RHEL4) uses udev and CentOS 3 (i.e. RHEL3) uses a dev package. When dev gets removed by upgrading to udev, your system is hosed (you have nothing left in /dev).
Otherwise, I've done plenty of hot upgrades by doing "yum upgrade" on many different versions of Fedora.
> which is the point that ESR seems to have finally stumbled upon in the head article
He stumbled upon his on inability to manage his own system and/or ask others how to do it.
Posted Feb 22, 2007 20:15 UTC (Thu)
by loening (guest, #174)
[Link]
On a workstation that sits 300 miles away from me that I haven't seen in years.
Posted Feb 25, 2007 14:54 UTC (Sun)
by smurf (subscriber, #17840)
[Link] (1 responses)
You can mount a tempfs onto /mnt/whatever, create the bare essential device nodes there, move-mount that to /dev, and start up udev. (In fact, this is how a udev-based system boots in the first place.)
Total downtime for programs attempting to open /dev/null (or whatever): Zero.
Afterwards, if you do want to remove the old /dev-supplying package, well ... RPM has a --justdb option.
Posted Feb 26, 2007 4:27 UTC (Mon)
by bojan (subscriber, #14302)
[Link]
Well, if you run "yum upgrade", it is a fact that that's is what's going to happen: upgrade to udev will remove dev, which will remove all entries in /dev.
As you explained, it is not necessarily what needs to happen - but it does by default. So, unless you're prepared for some creative surgery (as per you explanation), you will get screwed.
Coming back the original question of supported upgrades from CentOS 3 to 4 (or RHEL 3 to 4), it is obviuos why this is not a recommeded thing to do - people don't normally want to recommend a complicated and risky process that would in the end require a reboot anyway (new kernel). RHEL packages were designed to be upgraded using the upgrade process, not "yum upgrade" (remember: RHEL 3 and 4 don't even ship yum, it's a CentOS addition).
You can find some more info here (search for udev):
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manu...
Note how you have to be on 2.6 kernel before starting this. CentOS 3 (i.e. RHEL 3) is based on 2.4 kernel.
Instead, one cuts a small kickstart file, starts an upgrade and after some minutes has a fully upgraded system with far less risk of stuffing things up.
>> "RPM-based folks" are apparently missing out on aDo we need this crap on LWN?
>> lot of remote exploits and possible filesystem corruption!
>built in to a package management system.
> Great, but not on a dedicated host 10,000 miles away.Do we need this crap on LWN?
Speaking of remote upgrades with RPM. I personally have doneDo we need this crap on LWN?
RH8->RH9->FC1->FC2->FC3->FC4->FC5->FC6
So please enlighten us poor souls who have *no*idea* why you'd need to "clean out" /dev when moving to an udev-based system. Why not leave the old package-supplying-/dev-nodes installed?dev => udev
> why you'd need to "clean out" /dev when moving to an udev-based systemdev => udev