Ola Lundqvist wrote:
Hi Daniel
On Thu, May 10, 2007 at 10:56:08PM +0200, Daniel Hokka Zakrisson wrote:
...CUT...
The following features exist in vserver-debiantools:
* Package caching, which means that you can reuse downloaded packages
from one creation of a vserver to the next.
Not in util-vserver.
* strip a server
You can take a normal Debian server and run stripserver on it to
make it useful in vserver environment.
Is this really something which is used a lot? What exactly does it do?
I use it sometimes myself. It is useful when you want to make a vserver
from a real server installation.
What it does is all the postprocessing functionality (see below)
except that it do not install any packages. Like package removal,
hw init script removal, some files etc.
So it ought to be equivalent of running the initpost script, no?
* Automatical removal of packages not very suitable for a vserver
environment.
Really shouldn't be hard to add.
True.
* Automatical removal of a number of init functions.
The initpost script does this now (for etch).
Good, then I can remove that part. Do you know which ones that it
removes?
This list is in distrib/etch/vserver-config.sh:
bootlogd
checkfs
checkroot
halt
hwclock.sh
ifupdown
klogd
libdevmapper1.02
makedev
module-init-tools
mountall.sh
mountdevsubfs.sh
mountnfs.sh
mountkernfs.sh
mountvirtfs
networking
reboot
setserial
single
stop-bootlogd
stop-bootlogd-single
umountfs
umountnfs.sh
umountroot
urandom
* Configurable mirror location.
Always been possible with util-vserver.
I thought so. :)
* Generation of a number of files in /etc, like reduced inittab, etc.
Such as? I guess most of them are already taken care of.
That is likely the case. They are
/etc/inittab
Check.
/etc/locale.gen
Check.
/etc/apt/sources.list
Check.
/dev/ very reduced set (probably already handled)
Check.
/etc/hostname
Check.
/etc/hosts
Check.
/etc/resolv.conf (generate from host)
Has a separate entry in the configuration already.
/etc/apt/apt.conf.d/* (copy from host)
This isn't done.
/etc/fstab
What for? I discussed that with Hollow and found it a rather peculiar
thing to have, and as it didn't seem to have any impact, it was removed
in the merged version.
/etc/crontab (randomly)
Just for the /etc/cron.{hourly,daily,weekly,monthly} entries, right?
Also runs initial configuration within the vserver to set up passwords
etc.
I asked Hollow to remove this during the patch review as I think
building a guest should be fully automated, and not ask a bunch of
questions.
* Randomized crontab so that not all vservers execute the cron at
the same time.
Makes sense I guess.
Makes much sense. :)
* Generation of a vserver, that is actually suitable for
real booting, i.e. over NFS. The reason behind this is that
you may want to maintain NFS bootable computers within a vserver
environment to correct a number of faults.
What does this actually mean?
More or less the same thing as debootstrap does, but suitable for
vserver handling _and_ real booting at the same time.
Well, I got that, I meant more in detail what that actually entails.
Just not removing the hardware scripts, or is there more to it?
I assume that a couple (or all) of these features exists already,
but I do not know if all exists or not.
The main reason however why I keep this package is for backwards
compatibility. Some people, including myself are used to this
way of creating a vserver.
newvserver --hostname xx --ip x.y.z.e --domain x.y.com
I think the last thing is the main reason.
If all the listed features, from above is already in util-vserver
then I do not think we should suggest vserver-debiantools. However
if util-vserver do not have all the features above (except for the
backwards compatible newvserver command of course) then I think
it is useful to have a suggestion of that package.
Wouldn't it be better to work towards including the features in
util-vserver instead?
Sure. However I gave up a couple of years ago when upstream did
not want to include my scripts. I did not really have the time to
change it that much either. That may have changed however, and I have
not checked.
Well, with Hollow having already created the basic initpost (which from
what I gathered was based on newvserver), extending it really shouldn't
be a problem. I'd of course prefer having Debian people handle it rather
than me or Hollow, with us being Fedora and Gentoo people respectively.
It was much easier for me to maintain this software (as a wrapper)
instead of trying to merge it into the upstream software.
Regards,
// Ola
--
Daniel Hokka Zakrisson
--
Daniel Hokka Zakrisson
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
