vserver all changes logs

vserver all changes logs

Change log index

Version 0.0


First release

This is the first release of a very interesting project: Running several general purpose Linux server on a single box with a high degree of Independence and security. Check it out.

vserver package

Beside the kernel patch, the vserver package was created. It includes the utilities and the framework to handle several virtual servers.

Version 0.1


New v_xxx sysv init scripts to help the main server

If you are running the same network services both in the main server and virtual servers, you may end up with a little problem: The service in the virtual server can't start because the TCP port is already used by the main server. The solution is to restrict the main server service (HTTP for example) to use a single IP instead of all ( While most service may be configured to achieve that this is annoying. Using the chbind utility, part of this package (vserver) one can start any service, bound to a single IP. For example, you can do:

	/etc/rc.d/init.d/httpd stop
	/usr/sbin/chbind --ip eth0 /etc/rc.d/init.d/httpd start

This is annoying, especially because we want to automate the boot process. To solve this, the vserver package supplies 3 new services in the main server. They are off by default. There is v_sshd, v_xinetd and v_httpd. Those services are simple wrapper to start the original service using the chbind command above. So if you need to run the same network service in the main server and some virtual server, turn off the service (linuxconf/control/control service activity) and enable the corresponding v_ service.

Bug fixes

vserver build command

The build command populates a vserver and creates dummy /etc/fstab and /etc/mtab. This way, the df command is happy as well as other admin tools (Linuxconf for one). Previous versions of the vserver packages were copying the fstab and mtab of the main server and this was producing confusing output.

Version 0.2



The documentation found at http://www.solucorp.qc.ca/miscprj/s_context.hc was enhanced. Worth a review...

rebootmgr and vreboot utility

A virtual server is not able/allowed to re boot the computer. It is nevertheless useful to simulate a robot of the virtual server services. Basically, we end all services, kill all remaining processes and start over. This is achieved by running the following command from the main server:

	/usr/sbin/vserver SERVER restart

But it can't be executed from inside the virtual server. To solve this the rebootmgr (robot manager) was created. It is a service which installs a unix domain socket in each virtual server (/dev/reboot). The /sbin/vreboot utility is used to request a reboot from any virtual server. The reboot manager knows which vserver is sending the request and execute the command above.

The /sbin/vhalt utility is supplied as well, which simply end a virtual server activity.

The rebootmgr is a service and is off by default. You must enable it.

Bug fixes

Stopping a virtual server

There was a flaw in the vserver utility and sometime, a virtual server was not ended properly. Some processes were left running and this was preventing the restart of the vserver.

Version 0.3


/usr/sbin/vserver enhancements

The vserver utility is doing the /proc and /dev/pts mount when a vserver is started. It was calling the mount command with relative path and this was confusing /etc/mtab somewhat. It is now using absolute paths.

vserver is also a little more verbose when starting and stopping a vserver. This makes the /var/log/boot.log file a little more explicit.

Missing LICENSE file

The vserver is licensed under the GNU Public License (GPL). The package was missing the LICENSE file stating that.

Missing readlink utility

The vserverkillall (used by vserver VSERVER stop) was relying on the readlink utility, which is not always available (delivered with tetex). The vserver package now includes its own readlink utility in /usr/lib/vserver.

Bug fixes

New kernel 2.4.10ctx-2

A fix was done in the kernel to prevent changes in /proc from a virtual server administrator. The /proc file system was not properly protected by a capability. It is now. You can find the kernel patch patch-2.4.10ctx-2 as well as two pre-compiled kernel binaries for UP and SMP machines (kernel-2.4.10ctx-2.tar.gz)

rebootmgr ineffective when start at boot time

The rebootmgr service was not working at all. When notified to reboot or halt a virtual server, it was completely failing because its standard output and standard error channel was pointing to closed pipes. Now it redirect the /usr/sbin/vserver command to /var/log/boot.log (append).

rebootmgr service not restarted by Linuxconf

When you add a new virtual server, you must restart the rebootmgr service so it properly setup its /dev/reboot socket in that vserver.

The sysv init script was missing the tags used by Linuxconf so it knows when rebootmgr must be restarted.

Version 0.4


/usr/lib/vserver/vunify utility: new

The vunify script is used to unify the disk space used by several vservers. Vservers are running in chroot environment. As such, they can't share files. This is useful (secure, flexible), but annoying: Not fun having glibc installed 10 times for example.

It is possible to share files using hard links. vunify was created to merge common package using hard link so they use the same disk space. It works like this

/usr/lib/vserver/vunify refserver serv1 serv2 serv3 -- pkg1 pkg2 pkg3 ...

refserver is the reference server. serv1 to serv3 are other vservers and all vservers have a copy of the same RPM packages pkg1, pkg2. The utility will extract the list of file own by the various packages. Configuration files are omitted from the list. Then it will walk the vservers and erase the files and setup a hard link pointing to the file in refserver. Once done, it will turn the file immutable bit. This bit prevent the vservers from modifying the file. Even root can't do it. You will end up saving a log of disk space. You may gain some performance as well since the various shared object will be loaded only once in memory for all vservers. This could be noticeable if you have many vservers.

Experiment have shown that unifying the packages bash, glibc, perl and binutils save 60 megabytes per vserver. Given those package seldom change, this is a nice saving.

vunify also feature a --undo option to un-unify some package. It turns off the immutable bit and place a copy of the files in each vservers. This can be useful if you intend to update one package.

Have fun!

vserver command enhancement

The build option now turn off all service in the newly created vserver. this is useful because in general, a vserver runs few services. Further, many common services found in Linux are useless in a vserver environment. So after installing a vserver "enter" it (vserver VSERVER-name enter) and enable the service you need with either Linuxconf or chkconfig.

Bug fixes

rebootmgr service missing

vserver 0.3 has introduced a new service called rebootmgr allowing virtual server to request a reboot (of themselves). Unfortunately the sysv init script was missing in the package.

Version 0.5

The new vserver package relies on new ability found in the kernel patch ftp://ftp.solucorp.qc.ca/pub/vserver/diffctx-2.4.11-3 . This patch works with 2.4.12 as well. I have not released pre-compiled kernel for now.


chcontext and reducecap command line option

The two utilities support the new --flag command line option. This is used to set some flags in the security context. For new the two flags are:

  • lock

    Once set, a security context is locked. It can't request another security context.

  • sched

    This changes the way priority is calculated for processes in a vserver. The priority is kind of aglomerated. A vserver running 50 active processes will have a same impact on the server as if it was running a single process (roughly).

All those flags are one-shot. You can set them, you can't unset them.

vserver command: S_FLAGS support<

The vserver command supports the new --flag command line option of the chcontext utility. You encode the flags (lock and sched) in the vserver configuration (/etc/vservers/confname.conf) like this

	S_FLAGS="lock sched"

By default, all new vserver are created with S_FLAGS="lock".

Version 0.6


New kernel 2.4.13 and new immutable flags

The patch now work on top of kernel 2.4.13. Both normal and SMP kernel are supplied. This new kernel provides mostly the same feature and implementation as before. Here are the changes:

  • System call number has been changed to avoid conflict with other new feature in the kernel.

  • New IMMUTABLE-LINK-INVERT flag. This was contributed by Sam Vilain (sam@vilain.net). This new ext2 flag solves the unification issues. When you unify two vservers, to save disk space, you have to protect the file somewhat, to avoid one vserver from affecting the other. The solution is to turn the file immutable so even root can't modify them (root in vservers is not allowed to play with the immutable bit).

    There was a drawback with this. The unified vservers were locked somewhat. A vserver administrator could not perform package update for example.

    The new IMMUTABLE-LINKAGE-INVERT solves this. It modifies the way an immutable file behave. With this flag on, the file may be unlinked (removed), allowing normal package updates. But the original data can't be modified.

    The default for vunify and vbuild is to set both IMMUTABLE-FILE and IMMUTABLE-LINKAGE-INVERT bits on linked file. This gives you robustness (one vserver can't modify the linked file shared by other vservers) and flexibility (one vserver may evolve independently.

You absolutely need vserver 0.6 to use this kernel. You can find more information about the new immutable-linkage-invert flag at http://sam.vilain.net/immutable. You will find there a modified ext2fsprog package to use those flags. The vunify and vbuild utility do not need this package to operate though.

New vbuild utility

The /usr/lib/vserver/vbuild utility has been written. It allows one to clone a reference vserver, hard linking files when possible. You end up creating a new virtual private server with a large package set, yet using only few megs of disk space. Like the vunify command, vbuild sets the immutable flag on linked file so the vserver can't change them (since they are shared between several vservers).

Here is the command line usage:

vbuild [ options ] reference-server new-vservers

  • --test
    Show what will be done, do not do it.
    (not completed)
  • --debug
    Prints some debugging messages.
  • --noflags
    Do not put any immutable flags on the file
  • --immutable
    Set the immutable_file bit on the files.
  • --immutable-mayunlink
    Sets the immutable_link flag on files.
  • --stats
    Produce statistics on the number of file linked copied and so on.

By default, the immutable_file and immutable_link flags are set on the files. So if you want no immutable flags, you must use --noflags. If you want a single flag, you must use --noflags first, then the --immutable or --immutable-mayunlink flag.

New vtop utility

vtop is a simple shell script, executing the top utility in security context 1, so it can see all processes.

vunify rewrite

The /usr/lib/vserver/vunify utility has been rewritten. It uses roughly the same syntax with few more options.

vunify [ options ] reference-server vservers ... -- packages

  • --test
    Show what will be done, do not do it.
  • --undo
    Put back the file in place, using copies from the reference server.
  • --debug
    Prints some debugging messages.
  • --noflags
    Do not put any immutable flags on the file.
  • --immutable
    Set the immutable_file bit on the files.
  • --immutable-mayunlink
    Sets the immutable_link flag on files.

By default, the immutable_file and immutable_link flags are set on the files. So if you want no immutable flags, you must use --noflags. If you want a single flag, you must use --noflags first, then the --immutable or --immutable-mayunlink flag.

If packages is ALL, then all common package with the reference server will be unified. The new vunify makes sure this is the same package version before unifying.


System call renumbering

The system call we had chosen was already assigned to other projects so we picked new number. This make the old vserver package incompatible with the newer kernel 2.4.13ctx-3.

If you have already some vserver running and want to upgrade to the new kernel, here is the update sequence:

	# Stop all vservers
	/etc/rc.d/init.d/vservers stop
	# Disable the vservers service
	/sbin/chkconfig vservers off
	# Install the new kernel in LILO
	# reboot
	# Update to the new vserver package
	rpm -Uvh vserver-0.6-1.i386.rpm
	# Enable the vservers package
	/sbin/chkconfig vservers on
	# Start the vservers
	/etc/rc.d/init.d/vservers start

Version 0.7


/usr/sbin/vserver enhancements

The utility now handles the following enhancements in the vserver configuration file:


    This setting defines ulimit settings passed to the vserver when it is started.

  • S_CAPS

    This contains a set of capability available to vserver. For example, if you want a vserver to be able to do some pings, put the CAP_NET_RAW capability there.

When starting a vserver, the /var/run directory was not cleared. In some situation, the various startup script were failing because a bogus PID file was left there from a previous run.

chcontext: --cap option

The --cap option was added to help configure capabilities. The --secure option was too restrictive. --secure is used to remove critical capabilities and --cap is used to invert the effect by adding back some capabilities. This is used by the /usr/sbin/vserver front-end to handle the new S_CAPS /etc/vservers/*.conf configuration files.

chcontext: new --flag values

Two new flags are now handled by chcontext (and reducecap). Those flags are nproc and private. The nproc flag establish a hard limit on the number of processes run-able in a virtual server. It makes the original ulimit (-u) setting global to the vserver instead of just per user.

The private flag is a little weird. Once a security context has this flag set, it is not possible to join it. Even root in the root server with all capabilities is not allowed. This makes the virtual server fairly private. Security context 1 can still see which processes are executing in the vserver, but can't interfere.


A new kernel is available as well. The changes are minimal this time (the old vserver utilities are still compatible). Here they are:

  • ext3 file system

    Since ext3 is now part of 2.4.16, it has been modified to support the IMMUTABLE_LINKAGE feature.

  • ext3,ext2 and reiserfs are compiled (not as module) so they can be easily used as root file system.

  • The nproc and private security context flag have been added. nproc is especially useful to limit the total number of process in a vserver. Fork bomb are not possible anymore.

  • A little bug fix. It was possible to produce a oops with the new_s_context system call, when called by a non root user in the root server.

  • I am also supplying the patch against 2.4.13 (without the ext3 stuff) for those who wants it.

    The vservers service

    This sysv init script is used to start and stop all virtual private server. It only starts the vservers with the ONBOOT flag set to yes. It used to only end vservers with ONBOOT=yes as well. This was not really helpful. So now it starts the vservers with ONBOOT=yes, but stops any vservers.

    vserver-stat: new utility

    The /usr/sbin/vserver-stat was contributed by Guillaum Dallaire. It produces a report showing a summary of the different vservers. You see the number of process per vservers for example.

Bug fixes

chbind: identifying network device

chbind had a bad habit of probing the kernel for any value of the --ip command line option. Even if it was not a network device at all. This was triggering error message from modprobe. It now checks in /proc/net/dev first.

Version 0.9


/usr/sbin/newvserver: new

/usr/sbin/newvserver is an admin tool to help create new vserver. It allows you to enter pretty everything you need to specify a virtual private server. It supports unification. You pick the reference vserver and it does the job. It creates the vserver configuration file and update the vserver /etc/hosts accordingly.

This utility works both in graphical and text mode. You must install the packages linuxconf-lib and linuxconf-util from http://www.solucorp.qc.ca/linuxconf/download.hc .

I have separated the vserver package in two: vserver and vserver-admin. newvserver is part of the later.

/usr/sbin/vrpm: new

vrpm is a little wrapper for the rpm command. It lets you apply an RPM command on several vservers. For example, you can do

	/usr/sbin/vrpm ALL -- -Uvh /tmp/*.rpm
	/usr/sbin/vrpm server1 server2 -- -Uvh this-rpm.rpm

It takes care of the --root command line option.

/usr/sbin/vserver: new features

Various little things were added to this command:

  • /usr/sbin/vserver server stop

    This always umount /proc and /dev/pts even if the vserver was not running. The "enter" command leaves /proc and /dev/pts mounted and this was causing problems at shutdown time.

  • /usr/sbin/vserver server service service_name start|stop|restart

    This is a little helper to control a service inside a vserver. This allows you to enter, act on a sysv service and leave.

  • /usr/sbin/vserver server exec some commands

    This lets you execute a command in the context of a vserver and exits. The "service" and "enter" commands are implemented on top of that.

kernel 2.4.17 ctx-5

I have tested the vserver patch on 2.4.17. I have also found a bug in the ext3 fs for the new immutable-linkage. Unification was not working on an ext3 file system. Now all seems fine.

vbuild: one file system

The /usr/lib/vserver/vbuild utility has been enhanced to stay in one file system only. It is possible to build a vserver from another which has mount point (/proc generally) active.

Version 0.10


/usr/lib/vserver/vdu: New

This is a limited clone of the du command. It skips file with more than one link. It is used to evaluate the disk usage of an unified vserver. Using the normal du for this task is misleading since it will count all unified files.

/usr/sbin/newvserver: more stats

The utility now reports more statistic about the amount of file and directory copied/linked.

CAP_SYS_CHROOT capability

It is now possible to remove this capability from a vserver (No process, not even root, in a vserver can use the chroot system call). Just place !CAP_SYS_CHROOT in the S_CAPS variable of the vserver configuration file.

To support this feature, the /usr/sbin/vserver script had to be reworked a bit since entering a vserver context involves using chroot. So we had to kind of enter the context, then kill CAP_SYS_CHROOT

chroot and security issues: plugged

The new ctx-6 kernel solves the issues with chroot. With previous kernel, root inside a vserver with the CAP_SYS_CHROOT capability was able to escape out of the vserver and enter the root server. We solve this using a single line in fs/namei.c:vfs_permission(). All chroot escape involves walking you way toward the real root using relative chdir (chdir("..")). The trick was to make the /vservers directory into a "no man land" by issuing the following command:

	chmod 000 /vservers

Setting these permission bits (well turning them all off) make the directory inaccessible for any other user than root. The change in the kernel ctx-6 makes such a directory unusable even by root in a different security context (not 0).

The /usr/sbin/vserver will create the /vservers appropriately. If the directory exist, it will check the permissions and signal the admin if they are not 000.

New kernel ctx-6

The new kernel patch-2.4.17ctx-6 introduce many enhancements. This is still binary compatible, so moving to this kernel does not involve any configuration changes. Updating to vserver 0.10 is recommended, but there is no special upgrade step.

The features are:

  • /dev/pts is now private in each vserver. One vserver can't see or interfere with the other pseudo-tty of the other server, including the root server.
  • Network device: A vserver can only see the network device associated with its ipv4 root.
  • system V ipc: The sysv ipc resources are now private per security context.
  • The fakeinit concept allow usage of a normal /sbin/init in a vserver.
  • A signal handling bug was solved. The most noticeable feature is that cntrl-C now work when using "vserver name enter". Other networking issue are probably solved by this.

You can get the patch and binaries as usual from ftp://ftp.solucorp.qc.ca/pub/vserver . The pub/vserver/patches also contains a relative patch from ctx-5 to ctx-6. You can review what was done this way.

This kernel plugs probably most security issues. There is still to many things visible in /proc as seen from a vserver. A new file system called vproc will be written to provide a limited view.

While this kernel should prevent a vserver administrator to gain access to the vserver, there are still ways to produce some DOS by exhausting all resources. The nproc feature works correctly and control the amount of processes used by a vserver. Some more work is needed to address all the other resource limits (files, memory, ...)

No NIS domain in a vserver

A vserver may be run with a different NIS domain name than the root server. Or it could run with the same. To keep the same domain name, one just had to set the S_DOMAINNAME variable to the vserver configuration file to nothing.

There were no way to tell that you did not want a NIS domain name in a vserver when there was one set in the root server. You can now enter "none" as the S_DOMAINNAME value to achieve this.

Per vserver /sbin/init

The ctx-6 kernel supports the fakeinit context flag. This flag is entered in the S_FLAGS line of the vserver configuration file (/etc/vservers/xx.conf). Once you set this flag, the vserver will be started and stop using /sbin/init, found in the vserver environment. This is a normal /sbin/init as supplied by the distribution. You should take care of cleaning up /etc/inittab in the vserver environment. Using this feature, it is possible to use various run level in the vserver, switch between them and so on. You can also use respawn /etc/inittab services as well.

Here is what fakeinit does in the kernel:

This assigned the current process so it works like the process number 1. Using this trick, a normal /sbin/init may be run in a vserver. The /usr/sbin/vserver command will use /sbin/init to start and stop a vserver. A properly configured /etc/inittab is needed though.

  • Processes loosing their parent are re-parent to this process.
  • getppid() done by child process of this process returns 1.
  • getpid() done by this process returns 1.
  • This process is not shown in /proc since process number 1 is always shown.
  • An "initpid" entry is available in /proc/*/status to tell which process is the fake init process.

One nice thing about this feature is that the /usr/sbin/vserver is somewhat distribution independent. It simply runs /sbin/init to start a vserver and then "/sbin/init 6" to stop it (and then kills the remaining process). There are some drawbacks (for now) though and input are welcome.

First, the vserver start-up is no more synchronous. The /usr/sbin/vserver used to run "/etc/rc.d/rc 3" and wait until it ends. Now, it runs /sbin/init, but /sbin/init won't end until the vserver ends. So /usr/sbin/vserver has to let go /sbin/init in background. This is a little annoying.

When a vserver is started like this, we don't see all the service started as before. Without fakeinit, we see each service getting started and a OK/FAIL message for each. Now, it goes completely silent. I have not investigated this behavior. I suspect /sbin/init is opening a new tty (console) and runs the start-up scripts using that newly open console.

Since /sbin/init runs all the start-up code, we don't know when it is done so we can't run the post-start section of the /etc/vservers/xx.sh script properly.

Note that both start-up strategy still work: fakeinit and the original. So you current vserver installation will work as before without any fiddling. Once we have iron out the fakeinit drawback, this will become the default way of doing things.

Some capability missing

The chcontext and reducecap utility were incomplete. Many capabilities were not handled. They are now complete.

Bug fixes

/usr/sbin/vserver-stat: some fixes

The vserver-stat utility had various output glitches.

Version 0.11


/usr/sbin/vkill: new<

This is a simple script. You do

	/usr/sbin/vkill PID

and it will locate the vserver owning that process, enter its security context and issue the kill.


Various enhancements:

  • /var/run

    Only files are erased from /var/run at vserver build and start-up time. Sub-directories are left. Also, /var/run/utmp is created empty at start-up time.

  • /var/log/wtmp

    It is created empty at vserver build time. It is ignored after that.

  • 5 seconds sleep after stopping a vserver, before killing the remaining processes. 5 instead of 2.

  • S_CAPS not processed when entering a vserver

    When entering a running vserver, the S_CAPS setting was not enabled for the shell. So if you had given the vserver some capabilities, they were not available when using "enter".

Dynamic system call number

The 2 system calls used by the vserver project are not yet reserved in the kernel. To help people using the vserver patch with other patches, having conflicting system call number, the ctx-8 publish in /proc/self/status the system call numbers. The various utilities (chbind, reducecap and chcontext) are using this information on the fly. So you can move the system call around and the utilities keep working without recompile.

kernel ctx-8

Here is a small change log:

  • Dynamic system calls numbering

  • Per user/per context resources.

    The ulimit resources for a user used to be shared across vserver. This was plain wrong since user ID N in a vserver is unrelated to user ID N in another vserver.

    Contributed by Patrick Schaaf <bof@bof.de>

  • Using in a vserver.

    Note, this is unrelated to the multi-IP-per-vserver concept. A vserver normally use a single IP to listen and talk. In general, this is not a problem. But it breaks a little semantic. Most services out there simply do a bind on IP This way, they expect to grab any incoming traffic. They also expect that talking to is a good way (configuration less) to talk to themselves. Some services are using localhost (which is redirect to the ipv4root of the vserver) and some are using directly.

    The ctx-8 kernel now maps to the ipv4root of the vserver on the fly. This solves some issues with samba and should also (not tested) solve the issue with PostgreSQL.

  • Per vserver network activity.

    The output of netstat is now filtered by vserver. This includes /proc/net/tcp. This is not done per ipv4root but using the security context. This was contributed by Martin Josefsson <gandalf@wlug.westbo.se>

Man pages for most utilities

Thanks to klavs klavsen <kl@vsen.dk>, we have now a man page for all utilities. Now, we need a man page for the 2 system calls.

Version 0.12


kernel 2.4.18ctx-8

Nothing new vserver wise. The patch-2.4.17ctx-8 was adapted to the new kernel 2.4.18. There were minor adjustment needed in kernel/exit.c and kernel/fork.c. No new features.

2.4.18 introduces new system calls (reserved at least), so we had to move our own at the end. If you have vserver-0.12, it does not matter, as it adapts to the kernel on the fly. You can use the same binary to run a 2.4.17ctx-any kernel or the new 2.4.18ctx-8.

Bug fixes

dynamic system call

There was a bug. It was not working for the new_s_context. To move to the new 2.4.18ctx-8 kernel, you need vserver-0.12.

vserver-stat was changed to use the new dynamic system call feature

Version 0.13

Bug fixes

Dynamic system call number, a glitch

Since vserver 0.11, the vserver utility are able to probe the kernel to find the number of the system calls new_s_context and set_ipv4root. The same binaries may be used with different kernels (where the new system calls have different numbers).

This was done because the two system calls are not official( reserved in the official kernel) and probably won't be until we have covered more grounds...

vserver-0.12 uncovered a flaw where the file /proc/self/status was not properly parsed. But there was another gotcha. When used with an older kernel (older than 2.4.17ctx-8), the utility were using the values in /usr/include/asm/unistd.h. Unfortunately, those values are dependent on the kernel currently installed on your computer. If it is a 2.4.18 kernel, the system calls have different number than on older 2.4.17 kernel.

To make the story short, the vserver-0.13 utilities are not relying on kernel headers for their default, so work with older kernel as well as the new 2.4.17ctx-8 or 2.4.18ctx-8. They have been tested on 2.4.17ctx-6. Please upgrade.

Version 0.14


chbind: broadcast address

chbind accepts the --bcast option. It is supporting the new set_ipv4root which requires an IP number and a broadcast address.

If you only specify the --ip option with a device, the broadcast address of the device is used. This is used namely in the /etc/init.d/v_xxxx services.

/usr/sbin/chbind --ip eth0 /bin/sh

the new chbind works on older kernel. The broadcast address is simply ignored.

kernel 2.4.18ctx-9: set_ipv4root changed

This new kernel enhances set_ipv4root a bit. This is not the multi-ip support yet though. This kernel allows application relying on broadcast to work in vservers. The trick is to assigned both an IP number and a broadcast address to a vserver. The socket handling for UDP was modified a little (one line in net/ipv4/udp.c) so an incoming packet is processed if it matched the vserver IP or the vserver broadcast address.

There is no configuration changed to take advantage of that. You need the new kernel and vserver-0.14. Stuff like samba (which was already working in most cases) are now working completely. Even dhcpd works inside a vserver (see the FAQ though).

So the set_ipv4root was changed, but the kernel sports a syscall versioning system and vserver-0.14 supports it. So vserver-0.14 works with any "ctx" kernel. The new kernel works also with older vserver utilities except the vserver broadcast address will be improperly assigned.

vfiles: new utility

The vfiles utility is used to extract the list of non-unifiable files in a vserver. The utility works like this

/usr/sbin/vfiles reference-server server

Using the output of this command, one may archive only the relevant part of a vserver. You can use this to move a vserver from one server to another. Only move few megs. On the target server, use vunify to fill the missing files. You must have a identical reference server on the target server though.

Anyway, this is general purpose. Life may tell us if this is really useful :-)

vps reworked

vps was reworked a little. The previous version was not working on some distro. Test it out.

vserver configuration file

There are two new optional entries in /etc/vservers/*.conf:

  • IPROOTMASK: This is the netmask used to configure the IP alias. By default, it uses the netmask of the IPROOTDEV device.

  • IPROOTBCAST: This is the broadcast address used to configure the IP alias. Again, it uses the IPROOTDEV device settings by default.

You generally do not need to assign those fields. Just upgrading to vserver 0.14 and restarting your vserver and the IP alias will be configure. This was an issue for some service (as seen on the mailing list). Prior version were always setting the netmask to

vserver-stat and dynamic system calls

The utility was using fixed system call numbers unlike the other vserver utilities. Fixed!

v_xxxx services enhancements

/etc/init.d/v_sendmail was added to the list. By default each v_xxxx service perform a chbind on the main eth0 address. For each service, you can setup a file called /etc/vservices/service.conf (one per service). In that file, you can specify a different IP or device.


The extra configuration file is optional.

Version 0.16


Install vserver from cdrom

This is a start and contributions are welcome. I have written a script called /usr/lib/vserver/install-rh7.2. This script expects a single argument (for now), which is the name of the vserver to create. It will install a vserver based on Red Hat 7.2 CD (found in /mnt/cdrom) from scratch. It is not using the root server at all. It installs everything from the first CD. With unification, it creates a not-so-big vserver and contains pretty much anything an admin might want.

I would be interested in other script like this to install SuSE, Mandrake and Debian from scratch. At some point, the newvserver front-end will offer those in the pop-up list. So you will be able to install either from the root server, from another vserver or from any distribution CDroms.

Contribution welcome :-)

v services all supporting /etc/vservices/*.conf configuration

All the /etc/init.d/v_xxx services are now completed and use the optional /etc/vservices/xxx.conf file. This file provides the IP number to use to bind the service. By default, the service is bound to eth0. Using the optional file, you bind it to whatever you want

For example:


Various /usr/sbin/vxxxx utilities

Utilities like vtop, vpstree and friends are using /usr/sbin/chcontext to switch to context number 1. They are using the --silent option so you don't see the "New security context is 1" needlessly.

vserver script enhancement

A vserver may operate with as its IPROOT. This means the vserver is allowed to use any IP it wants, like the root server. The vserver script was trying to setup and IP alias with this address.

When not using the fakeinit (per vserver private init process) facility the vserver script was starting in runlevel 3. It is now using the default runlevel (initdefault) found in the vserver /etc/inittab file. One step closer to have this script distribution independent. Please test it and send me other fixes as needed.

The script uses /etc/init.d or /etc/rc.d/init.d on the fly.

When stopping a vserver, the IP alias is removed even if the vserver was not running. When you "enter" a vserver, the IP alias is put in place. If you stop it, it is removed. Especially useful when you fiddle with a two copies of a vserver (on different physical server).

When stopping a vserver, the vserver script /etc/vservers/xx.sh is always called with the post-stop argument. So doing a "vserver xx stop" clean everything.

When doing "vserver xx exec ..." or "vserver xx enter" and the vserver xx is not running, the /etc/vservers/xx.sh script is called with the pre-start option, making sure the vserver is entered with the proper environment.

When doing "vserver xx enter", bash is started with the option --login. This insure proper environment settings.

Bug fixes

chcontext: printing wrong result

When switching to a specific security context (generally context number one), chcontext was reporting 0 as the new context. A little miss-leading. Fixed!

cosmetic bug in save_s_context and vserverkillall

Those two utilities were reporting some shell errors. Although arm-less it was annoying. You could see the bug when shutting down a vserver.

kernel ctx-10

Thanks to Willy Tarreau, the netstat bug in kernel 2.4.18ctx-9 is fixed. 2.4.18ctx-10 is the same thing as ctx-9 with only cosmetic change + a little rework of "struct sock". The added field (in ctx-9) has been moved closer to the end of the structure so the beginning of "struct sock" still look like another kernel structure. (C does not have inheritance...).

Now that 2.4.18ctx-10 works (should be as reliable as 2.4.18ctx-8), it is time to test ctx-9 enhancements, notably the ability to support UDP broadcast in vservers. Samba now work completely out of the box in a vserver. Please test it out.

vbuild and vunify: zombies process

The vbuild and vunify are calling the rpm command repeatedly and were not waiting properly for its end status. This was creating many many zombie processes. Fixed!

vservers sysv init script

This script was sourcing the /etc/init.d/functions script uselessly. This script is a RedHat-ism and vservers do not need any of its facility anyway.

Version 0.17

Bug fixes

Compilation with stdc++

Some glibc distribution requires linking stdc++ while other not. I add it anyway and it should work on all.

vserver xx enter

This was using "bash --login" to setup a shell in the vserver environment. It is now using -login, which works on both new and older bash.

Version 0.18


Building vservers out of RedHat CDs

The newvserver utility has been enhanced so you can interactively build vservers from the first Redhat CD or either 7.2 or 7.3. This is done by using the /usr/lib/vserver/install-rh7,2 or install-rh7.3 script. The later is new in vserver 0.18.

The build process configure properly /etc/sysconfig/network to help some package operate properly. netatalk for one grabs the host name from /etc/sysconfig/network.

kernel ctx-12: binding to the broadcast address

ctx-12 allows this. A normal kernel allows this as well.

kernel ctx-12: multi-IP

The new kernel supports multiple IP numbers assigned to a vserver. This allows a vserver to setup services on more than one IP. To make use of that, you simply enter several IP number in the IPROOT field of the vserver configuration file:


Do not forget the quotes!

The vserver utility will create the necessary IP aliases. The first one is created using the vserver name (eth0:name) and the other are adding a number as a suffix (eth0:name1, eth0:name2, ...).

The multi-IP support keeps the original semantic of the vserver in some ways. A service doing a bind ANY (bind to will setup its IP service on the first IP number of the vserver. If you wants to listen to several IP, you will need to configure your service for each IP number explicitly. For example, for apache, you will need multiple listen statements. By default, apache has a "listen 80" statement (a bind any) which translate in a vserver to a listen first-ip-of-the-vserver:80. So you must simply add listen statement for the remaining IP. For example, for the above IPROOT statement:


This departs from the normal behavior of a Unix/Linux OS. When you do a bind any, you end up listening to every IP configured on the box. It was not possible to achieve that easily in the kernel, while keeping performance high (100%) and yet control which IP may be use by a vserver. So this is a compromise. Time will tell how usable it is.

Bug fixes

Building the package on rh6.2

The vserver source do include linux/capability.h. Mixing kernel and glibc header is not a good thing (generally), but glibc do not provide support for capabilities yet. This was causing some strange problem (remember the thread "C++ sucks". This was fixed by moving the #include after the other #include in various source.

Version 0.19


C++ issues

The pfstream stuff has been removed so the utility should compile with newer libraries (the pfstream stuff was deprecated).

Debian support

The vserver command now support Debian. It does it on the fly. It knows where to find the runlevel start-up script, how to turn on and off a service and so on.

There are still few things to do to completely support Debian, notably the unification of DEB package. We are getting there.

Multi IP on several devices

Since kernel ctx-12, you can setup up to 16 IPs per vserver. All those IPs had to be on the same device (IPROOTDEV). It is now possible to assign those IPs to several devices, using the explicit syntax:

	IPROOT="eth0: eth1:"

In the above example, IP will be setup on device eth0, will be installed on eth1 and will go on eth2 (IPROOTDEV is used by default).


All the scripts have been modified to allow the package to be moved in a different location. All the /usr/sbin and /usr/lib/vserver have been change to use $USR_SBIN and $USR_LIB_VSERVER. At the top of each script, those macros are defined. The install-fix.sh utility patch the script with the effective value of those macros.

This way, the package could be moved to /usr/local/sbin and /usr/local/lib/vserver if needed.

vrpm enhancements

The vrpm command is trying to run the rpm command in the proper context (if the vserver is running) so post-install script will have proper effect (and won't interfere with the root server).

vserver command enhancements

The "suexec" command was added. You can execute a command in a vserver context under a specific user-id (known to the vserver). It works like this

	vserver NAME suexec user command args ...

The "status" command was added. It reports some information about a given vserver. Here is an example:

	$ /usr/sbin/vserver smb001 status
	Server smb001 is running
	18 processes running
	Vserver uptime: 12:01

The --silent general option was added. It kills all informative messages. It is generally used with the exec or running command. For example:

	# Counting the processes
	vserver --silent XXX exec ps ax | wc -l

v_xxx pseudo services support multi-IP

The various pseudo services such as v_httpd and friends have been reworked. Previously they were setting the ipv4root to eth0 and starting the real service. It was possible to override the IP by providing a small configuration file in /etc/vservices. For a pseudo service v_xxx, you could setup /etc/vservices/xxx.conf and inside, define the variable IP. It was possible to enter one IP only. Now it is possible to enter two or more IP like this

	# File /etc/vservices/xxx.conf

Version 0.20


More documentation in the package

The package now contains the full change-log, the documentation found on the net and the FAQ. All formatted in text.

vrpm --unify option

The vrpm command has been enhanced to apply vunify to the packages it is updating immediately. You simply do

	vrpm --unify serv1 serv2 -- -Uvh some packages ...

vserver using $@ instead of $*

When using vserver xxx exec, the argument are passed using $@ instead of $*, preserving their topology (preserving argument with spaces). The save_s_context script was fixed as well.

Bug fixes

rebootmgr sysv script broken

In 0.18, the system V init script for the reboot manager service was not working. The service was not starting. As such, vservers were unable to request a reboot.

vserver-stat displays in Bytes instead of bits...

vserver-stat was displaying various quantities using Kb, Mb, Gb instead of KB, MB, and GB. vserver-stat can also display TB, but I could not tested it :-)

Version 0.21


/usr/lib/vserver/vcheck: new

The vcheck utility has been created to verify package integrity in one vserver using the package database of another server. This is a first step to create a Linux server where one can answer the following questions:

  • Has this server been cracked ?
  • What was changed ?

Currently, there is no Linux distribution (no OS in fact) which may answer those questions. Once a server has been abused, the intruder may have changed quite a lot and may have cover his tracks. When you execute a command on such a machine, you can't really trust the output.

Now, on a linux server running vservers and no network service in the root server, you have one part of the solution. The root server and the kernel can't be tempered. So you can always trust the various commands you are running.

<BIG disclaimer>

Now proving that along its entire life, the root server has never been opened to crack attempt, is a difficult project. All I say is that a root vserver can't be modified from the vservers or anywhere else if it has no network service.

This is nevertheless one goal of the vserver project. Create a robust and trusted root server in which you can run all kind of more flexible virtual servers.

</BIG disclaimer>

Back to our normal schedule...

So if you trust the root server and you trust another (reference) vserver (one which is never running), you can use the vcheck utility to perform an rpm verify command, but using the RPM database in the reference vserver. The corresponding packages will be checked.

	vcheck --verify refvserver vserver1 vserver2 ...

vcheck has another option, --diffpkgs, to compare the package list in to vserver. You can see how to vservers evolved.

Argument quoting part 2

The vserver command was discarding argument topology. A fix was done in 0.20, but it was flawed. Now it should work fine. You can do things like:

	/usr/sbin/vserver server exec command "argument with space"

And the command will receive a single argument.

GCC 3.2 support

The various little fixes have been added so the project compiles properly using GCC 3.2.

newvserver enhancements

Two section has been added to the dialog. One is "authentication". It lets you enter the vserver root password, select if you want MD5 passwords and shadow passwords.

The other section is called NIS/Ldap. It lets you enter the NIS domain, NIS server, LDAP base dn and LDAP server.

Both section are normally found at the end of the installation of a Linux distribution.

This information is enabled in the vserver using the authconfig command. Not all distribution carry this command. We will have to figure out how to enable this on all distribution. If /usr/sbin/authconfig is missing in the vserver, the information is not applied. So newvserver works anyway.

newvserver: installing from mandrake 8.2 and redhat 8.0

I have modified newvserver to install from those OS. Mandrake 8.2 does not work yet (work in progress). Not sure why. RedHat 8.0 kind of work. The problem is really weird. When I execute the following script on RedHat 8.0, to install a Redhat 8.0 vserver newvserver do:

	/usr/lib/vserver/install-rh8.0 redhat full

Now, if you run this with the Redhat supplied kernel (2.4.18-14), it works. If you use a 2.4.19 kernel (2.4.19ctx-14 for example), rpm installs few package and then wait forever, trapped in a pause() system call.

I have not yet explain this behavior.

rebootmgr using pidfile

The rebootmgr service now uses a PID file to locate the process. This makes the system V init script more reliable. The script itself does not include the "function" helper script anymore. This is a redhat-ism and it was not using it anyway.

vserver --nodev option

Sometime, you wish to enter a vserver without enabling its network device. You often need this because the vserver is a copy and the real vserver is already running on another physical server. Enabling the device would cause clashes on the network.

The --nodev option tells vserver not to skip this step.

	/usr/sbin/vserver --nodev server enter

vserver: vlan support

A vserver may be installed on an IP number sitting on a different vlan (Virtual LAN). You specify the IPROOTDEV has device.vlannum (eth0.231) or the IPROOT using device.vlannum:IP.

An IP alias will be set on this virtual device after configuring it. It uses the loopback number as the default IP to configure the vlan device.

Bug fixes

capchroot: incompatible NSS plug-gins

capchroot is used to cross the vserver root and then select the proper UID to execute the command. Unfortunately, this program is started in the root server environment, then switch the root and then uses getpwnam to learn about the user ID of a named user.

to perform the getpwnam() call, glibc uses NSS (Name Service Switch) plug-gins to access the user information. These plug-gins are taken in the vserver environment and are not always compatible with the root server glibc.

To avoid this problem, we really need two utilities. One running in the root server, switching root and then calling another (/bin/id ?) in the vserver to learn about the user. This way, both utilities will be compatible with each world. Remember that a root server may be some Linux distribution/release and the vserver may be running a totally different distribution/release.

For now, I have fixed the problem somewhat, but it is not perfect Before switching root, I perform a getpwnam("root"), so the plug-gins are loaded. When I perform the real getpwnam, after the switch, the plug-gins are already in memory so they work. Further, if the target user is root, I do not need to perform any of this and uses the UID 0.

Note that this capchroot feature is needed by the suexec sub-command of the vserver command.

This cheat kind of works. It works for most people. Now, if your vserver is running NIS and not your root server, for example, then the NSS plug-gins loaded are not the one needed in the vserver. In this case it does not work.

We will need a better solution. For now, what we have will work for pretty much everybody.

Stopping a vserver on debian

The vserver script was not setting the PREVLEVEL environment variable before switching to runlevel 6. This has the effect of not stopping the services properly.

Version 0.22


kernel 2.4.19ctx-15

A new kernel patch is available. It tool some time to achieve/debug (another tcp_tw_bucket issue, like ctx-9). Here are the features:

  • When sending an UDP request, the ipv4root is used as the source IP. Prior to ctx-15, an IP of the host server was used, so the reply was never getting back. ypbind in broadcast mode was failing because of that.

  • Bind(any) with multiple IPs. This was not working previously. You had to setup one listening socket per IP. Now, the default operation mode of most IP services, does what you expect: It receives any request coming to one of the IPs of the vserver.

  • Bind(any) and netstat: When performing a bind(any), it will show this way in netstat. Cool. there is one little catch. If you perform a netstat in the root server using the security context 1 (so you can see sockets of all vservers), you will see potentially several sockets bound to the same port using the address.

    How confusing...

    This is normal. Unless two vserver are sharing some IPs, they are allowed to do a bind( on the same port and it will show this way. So this is a little strange in the root server, but perfectly ok in the vserver.

  • A small optimization with bind(any) and a single IP. The previous semantic was to map a bind(any) to the first IP of the vserver (ipv4root). This semantic was kept as an optimization in the kernel in the case where a vserver has a single IP. This is the common case.

    This optimization may go away, maybe, when we will attack the per vserver private network loopback. Depending on the solution selected, the common case may become two IPs per vserver (the loopback and the main IP).

I have not done any benchmark with the new bind(any) stuff. It might be a little slower. Potentially not visible. Comments welcome.

newvserver: Excluded directories

When building a new vserver out of another, you can exclude few directories. Only the directory structure will be copied. By default, newvserver exclude /var/log, /var/run and /var/spool/mail.

There is a TAB in the form to enter up to 4 directories to exclude.

newvserver: sshd cleanup

When cloning a vserver, you may want to reset the sshd private keys so new ones are generated. A check-box is now provided to handle that. It is on by default.

This avoids having all your vserver ending with the same sshd private keys...

Per IP netmask

The IPROOT entry in the vserver configuration file now support one netmask per entry. The complete syntax is

IPROOT="[device:]ip[/netmask] ..."

where stuff in square bracket is optional.

server run-level

A vserver does not use its own init process unless fakeinit is used. Normally /sbin/init writes into /var/run/utmp to record the current run-level and some tools are using that.

Now even if you are not using fakeinit, /var/run/utmp is properly initialized with the proper runlevel (as found in /etc/inittab).

vbuild: new --excldir option

When using vbuild to clone a vserver, you can use the --excldir option repeatedly to exclude some files. The directory structure is duplicated, but no file is copied. This is used by newvserver.

vrpm: No unification is /var/log

When using the --unify, the /var/log directory is excluded. Some packages are owning files there and are not tagged as configuration file (which is fair). Unifying those files is creating problems.

This problem was specific to /var/log (and everything under) as far as I can see, so this is hard-coded in the vrpm script.

vserver profiles

It is sometime useful to operate a vserver with some settings and then operate it with different settings. A setting is called a profile and covers the S_HOSTNAME, IPROOT and IPROOTDEV.

There are two ways to select a profile:

  • Edit the configuration file and insert PROFILE=somename
  • PROFILE=somename vserver XX start

Once you have started a vserver with a given profile, it is stored in the /var/run/vserver/XX.ctx file, so you can enter and stop the vserver using the active profile, even if you have changed the profile value in the configuration file.

The newvserver tool has been modified so you can immediately enter the second profile value. By default, one profile is called prod and the other is called backup.

vservers may be used as a fail-over strategy where whole servers may be switched on and off on the fly. Now one may use some synchronization tool (rsync ?) to make sure the backup is up to date. Sometime, it is not enough and you wish to maintain the backup in sync with the production vserver in real-time or almost. To perform that, you need to enable the backup server, but you can't do that unless you provide different network setting (avoid having two vserver running with the same IP). So the profile concept was introduced.

When starting a vserver using a given profile, the environment variable PROFILE is defined so you can perform various action such as exchanging key configuration file, starting services differently and so on.

Linuxconf users may want to enable the switchprofile pseudo service (available lately) to switch between different configuration file set.

vserver: empty IPROOT

When a vserver must run with the same IP as the root server, the trick was to set IPROOT= Now setting an empty IPROOT is equivalent (and more intuitive).

Bug fixes

vserver: setting resources when using enter or exec

The vserver was not setting the ulimit resources when performing an "enter" or "exec" command. Fixed!

Version 0.23


Support for 17c kernel

The kernel ctx-17c support proper selection of the source IP based on routing information. This is useful for vservers with several IP numbers connected to private networks.

When you enter the IP addresses of the vserver, you may specify the netmask associated with this address. The syntax is

	IPV4ROOT=[device:]ip/mask ...
The /mask is new. If you forget to enter the mask, it is using the mask of the device on which the ip alias will be set.

Version 0.26



if this script exists, it will be executed after you create a new vserver with the newvserver command. The script receives a single argument: The path of the vserver (/vserver/vserver-name).

/usr/lib/vserver/distrib-info: new

All the utility originally using RPM to probe one vserver package database are now using the script /usr/lib/vserver/distrib-info. This is a front-end to potentially all packaging system. Currently, only RPM is supported but DEB and other packaging facility could be added, making all application like vunify, vbuild, newvserver and friend, more general.

Debian user have complained for some time. Now your chance. Patch for distrib-info welcome.

A man page has been written to explain what it does.

chbind: --ip ip/mask

The chbind utility has been modified to accept a netmask along with the IP when using the --ip option. You simply specify IP/netmask.

chcontext: CAP_QUOTACTL support

The kernel vs1.00 support a new capability allowing someone to handle the disk quota. Prior to this kernel, one needed CAP_SYS_ADMIN to handle quota. The vserver package (and chcontext) do understand this capability.


A man page was written

vserver-copy: new

The vserver-copy script let you copy a vserver from one machine to another. A man page has been written to explain how it works. It generally uses rsync over ssh to operate.

vserver-stat: show vserver description

It shows the vserver description at the end of each lines.

vservers sysv script

The script now support the PRIORITY variable in the vserver configuration files to control vservers start and stop order. Lower priority value are started first and stopped last.


chrootsafe: optional

The chrootsafe syscall did not make it so the utility uses it if it is there and use the normal chroot if not. They do not complain as before if chrootsafe is missing.

Version 0.27


Install redhat 9 and fedora core 1 from CD

The newvserver utility can now install a vserver from a RedHat 9 or Fedora core 1 first cdrom. As usual you can install a minimum vserver or the complete CD.

Support for vs1.1 kernels

The new kernel with the virtual switch system call is now supported. You can using vserver 0.27 with vs-1.0 (aka ctx) and vs1.1 kernels.

Bug fixes


The configuration files created by vserver and newvserver now correctly use -HS instead -of -H to set the global ULIMIT settings.

Version 0.28


/usr/sbin/vserver --verbose

The --verbose option was used so we can learn what vserver is doing when it setups the IP aliases.

New man page vserver.conf.5

This man page describe the format of the configuration file in /etc/vservers.

Running v_xxx service with the loopback

The v_xxx service (v_sshd and friends) are provided to help running service on the root server without interfering with similar services in the virtual servers. The various v_xxx services achieve this by starting the corresponding xxx services using chbind to restrict the IPs they are allowed to bind.

Previously, all those services were bound to eth0 only. Now by default (unless overridden in /etc/vservices/xxx.conf) the services are bound to and eth0.

This solves for one the problem with ssh X11 port forwarding since ssh assumes connections are done on localhost ( and not eth0.

Bug fixes

chbind: --ip without parameter

chbind was improperly parsing its command line and was crashing if the option --ip was used without value.

Security issue with vserver 0.27

vserver 0.27 on vs-1.1 kernels was not setting the capability ceiling properly, providing vservers with too much power.

Version 0.29


/usr/lib/vserver/printconf.sh: new utility

This utility shields application from the complexity of the vserver configuration files. It should also protect application from changes we may do to the configuration format.

This utility reads one vserver configuration file and prints the relevant variable one by line, without any comment. This utility should be used by any script operating on a vserver. C++ application should use the vutil_readconf() function, which is using printconf.sh.

The utility is generally used like this in the various scripts:

	eval `/usr/lib/vserver/printconf.sh --quote vserver-name`

The --quota option puts double quotes around the values to make the output usable by scripts. C++ application are not using it. They simply assume that everything passed the equal sign is the value, up to the end of the line.

All utilities in the vserver package are now complying with this strategy.

Debian patches

All the patches from the Debian projects were applied. Some enhancements were done (discussed in this change log). This includes new man pages, some C++ fixes, some stuff related to VSERVERS_ROOT.

New variables in configuration files

Few variables were added in vservers configurations files:


    This tells the vserver utility to generate a new /etc/mtab in a vserver every time it is entered or started. This is done after the pre-start step of the vserver companion script (/etc/vservers/*.sh).

    Originally, the file /etc/mtab was produced only at vserver creation time and this was fine for most cases. Sometime a vserver is mapped over multiple volume and /etc/mtab must be adjusted. Now this is done auto-magically.

    Every mounts visible in the vserver is included. Dummy devices (/dev/hdvN) are generated on the fly. Network mounts are shown as is (the origin of the mount)

    This feature may be turned off by entering

    in the vserver configuration file.


    This controls the base directory use to setup vservers. This variable is normally written in /etc/vservers.conf and shared by several vservers. The actual rool of the vserver is $VSERVERS_ROOT/name

    A vserver may override this variable. The newvserver utility will write a VSERVERS_ROOT= line in the vserver configuration file if a different value was selected (compared to the one in /etc/vservers.conf).


    While a vserver may redefine VSERVERS_ROOT, it is not that convenient. A vserver may simply define VSERVERDIR to point wherever it fits. This variable is optional, but the printconf.sh utility makes sure it is defined: If a vserver configuration file do not define VSERVERDIR, then it is set to $VSERVERS_ROOT/name.

    Application dealing with vservers file should rely on VSERVERDIR (and use printconf.sh)

newvserver: VSERVERS_ROOT support

The utility presents a new field to select the vserver root to use for vserver creation. A drop down let you review the various vservers roots used on this server and the amount of disk space available on each.

newvserver use /etc/vservers.conf to extract the default value for VSERVERS_ROOT. It also checks /etc/vservers/newvserver.default to extract the value from the newvroot variable (if available) (So /etc/vservers/newvserver.defaults override /etc/vservers.conf).

The --vroot command line option was also added to setup the default value.

rebootmgr: supports VSERVERDIR

The utility places its sockets in the proper directories, using vutil_readconf() to learn the vserver installation directory (VSERVERDIR).

Vservers configuration files

A small change was made to vserver configuration files. The file /etc/vservers.conf contains system wide defaults, but is not used directly by the various tools, except when creating a new virtual server. This file (/etc/vservers.conf) is normally sourced by the various vservers configuration files (included). From a tool perspective, for a vserver named foo, only /etc/vservers/foo.conf matters. foo.conf normally starts like this:

	# Description: Some vserver
	source /etc/vservers.conf

Using this strategy, sites are free to implement whatever logic they want to manage vservers. For example, sites may decide to move the S_CAPS or S_FLAGS to /etc/vservers.conf to minimize repetition in vservers.

All the utilities have been modified to obey this rules. Utilities for example, must source one vserver configuration file to learn its VSERVERS_ROOT directory (more on this in this change log).

You do not have to change anything to use vserver 0.29. The printconf.sh utility sources /etc/vservers.conf before sourcing the vserver configuration file. But newvserver and "vserver build" produces configuration files with the proper source command at the top.


v_xxx services bound to

V_xxx services (sshd, ...) are special services used in the root server to limit its IP scope to some IPs. This way, vservers are free to use the other IPs of the machine. In previous release, all v_xxx services were bound to eth0 only. It was possible to override this using a corresponding file /etc/vservices/xxx.conf with a line like:

	IP="ip1 ip2"

It turns out to be more practical to bind services to and eth0. X11 forwarding in sshd is working better like this. So now, all v_xxx services are bound to and eth0, unless overridden by the /etc/vservices/xxx.conf

Version 0.31


Installing several distro from CD

Support has been added to newvserver to install the following distribution from the first CD/DVD

  • Fedora core 1
  • Fedora core 2
  • RedHat enterprise 3
  • SuSE 9.0

vnetstat: new utility

The is a new utility, crude in fact, to show all sockets on a vserver.

Bug fixes

vrpm --unify

The --unify option now excludes files in /etc and /var/log from unification. In previous versions, only /var/log was excluded.

Version 0.32

Bug fixes

Setting the broadcast

The vserver script was setting an inappropriate broadcast on the alias device. It was using the same broadcast for all devices associated with a vserver.

Version 0.40


64 bits kernels

The utilities have been tested on opteron processors (64 bits). You can use the 64 bits or 32 bits version of the tools on a 64 bit kernel without problem.

chcontext command

Add support for the following flags (S_FLAGS in the configuration file) mount: hide /proc/mounts netif: hide network devices

Creating vservers using Fedora core 3 first CD

The newvserver command now support Fedora Core 3 first CD to create a vserver. It also works for 64bits (x86_64) fedora core 3.

Kernel 2.6 support

The utilities now work on 2.4 and 2.6 kernels.

New utility vserver-list

This scripts prints the list of vservers. This list is simple and usable in for loop (using back quote for example). You can get the list of running, not running, or all vservers.

New vserver commands

We have prototyped a new concept for some time now and vserver 0.40 is showing the first details of this technology. This is called "synthetic vservers" and may very well become a major shift in the way we manage projects and servers.

I am preparing a full presentation of this. For now, this is just to explain why the vserver command as the new sub-commands "assemble" and "remove".

A synthetic vserver is a vserver created out of another vserver but merging together resource file (packages), data and configurations. Once a vserver is assembled, you may use it as usual. Once you are done with it, you can remove it.

The interest of this strategy is that you usually end up with many vservers for different project, but all based on the same package set. They are often cloned from the same reference vserver. As the number of vserver grows, you end up with more and more admin tasks duplicated among all those vservers.

With synthetic vserver, you always have a clear separation from the admin tasks touching to reference vservers and configuration tasks associated with specific projects.

Anyway, as I said before, a full paper will be written shortly. To conclude, a synthetic vserver reduces the amount of admiin tasks needed and at the same time, provides an exact description of of project.

Using DHCP on vservers

A vserver may act as a DHCP client now. This is useful when you move vservers around (or transport them on your notebook) and wish to operate on the network without having to obtain a fixed IP address.

To enable this, just enter


in the configuration file. Note that this also works even if the root server (the workstation or notebook) is also using DHCP to get an IP address. If this is the case, you must edit the file /etc/dhclient.conf (generally missing) and place the following line.

	send dhcp-client-identifier "root server";

This allows the DHCP server to tell apart the requests coming from vservers from the requests coming from the root server, since they are all sharing the same MAC address.

Bug fixes

Command newvserver

It was not possible to clone the root server to create a vserver using this command. Now it works. It is not the best way to create a vserver since it is inheriting all the stuff you have configured/added to your root server, but it is an easy way to get started with vservers.