Domain: kaybee.org
Stories and comments across the archive that link to kaybee.org.
Comments · 11
-
autorpmwhat is RPMs answer to dselect
-
Re:More than just US$9.95"Nix gurus" don't necessarily have time to check for, download, and install every single RPM.
What kind of a Unix guru doesn't script this process? It's really just a matter of grabbing any updates in Redhat's 'updates/(versionnumber)/(arch)' and 'updates/(versionnumber)/noarch' directories and then applying an 'rpm -F (downloaded rpms)'. Not necessarily doable by the stereotypical RedHat user, but certainly not a problem for a Unix guru.
I've even got my own ugly, ugly, homebrew, hacked-up solution that, while not 100% automated, lets me do an update (for my desktop machine and all 3 servers) in the background with only ~30 seconds of manual intervention. Automating the last little bit wouldn't be too much harder.
The fact that RedHat's charging money for such a service amazes me. I understand that they provide value, I understand that it costs them money to provide this value, and I wish them the best of luck at making a buck, but it seems that their business model in this case can be devasted by someone willing to do a bit of scripting. Even Kirk Bauer's autorpm provides a free alternative (that has existed since before RedHat's update agent.
There're two things that I can think of that make RedHat's business model potentially viable:
- Lack of information - John Q. User will probably go with the quick-and-easy update process that's readily visible after installing RedHat.
- Priority updates - RedHat could hypothetically decide to offer updates via the update agent service before they're available via FTP. Depending on how this gets done, it could be delibrate (such as it appearing on the update agent a week before FTP) or just an artifact of bandwidth and priority (it may appear on the FTP site as soon as the update agent starts pushing, but connection limits and mirroring delays may mean it's not readily available until a day or two later).
-
Dependencies, Databases, and GUIs..oh my...So is it safe to say, the problem seem to have with the whole RPM vs apt-get is the ease of installing packages with the behind the scene or hiddent installation of dependent packages?
I am sure that in both cases, that it is possible with either some switch settings or additional step somewhere.
I was wondering if the possibility of having a unified database for the packages might be reasonable, maybe an XML/RDF based database which then both apt-get and RPM can use mutally.
I was wondering if some of the concerns of those that aren't big fans of RPM are to use gnorpm and/or Redhat's Up2date. They seem to have some nice GUI aspects that make installing packages a little easier as well as providing for the ability to identify and install needed dependencies like apt-get does.
Or maybe some other tools like Auto Update or AutoRPM
Also would use of the package transalation tools like alien help in the two working together?
I think one of the concerns over all the recent hits on many of the distributions, which was one of the weaknesses in the Standard Linux projects has been inconsistant packaging. Perhaps, combining the projects may be beneficial to both parties so that other innovations and work can be done elsewhere.
BreezyGuy -
Re:Too true.
6.2 was annoyingly unstable
eh? .. works fine for me.
GNOME kept crashing
Did ya get the latest GNOME RPMS? .. and what crashed GNOME?
I couldn't makefile anything,
You what? .. you mean you couldn't compile anything? .. egcs works and has worked fine for me for ages.. you don't say what you had problems with..
smbclient wouldn't logon to my Win2K tower,
Did you get the latest SAMBA RPMS? .. and did you read the SAMBA FAQ? :)
et cetera, et cetera. I just got sick of it fast.
Sorry you had that experience.. 6.2 has been running great for me. I of course keep all the packages that I use up to date .. and that's good enough for me. Not like that takes a long time either with autorpm from Kirk Bauer .. just run it as often as you like and that'll help you keep things up to date. It's all nice and simple IMHO.
-- -
Re:Why Debian is So Great...
The update system that can upgrade every package on the system with just two commands (apt-get update; apt-get upgrade). For busy people that don't have time to pore over every single update notice that comes in the mail or gets posted on the Web, that's worth a black-market price right there.
AutoRPM offers similar functionality for RPM based systems like Red Hat. You can for example use the AutoRPM to check the updated packages daily from the Red Hat ftp site (or from mirror sites). AutoRPM can then update the packages automagically.
-
Re:Interesting precedent- poor default configurati
You get them from RetHat's site. Using a machine that is secure. And put them on a floppy. Duh.
Admittedly, RedHat (and other vendors) could make this easier on novice users. For example, during the install they could, leaving all services disabled, go to the RedHat site and get the latest security updates.
Until then, y'all should check out Kirk Bauer's AutoRPM, which is an excellent way to keep your systems up to date. It runs from cron, letting you know what has been updated. And it will optionally install the goods for you, even checking signatures first. -
Uh... AutoRPM.
Uh, there's AutoRPM. There's also Symantec's LiveUpdate feature. And let's not forget Lotus Notes replication (which does code, not just data, y'all).
That's off the top of my head. And that's just ones using the public Internet that have UIs that ask users what they want to do. I daresay, this is no different from what most automated file mirroring and ASD (automated software distribution) systems do. Computer Associates, Tivoli and a few other companies I can think of will have something to say about this. A look at the legal status screen makes it appear they already have. -
Also look at autorpmAn update tool that I have been using for a long time is autorpm. It works very well and you do not have to pay for RedHat's up2date service.
Alternatively, if you have a fast internet connection, just download all of the updates and do a "rpm -f *.rpm".
-
Re:Files all over
Hmm. That sounds like a lot of work, especially for a home network.
I guess the initial goal would be to design the network such that the other machines get updated from a central one, (or they all mirror each other in some way) or put all the important stuff on the networked drives.
I'm sure there are software packages that could help you out here. I'd probably do something funky with locate and cron, but maybe something like AutoRPM would work better.
---
pb Reply or e-mail; don't vaguely moderate. -
Re:My Opinion
Yes, there is -- they're calling it the RedHat Update Agent, and its main job seems to be to perform RPM upgrades automatically as they become available. It's hardly new, and if ZDnet had done any research (they read the HOWTOs, and Apache's security docs, and ignored the rest), they might have found it. AutoRPM has been in common usage for quite a while now -- it's a nifty little app that picks up the updates from FTP, NFS mount, etc., checks the PGP signatures, and installs the upgrades, then notifies you that it happened so you can check its work. Closes the vulnerability gap a bit.
-
Re:How about automatical critical updates?
You might also have a system that automatically checks these critical updates and alerts the sysadmin, offering to automatically install the update.
You mean autorpm? It does all this if you want it to. I'm running it on some of our `Corporate' workstations in `scan and report' mode. I do NOT use the `autoupdate' feature, since I like to keep a tab on what gets installed/updated. It has given me warning within a (/etc/cron.daily) moment of updated packages ever since.