Current Mood: anxious

Which, as many people know, is not easily upgradeable.

Dude... what crack are you smoking?

If you can't upgrade a RedHat box, you shouldn't be a Linux sysadmin.

You fucking put the CD in the drive and press "upgrade." That's one of RedHat's strengths... none of this "apt-get" or "emerge" bullshit (which... before you say anything, think about why Cal Poly is using RedHat in the first place...)

I wouldn't recommend upgrading to 8.0 yet, though; 7.x (where x < 3) -> 7.3 should be a cinch.

If you can't upgrade a RedHat box, you shouldn't be a Linux sysadmin.

Dude...if you want to disagree/debate, fine. I'd love to hear your (substantive, well-thought-out) views on Redhat, and why it's better than Debian/Gentoo/<insert distro here>. Throwing insults around is just mean/stupid and doesn't add anything to the discussion.

You fucking put the CD in the drive and press "upgrade."

Do you know what happened the last time I tried that with Redhat? The system got completely fubared, because rpm screwed up. Libraries ended up with the wrong versions, and pretty much nothing (including ls) would execute. I had to wipe and reload everything.

Perhaps they've gotten better in recent versions...I haven't tried Red Carpet (or had anything to do with Redhat past 7.2), so who knows.

Have you done upgrades at all? What version of Redhat are you using and what kernel are you running?

That's one of RedHat's strengths... none of this "apt-get" or "emerge" bullshit

You call that a "strength"? I certainly don't...I consider it a weakness. I think it's stupid that you have to wait for the next release (which could take months) before you can get system updates. I also don't like the fact that I have to take the whole system down just to do an upgrade.

One of the big advantages to Open Source is the rapid development/release cycle...if there's a bug at noon on a given day, chances are it will be patched and released by distros like Gentoo by 4 PM the same day. (Case in point: The recent CVS vulerability.) Redhat can't do that, because the infrastructure (a la apt/portage) just isn't there. With Redhat, if there's a security update, you get to manually download/install the affected RPMs yourself (and hope there aren't any dependency conflicts), or wait for the next release, which could be months away.

True, Red Carpet (is that still just a Ximian thing? I don't even know...) automates this process, but that's a paid subscription service. If you don't give Redhat your $x/month, you're out of luck as far as easy updating is concerned. Now, perhaps MDS is willing to foot the bill for that...but why pay when you can get the same functionality for free from Debian/Gentoo?

(which... before you say anything, think about why Cal Poly is using RedHat in the first place...)

It could also something to do with the fact that it comes installed by default on Dell PowerEdge Linux servers.

However, assuming they actively thought about it (I don't know one way or the other), I suspect they're using it because (a) it's relatively mainstream, and (b) they can get support for it. However, since they're looking for a sysadmin, it's pretty clear that they're not talking to Redhat for support (since part of the job description is documenting simple tasks like adding user accounts), and they weren't thinking too much about upgradability/maintainability (since they're still running Redhat 7).

I wouldn't recommend upgrading to 8.0 yet, though; 7.x (where x < 3) -> 7.3 should be a cinch.

Does 7.x (I don't even know what the latest 7. version is...3 I think) support the 2.4 kernel? I'd like to be able to use iptables and grsecurity, if possible.

Chances are (if I get the job), I'm going to keep it a Redhat system and upgrade it (pain though it may be)...but if the upgrade doesn't work for whatever reason, I need to consider other options.

So, let me ask you this...if I have a Redhat system that I want to upgrade, without taking it down (except for a reboot to switch to a 2.4 kernel, which takes much less time than rebooting to the CD and doing the updates), how would I do that?

It could also something to do with the fact that it comes installed by default on Dell PowerEdge Linux servers.

This should be:

It could have something to do with the fact that it comes installed by default...

It used to be "could also have", but I deleted the wrong word. Meh.

I'd love to hear your (substantive, well-thought-out) views on Redhat, and why it's better than Debian/Gentoo/<insert distro here>

I'm not going to have a discussion with you on it if you claim things I never said. This isn't about which distro is better; this is about being able to do something really simple in what one might call the most bone-headed distribution of all (Mandrake counts, too).

Do you know what happened the last time I tried that with Redhat? The system got completely fubared, because rpm screwed up.

I'm sorry, but then you did something wrong. I've never had an upgrade, where RedHat is installed and working on the box, fsck up on me.

Have you done upgrades at all?

I originally installed RedHat 4.2, back in 1996 or so.

I've upgraded from that to 5.0, then 5.1, followed by 5.2 and 6.0. Then I got a new drive, so 6.1 was installed fresh, followed by 6.2. That 6.2 stayed around for a long time and was eventually upgraded to 7.2. 7.3 was installed fresh (new drive) again. Considering RedHat releases about every 6 months, I think that's a pretty good record.

So yes. I have upgraded.

And 7.x has always run the 2.4 kernel.

With Redhat, if there's a security update, you get to manually download/install the affected RPMs yourself (and hope there aren't any dependency conflicts), or wait for the next release, which could be months away.

This is bullshit, which I'm not even going to respond to. How you got hired to run a RedHat server when you obviously don't even know how to handle security updates is beyond me.

Now, perhaps MDS is willing to foot the bill for that...but why pay when you can get the same functionality for free from Debian/Gentoo?

You can get it free for personal use, IIRC. I don't actually use automated update processes because I care about what happens to my system; I actually like to know when it updates dependencies, what version it's updating them to, and what it's doing. Last time I tried apt, it got confused and sat there in a loop, trying to update dependencies that were dependant on each other. Needless to say, I was not impressed.

Is Debian certified to run Oracle? Show me Gentoo's common criteria rating.

See, the thing you don't get is RedHat is popular among the corporate set and institutions like Cal Poly because the institution can rely on a company for support. They can't rely on some open source developer fixing some critical bug in CVS four times before they get it right while they're down for fix v.1, 2, and 3.

However, since they're looking for a sysadmin, it's pretty clear that they're not talking to Redhat for support (since part of the job description is documenting simple tasks like adding user accounts), and they weren't thinking too much about upgradability/maintainability (since they're still running Redhat 7).

This line of logic shows you know nothing about how institutions work. Now, I don't necessarily agree with "how institutions work," but that's how they do things; just because they hire you doesn't mean that the institution thinks it's ok for you to make decision that will void a $20,000 support contract 'cause you were trying to "be cool and just install this thing."

Does 7.x (I don't even know what the latest 7. version is...3 I think) support the 2.4 kernel? I'd like to be able to use iptables and grsecurity, if possible.

Has since 7.0. Maybe you should do some research on RedHat before you start calling it ass.

but if the upgrade doesn't work for whatever reason, I need to consider other options.

If you can't figure it out, I'll be seriously disappointed in your abilities as a sysadmin. Now don't get me wrong... I don't think you actually give a shit, and really, I don't really care that much either. But if you can get RedHat 7.x to upgrade to 7.3 without horking things up... ...

And I suspect MDS will be the same; I can see it now: "You wanna install Gen-what? Ok; where do we get a support contract for it? Is it certified to run RealAudio's streaming server? No? Then you can't install it? Oh, you already did without asking us? Nice. You're fired."

I'm sorry, but then you did something wrong. I've never had an upgrade, where RedHat is installed and working on the box, fsck up on me.

Uhm, no. I was running RedHat 6.0, under a pretty standard install. Everything was working just fine. I stick the 6.2 CD in, boot, push "Upgrade". It does its thing, I reboot, and everything is fscked up. Everything was peachy beforehand, and broken afterwards. I never did a RedHat upgrade again.

I don't actually use automated update processes because I care about what happens to my system; I actually like to know when it updates dependencies, what version it's updating them to, and what it's doing.

In Gentoo, emerge -p tells you all you need to know. I agree with you...I like to know what's going on. Gentoo tells me exactly what's going on, and what's more, it doesn't screw around with my files in /etc...it creates a ._* file with the changes, which I can merge in using either the etc-update utility, or manually.

just because they hire you doesn't mean that the institution thinks it's ok for you to make decision that will void a $20,000 support contract 'cause you were trying to "be cool and just install this thing."

Uh, no shit. Where did I say anything about screwing around with the main server before talking to my supervisor? I'm not that naieve, and I actually do understand something about how educational institutions work.

Maybe you should do some research on RedHat before you start calling it ass.

I've done all the research I need...I used it from 5.2 up through 7.2 before finally getting frustrated and switching to Debian. Just because I happen to forget which kernel the 7.0 series uses doesn't mean I don't know anything about the distro.

Now don't get me wrong... I don't think you actually give a shit, and really, I don't really care that much either.

Pretty much. It's been a fun flamewar, though. :)

And I suspect MDS will be the same; I can see it now: "You wanna install Gen-what? Ok; where do we get a support contract for it? Is it certified to run RealAudio's streaming server? No? Then you can't install it? Oh, you already did without asking us? Nice. You're fired."

Except I'm not stupid enough to screw around with their main server without first (a) doing it on the development server, and (b) talking to my supervisor. So I'm not particularly worried about this possibility. Before you assume I'm stupid, you might want to check first. :p

So, let me ask you this...if I have a Redhat system that I want to upgrade, without taking it down (except for a reboot to switch to a 2.4 kernel, which takes much less time than rebooting to the CD and doing the updates), how would I do that?

You don't.

And you know... that's ok. Just because Gentoo can do it doesn't mean it's OK if RedHat doesn't. RPM existed... what... in 1995?!

You just need to accept the fact that RedHat, and its distrubtion's mission, are different than Gentoo's and maybe even Debian's.

And... that's ok.

You know... I re-read this now, and I think to myself "I'm kinda being harsh on him." I realize that. There are a lot of reasons for that, and this is mostly a flame war, in the great tradition of flame wars that don't mean anything.

But it took me many years to understand how institutional situations like this play themselves out; and the fact that you would even consider installing Gentoo tells me you haven't learned those lessons yet; I just hope you learn them before you do something stupid because you wanted to do it and you thought it was "better," all without talking to the people that pay your salary, first.

You don't.

And to me, that is bad pie, because it means downtime.

RPM existed... what... in 1995?!

So? All that means is, RPM is old. It says nothing about RPM's comparative ability or suitability to a particular problem as compared to Apt or Portage.

You know... I re-read this now, and I think to myself "I'm kinda being harsh on him." I realize that. There are a lot of reasons for that, and this is mostly a flame war, in the great tradition of flame wars that don't mean anything.

Yeah, well, I expect that from you. So no worries. As I've said before, much better to have a friend who will bite your head of when he thinks you're doing something wrong, than to have a friend who will sit there silently and let you screw up.

Besides, flame wars just for the hell of it are fun. :)

But it took me many years to understand how institutional situations like this play themselves out; and the fact that you would even consider installing Gentoo tells me you haven't learned those lessons yet;

I think you've jumped ahead a bit here, for several reasons. First, I worked (volunteered) in an institutional situation for 3 years maintaining the main web and email server for my high school. Teachers actually used their webpages for things like coursework...so if something went down, we had angry teachers on the phone usually within a couple of hours.

The main difference between that and Cal Poly is that "back in the day", there weren't really any established things like "support contracts" in the Linux world. Redhat may have had something then, but nobody at my HS was aware of it, and even if they were, they sure as hell didn't have the money to pay for it.

The whole rationale behind using something like Gentoo or Debian is to minimize downtime, while keeping things secure and up-to-date. IMO it's harder to do that with Redhat than it is with the other distributions.

I just hope you learn them before you do something stupid because you wanted to do it and you thought it was "better," all without talking to the people that pay your salary, first.

Whoa, back up there. Nobody said anything about running off and screwing around with the server without talking to supervisors, thinking it through, and testing it on the devel server first. The whole point of this is to minimize downtime and provide a useful service, not to do cool and funky stuff with Linux distros.