Patrick Spinler wrote:
-----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!
Thanks to Brad on that one. I didn't play any role in it ;)
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.
Good idea. I opened a Feature Request for this @
https://enterprise.redhat.com/issue-tracker/?module=issues&action=view&tid=242519
(IT 242519). We'll see what engineering says re: how hard this would be
to implement. Since the code is already in SLES, it *might* just be a
matter of taking it & putting it through Red Hat QA. We'll see.
+) 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.
Submitted Red Hat Issue Tracker #242520
https://enterprise.redhat.com/issue-tracker/?module=issues&action=view&tid=242520
*) 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.
Actually, Red Hat & IBM have been working on this one.
IBM LTC 201690
Red Hat BugZilla 463184 (https://bugzilla.redhat.com/show_bug.cgi?id=463184)
1. Feature Overview:
Feature Id: [201690]
a. Name of Feature: Installer - FCP LUN discovery tool
b. Feature Description
This feature should exploit the functionality to discover the LUNs on the
Storage System for a given
FCP adapter and WWPN, integrating the LUNs discovered as a drop down list
(combobox) in the SCSI
configuration dialog, so that the customer does not have to manually give it.
3. Business Case
These changes will improve the installation experience for customers by making
the installation
workflow more usable and efficient, which will result on an improvement of the
customer
satisfaction. Without this feature is the input of a 64bit value in Hex (=16
characters) not so so
usable and can produce errors and frustration for the customer.
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.
I understand this, but I also think it's part of learning a new
operating system. Just like when you get into a new car you must find
the blinkers, head lights, seat adjust, etc. Similar, but a little
different in each one.
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?
I don't see why it couldn't be. I'll look into this some more. In
theory it'd be easy enough to send something through logger to
/var/log/system-config-* or /var/log/messages.
*) 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.
It's a recognized problem. We've actually changed how some of the
documentation & release notes are done.
When a developer signs off/finalizes a patch they get prompted for a
release notes comment. When we perform our builds only BugZillas with
the completed release notes get pulled in, ensuring that anything
included has some documentation.
As for the RHEL guides, we've hired a few (I don't know how many, could
just be 1-2) doc writers to professionalize our guides. Many changes
were made to the RHEL 5.2 docs, even more coming in 5.3. One of the
things I like best is the automated "what changed" doc:
http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.2/html/Package_Manifest/index.html
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.
Look for a RHN Satellite Starter Kit late Q1
*) 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.
Since you have Satellite, the easiest way to accomplish that would be
through Satellite Channels. You could snapshot "RHEL 5.1," RHEL 4.3,"
etc and only allow systems to upgrade against that release. I can talk
about this more off list if you want.
If there's enough interest, I'll volunteer myself to give a RHN
Satellite Webinar to those on this list.
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 ...
Reference the SELinux note I sent out. Essentially you can use
"semanage" to only disable SELinux protections for certain label types.
If your label type is "textrel_shlib_t", you could do:
# semanage permissive -a textrel_shlib_t
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?
Nothing more than personal preference.
Imagine if you have 400 systems you need to patch by tomorrow morning,
and you only have a slow link up to your patch server. Do you really
want all 400 systems connecting to your update server at once? By
having the packages locally, you could just to a "yum update httpd" and
be done with it.
Having the systems iteratively check for updates, say every other day,
is more ideal for _some_ people.
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. :-)
I'd say it did start the process to improvement. As a direct result of
your EMail I've opened up two feature requests -- we'll see how those
progress. We've already missed the cut off for RHEL 5.3, so we'd be
looking at RHEL 5.5 or (worst case) RHEL6.
-Shawn
----------------------------------------------------------------------
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
