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.
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
GENERATEMTAB=noin 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 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.
# 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.
It turns out to be more practical to bind services to 127.0.0.1 and eth0. X11 forwarding in sshd is working better like this. So now, all v_xxx services are bound to 127.0.0.1 and eth0, unless overridden by the /etc/vservices/xxx.conf