Attempt to modify Gentoo-baselayout to make vserver-deployment easier without breaking the current behaviour and without needing to split the baselayout.

The modifications outlined below were tested with sys-apps/baselayout-1.9.4-r2 on a vserver-enabled system without trouble; further testing is needed as failures in baselayout may render the system unbootable.

sources of information:

- http://vserver.strahlungsfrei.de/tiki-index.php?page=VServerGentooNew
- http://www.linux-vserver.org

related Gentoo-packages:

- sys-kernel/vserver-sources
- sys-cluster/util-vserver

#### helper-functions and modification of /sbin/rc and /etc/inittab

- helper-functions we use:

      instserv sbin # cat /sbin/vserver-functions.sh
      #!/bin/bash
      ##
      ## basic function-set for integration in gentoo-baselayout -- this
      ## should allow save (re-)booting of vservers and root-servers without
      ## maintaining 2 completely different baselayouts.
      ## Idea: we simply check if we are on a root- or v-server and react accordingly.
      ## If there is no "s_context:" at all we have a vanilla (i.e. non-vserver) system
      ## that is treated like a root-server.

      check_context() {
              ## TODO: error-handling? what to do if /proc/$$/status does not exist?
              awk '/^s_context:/ { print $2; }' /proc/$$/status
      }

      on_rootserver() {
              local ctx=$(check_context)

              if [ "x${ctx}" = "x0" -o "x${ctx}" = "x" ]; then
                      ## we are on the root-server or a non-vserver-system:
                      return 0
              else
                      return 1
              fi
      }

      on_vserver() {
              on_rootserver && return 1 || return 0
      }

- modify /sbin/rc to perform a depscan (the "fake-init"-stuff prevents /sbin/rc to do it as the runlevel is never "S"!?):

      instserv sbin # diff -u rc.org  rc
      --- rc.org      2004-06-13 13:32:17.000000000 +0200
      +++ rc  2004-07-03 15:40:42.000000000 +0200
      @@ -10,6 +10,10 @@
       [ -f /sbin/livecd-functions.sh ] && source /sbin/livecd-functions.sh
       umask 022

      +## vserver-support:
      +[ -f /sbin/vserver-functions.sh ] && source /sbin/vserver-functions.sh
      +on_vserver && /sbin/depscan.sh
      +
       try() {
              local errstr
              local retval=0

- create two new runlevel-directories and adjust /etc/inittab:
  [ "vdefault" may be omitted, see "Plan B" below ]

      mkdir /etc/runlevels/{vboot,vdefault}
      instserv runlevels # diff -u /etc/inittab.org /etc/inittab
      --- /etc/inittab.org    2004-06-13 13:32:17.000000000 +0200
      +++ /etc/inittab        2004-07-03 15:49:16.000000000 +0200
      @@ -17,14 +17,14 @@
       si::sysinit:/sbin/rc sysinit

       # Further system initialization, brings up the boot runlevel.
      -rc::bootwait:/sbin/rc boot
      +rc::bootwait:/sbin/rc vboot

       l0:0:wait:/sbin/rc shutdown
       l1:S1:wait:/sbin/rc single
       l2:2:wait:/sbin/rc nonetwork
      -l3:3:wait:/sbin/rc default
      -l4:4:wait:/sbin/rc default
      -l5:5:wait:/sbin/rc default
      +l3:3:wait:/sbin/rc vdefault
      +l4:4:wait:/sbin/rc vdefault
      +l5:5:wait:/sbin/rc vdefault
       l6:6:wait:/sbin/rc reboot
       #z6:6:respawn:/sbin/sulogin

  => nothing is started up by defaut, to add a service use, e.g.

      rc-update add sshd vdefault

  => this does not work as the values in /etc/inittab are not used; they are overridden by the "vserver"-tool from "sys-cluster/util-vserver" so that always "default" is choosen.

  Plan B:

      cd /etc/runlevels; mv default default.org; ln -s vdefault default

  We might as well de-populate the original default-runlevel with "rc-update" and omitt the whole "vdefault"-stuff above.

- prepare a configfile for your vserver on your root-server (/etc/vservers/my_vserver.conf).

#### modify initscripts

We need to modify some initscripts as some operations are not possible within a vserver and the dependency-tracking of the Gentoo-initsystem is more than unhappy with failing services (which is the perfectly correct behaviour).

A vserver "inherits" some of the root-server setup or get's configured from the root-server. This is the case for, e.g. hardware-clock and network-configuration.

List of initscripts that we need to make vserver-aware:

    hostname
    modules
    checkfs
    localmount
    clock
    consolefont
    serial
    net.eth0
    net.lo

We use the same trick as in `/sbin/rc`, each initscript gets the following lines added at the top (directly after the copyright-header):

    ## vserver-support:
    [ -f /sbin/vserver-functions.sh ] && source /sbin/vserver-functions.sh
    on_vserver && exit 0

(if this get's integrated in the offical baselayout the sourcing of vserver-functions.sh will happen at a more central place and not in every initscript)

#### reboot and halt

In order to enable reboot and halt for a vserver `rebootmgr` needs to be running on the root-server and `/sbin/halt` on the vserver needs to be replaced by `vreboot` from sys-cluster/util-vserver. (what about `/etc/init.d/shutdown.sh`?)

Simply overwriting it is not a good solution as the next baselayout-update will revert to the "wrong" (non-vserver) version.
If we only modify `/etc/init.d/halt.sh` and `/etc/init.d/reboot.sh` like

    sed -i -e "s@/sbin/halt@/sbin/vhalt@g;" /etc/init.d/halt.sh
    	:
    	:

it is still possible to type `reboot` on the shell-prompt and loose contact with your vserver.

=> we need to decide what way to go here (maybe a vserver-USE-flag for baselayout could be introduced?).