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]
