From: Kilian Krause (kk_at_verfaction.de)
Date: Sun 13 Mar 2005 - 12:10:27 GMT
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
_______________________________________________
Vserver mailing list
Vserver_at_list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver