Ola Lundqvist wrote:
Hi again
On Fri, May 11, 2007 at 05:31:54PM +0200, Daniel Hokka Zakrisson wrote:
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?
Yes, that would be the same. Can you run it on an already installed
system?
Sure, but maybe it's not quite as nice as it could be. If you're copying
it with build -m rsync or build -m template, you can use -d etch to run
it, but otherwise you'll need
/usr/lib/util-vserver/distributions/<dist>/initpost
/etc/vservers/<guest> /usr/lib/util-vserver/util-vserver-vars
* 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
Those are removed in vserver-debiantools.
klogd hwclock.sh setserial urandom networking umountfs halt reboot
So it seems like only urandom is missing, unless it really should be
there.
Hmm? urandom seems to be both in your and my list.
* 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.
Nice. I'll remove that from vserver-debiantools then.
/etc/resolv.conf (generate from host)
Has a separate entry in the configuration already.
Ok with me.
/etc/apt/apt.conf.d/* (copy from host)
This isn't done.
Ok. The question is if it should. :) It has been left there as it
was there from the beginning, but I tend to think that maybe it should
not be done.
Yeah, that's my first impression as well.
/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.
It was needed a long time ago. Probably not now.
/etc/crontab (randomly)
Just for the /etc/cron.{hourly,daily,weekly,monthly} entries, right?
Right. But it overwrites the file so if debian changes it will not be
seen...
Sounds like an improvement would be to use sed then, no?
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.
But then you get those questions the first time you start the vserver, or
am I mistaken here?
Only if you run whatever command is needed to do so ;)
* 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?
There are actually two scripts. newvserver and newnfsvserver. They
are almost the same but the newnfsvserver do not remove harwarde
specific things. I'm actually not fully sure that it works anymore
as I have not tested it for about 4 years. :)
So not something I'd consider critical then.
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.
I see. This sounds really good. If I know that my changes will be accepted
(unless they break things of course) by upstream I'll happily make changes
so we can get rid of the vserver-debiantools package.
The only big thing that I see is the randomize of crontab and the
package caching. The first would probably be useful for all architectures
while the second is deb specific.
Not necessarily. Package caching could probably be used by all of the
net installation methods, just that the paths would vary a bit.
Regards,
// Ola
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
--
Daniel Hokka Zakrisson
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
