Richard, Valuable information, thank you! I'm going to discuss this further, if you don't mind. After all, a main selling point of Linux on the mainframe is leveraging the time and skill of our administrators. If we don't find ways of sharing packages we install among members of the Linux farm then we're not likely to make as much progress in this area as we could!
Imagine how nice it would be if RPM had a "hierarchy of data bases" in which it searched for prerequisites and co-requisites. When creating large farms of servers the so-called "master RPM data base" would have all the information about all the distributor-supplied packages which were installed on the system, plus any security patches which were recently applied. Then each individual server in the farm, which used the master server's disks in R/O, would be able to see that: - a package was installed already. That's good, no need to waste disk space reinstalling. - a package was serviced. That's good, all the needed security patches are installed too! This is a big selling point for running Linux on mainframes! Do the work once and leverage it over and over again. However, each server in the farm has unique needs. So each user (owner) will want to install add-ons as needed. RPM would, in my scheme, keep a second data base updated (let's call it the "user's RPM data base"). Because RPM searches the master DB first and the user DB second, the tool still knows what's installed and most importantly, when things are refreshed. Certainly I could have given each server a copy of the original RPM data base, but over time that get's "stale", as it doesn't know about any patches recently installed. I can imagine that there could be times that installing a new level of (for example) Apache might imply that other packages have to be updated, in lock-step. (IE: when Apache isn't backward compatible. Perhaps an unlikely example, but let's go with it.) And that could mean that me, as owner of the master RPM data base and R/O disks need to take special effort to help my users prepare for upgrades. I think that could be handled. Does this sound like a helpful idea? -----Original Message----- From: Richard Hitt [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 06, 2003 5:15 PM To: [EMAIL PROTECTED] Subject: Re: RPM Data Bases and Sharing Linux Disks Hi, William The rpm database is nominally in /var/lib/rpm, if I'm not mistaken. An unprivileged user should trivially be able to change this to his own directory, by making a ~/.rpmmacros file and adding to it a %_dbpath value. See /usr/lib/rpm/macros, in which you'll find: %_dbpath ${_var}/lib/rpm That said, I don't at all see that the two rpm databases (the system's and an unprivileged user's) could possibly share information, but at least now you know where rpm configuration parameters reside and how you can override them. Richard Hitt [EMAIL PROTECTED] Scully, William wrote: >I apologize for the long note. But this topic may be of particular interest to those >of you hoping to create vast "farms" of Linux servers. And of particular interest if >you hope to manage the software on these farms effectively. > >I've been reviewing the excellent document Linux on IBM eServer zSeries and S/390: >Large Scale Linux Deployment, SG24-6824-00, in the hopes of using some of the >techniques described there to create a farm of servers which share the maximum amount >of directories in R/O mode. One objective is to allow an owner of a Linux server to >install a package, using RPM, on their own server. Perhaps a copy of our >locally-developed software; perhaps something the user needs or wants that they found >on the Internet. Another objective is to be able to have me (or one of my peers) >install security fixes or upgrade packages once, and see those updates on all the >other servers. > >It seems in order to update a package that I'll need to keep strict R/W control over >the RPM data base. After all that's how I know what's installed and what's been >patched. But if an end-user wants to install a package, they too will need to >interrogate and update the RPM data base. As I understand it there's only one RPM >data base. > >This seems to be hard to solve. The authors of the Red Book mentioned above suggests >that SPEC files can be used to force (ask?) that a separate RPM data base be used. >That is, there would be one RPM data base for my work and another RPM data base for >whatever the user did. However this presumes that whomever is installing the package >knows (probably) a lot more about the nuances of RPM than may be practical, in real >life. > >What might make this easier to handle is the ability, somehow, to merge two RPM data >bases. Then, as I perform service on or added packages to the "base" Linux system, I >would somehow "refresh" each user's copy of the RPM data base with what's current >from mine. (Let's gloss over some obvious gotcha's about this, like what if the user >installed THE first, then I installed it; who's entry to keep?) Does anyone know if >this is possible (the merging of data bases)? > >Any other techniques you've found to be helpful would be appreciated, if you'd >mention them here. > >William P. Scully >Systems Programmer >Computer Associates International, Inc >2291 Wood Oak Drive >Unit 5-29C >Herndon, Virginia 20171 > >Work: +1 703 708 3976 > >[EMAIL PROTECTED] > > > >
