From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Thu 11 Dec 2003 - 00:43:11 GMT
On Wed, Dec 10, 2003 at 12:09:52PM -0500, Jacques Gelinas wrote:
> 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`
sounds good to me ...
> 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.
good, up to date debian kernel patches are
available too, so debian should be fine ...
> 1.3. New variables in configuration files
>
> Few variables were added in vservers configurations files:
hmm, newly installed 0.29er tools on my test platform
just give the following ...
# vserver XXXX start
source: No such file or directory
/usr/sbin/vserver: 200: Syntax error: Bad substitution
maybe using '. /etc/vservers.conf' and not assuming
that /bin/sh == /bin/bash would be more generic?
> + 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.
this sounds good, but 'ufs' should be the default
not ext3, because specifying ext3, will prohibit
any quota support, as the tools require raw block
device access in this case (ufs works fine, by the
way) also specifying usrquota,grpquota would be a
good thing, as it doesn't hurt on a non quota setup
> + 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)
hmm, doesn't this indirectly weaken the 000
chroot barrier, by allowing arbitrary locations,
which might not be secure?
> 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).
It would be nice to have userspace support for
the all-new-userspace-reboot-helper introduced
in vs1.1.3 on public demand ...
> 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.
wrong, see above ...
best,
Herbert
PS: To: Vserver mailing list <vserver_at_dns.solucorp.qc.ca>
shouldn't that read <vserver_at_list.linux-vserver.org>?
> ---------------------------------------------------------
> 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
_______________________________________________
Vserver mailing list
Vserver_at_list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver