Red Hat Network - Does It Need More Improvement?

irregular_hero asks: "I'm curious as to the experiences of other users about Redhat's much-publicized Red Jat Network support offering. I was initially impressed by the product, which seemed to offer a central console for application of updates. However, in recent weeks, I have become somewhat disillusioned with the service. This morning marked the 12th time I have been unable to even log on to the service in the past 2 months I have used it. I get various errors: 500 Server Errors, pauses of interminable length, and even empty pages. This morning, a new error occurred. Once logged in, all of my painstakingly prepared system profiles had disappeared. I can only hope that they will reappear soon." Sounds like there might still be a few bugs. Irregular_hero's bug-list continues, below. Have any of you found workarounds to these problems? Do you have others to add to the list?

"Still other things annoy me about the service:

• The RPM Update 'wait' screen that appears after you press the form button for the update does not work in Internet Explorer 5. (Yes, I know -- but there are administrators who are forced to use Windows desktops by the PHB types)
• Viewing package profiles seems to work when the managed machine is version 7.0, but not when it's 7.1. All fields in the 'package details' screen are blank.
• When manually adding a system profile, there is no option to select Redhat Linux 7.1 -- only 6.2 and 7.0. This is especially surprising since RHN is supposed to be a big plus to the 7.1 package.
• here is no way to view what update packages have been queued for delivery to each system. Conversely, there is no way to view a history of updates applied through the service.
• There is no way to apply a group of errata updates to all machines without navigating through multiple screens. This would be a big boon to admins who have to take care of a number of machines.
• You cannot group machines by function, geographical location, or ownership. This makes the update process difficult for administrators who have to update customers one at a time after first informing them.

Has anyone else experienced difficulty both accessing and using Red Hat Network? I certainly expect more from the service for my $19.95/month/machine subscription. Do you?"

Comments

Re:Custom kernels

[jd]

My apologies. That was what I was meaning.

Some glitches with RHN

[jd]

It -WON'T- work with glibc-2.2.3, from their Rawhide RPMs. Ok, sure, those are experimental, but since everything else (apart from Konquerer) worked just fine, it tells me that the problem is in RHN, not glibc.

Second, it's very limited. Sure, I can get the latest RPMs from Red Hat, but Ximian's "channel" idea seems much, much neater.

Third, it detects 3rd-party RPMs as "older" than their own RPMs, EVEN WHEN the 3rd-party RPMs have a greater version number. (Example: SGI's quota 3.01 is deemed "older" than RH's quota 3.00.)

Fourth, RHN =SHOULD= have some kind of flag for the Rawhide RPMS, simply to make life easier. It should be possible to upgrade to an experimental package as easily as a regular one. Otherwise, wide-spread testing on a wide range of environments becomes an interesting challange.

Fifth, Python was NOT a smart language to choose. The differences between 1.xx and 2.xx are just too big. Let the language settle down, before writing misison-critical stuff in it. (And I'd count updaters as "mission critical"! If they fail, there is absolutely no guarantee as to what state the system is in.)

Sixth, you really do need to be offering 3rd-party extensions, as well, maybe on a seperate list. RPMs for LM-Sensors, Berlin, XFS, JFS and AFS should be easy enough to build. (Maybe even add them to Rawhide, and offer them through a Rawhide list.) RPMs for glibc with IBM's PTh-NG extensions would be useful, too. Save on having overlapping packages, which is horrible.

Last, but not least, one addition I would =LOVE= to see -- custom kernel building. You've =got= the hardware list. You've =got= the latest sources. Ergo, you can build an optimal kernel for that user's setup, and offer it as a download. (If you compile everything as modules, first go around, and then a selection of skeletal kernels with various options, this shouldn't be difficult at all.) To make this a really "powerful" option, you could compile skeletons for vanilla Linux, ac Linux, SE Linux and MOSIX.

(Of course, the odds of anyone in Red Hat reading any of the posts on this Ask Slashdot are amazingly slim. Still, where there's life, there's hope.)

Re:Some glitches with RHN

[buysse]

Third, it detects 3rd-party RPMs as "older" than their own RPMs, EVEN WHEN the 3rd-party RPMs have a greater version number. (Example: SGI's quota 3.01 is deemed "older" than RH's quota 3.00.)

There's a simple explanation for this one. RPM includes a 'Epoch' key in the package. The 'version is higher' calculation goes like this.
if (packageA.epoch != packageB.epoch) { if (packageA.epoch > packageB.epoch) { install(packageA); } else { warnversion("packageB is newer than packageA, which you already have installed."); } } else { // regular version number comparison. you get the idea.

Don't blame RH for SGI's problem -- if SGI had wanted to make sure that their RPMS were overwritten, they should have set the epoch higher.

Unavailable from behind HTTP Proxy

[Chuck Milam]

Since my upgrade to RH 7.1, try as I might, I cannot get the RHN to work from behind a http proxy. Yes, I've set the http_proxy env variable and modified the appropriate files in /etc/sysconfig/rhn to reflect the correct proxy information. From home with a direct connection, I have no problems.

Custom kernels

[TBone]

They can't practically offer custom kernels - according to the discussion about the new kernel config stuff that is being written, there's something like 2 billion different confiugrations, and that's if there are no more additions to the config file. You're tlaking years to build all the possible configs.

What they can do, however, is build a kernel with _nothing_ compiled in, or minimal device (SCSI, Network, IDE, etc) which would limit the ketnel to maybe 50 variations. Then, compile EVERYTHING as a module, and based on your config, build an RPM with a certain kernel, and a modules.conf file. Not _quite_ a custom kernel, buit a custom-configured kernel.

volution

[johnjones]

please redhat is built useing the nortel thing and they have mereged with CTP alot of work and its closed buggy and they dont own the core

caldera wrote volution you can run it on your own and it WORKS

http://www.caldera.com/products/volution/

try it out

regards

john jones

Re:volution

[irregular_hero]

Volution is, no doubt, a lovely piece of work. The screenshots make one drool.

But it doesn't support either RedHat 7.0 or 7.1, and only supports certain other distributions if you replace certain components in them with Caldera Volution "Compatible" packages. For example, to manage a Mandrake 7.1 box from Volution, you have to replace the Mandrake version of apache with one that comes with the Volution install package.

Volution is also a proprietary package. At least the client pieces of RHN are available in source code form. Not that I'm above using proprietary software for management -- we've spent enough on Tivoli to fund the armies of several small countries -- but the idea of sticking to something I can vet is nice.

It's also almost useless for individual users who manage a number of machines for personal use only. There's a 60-day trial version available, but after that, you've got to buy it -- and it isn't cheap.

Then again, I suppose it's cheaper than RHN's $19.95/mo. per system over the long haul. But I don't expect Caldera would sell Volution to capital-cost poor individuals on a payment plan. :>

Hrm

[jfunk]

On top of all that, has *anyone* seen source code for RHN? Would you know where to get it? Legitimate question, I was looking for it a while back, but said screw it and wrote my own system.

Speaking of which, has anyone seen documentation for Red Hat's rpmlib.so for Python that is somewhat complete? I found one that was almost a year old, on a mailing list archive but it cuts off just before describing the "callback" argument for the run() function. Interestingly enough, if your callback isn't perfectly right, the program will segfault. No exceptions, nothing. In Python that is wrong, wrong, wrong. One of the major design goals was strong exception handling. Of course, when you're writing modules in C that means actually playing nice...

Oh well, enough ranting... I'm just annoyed by Red Hat's holier-than-thou Open Source stance, while pulling crap like this.

Possibly SSL-related

[devphil]

Same problem here. I found that by viewing the "console output" and watching the Python libraries complain, the problem seemed to be with SSL.

No idea, what, though. All it gave me was "Error 0," and when I reported this to RHN's bugs list, I got no response.

Update up2date manually

[Nailer]

I'd get SSL_Connect errors whenever I tried to do an update from a gateway machine. Updating up2date (and python-xmlrpc) manually fixed it.

What up2date *really* needs is a way to point it at third party, unsupported package repository (like freshrpms.net or falsehope.com) and use as a general software installer.