-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Shawn Wells wrote: > Hi Patrick, > > I thought I'd take the chance to respond to this, publicly, since I > haven't seen any other threads. >
... >> *) Integration to the Z platform >> > 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. > Thanks Brad, and Shawn! A couple of other notes about s390 integration, since I didn't want to put everything in my first message: *) mkinitrd mkinitrd in SuSE is notably more convenient, in two ways. One s390 specific way, and one architecture neutral way: +) It automagically pulls the current list of activated DASD channel numbers, and includes those in the ramdisk image it builds for activation at next IPL. No forgetting to edit /etc/modules.conf when extending a machine with more DASD. +) It automagically builds a initrd for every installed kernel in /boot, unless given just a specific kernel by command line options. Not having mandatory options for mkinitrd is sweet. *) Device management It's convenient and easy in YaST to, for example, bring a new DASD online, dasdfmt it, partition it, and add it to a volume group. But using system-config-lvm? Not so easy. In fact, the information it displays is outright incorrect. Enough so that I'm quite adverse to trying to use it and messing things up. On one machine, for example, it shows /dev/dasdc under the list of "Uninitialized entities", despite the fact that /dev/dasdc1 is a active PVM in an active volume group. I can't comment on other device types, e.g. qeth devices, because we do those so infrequently in comparison. > 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/ I mostly use google. Sometimes google points out an article in kbase or Novell's support center. Sometimes I get a good hit on a blog or email list archive. Of course typing "system-config<tab><tab>" at a terminal gives you a list of installed configuration tools, but you have to be taught to do that in the first place. On the flip side, a real strength of AIX's SMIT and SMITTY administration tools compared to YaST is that they show you exactly what they are changing and what commands they're running. Would it really be so hard to throw a "--show-action" flag on the system-config toolchain, and a simple GUI front end on top of them? *) Another addition to my list, but one I didn't talk about in comparison was documentation. Here I have to comment that for new Redhat facilities the documentation is often missing or incomplete. For example, when RHEL 5 first hit I set up a test host to mess around with Xen virtualization. The RHEL 5 Virtualization manual was flat out incorrect in what the packaged management tools could do -- there was a bunch of unimplemented functionality that the manuals none-the-less documented. Ditto trying to figure out the new LVM based software mirroring. The documentation was mostly just plain missing when the feature was released, and still pretty damn sparse and hard to find and use even today. Ditto again when I was trying to prototype Redhat Satellite here this last spring. We had our local customer rep come and help us do the install, and he ended up spending considerable time on the phone and internal chat channels to redhat engineers getting our setup running. To be fair to Marc, who did really yeoman duty for us, we were installing into a Xen virt when that was not explicitly listed as being supported. Never the less the errors were obscure, confusing, and mysterious. That's a bit beyond the hope of mere mortals who have only public facing documentation to work from. The situations with virt management tools and satellite have both improved a lot over the past year, but my point is the problems when I first encountered them. > >> *) Updating / patching the system >> >> Here, Redhat really shines. >> > Why, thank you ;) One area where both Redhat and SLES need some work is in terms of putting out discrete, reversible patch sets. On Solaris and AIX both (been too long away from HP-UX to comment), it's easy to apply a coherent "Patchset Foo 20.3.5", and to roll that patchset out if needed. On e.g. redhat, if I say "yum update" for a dev box on monday of week 1, by the time I get through test and qa to production on friday of week 3, I'm applying different patches. And if any of them break, I'm forced to go back and by hand apply a few dozen or hundred point revision RPM's. Yes, Satellite is supposed to let you do this. Compared to other big *nix vendors though, that's pushing the patch packaging work onto me. > Perhaps an interesting project to you will be PackageKit > (http://www.packagekit.org/) which is in Fedora now, and should be in > RHEL6. I'll keep my eye on it. Thanks! > >> *) SELinux v. AppArmor >> > 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. > Unfortunately, I'm not sure it'll do any good. This may be because of my lack of understanding of SELinux but here's the scoop. As an example, our monitoring product installs a private JVM in it's install directory. It's the first install step, and it uses this private JVM to bootstrap the rest of it's install. As installed, the private JVM won't run, because it has relocatable shared library segments. So, in theory, I could "chcon chcon -t textrel_shlib_t" to apply a new label to a few libraries and go on, yes? The only problem is, restarting the tool's install process wipes and recreates the directory tree containing the private JVM, thus loosing the labels I just created. Catch 22. The only way around it with my limited knowledge appears to be to setenforce 0, install the product, then apply chcon, semanage fcontext (for the next IPL), setenforce 1, and relabel everything. And the vendors, when called, say "nope, sorry, selinux is unsupported, you'll have to turn it off." Grrr ... >> *) Extraneous crap in the distro > > 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. Thank you! I'll look at both of these. > > 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. Thank you again. We'll look at this. Right now, we're just "chkconfig yum-updated off". Why use the cpu, bandwidth and disk until the day or so before I know I'll do an update? > 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. > I really appreciate your response and feedback Shawn. Overall, I'm very happy with Redhat, and don't regret our decision to start migrating from SuSE. Nevertheless, I hope this helps both distros improve. A little competition is a good thing. :-) Happy Thanksgiving! - -- Pat -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJKtwMNObCqA8uBswRAm/KAJ9bCY9sp+/7A4UAI3wpyOsNGXJl1gCcDp/Z a6luAwHDAaJg1LkDApsNOXI= =LMRF -----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
