About this list Date view Thread view Subject view Author view Attachment view

From: Thomas Gelf (vserver_at_gelf.net)
Date: Thu 05 May 2005 - 09:22:33 BST

Hi all!

Sorry for starting a new thread - this one has to do with some parts of
"Summary of recent improvement discussion", some parts of "OpenFoundry
project for Vserver Utilities" and want's to offer a solution for the
util-vserver / vserver-debiantools mix in Sarge / SID. As a summary and
for all of you who didn't follow it on IRC here a (not really short)
summary of the discussion between me (Thomas Gelf / nickname Pazzo) and
Ola Lundqvist (nickname ola) about improvements / future direction of
Vserver utils for Debian:

Discussion started on 2005/05/03 at 18:23:34 (timezone Europe/Rome)

ola I have just sent a mail to the mailinglist about some changes
        that I will make.
ola Please comment if you have comments. :)

... (searching/fixing bug in SID's .207 utils)

Pazzo ola: what about vserver-debiantools - what are they doing more
        than util-vserver?
Bertl ola: how would that improve things? IIRC isntallation happens in
        a non chrooted environment ...
        ola: last two items sound sane to me ...
ola Pazzo: vserver-debiantools fix a number of files inside the
        vserver (like /etc/apt/sources.list) and some more things. It
        also have a .deb cache feature.
Bertl ola: we should keep one thing in mind: we do not want to make a
        debian branch, a redhat, and a gentoo branch .. we want to make
        _one_ tool which can handle _all_ of them on _all_ distros ...
Pazzo ola: hmmm... that's a good thing and really useful. I did so by
        creating /usr/lib/util-vserver/vserver-cleanup and
        ola: and then using vserver build -m debootstrap with the "-s"
ola Bertl: I agree.
Pazzo (vserver-cleanup is called then by the debootstrap script)
ola Pazzo, that can be a good thing.

... (next step: some little change proposals, small bug fixes, step 1:
    update-rc.d behaviour)

Pazzo ola: another thing: $REMOVE_LINKS
        ola: update-rc.d -f removes all links in /etc/rc?.d - BUT...
        ola: ... I discovered that debian's package management will set
        it back to "default" if you upgrade a package and it finds no
Bertl hmm, isn't that a bug then?
Pazzo Bertl, ola: if you leave a single link there it doesn't do so
ola Pazzo: Yes I know that, but I do not have any solution for that
        using the current script.
DaCa Pazzo: yes, the trick is to leave at least one link there
Bertl Pazzo: hmm, yeah, maybe in an unused runlevel?
ola Ahh yes that was the solution. I do not do that using the
        maintainer script though.
Pazzo we did update-rc.d $service stop 90 3 .
        for all packages that should be removed
Bertl hmm, doesn't that mean that shutting down the server will call
Pazzo Bertl: Debian uses runlevel 2 by default
        putting the stop link into 4 or 5 would also be ok
Bertl something completely different, why don't we use a 'special'
vserver runlevel?
Pazzo Bertl: because of tools like update-rc.d and package
management / postinstall scripts?

... (step 2: newvserver provides it's own inittab)

Pazzo ola: for /etc/inittab maybe some grep would be less "intrusive"
        than providing a own inittab file:
        mv $VS_ROOT/etc/inittab $VS_ROOT/etc/inittab.dist && grep -v
        respawn\:/sbin/getty $VS_ROOT/etc/inittab.dist >
ola Pazzo: Yes grepping is less intrusive than providing a new file.

... (step 3: removing symlinks is not "upgrade-proof" - fixing this and
        adding other scripts that should be removed)

Pazzo ola: what about ifupdown, mountvirtfs, mountall.sh and
        I'm removing them too
ola Remove those symlinks too or.
Pazzo for i in klogd networking mountvirtfs mountall.sh mountnfs.sh
        ifupdown; do
ola If you have a patch that would be great.
Pazzo update_rc $i
        update_rc is a small shell function removing with -f the
        symlinks and adding one stop link
Pazzo http://www.pastebin.com/279170

... (shell code sniplet)

function update_rc() {
  program=`chroot $VS_ROOT which update-rc.d`
  if [ -x $VS_ROOT/$program ]; then
    chroot $VS_ROOT $program -f $service remove
    chroot $VS_ROOT $program $service stop 90 3 .
    error 1 UPDATE_RC.D "Konnte update-rc.d in VServer nicht ausführen"

ola for link in $REMOVE_LINKS
            update-rc.d -f \$link remove
            update-rc.d -f \$link stop 90 3 .
        This is how it will look now. Will that do the proper things?
ola Pazzo: I agree that it may be a better solution. Patches are
        welcome. :)
        REMOVE_LINKS="klogd hwclock.sh setserial urandom networking
        umountfs halt reboot"
        So what am I missing... mountall.sh mountvirtfs and mountnfs.sh
        and ifupdown.
Pazzo ola: sure - we did the strange function because we do not want
        the vserver to be started
ola ok
Pazzo (maybe better replace update-rc.d with a variable)
ola maybe not that important.
Pazzo ok
ola What do update-rc.d -f \$link stop 90 3 .
        put a stop link in ... runlevel 3?
        Will that prevent it from upgrades to be added?
Pazzo ola: yes
        unfortunately I don't remember where - but I read somewhere that
        debian while updating it's rc-stuff it :
        - looks if there is some link
        - if not, it sets them to the defaults
ola Actually some parts may actually be generic, and not just for
Pazzo - if yes it doesn't touch them

... (step 4: maybe useless)

Pazzo hmm... I'm also doing "shadowconfig on", set /etc/mailname to
        the hostname - but I don't know if this would be settings for

... (step 5: sources.list)

Pazzo ola: I think it should be possible to modify the default
        sources.list - so better put it into


Pazzo hey, copying ssh keys is a good idea

... (now I'm trying to explain how I modified util-vserver 'til now to
    fit my needs on my Debian hosts)

ola I'm not sure how to provide all this features to vserver ...
        I can not add a huge number of arguments, or can I.
Pazzo ola: what do you think about our debootstrap script solution?
        I'm doing vserver xy build ...
        -s /usr/lib/debootstrap/scripts/vserver_sarge
        vserver_sarge is similar to sarge, with some extra excludes
        and it calls our /usr/lib/util-vserver/vserver-cleanup script
ola Yes that is a good solution. The -s option is debian specific
        though. :)
        Whould I add that to the "real" util-vserver too?
Pazzo maybe you could take your cleanup part as it is for sure done
        more careful than my one ;-) ...
        ola: I would make /usr/lib/debootstrap/scripts/vserver_sarge
        part of util-vserver, you could also move it to something
        like /usr/lib/util-vserver/distributions/somewhere and also put
        the debian cleanup stuff there

... (later)

Pazzo ola: for the debootstrap script: you may modify the packages
        there, remove unsupported archs and call the cleanup script
        after the second_stage_install
        as told before I would also take the sources.list out of the
        cleanup script and put it somewhere in

... (short summary, trying to explain)

newvserver (from vserver-debiantools) creates a vserver and does some
cleanup (removing getty's, klogd - all the bad things) and leaves out
useless (in a vserver) packages. as creating a vserver should be
util-vserver's job on all distributions I don't like the idea of having
a different tool for Debian and did the following:

- time ago the "-s" switch was added to util-vserver (at least in the
  debian package, don't know if my suggestion and "patch" has found it's
  way into upstream sources) to allow us to tell the debootstrap method
  to use a special script. the same switch is also used by debootstrap
  itself, so this seems to be clean and logical.

- this "-s" switch allowed me to create a special debootstrap script
  leaving out some packages / unused archs and calling a cleanup-script
  lying somewhere in /usr/lib/util-vserver - probably
  /usr/lib/util-vserver/distributions/somewhere would be the right
  place, any suggestion? this cleanup script is then doing all the
  cleanup with chroot & co and without starting the vserver

... (another script was mentioned - I don't know enough about it to say
    if it could be moved to util-vserver, maybe someone else can do so)

Pazzo what else is debian-specific in vserver-debianutils?
        what does newnfsserver do?
        ehm - newnfsvserver
ola Pazzo: It will create a vserver suiteable for a nfsrootmounted
        diskless client.
        The name is not perfect.

... (ola fixed some of the discussed things in newvserver, I did some

Pazzo ola: I got some errors as the created sources.list fails
        partially (I'm mirroring only binary packages, no sources) - but
        that's ok
Pazzo ola: some other thoughts:
        - I don't like the idea of starting/stopping vservers while
          creating them, it should be possible to do all this jobs with
          chroot & co

... (it "shouldn't" be possible, it IS possible as we are already doing
    so :)
... (let's go on, thoughts about "non-interactivity")

Pazzo - vserver XY build is non-interactive, newvserver is interactive
        - I would prefer the idea of using "vserver XY build" with a
          special debootstrap script which is then calling the cleanup
        - interactivity should be an extra option but not on by default
          (root password, timezone and such stuff)
        - timezone config can be taken from the host
        - another thing breaking "non-interactivity": as written before
          adding deb-src http://mymirror/... did fail as I have no local
          src mirror. result:
          update available list script returned error exit status 1.
          Press <enter> to continue.
          this "Press ..." shouldn't be there
ola Pazzo: I agree.
ola I like the ideas.
ola Sounds like a good solution. I'll work on something. If you have
        time I would be happy if you can provide files/patches etc. :)

Discussion finished at 20:32:34

Ok, what else?

* Replying to the "OpenFoundry-thread" Ola told us
  (http://list.linux-vserver.org/archive/vserver/msg09644.html) that he
  would add the remount hack to vserver-stop - that's what I'm doing in
  my .debs since I realized in a discussion with Bertl that atm it is
  the only possibility to do stop vservers without pain. Enrico told me
  that he wouldn't add such a hack to his utils and Bertl that this is
  for sure not a job to be done in the kernel patch so what else should
  I do?

  Kilian Krause started the "packaging review for new Debian packages"
  thread on this ml on 2005/12/27, I had some discussion with him,
  reviewing differences between his and my util-vserver package. You can
  read up discussion here:


  That's where the remount-hack probably found it's way into official
  Debian packages - maybe in the meantime this is outdated - I don't
  know. Is the remount hack still needed?? Is there still no

  If not I'm would be happy if also upstream sources contain it unless
  someday someone will find a better solution - but we should not forget
  about it!

* Ola asked if his tools should be added to util-vserver: yes and no -
  what they are doing is useful, but in my opinion they shouldn't be
  separate tools as I prefer my debootstrap-script approach. What's your

* Adding --numeric-ids to vserver-copy sounds good - but don't ask me
  about vserver-copy as I didn't use it 'til now - debootstrap is great
  and with a local mirror for sure my preferred way of installing Debian

* I have no idea what Ola's changes to vserver-build.debootstrap will be
  - and maybe these will become useless if we are using debootstrap
  scripts. Ola?

* force-reload - hmmm... never seen before :) What does it do? kill
  everything in a context?

* another question: what is the preferred initstyle for a Debian Vserver
  on kernel 2.6? I'm using "plain" and not able to shut down my vservers
  cleanly - error msg is:

> vkill: vc_ctx_kill(): No such process
> Vserver '/etc/vservers/XY' still running unexpectedly; please
> investigate it manually...

  any idea / suggestion?

* I also have read the discussion about who should be responsible for
  package management - the vserver itself or the host for all vservers.
  I have not enough knowledge about rpm & yum to tell you something
  intelligent about them.

  For Debian the way described in this mail is the best thing for my
  needs and maybe for others too - I believe that a Debian Vserver
  without package management tools makes no sense. Maybe that's not
  true for rpm-based distributions - I don't know.

  In my opinion package management is a Vserver's job - the host should
  care about installing / destroying / copying / moving / starting /
  stopping them - that's it.

Ok, that's all folks - let's start the flame war ;-)

Best regards,
Thomas Gelf

Thomas Gelf <vserver_at_gelf.net>

_______________________________________________ Vserver mailing list Vserver_at_list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver

About this list Date view Thread view Subject view Author view Attachment view
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Thu 05 May 2005 - 09:23:13 BST by hypermail 2.1.3