Hi Patrick, I thought I'd take the chance to respond to this, publicly, since I haven't seen any other threads.
This note has been sent around internally to Red Hat to highlight *customer* feedback. Similar to any other company, the most change occurs when we can point to customers and show management that there are *other* people requesting/commenting on the same things. This has been great, thanks for sending the note out. Patrick Spinler wrote:
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.
The zipl issues were fixed and will be released in RHEL 5.3, https://bugzilla.redhat.com/show_bug.cgi?id=381201. Brad Hinson (who many people on this list know) was the champion of getting this pushed through.
*) 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.
Honestly, this may be more of a "sendmail vs postfix" issue than "SLES vs RHEL." But I am glad the process was easy.
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.
Out of curiosity, where do you (and ultimately, everyone else on the list) turn to for this information? Are you familiar with Red Hat's Knowledge Base (http://kbase.redhat.com) and Novell's support center (http://www.novell.com/support/microsites/microsite.do)? Always a good one is the Linux documentation project: http://tldp.org/
*) Updating / patching the system Here, Redhat really shines.
Why, thank you ;) Perhaps an interesting project to you will be PackageKit (http://www.packagekit.org/) which is in Fedora now, and should be in RHEL6. At its core it's an API to package management subsystems like yum, apt, and conary. The end goal is that package management tools can be written against the PackageKit API -- which means you'll be able to use the same tool across all platforms. While it may be a "Red Hat" project, it's truly based around an open source community -- not "just a RHEL thing." Check out the core contributors page (http://www.packagekit.org/pk-authors.html) and you'll notice openSUSE involvement in getting zypp integrated in! This will be a great tool when released.
*) 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 :-)
I'm pretty keen on hearing more about this. While switching your system into Strict or MLS mode _will unquestionably break things_, leaving it in the stock Targeted mode shouldn't be to much of a hassle. What apps did you run into problems with? If you're willing to send over your policy, I'd love to evaluate it and perhaps get it integrated into RHEL for other customers to take advantage of.
*) Extraneous crap in the distro Okay -- both of you. Please, turn off your crap. Not every machine needs to be running cups.
The amount of packages installed is completely customizable. Don't install cups if you don't need it. In RHEL you may want to evaluate if "Minimal" is a good choice for you. Don't know what I'm talking about? http://www-128.ibm.com/developerworks/eserver/library/es-rhel-coexist/rh3.jpg We've also gotten together with our friends in government circles and started to work on open source kickstarts that meet various standards. Some of the best ones I've seen are from Tresys through the CLIP project: http://oss.tresys.com/projects/clip Their kickstart locks things down to DoD standards, take a look at their package list (direct link: http://oss.tresys.com/projects/clip/chrome/site/files/rhel5.2/clip.ks) and eval it for your needs. It might be a bit strict, but could help you create your own template.
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.
The discussions around yum-updated have been long internally to RHT. I don't know what the history is there, other than I'm in no position to change it. And I do agree with you on that point, especially for enterprise servers. If you're interested, there are ways to make yum-updated a bit less evel. A good amount of customers prefer to have their systems *download* the package, but not *install* it. Saves them download time/bandwidth later when doing maintenance. ---------------------------------------- # vim /etc/yum/yum-updatesd.conf # how often to check for new updates (in seconds) # CHANGE THIS to your own value run_interval = 3600 # how often to allow checking on request (in seconds) # CHANGE THIS to your own value updaterefresh = 600 # automatically install updates do_update _*= no*_ # automatically download updates do_download *= yes* # automatically download deps of updates do_download_deps *= yes* ----------------------------------------
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.
That's outstanding to hear. To me your rant has been useful, as it allows us to point our finger at a customer and show engineering things need to be changed. Your note has actually been passed to our entire engineering department -- which is what brought it to my attention -- for discussion.
Hope this helps some other folks looking at the same things we were.
Was interesting to me. Cheers, Shawn -- Shawn D. Wells W/W Lead, Linux on System z Team Lead, Linux on System z SMEs [EMAIL PROTECTED] http://www.redhat.com/z/ ---------------------------------------------------------------------- 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
