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?
> >>>* 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.
> >>>* 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.
> >/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...
> >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?
> >>>* 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. :)
> >>>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.
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
>
--
--- Ola Lundqvist systemkonsult --- M Sc in IT Engineering ----
/ [EMAIL PROTECTED] Annebergsslingan 37 \
| [EMAIL PROTECTED] 654 65 KARLSTAD |
| http://opalsys.net/ Mobile: +46 (0)70-332 1551 |
\ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 /
---------------------------------------------------------------
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
