-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hey all: We made the decision earlier this year to consolidate all our linux penguins to a single distribution, both to simplify our support and licensing, and concentrate our expertise. We decided to migrate our Z SLES penguins to Redhat rather than our distributed penguins to SLES mostly as a matter of effort. We have about the same numbers of distributed and virtual penguins, and it's a lot lot easier to clone a replacement redhat image on Z than reinstall a distributed box with SLES. This also means a lot less app downtime, since both the old SLES and new RHEL boxes can be running on Z without a lot of extra effort while the app migrates. So, round about now, we've had a number of months of working with both SLES and RHEL side by side on Z, and I have a few observations about what it's like to administer each one. *) Integration to the Z platform SLES is pretty clearly ahead of the game here. Generally not by huge leaps and bounds, but noticeably. For example, when adding more dasd to an image, "mkinitrd && zipl" suffices on sles to insure that the new dasd will be brought online the next time the image is IPL'd. On rhel, similar to the way sles 8 used to work, you have to manually edit /etc/modprobe.conf before running mkinitrd, and mkinitrd doesn't default any of the arguments. Additionally, we edit /etc/zipl.conf to enable a boot menu with an added single user mode boot option, to aid in system recovery. On redhat, zipl fails to recognize the "defaultmenu=" option, and it must be specified by "zipl -m ..." on the command line. On suse, this just works. *) GUI v Text mode administration No doubt about it YaST is a great tool for gui oriented admins, or admins who may just not remember what exactly to do at that moment. The flip side is it's sometimes awkward to administer the system outside of YaST. For example, at the request of our mail team, we wanted to adjust the relayhost / smarthost setting on our all our boxes. On SuSE, it took quite some doing to discover I had to edit /etc/sysconfig/postfix, and not just /etc/postfix/main.cf. I tried the latter, but found YaST (really SuSEconfig, running under yast) complained incessantly. On redhat, a quick edit of "/etc/mail/sendmail.mc", followed by a "make && service sendmail reload" and I was done. In general, SuSE is a more strongly GUI'ish system, and Redhat is heavily command line, with individual GUI tools if you happen to know how to find them. *) Updating / patching the system Here, Redhat really shines. Last week friday, I patched 8 SLES systems from 10.1 to 10.2 -- it took nearly 6 hours. YaST online_update was slow as heck, had to be run, rerun, and run yet again, and kept popping up annoying dialogs mid-update I had to answer before it'd continue. It was a nightmare. Eventually, it got a little easier when I remembered I could run "zypper update" from the command line, but even that I had to run and re-run, I still needed to run yast online_update once to select the "migrate to 10.2" package I couldn't find using zypper, and I still had to answer specious y/n questions. And where the heck did "zypper" come from, anyway? SuSE, Can't you just use "yum" or "apt" or something like all the other distros? Seems like another case of pointless functionality duplication. And one that's not all that well documented to boot. On redhat this last monday? I upgraded 9 systems from 5.1 to 5.2. One command: "yum update". Walk away. Get coffee. Come back 30 minutes later, and all 8 machines are done and ready to re-ipl. Dear heaven what a contrast. Interestingly, *both* distros trashed our custom zipl bootmenu. SuSE just plain erased our single user boot selection. Redhat added a "default=(newest_kernel_image)" to zipl.conf, which didn't work, since zipl errors with both a "default=" and "defaultmenu=" option in the file. *) Getting support We have both IBM support and Redhat support. Generally call IBM with anything Z related, whither redhat or suse, and I haven't noted a significant difference in response from IBM favoring either side. I've never called Novell / SuSE support directly, so I can't really compare Redhat v. Novell. Sorry. :-S *) Available software in distro Redhat seems to be the winner here. It has a number of things than suse for instance subversion and a wider selection of perl modules. *) SELinux v. AppArmor APPArmor just hasn't gotten in our way so far. Go SuSE. On the other hand, something that's been a big adjustment - SELinux in redhat 5. It seems like none of the vendors out there support running under SELinux. For example, for both our monitoring product and backup solution I've had to craft custom SELinux policy exceptions. I don't really blame Redhat for this, but I'm pissed as all h*** at the vendors. Follow me on this as I descend into ranting for the rest of this post, or perhaps not, to preserve your sanity :-) <3rd party vendor rant> Okay, redhat 5's been out for what, 10 months or so now? Redhat 4, which also had SELinux, but only in warning mode, was out for like 2 years before Redhat 5 was released? What in the snark have you 3rd party vendors been *doing* all this time? If you say you're going to support bloody Redhat, don't you think that taking the nearly 3 years available until now to adopt to the coming of SELinux, a standard Redhat feature, might be advisable? Going without support for this huge change in how the system operates for nearly 3 years shows an inexcusable lack of attention for my platform. How am I supposed to believe that your product support is adequate for me again? Oh yea, and the same goes for firewall rules. Telling me to just turn off two major subsystems is not support. Personally, if these products weren't mandated by my it management, I'd toss 'em and go with working replacements. </rant> *) Extraneous crap in the distro This one's all rant. The gist of which is my pet peeve regarding installing extra crap, especially auto-update or update tracking services. Read at your own risk. <distro rant> Okay -- both of you. Please, turn off your crap. Not every machine needs to be running cups. In particular, "zmd" is a bandwith and cpu wasting pig which has caused us so many problems we now kill it with extreme prejudice where ever we can find it. "yum-updated" isn't quite as bad, but still qualifies as evil. Actually, let me make this point strongly. No, distro makers - WE DON'T WANT OUR SYSTEMS TO AUTO UPDATE! This is a 24x7 highly available setup, with tight change control. Running a daemon to tell me what's out of date is pointless, because I won't make a change based on that. Changes are a big deal, and need testing, paperwork, and considerable work. That's why we run predictable and scheduled bi-annual maintenance and patch cycles. Running a daemon which automagically updates stuff is even worse. This is not my workstation or home computer. This is a data center. Stop trying to hold my hand about this -- we hire professional administrators for a reason. Have the tools there -- fine and good. Automatically assume all systems must run the tool -- severely broken. </rant off> So, overall, it's not been a huge effort to migrate from SLES to RHEL. It is different, and definitely more command line, but not so completely foreign that we feel it to be broken or impossible. Hope this helps some other folks looking at the same things we were. - -- Pat -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJHRDZNObCqA8uBswRAp3IAKCCwmYP0nnRLUgC+/rxr3OZmdUA0QCffPJz +EZHB01jW3ADc3qcAZwCh7A= =XaWg -----END PGP SIGNATURE----- ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
