From: Jacques Gelinas (jack_at_solucorp.qc.ca)
Date: Wed 10 Dec 2003 - 17:09:52 GMT
Vserver 0.29 is available at ftp.solucorp.qc.ca/pub/vserver. Here is the change log.
vserver 0.29
Change log
1. Enhancements
1.1. /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.
1.2. 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.
1.3. New variables in configuration files
Few variables were added in vservers configurations files:
+ GENERATEMTAB=yes|no
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=no
in the vserver configuration file.
+ VSERVERS_ROOT
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).
+ VSERVERDIR
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)
1.4. 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.
1.5. rebootmgr: supports VSERVERDIR
The utility places its sockets in the proper directories, using
vutil_readconf() to learn the vserver installation directory
(VSERVERDIR).
1.6. 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.
---------------------------------------------------------
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
_______________________________________________
Vserver mailing list
Vserver_at_list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver