Summary: | modifications to baselayout to add vserver-support | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Thomas Eckert <eckert.thomas> |
Component: | [OLD] baselayout | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | VERIFIED LATER | ||
Severity: | enhancement | CC: | GertThiel, hollow, jamespic, maze, patrick, satya, stephane.gautier, yvasilev |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 66472 | ||
Attachments: |
gentoo-vserver-baselayout.html
diff against 1.6.9 vserver.patch rc-scripts-1.6.9-vserver.diff xdm.initd.patch for vserver-guests |
Description
Thomas Eckert
2004-07-03 08:39:37 UTC
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. |