On Saturday 08 February 2003 06:46 am, you wrote: > This is a magnificent idea. I started having trouble with the multiple rpm > database situation about a year ago and posted it to this list. Looks like > the situation hasn't changed much since then. If we could just have rpm > search one shared global rpm database and one local rpm database (with all > local updates being added to the local database and the global database > being the local database for the master server), that would solve all my > problems. > > The only problem I can see is getting Red Hat to create and implement the > new standard. rpm does, after all, stand for "RedHat Package Manaager".
Well, someone could code it and post it at sourceforge, unc or some other Linux/Free/Open Source Software site, and wait until Red Hat wakes up and smells the coffee. Even they can't argue with satisfied customers. Wesley Parish > > They say there are three signs of stress in your life. You eat too much > junk food, you drive too fast and you veg out in front of the TV. Who are > they kidding? That sounds like a perfect day to me! Gordon Wolfe, Ph.D. > (425)865-5940 > VM & Linux Servers and Storage, The Boeing Company > > > ---------- > > From: Scully, William > > Reply To: Linux on 390 Port > > Sent: Friday, February 7, 2003 6:34 AM > > To: [EMAIL PROTECTED] > > Subject: Re: RPM Data Bases and Sharing Linux Disks > > > > 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] -- Mau e ki, "He aha te mea nui?" You ask, "What is the most important thing?" Maku e ki, "He tangata, he tangata, he tangata." I reply, "It is people, it is people, it is people."
