Hi Gilles, i'll comment to this email rather than the one which does only refer to this list :-P
Yes, util-vserver 0.30.204 is in SID now and it should be offering a transition-path according to the changelog. See the 0.30.203 uploads at http://packages.qa.debian.org/u/util-vserver.html for the detailled wording. I daresay i haven't challenged it as i don't have any "old-style" vservers around. But whoever has a sarge could bootstrap that old config-style and then upgrade to the SID version and report back success/problems. > Ideally, the "template" should be with the minimum functionality, with > everything that's necessary (to make it comfortable to install the server > applications) and nothing that comes in the way of vserver (i.e. all > hardware- and kernel-related packages). well, *where* i'd prefer this to be put is cdebootstrap. It's quite easy to select a "flavour" like "build" already. Thus adding a "skeleton" or a "vserver" flavour should be quite feasible. As debootstrap's options are directly accessible through the commandline, that's quite accessible already, yet the (c)debootstrap don't offer a "vserver profile yet, only the buildd profile. Moreover, with cdebootstrap replacing debootstrap we should seriously move forward to it and ask cdebootstrap's upstream to include some flavour for this - in case you need more than the "standard" flavour which is already in. > So here is a list of steps that could be added to the "vserver build" > script to come closer to such a ready-to-use vserver environment: > > 1. Removing dispensable packages: > > pciutils fdutils ipchains makedev ppp pppconfig pppoe pppoeconf > dhcp-client console-common console-data console-tools klogd sysklogd > > [Note: klogd still triggers that cpu-hogging behaviour, which makes it > *indispensable* to remove...] > > Others? well, for now i prefer doing a "cdebootstrap -f build ..." which brings me somewhat closer to what i want, objections? the above list is missing, however the sysklogd should be included into the vserver flavour for sure. Plus the build flavour doesn't boostrap a working set of /dev entries. Having a /dev/null, /dev/random and /dev/urandom however is quite essential for a working vserver. This would then need to go into the new profile aswell. > 2. Installing indispensable packages: > > less ssh > > Others? vim ;) > 3. Prepare for package installation: > (a) Copy the contents of the host's "/etc/apt/sources.list" > (b) Run "apt-get update" apart from sources.list a resolv.conf is needed to get a working networking setup. > 4. Network interfaces > (a) In the "/etc/init.d/reboot" script: Remove the "-i" option (to avoid > the guest trying to deconfigure the network interfaces upon halting). i guess this should be an option in /etc/default/reboot or so. Have you tried rasing this against the package in Debian? Having the util-vserver package bring forth an alternative /etc/init.d/reboot is probably not an option. > (b) Remove "spurious" links to scripts that will try to configure the > interfaces: > update-rc.d -f ifupdown remove > update-rc.d -f ifupdown-clean remove > update-rc.d -f networking remove > > 5. ... [Not yet finished.] when building from the "build" flavour we also need to put a proper /dev setup and move start-stop-daemon.REAL into place. Moreover you must not boostrap into an existing mountpoint with util-vserver, i.e. you can only boostrap into a subdir of a partition not into the mountpoint itself. I kinda dislike that, but apparently Enrico thinks it's neccessary as even the --force doesn't yield me a chance to overcome this. > > Some more questions: > > (a) Should I remove the "mount" package (to suppress any attempt by the > vserver > guest to try such things)? [The Debian package management issues a > strong > warning when uninstalling it (package is "essential").] > > Or should I only remove the symlinks as for the networking scripts? I'd rather go for the not running it rather than removing any chance of even trying. At least if this could be working for some vserver client setup. > (d) The file "/etc/hostname", inside the vserver, contains the host's name > instead of the > guest name. Is it supposed to be so? ["uname -n" provides the right > name.] uname does also report the kernel arch rather than the userland arch (in case x86_64 and i386 differ). At least for the latter Herbert just needs a box to test this. What I kinda would love to see is dchroot support with vserver. Going through sudo with vserver suexec is kinda long way to type and setup. Having a dchroot context-enabled would be a very handy thing for especially developer build environments IMHO. -- Best regards, Kilian
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
_______________________________________________ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver