No War

Paul Sladen's s_context/vserver FAQ

(or all the question I can't be arsed to answer, yet again, as of 2003 March 9th 2005 January 17th)

Thanks for contributions received from Herbert Pötzl

Q: I can't remember how to unsubscribe?

Exactly the same way as you signed up! As you are clearly an intelligent person you can probably remember how you managed to sign up and do the same to unsubscribe. If you've forgotten, you can go to the mailing-list control on the main vserver site:

Sebastian Wolfgarton reminded me (2005-01-17) that the URL is now:

Q: Where are the mailing list archives now?

Vlad unfortunately had to stop running them. A full set going back to 2001 October can be found here:

Q: When I SSH/FTP to my vserver I still login into the host server?

The problem comes if you bind to `0.0.0.0' in the host server without using a `v_sshd' script. This then snatches all the addresses on the server (including all vserver addresses), even if the vservers haven't been started yet.

The best way is not to run much (or anything) in the host server--except SSH--and to make sure you either use a `v_ssh[d]' script, or manually set SSHd to bind to one IP address in the host server (including chbind'ing or remembering to disable `inetd').

If you are *just* running the SSH daemon (and NTP), my preferred option is to put the

	ListenAddress 1.2.3.4      # Host Server

directive in the `/etc/ssh/sshd_config' file). This will get rid of alot of your `problems' and allow you to find out what is happening more clearly. (But might cause some troubles if you change the host servers' IP Address ;-)

Q: Writing v_xxx scripts for the host server?

Note: the following is correct, works and is highly illustrative, however newer versions of the vserver tools use a different method.

Lets, for example, take a look at a sample `v_httpd':

	# description: Wrapper to start httpd bound to a single IP
	IP=eth0
	exec /usr/sbin/chbind --ip $IP /etc/init.d/httpd $*

the `chbind' tool `binds' (reduces) the IP address(es) to the given ones give in the `--ip $oneip' paramater (in this case the first IP address on eth0 and then calls the original script to start their service.

Q: I tried the first 40 links on Google! Where is the vserver Homepage?!

Jacques Gelinas' main site for the `s_context' (security context) Linux kernel patches and the vserver home page is:

Q: The main `ftp.solucorp.qc.ca' server is dead (again), is there a mirror?

The "Paul Sladen Mirror Service" provides a European mirror here:

Q: Where can I download Sam Vilain's Ext2 patches?

Sam's immutable-linkage-flag stuff can now be got here:

Q: How do I get Quota to work in vservers?

Read Herbert Pötzl's Quota Howto and get the Tools/Patches here:

Q: I "neeeed" to use the Redhat kernel sources?

Alexey Lyashkov provides patches against the Red-Hat source trees here:

Adam Pendleton also provides source-RPMs of the above:

Q: I "neeeed" a 2.4.$latest kernel, where are they?

Herbert Pötzl provides unoffical patches on his page:

Q: I "neeeed" -ac kernel patches, where are they?

Apparently, ``To patch the kernel you need:''

  1. 2.4.18 vanilla kernel
  2. The -ac3 patch (this is what I used)
  3. The vanilla ctx12 patch

and to apply them in that order. ``First apply the ac3 and then the ctx12 patch (the patches fail if applied in the other way). ac3 patches perfectly. ctx12 patches with some fuzz (no rejects).''

Additionally, some -ac patches are used in RH kernels so Alex's RH patches may (or may not) be helpful aswell:

Q: Where can I get decent Debian/Woody stuff

There is a `newvserver' and small patch to fix set-group-id (gid=tty) mounting `/dev/pts' under Debian systems here:

These second `.deb's were originally done for private use: (make sure you read the README file if you want to read them)

Mark Lawrence orginally did a `.deb' package and newvserver script. Opal has also done an out-of-date one that is in the Debian archive and requires messing about with Sid (view bug page). A while ago there was old stuff at this.is too.

Q: How can I run NTP in a vserver (or change the timezone)?

NTP is used to keep the kernel clock synchronized to GMT/UTC. This is a system level function and should be done in the host server.

Changing the timezone in a vserver is merely about telling Libc in that vserver what the current timezone offset is. This is done my changing the /etc/localtime file (and normally linking it to a different timezone).

This can be done by running `tzconfig' under Debian, or `timeconfig' on Red Hat based systems.

Q: Why does `du' complain about /proc access?

du: cannot change to directory `./proc/1/fd': Permission denied

This is related to the fakeinit fiddling that goes on to make the first-process in a context look-like it has pid=1 (pretending to be init, whereas the real pid=1a process is in a different context and so you can't access its resources.

`du' will give the correct answer though, it's much like the cosmetic problems with `lsof'.

Q: Why does klogd give an error?

Kernel logger (klogd) requires access to the kernel messages buffer which could allow klogd running inside vserver to ``steal'' messages intended for the root server. This is a "low-level" and should only be done in the main server and not within a vserver.

You should run `syslogd' in each server normally to continue monitoring the rest of the services.

Q: What still needs doing?

A new userspace and most of this lot by my reckoning:

Q: Bind 9 doesn't work in a vserver

It goes against the Unix design of irreversible giving up privileges and actually tries to raise its own `ulimit' privileges which is restricted in a vserver to stop anybody raising their processes above other vserver users.

It is Bind that is ``broken''. It can be fixed by recompiling with:

	./configure --disable-linux-caps

which fixes this stupidity. Curse the bind8 exploits, curse the maintainers who leave `--enable-linux-caps' on by default and curse the ISC coders for putting it in there in the first place! ;-)

The problem is actually slightly worse than this and is down to the bad assumptions that Bind9 makes about threads, linux and capabilities. Without fixing their over-intelligent detection code, you can only run Bind9 under vserver as root (uid=0). Since this is already running in a secure vserver this is less of a problem.

This seems to have come up a couple of times since:

The conclusion is to: run it as root within a vserver.

Q: How do I monitor bandwidth usage in a vserver?

	iptables -A INPUT  -i eth0 -d 10.0.0.42
	iptables -A OUTPUT -o eth0 -s 10.0.0.42
	iptables -A INPUT  -i eth0 -d 10.0.0.43
	iptables -A OUTPUT -o eth0 -s 10.0.0.43

and typing `iptables -xvL' will give you output something like:

 
	Chain INPUT (policy ACCEPT 7157991 packets, 932430425 bytes)
	    pkts    bytes target     prot opt in     out   source    destination
	     246    19163            all  --  eth0   any   anywhere  10.0.0.42
	    3298   230541            all  --  eth0   any   anywhere  10.0.0.43
	    5158   339958            all  --  eth0   any   anywhere  10.0.0.44

	Chain OUTPUT (policy ACCEPT 7574898 packets, 3080985747 bytes)
	    pkts    bytes target     prot opt in     out   source    destination
	    2054   344237            all  --  any    eth0  10.0.0.42 anywhere
	    2634   466259            all  --  any    eth0  10.0.0.43 anywhere
	    4059   734240            all  --  any    eth0  10.0.0.44 anywhere

Or, to have all that setup and cron'ed collection done nicely for you, use the IP-Accounting-Next-Generation Package (ipac-ng):

Q: Is IPv6 Support done?

No. Although it should be very easy to basically copy across the code from the IPv4 mangling. If anyone fancies doing it should basically be a cut and paste job. Jacque's last offical statement was in this thread:

Q: I heard chroot() isn't secure?

Lucky we fixed it then isn't it!... Remember to do:

	chmod 000 /vservers

Some people consider this a kludge; it is achieved by the addition of the following code to `fs/namei.c' in the kernel source:

	/*
		A dir with permission bit all 0s is a dead zone for
		process running in a vserver. By doing
			chmod 000 /vservers
		you fix the "escape from chroot" bug.
	*/
	if ((mode & 0777) == 0
		&& S_ISDIR(mode)
		&& current->s_context != 0) return -EACCES;

If a directory with permissions `000' (shown as `d---------') is accessed by a vserver, then `-EACCES' is returned regardlessly and permission is denied. (Normally a `000'ed file is only access by root and this changes to only accessible by root within the host-server).

Q: How do I transfer (`rsync') a vserver between hosting servers?

alpha and beta are hosting servers running the `s_context' patch. uno is the vserver to copy:

	alpha% rsync -aPxvze ssh --delete --stats --numeric-ids {,beta:}/vservers/uno/

Preserve attributes, show progress and continue where interrupted, don't cross filesytems, do be verbose, use SSH, dodelete files no-longer present on the alpha copy, show statistics.

Francois Deppierraz adds: ``The --numeric-ids rsync option is [required] to avoid messing with files ownership.''

With the `vserver' userspace tools version 0.22 onwards it may be worth investigating the `PROFILE=' options which may help with keep backups synchronized, but not running.

Q: Backup and replication using `dump/restore'?

Another method for backing up vservers (or duplicating between machines for failover) is to use the `dump' and `restore' tools which allow incremental backup and compression. Since these operate on the inode level they handle open files correctly (aswell as efficiently handling hardlinks in a unified setup).

Herbert Pötzl also has had good experiences with `dump' 0.4b32 producing pretty small (zlib/bzip2 compressed) images of a template server together with its clones using the following command:

	# dump 0zf <backup-file> /vservers/{<template>,<clone1>,<clone2>,...}

A practical example would be:

	# dump 0zf /backup/daily.dump /vservers/{ISRV,IS01,IS02,IS03}

Q: Tomcat doesn't work with localhost in a vserver?

Tomcat 3.3.1 can be made to work in a vserver by explicitly setting its IP address in the `server.xml' config file. However Tomcat 4.x apparently has a bug filed against it that implies that ``it cannot be fully configured to use an arbitrary IP address''.

Q: RPM updating on a (unified) system with `vrpm'?

Consider the following setup:

	SERV    (template used for vservers)
	SV01    (first vserver/clone)
	SV02    (second vserver/clone)
	SV03    (third vserver/clone)

and the package `wossname-0.1.noarch.rpm' needs to be updated on all the vservers to a newer version called `wossname-0.2.noarch.rpm', then usually this would be done with the following command on each vserver:

	rpm -U wossname-0.2.noarch.rpm

In vserver setup, you could do it the same way, by copying the package to each vserver SV01,SV02,SV03,... and manually installing it. A much better solution would be to use the `vrpm' wrapper script to upgrade all the vservers at once with the following command:

	# vrpm SERV SV01 SV02 SV03 -- -U wossname-0.2.noarch.rpm

Or even better:

	# vrpm --unify SERV SV01 SV02 SV03 -- -U wossname-0.2.noarch.rpm

which actually unifies the packages after installation/update.

Q: How to re-unify packages?

    	# /usr/lib/vserver/vunify <template> <clone1> <clone2> -- <packages>

For example to locate all the files from the `apache', `apache-conf' and `mod_php' RPM Packages three vservers/clones (IS01-03) from a common template (ISRV), use:

    	# /usr/lib/vserver/vunify ISRV IS01 IS02 IS03 -- apache apache-conf mod_php

(This is better because unification is a little more than just a hardlink; it is a hardlink with additional immuteability [except for removal]. Therefore you are not be able to change the file or link in the root server until you remove the immutable flag or the file. The script handles this correctly for you).

Q: NFS (Network File System)?

The kernel NFS server isn't available within a vserver. The userspace nfs client/server may work.

Q: What other capabilites can I use with a vserver?

Normally you restrict everything you can in a vserver, to do with accessing hardware or system-related features of the kernel (eg: filesystem mounting, rebooting, creating device nodes or setting the system clock). vservers are often given the `CAP_NET_RAW' to allow a vserver to produce low-level packets such as ICMP ping. Sometimes you may wish to allow them additional capabilites:

The `/usr/include/linux/capability.h' Include file helpfully lists the actual capabilities available and the following LIDS Howto (Linux Intrusion Detection System) lists what each capability enables/disables:

Update 2018: Joel Stephens noted that the original LIDS project website is down. But that a good comparision overview of a number of Linux-related intrusion-detection systems can be found at:

Q: How do I patch my kernel?

This is answered in many places, such as the Kernel-HOWTO:

See the section for where to download patches above.

Some more vserver stuff.

Back to the rest of Paul Sladen.