From: Jacques Gelinas (jack_at_solucorp.qc.ca)
Date: Tue 14 May 2002 - 04:59:04 BST
On Mon, 13 May 2002 12:33:48 -0500, Justin M Kuntz wrote
>
> Hello,
>
> I've used the /usr/lib/vserver/install-rh7.2 script to create my first
> vserver. The only problem I noticed with this process is the install-rh7.2
> script references install_post.sh when really it should be install-post.sh
>
> Now that I have my verver up and running on 2.4.18-ctx10 with vserver 0.17,
> I wanted to understand better the boot process and what is the minimum
> process list that should be operating in a vserver environment. The
> /usr/lib/vserver/install-post.sh script was very helpful to understand what
> vserver is doing after installing the RPMs.
>
> The inittab does a few things I think should be disabled, and I'd like to
> hear your thoughts. First, the default sysinit is called:
> si::sysinit:/etc/rc.d/rc.sysinit
>
> ... and this rc.sysinit script does all sorts of things which could and
> probably should be trimmed down for a vserver. Notably, it does file
> system checking, starts up pre-syslog logging, etc. I noticed the update
> daemon doesn't look like it needs to be running on vservers as well as the
> main server, so I commented that out as follows:
rc.sysinit does not contain anything useful (or doable by) for a vserver.
> # Things to run in every runlevel.
> #JMK - I think this should not be running since the main server runs
> kupdate
> #ud::once:/sbin/update
Indeed update is only needed a single time on the physical server.
> I assume these lines probably wouldn't mean much in a vserver because the
> primary init is not going to know to tell the vserver inits what is
> happening in case of powerfailure or ctrl-alt-del by default, without
> special configuration... so I left them alone for now:
> ca::ctrlaltdel:/sbin/shutdown -t3 -r now
> pf::powerfail:/sbin/shutdown -f -h +2 "Power Failure; System Shutting Down"
> pr:12345:powerokwait:/sbin/shutdown -c "Power Restored; Shutdown Cancelled"
Right.
> The tty inputs I assume can all be disabled since the vserver has no
> control over the main machine's console anyway, and they'll just generate
> needless /var/log/messages traffic in the vserver about not having access
> to the ttys?
> # Run gettys in standard runlevels
> #1:2345:respawn:/sbin/mingetty tty1
> #2:2345:respawn:/sbin/mingetty tty2
> #3:2345:respawn:/sbin/mingetty tty3
> #4:2345:respawn:/sbin/mingetty tty4
> #5:2345:respawn:/sbin/mingetty tty5
> #6:2345:respawn:/sbin/mingetty tty6
If you create say /dev/tty2 in a vserver, then it would be possible to
have one console per vserver. A neat way to switch between them as needed.
/dev/ttyX are not created by default on vservers. You will need to trim the
tty usage on the root server, in its own /etc/inittab.
> This leaves me with my big question being what to do with syslog and
> minilogd. I assume that the processes running inside the vserver are going
> to try to talk to the standard logging mechanism inside that vserver. Red
> Hat has a white paper on this which is a good read:
> http://www.redhat.com/support/wpapers/redhat/initscripts/index.html#toc
No, by default they can't reach the root syslog. They talk to the syslog daemon
using /dev/log, which is a unix domain socket. In general, each vserver runs its
own syslogd process, so each has its own set of /var/log files. In general a vserver
will also run crond, so log files are rotated once in a while.
Note that a syslogd daemon can setup multiple /dev/log socket. or you can use
hard links to setup /dev/log using the root server /dev/log in every vserver.
This way, logging would go to the root log files.
This could be used in a high security setup, where logging become invisible
to a vserver (and thus an attacker wanting to cleanup).
Another solution would be to run one syslogd setup per vserver, but in the root
server. This will avoid mixing messages from each vservers.
> So this is what I get after running "vserver rh72 start" followed by
> "vserver rh72 enter":
> [root_at_vserver:rh72 log]ps -ef
> UID PID PPID C STIME TTY TIME CMD
> root 1 0 0 May11 ? 00:00:06 init [3]
> root 14695 1 0 13:14 ? 00:00:00 minilogd
> root 14911 14900 0 13:15 pts/3 00:00:00 /bin/bash -login
> root 14965 14911 0 13:15 pts/3 00:00:00 ps -ef
> [root_at_vserver:rh72 log]
>
> Now, minilogd is running but I think it is just collecting the messages and
> not actually writing them anywhere until we start syslog. But starting
> syslog also attempts to start a kernel log daemon, which I don't think we
> want since the main server is already going to be running a kernel log
> daemon - right?
Yes klogd can't grab kernel message (capability). But start the syslog service
anyway. It fails to start klogd but syslogd starts and work fine.
> [root_at_vserver:rh72 init.d]./syslog start
> Starting system logger: [ OK ]
> Starting kernel logger: [ OK ]
> [root_at_vserver:rh72 init.d]ps -ef
> UID PID PPID C STIME TTY TIME CMD
> root 1 0 0 May11 ? 00:00:06 init [3]
> root 14911 14900 0 13:15 pts/3 00:00:00 /bin/bash -login
> root 14979 1 0 13:16 ? 00:00:00 syslogd -m 0
> root 14987 14911 0 13:16 pts/3 00:00:00 ps -ef
> [root_at_vserver:rh72 init.d]
>
>
> So somehow by running syslog, it is disabling the minilogd and replacing
> that with syslogd, and I'm not sure why the kerneld doesn't startup too.
You don't need kernel on a 2.4 kernel. Further, kerneld can,t work in a vserver
since a vserver is not allowed to load kernel module.
Or you mean klogd. klogd is not allowed to work in a vserver because
of the capability system. If it was allowed, it would steal message away
from the root server.
> I'd appreciate any ideas or suggestions to further streamline the startup
> process and make sure minimal services and logging are loaded which won't
> interfere with the root server.
In general, we do not run /sbin/init in a vserver. We simply start services
in runlevel 3 (whatever is defined in /etc/inittab as the default). In general
we have sshd, syslog and crond running.
> For now I'm going to re-enable syslog inside the vserver as follows:
> [root_at_vserver:rh72 /]chkconfig --level 2345 syslog on
Yes this is we do on our vserver.
---------------------------------------------------------
Jacques Gelinas <jack_at_solucorp.qc.ca>
vserver: run general purpose virtual servers on one box, full speed!
http://www.solucorp.qc.ca/miscprj/s_context.hc