Red Hat Network - Does It Need More Improvement? 18
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.
RHN is fine (Score:1)
Red Jat? (Score:1)
Re:Custom kernels (Score:2)
Some glitches with RHN (Score:4)
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.)
Unavailable from behind HTTP Proxy (Score:3)
Re:Some glitches with RHN (Score:2)
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. // regular version number comparison. you get the idea.
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 {
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.
Custom kernels (Score:3)
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 (Score:2)
caldera wrote volution you can run it on your own and it WORKS
http://www.caldera.com/products/volution/ [caldera.com]
try it out
regards
john jones
RHN and web support problems (Score:1)
I attempted to log in for web support as a registered user to ask if there were a workaround for this incompatibility, but when attempting to register the product it said "This product is already registered" and when attempting to fill out the support form, it never could figure out my product ID, so I had an empty select box and no way to request support. I tried off and on for about a week to submit a support request, but to no avail.
Apparently, if their web support request form doesn't work, you're somewhat out of luck, and I find this a bit disturbing. I wouldn't mind waiting awhile for an email response if there were an email address available in lieu of the form.
On the whole, I have never, ever, had nearly the problems with Debian's apt-get update/upgrade/install as I had with RedHat's up2date and the RHN, I'm sorry to say. I had really high hopes for it, and I will say that RH7 is a huge improvement over RH6. (Nice job, guys!) but while I got around these problems all right, I'm afraid for the new users who might run into these sorts of problems and be unable to fix them. The moral of the story: you still need to know how to compile source (at the least) to be really safe.
Upgrading from 7.0 to 7.1 through RHN (Score:1)
Otherwise it's been pretty nice. I've gotten several good security patches in a timely manner and it was quite painless.
Has anybody sucessfully upgraded from RH 7.0 to 7.1 through RHN? I'd like to switch to the new kernel and firewall, but I don't know how to tell it to use the 7.1 configuration instead of the 7.0.
- Mike
Hrm (Score:2)
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 (Score:2)
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 (Score:2)
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.
up2date really buggy... (Score:1)
Wonder how Progeny's Service Network will fare in comparison. Up2Date's bugginess drove me back to Debian within one week... a flaw on otherwise solid underpinnings IMHO.
Michel
Latest Release of RedHat (Score:1)
If it ain't broke...
Re:Upgrading from 7.0 to 7.1 through RHN (Score:1)
Re:volution (Score:2)
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. :>
I Always Disable RHN (Score:1)
Notice that when you install Redhat, the installer never explains what RHN is, nor does it give you a chance to say 'no, don't use this'. I see that and think that Redhat is trying to hide something in the package.
I also do not like how, short of either a recompile or polluting my DNS I can't make the RHN update from my server. If nothing else, from a bandwidth point of view, if I have 10,000 machines, I want to download the package from Redhat, test that package in a lab, then put it on my server internal to my network and have all 10,000 of my user's machines update from a local server as opposed to tying up my already skimpy bandwidth out to the Internet.
In a way, this package disappoints me because I like the Redhat distro. I like the way it handles, and when I'm putting a stealth box into the network, the Redhat name gives me credibility with PHBs, who are willing to trust my judgement and look the other way. If I had used just about any other distro, those PHBs would have been unplugging cables to keep the box off the network.
In summary, the package should have setup options during a normal installation that allow me to either use it with Redhat servers, use it with my own servers, or disable it. And there should be an easy to follow set of directions so that I can setup my own server on my network and run the update process from there.