"Michael Schloh" <[EMAIL PROTECTED]> writes: > On Wed, Mar 02, 2005, Simon J Mudd wrote: > > By mistake I installed a 2.3 over the top of a running /openpkg (2.2) > > losing the rpm database and thus all packaging information[1]. > > > Yes this can unfortunately happen with OpenPKG's rpm(1) and other Unix > tools like cpio(1) and tar(1). > > > I appear to have configured the 2.2 build with openpkg-r but the 2.3 > > without special users and am having permission problems reinstalling the > > packages with the old configuration files. I understand the problem but > > am unsure which permissions need fixing. > > If you have no backup of the old instance and can't remember which packages > were installed before, then your chances of a sucessful restoration are low.
Luckily the only part of the old instance that was overwritten was the "openpkg" files, including alas the original openpkg RPM database!. As the rest of the files were there for the moment I've moved the "corrupted" instance to /opkg22 and am rebuilding all instances (that I can remember) into a new 2.3 version at /openpkg. > However, the nice thing about OpenPKG is that it has so few system entry > points that a complete removal and new installation is simple. Just make > sure you backup the inconsistent (half 2.2 half 2.3) instance before > completely removing it. It might contain important files for your > configuration information in /openpkg/etc. Yes, I've done that and am nearly all the way back to a working system. It's just a shame I lost my rpm database which on an rpm based "system" means having no knowledge about what is installed. On a normal distribution you can do rpm --initdb but this is not normal and the consequences of running openpkg-2.3.0-2.3.0.ix86-whitebox3.0-ope.sh and defining a prefix of an existing "running" openpkg instance is "fatal" (or nearly so). > > I would also like to know if the different openpkg users can be > > reconfigured on a running system and how this would be done. Where are > > they defined? > > Check the /etc/passwd file where they are probably defined in your case, > though it's hard to be exact without without knowing more about your > platform and environment. I meant the openpkg-r and other users which can be configured. > Simply reconfiguring file ownership on Unix is trivial but don't forget > about the things you can't easily change such as user or group ids possibly > written to a binary at a package's compile time. That was one of my questions: if I reinstall openpkg with different "openpkg users" can I use the existing openpkg binaries I built with a different configuration or are these users "hard-coded" in the binary rpm? My guess is they _are_ hard-coded which means I have to rebuild all binary rpms again from the src rpms. > Changing the ownership or file modes over a complete OpenPKG instance is > probably not worth the effort. Although I've not used it there is a > '--setugids' argument you can pass to rpm. Another good argument to use > is '--verify'. Run /openpkg/bin/openpkg rpm --help and read about these > and other arguments that could be useful if you continue with restoration. Yes, but here we are talking about different things. I was talking about "fixing" an installed openpkg instance which I had configured without the susr/musr/nusr/rusr to use values I had set before. I think previously I had only set the "r" user openpkg-r. > > [1] Please can the openpkg-x.y.z-openpkg-2.3.0-2.3.0.ix86-yyy-ope.sh > > script check before overwriting existing /openpkg/RPM/DB/* files as the > > consequences of the install are quite difficult to recover from. > > The basic OpenPKG components are not the place to put such comprehensive > error checking, because they are intended to be as simple and compact as > possible. The place for your suggested error checking as well as 100 other > error checks is the upper layer OpenPKG user interface which does not yet > completely exist. The idea is an old one which is mostly still on the > drawing board and slowly being developed. I think the only thing to check is that if $prefix/RPM/DB is NOT empty then continuing is potentially going to destroy your installed system. Once rpm's knowledge is gone openpkg can not be "managed" any further. The existing system will work, but that is all. > > Any pointers or explanations of how they are used would be most welcome. > > I remember reading something about this before but can not now find the > > info in the release notes or manual about this topic. > > I'll try to guess your specific questions regarding OpenPKG user and groups: > > 1 The advantage of installing a new OpenPKG instance with its own new user > and group is more complete encapsulation and abstraction from other system > resources. > > 2 An advantage of OpenPKG having several different users and groups is finer > grained security. > > You always control at bootstrap time with which user and group names and ids > the new OpenPKG instance will be installed and later run. Importantly, it is > possible to specify already existing users/groups (removing advantage #1), > which allows users with no root access to install and manipulate OpenPKG > instances. One can specify the same user/group for all four OpenPKG users > at bootstrap time (removing advantage #2) should multiple be undesirable. > > There are many ways in which the different user and group information is > used. Often a daemon binary will be launched as root, but change to a less > privileged user such as the openpkg-r or openpkg-n in your case. > > http://www.openpkg.org/doc/quickref/openpkg.txt (search for 'user') > http://www.openpkg.org/doc/handbook/openpkg.html#security-usergroup Thanks for the references, but they do not make things _that_ clear to me. I think perhaps the lack of an example may be the issue. For example amavisd appears to need a non-root user to run as and that is now missing in my installation. I think I'll just have to rebuild (again) the openpkg 2.3 using --user=openpkg and --group=openpkg which I think is what I did before. Thanks for the pointers anyway. Regards, Simon ______________________________________________________________________ The OpenPKG Project www.openpkg.org User Communication List openpkg-users@openpkg.org
