the same text as pasted below is added as an attachement in html -- this is better readable. --- snipp --- 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?). --- snapp --- Reproducible: Always Steps to Reproduce:
Created attachment 34714 [details] gentoo-vserver-baselayout.html the same information as in the description-field -- maybe better readable.
addition for the "reboot and halt"-section: with util-vserver it's possible to "stop" and "start" a vserver from the host-system. the following changes in /etc/init.d/halt.sh (the vserver's halt.sh, not the host-system's) let the "stop"-case finish without errors (patch for baselayout-1.9.4-r3): --- snipp --- --- /etc/init.d/halt.sh 2004-08-25 21:33:12.000000000 +0200 +++ /vservers/v1/etc/init.d/halt.sh 2004-08-27 18:28:45.000000000 +0200 @@ -31,7 +31,7 @@ # occure, bug #13599. umount -at tmpfs &>/dev/null -if [ -n "`swapon -s 2>/dev/null`" ] +if [ -n "`swapon -s 2>/dev/null`" -a ! on_vserver ] then ebegin "Deactivating swap" swapoff -a &>/dev/null @@ -162,7 +162,7 @@ # Get better results with a sync and sleep sync; sync sleep 1 -if ! mount_readonly +[ ! on_vserver ] && if ! mount_readonly then killall5 -9 &>/dev/null sync; sync --- snapp ---
i am writing a gentoo vserver guide atm, this sounds interesting... perhaps i'll do some experimental baselayout ebuilds tomorrow so they can be tested before they get in main portage if you like contact me on freenode (nick: Hollow)
first part of the guide is done. i created vserver enabled baselayout ebuilds you can find the guide and all ebuilds at http://oss.croup.de/vserver/guide/
@benedikt: i've tested your ebuilds and they work very smooth (used the 1.9.4 baselayout). your guide is very nice and correct (good work, thanks). for the configuration-part of the guide: one thing that will cause trouble for most users is that most (all?) daemons on the host-system will bind to 0.0.0.0 preventing any daemons from a slave-vserver to start up, example: sshd on the host-system: need to edit /etc/ssh/sshd_config to allow sshd for slave-vservers to start up: ListenAddress <your "primary" host-ip>
what's the status here? is there any chance to get that into baselayout?
Created attachment 50428 [details, diff] diff against 1.6.9
ok, some of those hunks make sense and a bunch dont :) since i dont know anything about vservers, i glanced through their wiki real quick ... it seems that each vserver has a separate filesystem ? so each vserver has its own /etc/ config tree ? if that is the case, then i would say that the hunks for consolefont/net.lo/serial wont be merged ... i'd rather just keep the files slim and tell you to not add them to your default runlevel with respect to the detection functions, what is the typical output of 's_context:' on a vserver ? just an integer ? what kind of output can we expect on a selinux system ?
> it seems that each vserver has a separate filesystem the vserver itself has no seperate filesystem, but you can put it on one, if you like, it doesn't matter > so each vserver has its own /etc/ config tree ? yes, vserver is sth between chroot, jail and UML, so it has it's own /etc > if that is the case, then i would say that the hunks for consolefont/net.lo/serial wont be merged ... i'd rather just keep the files slim and tell you to not add them to your default runlevel consolefont, serial ok, but how to tell other init scripts that net is up if i remove net.* from the runlevels? network interfaces are setup on the host system before the vserver starts > with respect to the detection functions, what is the typical output of 's_context:' on a vserver ? just an integer ? what kind of output can we expect on a selinux system ? s_context is an integer containing the context id of a vserver, the root always has 0, vservers always have >=2, context 1 is reserved for use by util-vserver apps
output of /proc/$$/status: root-server: kronos ~ # cat /proc/$$/status Name: bash State: S (sleeping) SleepAVG: 88% Tgid: 10377 Pid: 10377 PPid: 10376 TracerPid: 0 Uid: 0 0 0 0 Gid: 0 0 0 0 FDSize: 256 Groups: 0 1 2 3 4 6 10 11 20 26 27 VmSize: 4356 kB VmLck: 0 kB VmRSS: 1572 kB VmData: 180 kB VmStk: 36 kB VmExe: 660 kB VmLib: 1340 kB VmPTE: 12 kB Threads: 1 SigPnd: 0000000000000000 ShdPnd: 0000000000000000 SigBlk: 0000000080010000 SigIgn: 0000000000384004 SigCgt: 000000004b813efb CapInh: 0000000000000000 CapPrm: 00000000fffffeff CapEff: 00000000fffffeff s_context: 0 ctxflags: none initpid: none ipv4root: 0 ipv4root_bcast: 0 vserver (s_context is random here, though it could be set to a fixed value): gentoo1 ~ # cat /proc/$$/status Name: bash State: S (sleeping) SleepAVG: 98% Tgid: 10352 Pid: 10352 PPid: 9290 TracerPid: 0 Uid: 0 0 0 0 Gid: 0 0 0 0 FDSize: 256 Groups: 0 1 2 3 4 6 10 11 20 26 27 VmSize: 5380 kB VmLck: 0 kB VmRSS: 1412 kB VmData: 176 kB VmStk: 36 kB VmExe: 608 kB VmLib: 1344 kB VmPTE: 16 kB Threads: 1 SigPnd: 0000000000000000 ShdPnd: 0000000000000000 SigBlk: 0000000080010000 SigIgn: 0000000000384004 SigCgt: 000000004b813efb CapInh: 0000000000000000 CapPrm: 00000000d44c04ff CapEff: 00000000d44c04ff s_context: 49152 ctxflags: 202000015 initpid: 0 ipv4root: 0102a8c0/00ffffff ipv4root_bcast: ffffffff
Created attachment 50516 [details, diff] vserver.patch try this one
comment #11 - _looks_ mostly ok -- I'll test it next week (hopefully till wednesday). - the for /sbin/functions.sh-part + grep -qs '^s_context:[[:space:]]*[1-9]' /proc/self/status could be made more robust (not that it was more robust in my original version;) - what about the net.*? side-note: a drawback of my original "exit-0-early-in-vsservers"-suggestion is that rc-status shows theses fake-services as "off". Without having looked at the code I feel that to fix this we could "move" the patch to a more central position like "ebegin" or the like? @Mike: good to have you on-board :)
none of the other init scripts will be patched since you can setup your /etc/ files to work properly, including net.* (set 'config_eth0=( "null" )') wrt to the grep, i dont see what lack of robustness you're refering to ...
net.*: like ``iface_ethX=""'' in /etc/conf.d/net? i was thinking of leading 0s ... on 2nd thought it may be silly.
Created attachment 50533 [details, diff] rc-scripts-1.6.9-vserver.diff i tried your patch and it works, though i added some `return 0` and `exit 0` to reflect the default behaviour even if some of the init scripts would work under certain circumstances (mainly where vservers have more capabilities or unlikely setups)
re #12,14: there are changes that need to be done in- and outside the vserver to get it running with this patch. i'll add them to my guide at http://dev.gentoo.org/~hollow/vserver/guide/ as soon as this patch goes into cvs fyi here is a list of init scripts included in baselayout and for what reason they need to be changed: bootmisc works checkfs may work, not needed by default (exit 0) checkroot may work, not needed by default (exit 0) clock fails (fake like UML) consolefont fails (fake like UML) crypto-loop unknown domainname may work, remove from runlevels halt.sh fails, util-vserver does all halting (exit 0) hostname may work, not needed by default (exit 0) keymaps fails (fake like UML) localmount may work, not needed by default (exit 0) modules fails, not supported by vserver (exit 0) net fails, util-vserver cares about interfaces for now, this could be changed by the new NGNet patches which are far away from stable (exit 0) netmount may work, remove from runlevels numlock fails, remove from runlevels reboot.sh fails, util-vserver does all rebooting (exit 0) serial fails, remove from runlevels
addition to comment #16 [ thanks for the "networking-ng" background ] xdm: uses /dev/initctl that is not available in vservers (ctx!=[0|1]) -- see patch for a possible solution. i didn't manage to test out the new stuff yet but as Benedikt did so it should be ok.
Created attachment 50964 [details, diff] xdm.initd.patch for vserver-guests patch against: # $Header: /home/cvsroot/gentoo-x86/x11-base/xfree/files/4.3.0/xdm.start,v # 1.3 2003/12/04 06:37:47 spyderous Exp $ from vserver-patched baselayout-1.9.4-r6
never used xdm in vservers, but initctl is not accessable, right. vapier: is there a possibility to fake the status of init scripts during boot? i'm thinking of an extra init scripts which fakes all the init scripts you won't need before
since this approach seems to never get into baselayout i will come up with another solution soon, please be patient.
It's not resolved, it's open and *critical*. Emerging baselayout on a gentoo vserver just breaks the vserver. Repatching must be done by hand. What a pain. Please reopen.
use openrc/baselayout-2
(In reply to comment #22) > use openrc/baselayout-2 > That is what i do and, (guess what) it won't boot unless this script is used to patch the vserver openrc/baselayout-2 stuff: /usr/lib/util-vserver/distributions/gentoo/initpost.
jamespic@gmail.com: I've got 10+ vservers that run fine with Baselayout2+openrc (Full ~arch systems) If you've got issues with that specific combination, please file a new bug.
(In reply to comment #24) > I've got 10+ vservers that run fine with Baselayout2+openrc (Full ~arch > systems) > I've got 10+ vservers that run fine with Baselayout2+openrc as well. But that's not the question i'm trying to empathize. If you do `emerge baselayout` in your vserver, and then reboot it from the host works perfectly? Wouldn't that mean that /usr/lib/util-vserver/distributions/gentoo/initpost is called by vserver ... build without any relevant reason? In that case i'll file an issue.
1. Reboot in my vservers works perfectly. 2. /usr/lib/util-vserver/distributions/gentoo/initpost (lib64) is part of sys-cluster/util-vserver, NOT baselayout or openrc, so emerging baselayout+openrc doesn't have anything to do with it. Open a new bug.
