[EMAIL PROTECTED] (Velu Erwan) writes: >>I do not know if urpmi supports this, but it should be possible to >>specify the version of Mandrake Linux. E.g. >> >>| vserver ... build -m urpmi -- -d mdk10 >> >> >> > Of course it could be done, but the main idea was to install the > vserver using the virtual basesystem rpm (available on all > mandrakelinux release).
I have to admit that I do not know anything about 'urpmi', but with 'yum' and 'apt' I can configure the repository which is going to be used. This makes it possible to install FC2 guests on FC3 hosts by using '... -d fc2'. So it would be nice when I could call 'urpmi' in the same way (install mdk9 guests on a mdk10 hosts e.g.). >>>- _rpmdb_mntpoint=/.rpmdb >>>+ _rpmdb_mntpoint=$BASEDIR/.rpmdb >> >>This does not look sane. The rpm-database mountpoint MUST be at the / of >>the vserver. >> > I must assume that some hack were introduce but certainly because I > didn't catch everything in vserver's architecture. Oooh... I just detected an ugly bug in the rpmdb handling which was hidden by the /var/lib/rpm symlink. Please try [1] if it fixes your problems. Else: Base idea behind the external packagemanagement is, that host commands shall never rely on any guest data. E.g. I do not trust db4 (the databasesystem used by rpm) enough to store the rpmdb within the guest. Perhaps there are exploits in the database-reading-code which can be triggered by a manipulated database. So, using /var/lib/rpm as a place for the rpmdb is dangerous: an attacker within the vserver could create a /var/lib -> /somewhere symlink pointing to such a manipulated database. And there is nothing which can be done against it... That's why, the rpmdb has to be mounted into the toplevel directory where such symlinks are impossible. Using /.rpmdb is a hack; /dev would be a much nicer place because it is available everywhere and ignored by rpm. But there is rh bugzilla bug #106057 which requires that the rpm database must be both in the chroot-environment and in the real-root one. So the /.rpmdb has to stay. The position of the rpm-database is specified by the %_dbpath macro which is changed in the vserver specific rpm-configuration. I do not know if 'urpmi' honors this macro (apt had a similar bug which caused me to create an (insecure) /var/lib/rpm -> /.rpmdb symlink), whether it must be configured at another place, or if 'urpmi' must be fixed. >>>+_VURPMI="$SBINDIR/urpmi" >> >>path should be determined in %configure. And the variable should be >>named '_URPMI', not '_VURPMI'. >> >> > Once again a lake in the the global knoweldge :/ How will you operate after the vserver was build? Do you require an 'vserver ... pkgmgmnt internalize'? If not, you should create a 'vurpmi' wrapper. A plain 'urpmi --root /vserver/...' is dangerous and must never be used. Enrico Footnotes: [1] http://savannah.nongnu.org/cgi-bin/viewcvs/util-vserver/util-vserver/scripts/vserver-build.functions.rpm.diff?r1=1.5&r2=1.6
pgpG6nJ1dZb2x.pgp
Description: PGP signature
_______________________________________________ Vserver mailing list [email protected] http://list.linux-vserver.org/mailman/listinfo/vserver
