http://wiki.linux-vserver.org/api.php?action=feedcontributions&user=KornAndras&feedformat=atomLinux-VServer - User contributions [en]2024-03-28T10:51:53ZUser contributionsMediaWiki 1.20.2http://wiki.linux-vserver.org/util-vserver:SplitSharedNetworksutil-vserver:SplitSharedNetworks2019-01-03T15:25:46Z<p>KornAndras: /* Namespace ramblings */ "albeit" is its own word</p>
<hr />
<div>= Split shared networks with util-vserver: =<br />
What are we trying to manage here:<br />
vservers are pretty good and pretty secure wrt networking. But there comes a time when your iron is to big and can server vservers on security wise multiple networks. Multi-homes is always a pain especially if you have an external firewall. You will make vlans on your big iron, but how will you firewall between one vlan and another on that same iron? Will you duplicate functionality, and have extra firewalling on your big iron, while you have another big iron doing that dedicated already?<br />
That's where network namespaces come into the picture. Network namespaces give the ability to have a seperate ip-stack per namespace. That's right: that's including iptables, multiple routing tables and whatever.<br />
If we can have multiple ip-stacks, we can give each vserver a seperate ip-stack, right? Well, yeah, but why? An ip-stack usually means another l2 or l3 interfacing, especially if those vservers are supposed to be on the same network. So we group all vservers in that belong security wise into same network also into the same network namespace. This gives the benefit that we don't have to fool around with special virtual bridges, virtual ethernet devices or whatever.<br />
<br />
So this page will describe how to setup multiples of (a group of vservers which share the same ipstack on a single vlan) on a single system with only using vlans as network virtualization.<br />
<br />
= Namespace ramblings =<br />
Playing with the latest and greatest ip route I discovered that ip supports the creation and naming of network namespaces, albeit with a trick.<br />
The current ip route utility manages network namespaces by creating a new namespace, and then bind-mounting /proc/self/ns/net (a file!) to /var/run/netns/<a file named after the namespace>.<br />
<br />
Network namespaces always had a big problem of not being able to reach them, unless you know a pid in that namespace. There is another technique, and that is to open a file which is somehow located in that namespace. Enough of that.<br />
== Vserver to ip ==<br />
How can we use that? First we must make sure that we are compatible: we can make vserver create the network namespace and let the ip utility know about that:<br />
<PRE><br />
mkdir -p /var/run/netns<br />
touch /var/run/netns/$VSERVER<br />
vspace -e $VSERVER --net mount -o bind /proc/self/ns/net /var/run/netns/$VSERVER<br />
</PRE><br />
From then on you can use the following incantations:<br />
<PRE><br />
ip netns exec $VSERVER cmds<br />
vspace -e $VSERVER --net cmds<br />
</PRE><br />
== Interface to vserver ==<br />
To put a network device into that namespace we do something like this:<br />
<PRE><br />
ip link set dev $IFACE netns $VSERVER<br />
</PRE><br />
We can check that with:<br />
<PRE><br />
ip netns exec $VSERVER ip a ls<br />
vspace -e $VSERVER --net ip a ls<br />
</PRE><br />
=== Useful interface creationism ===<br />
What's a network namespace without an interface? Here are some create statements:<br />
<PRE><br />
# Create an interface on a a "real" device<br />
# A macvlan in bridge mode is as if we have a second network card<br />
# in the same network. It already knows all mac-addresses, so the "bridging" code is lightweight<br />
ip link add link $BASEDEVICE name $VSERVERDEVICE type macvlan mode bridge<br />
<br />
# Create a virtual network tunnel<br />
# This is basically a virtual cross cable type of interface<br />
# You can use a veth like any ordinary device like<br />
# plugging it into a bridge device<br />
ip link add name $DEVICE_A type veth peer name $DEVICE_B<br />
<br />
# Create a normal vlan interface on a device.<br />
# Great when giving vservers a seperate vlan<br />
ip link add link $BASEDEVICE name $VSERVERDEVICE type vlan id $VLANID<br />
<br />
</PRE><br />
<br />
Remember though: all interfaces need valid mac-addresses, especially when going to the outside.<br />
I use this complex script to generate a pair of static mac-addresses for a veth:<br />
<PRE><br />
stringasmac() {<br />
echo "$1"|sed 's/\(..\)\(..\)\(..\)\(..\)\(..\)\(..\)/\1:\2:\3:\4:\5:\6/'<br />
}<br />
read CONTEXTID < /etc/vservers/${VSERVER}/context<br />
MACSTRING=$(printf "%04x" $VID)$(printf "%04x" $CONTEXTID)<br />
MACADDRC=$(stringasmac 02${MACSTRING}00)<br />
MACADDRH=$(stringasmac 02${MACSTRING}01)<br />
</PRE><br />
Valid addresses are addresses that have bit0 unset and bit1 set in the first byte.<br />
It means a normal (bit0: 1 == multicast) and locally administrated (bit1: 1==Not official) address.<br />
You set them like:<br />
<PRE><br />
ip link set address ${MACADDRC} dev ${CLIENTDEV}<br />
</PRE><br />
== ip to vserver ==<br />
Turned around, could we create a namespace and use it in vserver? We can then prepare interfaces in the namespace before starting the vserver.<br />
If it works, it should go like this:<br />
<PRE><br />
ip netns add $VSERVER<br />
ip netns exec $VSERVER vserver $VSERVER start<br />
</PRE><br />
== interface management ==<br />
Any vserver with a seperate network namespace should have it's lo brought up (in *that* namespace).<br />
Any link configuration should be done within that namespace. Util-vserver needs some patches for that.<br />
<br />
== /proc/net/ ==<br />
Initially the contents of /proc/net/ is not visible in the vserver. vprocunhide unhides only /proc/net from the host network namespace. So to be able to see /proc/net/* inside the vserver you will have to run vprocunhide in the created network namespace again. Something like that could be useful:<br />
<pre><br />
ip netns exec $VSERVER /usr/lib/util-vserver/vprocunhide<br />
</pre><br />
<br />
= Applied namespace ramblings =<br />
== The Script ==<br />
This script should be symlinked from /etc/vservers/<name>/scripts/(initialiaze,prepre-start...).d .<br />
<PRE><br />
function createMacVidId() {<br />
(<br />
printf "02"<br />
printf "%04x" $1 # I usually use VID<br />
printf "%04x" $S_CONTEXT<br />
printf "%02x" $2 # IFACE number f.i.<br />
)|<br />
sed 's/\(..\)\(..\)\(..\)\(..\)\(..\)\(..\)/\1:\2:\3:\4:\5:\6/'<br />
}<br />
function usesipnetns() {<br />
local netspace<br />
if [ -s "$VSERVER_DIR/spaces/net" ]<br />
then<br />
read netspace < "$VSERVER_DIR/spaces/net"<br />
[ "$netspace" = "$VSERVER_NAME" ]<br />
return $?<br />
fi<br />
return 1<br />
}<br />
case "${1}" in<br />
initialize)<br />
if usesipnetns<br />
then<br />
_HIP="$_IP"<br />
_IP="$_HIP netns exec ${2} $_HIP"<br />
$_HIP netns add ${2}<br />
$_IP link set dev lo up<br />
fi<br />
;;<br />
prepre-start)<br />
if usesipnetns<br />
then<br />
$_HIP link add link eth0 name fw-vlan2 type vlan id 2<br />
$_HIP link set dev fw-vlan2 address $(createMacVidId 2 0)<br />
$_HIP link set dev fw-vlan2 netns ${2}<br />
$_HIP netns exec ${2} $_VPROCUNHIDE<br />
fi<br />
;;<br />
# By now all options are generated, time to override them<br />
pre-start)<br />
# NICE_CMD=(/sbin/ip netns exec ${2} "${NICE_CMD[@]}")<br />
if usesipnetns<br />
then<br />
local index<br />
local NEWVSPACE_CMDS<br />
declare -a NEWVSPACE_CMDS<br />
index=0;<br />
<br />
while [ $index -lt ${#VSPACE_SHARED_CMD[@]} ]<br />
do<br />
if<br />
[ "${VSPACE_SHARED_CMD[$((${index}+0))]}" = "$_VSPACE" ] &&<br />
[ "${VSPACE_SHARED_CMD[$((${index}+1))]}" = "--enter" ] &&<br />
[ "${VSPACE_SHARED_CMD[$((${index}+2))]}" = "${2}" ] &&<br />
[ "${VSPACE_SHARED_CMD[$((${index}+3))]}" = "--net" ]<br />
then<br />
NEWSPACE_CMDS=("${NEWSPACE_CMDS[@]}" $_HIP netns exec "$2")<br />
index=$(($index+5))<br />
else<br />
NEWSPACE_CMDS=("${NEWSPACE_CMDS[@]}" "${VSPACE_SHARED_CMD[$index]}")<br />
index=$(($index+1))<br />
fi<br />
done<br />
VSPACE_SHARED_CMD=("${NEWSPACE_CMDS[@]}")<br />
unset NEWVSPACE_CMDS<br />
unset index<br />
fi<br />
;;<br />
post-start)<br />
;;<br />
pre-stop)<br />
if usesipnetns<br />
then<br />
_HIP=_IP<br />
_IP="$_HIP netns exec ${2} $_HIP"<br />
$_HIP netns add ${2}<br />
$_IP link set dev lo up<br />
fi<br />
;;<br />
post-stop)<br />
$_IP link del fw-vlan2<br />
$_HIP netns delete ${2}<br />
;;<br />
esac<br />
</PRE><br />
<br />
== Explanation ==<br />
The script uses a configuration fault (e.g: <vserver>/spaces/net contains it's<br />
own name) to indicate that the script should create the network namespace. Actually util-vserver will think that it is using a shared network namespace, and we replace that incantation of vspace with our own. You are expected to create and give the interfaces in the prepre-start section.<br />
Standard util-vserver functionality can configure those interfaces by prefixing<br />
$_IP with the vspace or ip netns prefix.<br />
This way, the interfaces are UP *and* RUNNING before the vserver itself starts,<br />
hence making it ideal for f.i. DHCP servers on dedicated vlans.<br />
<br />
Configuration issues: for the script to work you now have to have the right /run/netns/vserver-name in the /etc/vserver-name/namespace-cleanup-skip file.<br />
<br />
== future ==<br />
I will add functionality to allow shared network namespaces. It's not that hard.</div>KornAndrashttp://wiki.linux-vserver.org/Frequently_Asked_QuestionsFrequently Asked Questions2018-02-20T16:01:32Z<p>KornAndras: split nondefault mark value stuff into its own question</p>
<hr />
<div><div style="margin: 2em auto 2em auto; padding: 10px; background-color: #F9ECCD; border: 1px solid #004433; text-align: center;"><br />
[[Image:Icon-Caution.png|left]]<br />
We currently migrate to MediaWiki from our old installation, but not all content has been migrated yet. Take a look at the [[Wiki Team]] page for instructions how to help or look at the [http://oldwiki.linux-vserver.org old wiki] to find the information not migrated yet.<br />
<br />
'''To ease migration we created a [[List of old Documentation pages]].'''<br />
</div><br />
<br />
CURRENTLY THE CONTENT OF THE OLD WIKI FAQ (AND MORE) IS BEING MIGRATED TO THIS PAGE (TASK: DERJOHN)<br />
<br />
<br />
__TOC__<br />
<br />
== General ==<br />
<br />
{{Question<br />
|Question=What is the status of Linux-VServer?<br />
||Details=Linux-VServer has more than a decade of maturity and is actively developed. Two projects are similar to Linux-VServer, [[http://lxc.sf.net LXC]], and [[http://openvz.org OpenVZ]]. Of the two, OpenVZ is the more mature and offers some similar functionality to Linux-VServer. LXC is solely based on the kernel mechanisms such as cgroups that are present in modern kernels. These kernel mechanisms will continue to be refined and isolation will mature. As that occurs, Linux-VServer will take advantage of those new features separately from LXC and continue to provide the same robust user interface that it does currently. Currently, LXC offers significantly less functionality and isolation than Linux-vserver. LXC will eventually be a robust wrapper around kernel mechanisms but is still under heavy development and not considered ready for production use.<br />
|Signature=beck}}<br />
<br />
<br />
<br />
{{Question<br />
|Question=What is a 'Guest'?<br />
||Details=To talk about stuff, we need some naming. The physical machine is called 'Host' and the 'main' context running the Host Distro is called 'Host Context'. The virtual machine/distro is called 'Guest' and basically is a Distribution (Userspace) running inside a 'Guest Context'.<br />
|Signature=derjohn}}<br />
<br />
<br />
{{Question<br />
|Question=What kind of Operating System (OS) can I run as guest?<br />
||Details= With VServer you can only run Linux guests. The trick is that a guest does not run a kernel on its own (as XEN and UML do), it merely uses a virtualized host kernel-interface. VServer offers so called security contexts which make it possible to separate one guest from each other, i.e. they cannot get data from each other. Imagine it as a chroot environment with much more security and features.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=Is this a new project? When was it started?<br />
||Details=The first public occurrence of Linux-VServer was Oct 2001. The initial mail can be found here: http://www.cs.helsinki.fi/linux/linux-kernel/2001-40/1065.html<br />
So you can expect a mature software product which does its magic quite well (And hey, we have a version > 2.0!)<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=Which distributions did you test?<br />
||Details=Some. Check out the wiki for ready-made guest images. But you can easily build own guest images, e.g. with Debian's debootstrap. Checkout [[Building Guest Systems]] how to do that.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=Is VServer comparable to XEN/UML/QEMU?<br />
||Details=Nope. XEN/UML/QEMU and VServer are just good friends. Because you ask, you probably know what XEN/UML/QEMU are. VServer in contrary to XEN/UML/QEMU does not "emulate" any hardware you run a kernel on. The purpose of Linux VServer is to isolate (groups of) applications. The isolation is done by the kernel (see [[Overview]] for a more detailed comparison). You can run a VServer kernel in a XEN/UML/QEMU guest. This is confirmed to work at least with Linux 2.6/vs2.0.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=With which version should I begin?<br />
||Details=If you are new to VServer I recommend to try the latest stable kernel patch, and the latest util-vserver "alpha" release.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=Is VServer secure?<br />
||Details=We hope so. It should be as least as secure as Linux is. We consider it much much more secure though.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=Performance?<br />
||Details=For a single guest, we basically have native performance. Some tests showed insignificant overhead (about 1-2%) others ran faster than on an unpatched kernel. This is IMVHO significantly less than other solutions waste, especially if you have more than a single guest (because of the resource sharing).<br />
|Signature=derjohn}}<br />
<br />
<br />
{{Question<br />
|Question=What is the "great flower page"?<br />
||Details=Well, [http://www.nongnu.org/util-vserver/doc/conf/configuration.html this page] contains all configuration options for util-vserver. The name of the page is derived from the stylesheet(s) it contains.<br />
|Signature=derjohn}}<br />
<br />
<br />
<br />
== Resources usage ==<br />
<br />
{{Question<br />
|Question=Resource sharing?<br />
||Details=Yes ....<br />
* memory: Dynamically.<br />
* CPU usage: Dynamically (token bucket)<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=Resource limiting?<br />
||Details=You can put limits per guest on different subsystems.<br />
* using ulimits and rlimits (rlimit is a new feature of kernel 2.6/vs2.0.) per guest, to limit the memory consumption, the number of processes or file-handles, ... : see [[Resource Limits]]<br />
* CPU usage : see [[CPU Scheduler]]<br />
* disk space usage : see [[Disk Limits and Quota]]<br />
Note that you can only offer guaranteed resource availability with some ticks at the time.<br />
|Signature=derjohn&xm}}<br />
<br />
{{Question<br />
|Question=How do I limit a guests RAM? I want to prevent OOM situations on the host!<br />
||Details=First you can read [http://linux-vserver.org/Memory+Allocation] and [[Memory Limits]].<br />
If you want a recipe, do this:<br />
# Check the size of memory pages. On x86 and x86_64 is usually 4 KB per page. (on linux "getconf -a|grep PAGE" will give you the information)<br />
# Create /etc/vserver/<guest>/rlimits/<br />
# Check your physical memory size on the host, e.g. with "free -m". maxram = kilobytes/pagesize.<br />
# Limit the guests physical RAM to value smaller then maxram:<pre>echo %%insertYourPagesHereSmallerThanMaxram%% > /etc/vserver/<guest>/rlimits/rss </pre><br />
# Check your swapspace, e.g. with 'swapon -s'. maxswap = swapkilobytes/pagesize.<br />
# Limit the guest's maximum number of as pages to a value smaller than (maxram+maxswap): <pre> echo %%desiredvalue%% > /etc/vserver/<guest>/rlimits/as </pre><br />
# Correctly display the memory information inside the guest:<pre>echo "VIRT_MEM" >> /etc/vservers/<guest>/flags</pre><br />
It should be clear this can still lead to OOM situations. Example: You have two guests and your as limit per guest is greater than 50% of (maxram+maxswap). If both guests request their maximum at the same point in time, there will be not enough mem .....<br />
|Signature=derjohn}}<br />
<br />
<br />
{{Question<br />
|Question=Disk I/O limiting? Is that possible?<br />
||Details=Well, since vs2.1.1 Linux-VServer supports a mechanism called 'I/O scheduling', which appeared in the 2.6 mainline some time ago. The mainline kernel offers several I/O schedulers:<br />
<pre><br />
# cat /sys/block/hdc/queue/scheduler<br />
noop [anticipatory] deadline cfq<br />
</pre><br />
<br />
The default since 2.6.18 in Sept 2006 is CFQ, described below, and prior to that was anticipatory a.k.a. "AS" ([[http://en.wikipedia.org/wiki/CFQ#Kernel_2.6.18_.2820_September_2006.29 Wikipedia]]). When running several guests on a host you probably want the I/O performance shared in a fair way among the different guests. The kernel comes with a "completely fair queueing" scheduler, CFQ, which can do that. (More on schedulers can be found at http://lwn.net/Articles/114770/)<br />
This is how to set the scheduler to "cfq" manually:<br />
<pre><br />
root# echo "cfq" > /sys/block/hdc/queue/scheduler<br />
root# cat /sys/block/hdc/queue/scheduler<br />
noop anticipatory deadline [cfq]<br />
</pre><br />
Keep in mind that you have to do it on all physical discs. So if you run an md-softraid, do it to all physical /dev/hdXYZ discs!<br />
If you run Debian there is a predefined way to set the /sys values at boot-time:<br />
<pre><br />
# apt-get install sysfsutils<br />
[...]<br />
<br />
# grep cfq /etc/sysfs.conf<br />
block/sda/queue/scheduler = cfq<br />
block/sdc/queue/scheduler = cfq<br />
<br />
# /etc/init.d/sysfsutils restart<br />
</pre><br />
<br />
For non-vserver processes and CFQ you can set by which key the kernel decides about the fairness:<br />
<pre><br />
cat /sys/block/hdc/queue/iosched/key_type<br />
pgid [tgid] uid gid<br />
</pre><br />
Hint: The 'key_type'-feature has been removed in the mainline kernel recently. Don't look for it any longer :(<br />
<br />
The default is tgid, which means to share fairly among process groups. Think every guest is treated like a own process group. It's not possible to set a scheduler strategy within a guest. All processes belonging to the same guest are treated like "noop" within the guest. So: If you run apache and some ftp-server within the _same_ guest, there is no fair scheduling between them, but there is fair scheduling between the whole guest and all other guests.<br />
<br />
And: It's possible to tune the scheduler parameters in several ways. Have a look at /sys/block/hdc/queue/....<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=Nice disk I/O scheduling, is that possible?<br />
||Details=Well, since linux 2.6.13 processess have another priority next to the cpu nice scheduling hint, it's called io nice.<br />
It's split into three groups, called real-time, best effort and idle. The default is best-effort, but within best-effort, you can have a niceness from 0 to and including 7.<br />
You can set this niceness by the tool ionice, which for debian is either in the package util-linux or schedutils.<br />
To change the io-niceness you need the <tt>CAP_SYS_NICE</tt>, '''and''' need to have the same uid as the processe you want to ionice.<br />
<br />
:'''Note:''' If you want to use any schedulung other than best-effort you will also need the <tt>CAP_SYS_ADMIN</tt>-flag. Be warned that this gives quite some capabilities to the vserver, not just for I/O scheduling!<br />
<br />
If you want to increase the niceness of an I/O hogging process within a vserver you need to do:<br />
<PRE><br />
chcontext --xid sponlp1 sudo -u '#2089' ionice -c2 -n5 -p24409<br />
</PRE><br />
with sudo and ionice installed on the root server to increase the *nice*ness of pid 24409, with uid 2089<br />
|Signature=Groteblup}}<br />
<br />
{{Question<br />
|Question=I want iotop to display all guest processes on host to give me a nice overview of I/O usage.<br />
||Details=You must allow iotop to read information from all guests. Add <br />
<br />
<PRE><br />
# setattr --watch /proc/vmstat<br />
</PRE><br />
to, for example, rc.local, and later run iotop:<br />
<PRE><br />
# vcontext --migrate --xid 1 -- iotop<br />
</PRE><br />
|Signature=corey via ser}}<br />
<br />
== Unification ==<br />
<br />
{{Question<br />
|Question=What is unification (vunify)?<br />
||Details=[[Unification]] is Hard Links on Steroids. Guests can 'share' common files (usually binaries and libraries) in a secure way, by creating hard links with special properties (immutable but unlinkable (removable)). The tool to identify common files and to unify them is called [[vunify]].<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=What is [[vhashify]]?<br />
||Details=The successor of [[vunify]], a tool which does unification based on hash values (which allows to find common files in arbitrary paths.)<br />
It creates hardlinks to files named after a hash of the content of the file. If you have a recent version of the vserver patch (2.2+), with CONFIG_VSERVER_COWBL enabled, you can even modify the hardlinked files inside the vservers and the links will be broken automatically.<br />
There seems to be a catch when a hashified file has multiple hardlinks inside a guest, or when another internal hardlink is added after hashification. Link breaking will remove all the internal hardlinks too, so the guest will end up with different copies of the original file. The correct solution would be to not hashify files that have multiple links prior to hashification, and to break the link to the hashified version when a new internal hardlink is created. Apparently, this is not implemented yet (?).<br />
<br/>|Signature=Guy-<br />
<br/><br />
Note: hashify cannot cross XFS project QUOTA because hardlinks cannot cross projects.<br />
}}<br />
<br />
{{Question<br />
|Question=How do I manage a multi-guest setup with vhashify?<br />
||Details=For '[[vhashify]]', just do these once:<br />
<pre><br />
mkdir /etc/vservers/.defaults/apps/vunify/hash /vservers/.hash<br />
ln -s /vservers/.hash /etc/vservers/.defaults/apps/vunify/hash/root<br />
</pre><br />
Then, do this one line per vserver:<br />
<pre><br />
mkdir /etc/vservers/<vservername>/apps/vunify # vhashify reuses vunify configuration<br />
</pre><br />
To hashify a running vserver, do (possibly from a cronjob):<br />
<pre><br />
vserver name-of-guest hashify<br />
</pre><br />
<br />
The guest needs to be running because vhashify tries to figure out what files not to hashify by calling the package manager of the guest via <tt>vserver enter</tt>.<br />
<br />
In order for the OS cache to benefit from the hardlinking, you'll have to restart the vservers.<br />
<br />
To clean up hashified files that are no longer referenced by any vserver, do (possibly from a cronjob):<br />
<pre><br />
find /vservers/.hash -type f -links 1 -print0 | xargs -0 rm<br />
</pre><br />
<br />
Until you do this, the files still take up place even though no vservers need them.<br />
|Signature=Guy-}}<br />
<br />
== Filesystem usage ==<br />
<br />
{{Question<br />
|Question=Is there a way to implement "user/group quota" per VServer?<br />
||Details=Yes, but not on a shared partition for now. You need to put the guest on a separate partition, setup a vroot device (to make the quota access secure), copy that into the guest, and adjust the mtab line inside the guest. If 8 vroot device is not enough for you, you can add more with the kernel parameter max_vroot (exemple for built in kernel vroot /vmlinuz-2.6.31.6-vs2.3.0.36.26aq root=/dev/md1 ro max_vroot=20 ). If vroot is a module you'd actually want to put for exemple "options vroot max_vroot=20" in /etc/modprobe.conf and then just do modprobe vroot<br />
|Signature=derjohn,gadnet}}<br />
<br />
{{Question<br />
|Question=What about "Quota" for a context? Howto limit disk usage?<br />
||Details=Context quotas are now called Disk Limits (so that we can tell them apart from the user/group quotas :). They are supported out of the box (with vs2.0+) for all major filesystems (ext2/3, ReiserFS, JFS). You need to tag the FS with XID (see below). Please read [[Disk Limits and Quota]] for more information.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=How do I tag a guest's directory with xid?<br />
||Details=Tagging the guest's files gives you several advantages, e.g. the accounting will work properly.<br />
Filesystem XID tagging only works on supported filesystem. Those are currently: ext2/3, reiserfs/reiser3, xfs and jfs.<br />
To activate the XID tagging you have to mount the filesystem with "-o tag" (former tagxid is outdated since VS2.2). Attention: It's _not_ possible to "-o remount,tag", you have to mount it freshly. The guests will tag their files automatiaclly. If you copy files in from the host, you have to tag them manually like this:<br />
<pre><br />
chxid -c xid -R /var/lib/vservers/<guest><br />
</pre><br />
Note: Context 0 and 1 will see all files, guests will only be able to access untagged files and their own XID. They can see other XID files but no information about the file, e.g. no owner, no group, no permissions.<br />
Note: It is not advised to tag the root filesystem, as [http://www.paul.sladen.org/vserver/archives/200602/0020.html explained by Herbert] : trying to do so will expose you to some troubles !<br />
|Signature=derjohn_and_gonzo_and_are}}<br />
<br />
{{Question<br />
|Question=How can I copy anything from host to guest partition, normally unvisible on host?<br />
||Details=You should just change namespace, e.g.:<br />
<pre><br />
vnamespace --enter <xid> -- /bin/bash<br />
</pre><br />
and then use standard cp or rsync programs.<br />
|Signature=SergiuszPawlowicz}}<br />
<br />
{{Question<br />
|Question=Why is the barrier attribute disappearing on reiserfs filesystem after umount or host reboot?<br />
||Details=The filesystem has to be mounted with explicitly defining the 'attrs' option, i.e. <br />
<pre><br />
mount /dev/reiserfsdev /vservers -oattrs<br />
setattr --barrier /vservers<br />
</pre><br />
to get the barrier survive after umount/reboot.<br />
|Signature=Nikolay Kichukov}}<br />
<br />
== Network ==<br />
<br />
{{Question<br />
|Question=Does it support IPv6?<br />
||Details=Currently it requires an additional patch, but the functionality should be available in 2.3+ soon. [[IPv6]] has more information.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=I can't do all I want with the network interfaces inside the guest?<br />
||Details=For now the networking is 'Host Business' -- the host is a router, and each guest is a server. You can set the capability ICMP_RAW in the context of the guest, or even the capability CAP_NET_RAW (which would even allow to sniff interfaces of other guests!). Likely to change with ngnet.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=How do I add several IPs to a vserver?<br />
||Details=First of all a single guest vserver only supports up to 16 IPs (There is a 64-IP patch available, which is in "derjohn's kernel").<br />
<pre><br />
Update from IRC (2011-08-22):<br />
<mmouse> quick question: what is the maximum count of IPs (v4) I can have in a single guest?<br />
<daniel_hozac> unlimited.<br />
</pre><br />
<br />
Here is a little helper-script that adds a list of IPs defined in a text file, one per line.<br />
<pre><br />
#!/bin/bash<br />
j=1<br />
for i in `cat myiplist`; do<br />
j=$(($j+1))<br />
mkdir $j<br />
echo $i > $j/ip<br />
echo "24" > $j/prefix<br />
done<br />
</pre><br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=How do I assign a new IP address to a running guest?<br />
||Details=This is done from the host server:<br />
* add the ip on the host, for example<br />
<pre><br />
ip addr add 194.169.123.23/24 dev eth0 <br />
</pre><br />
* add the ip to the guest's network context (a guests NID is the same as the XID {context ID})<br />
<pre><br />
naddress --add --nid <nid> --ip 194.169.123.23/24 <br />
</pre><br />
* enter the guest (best via ssh) <br />
* restart the services that need to make use of the new address if required <br />
* update the config in ''/etc/vserver/<servername>/interfaces'' to reflect the changes for the next guest restart (if desired)<br />
|Signature=BenjaminGreen}}<br />
<br />
{{Question<br />
|Question=If my host has only one a single public IP, can I use RFC1918 IP (e.g. 192.168.foo.bar) for the guest vservers?<br />
||Details=Yes, use iptables with SNAT to masquerade it. <br />
<pre><br />
iptables -t nat -I POSTROUTING -s $VSERVER_NETZ ! -d $VSERVER_NETZ -j SNAT --to $EXT_IP<br />
</pre><br />
See: [[HowtoPrivateNetworking]] and <br />
http://www.tgunkel.de/it/software/doc/linux_server.en#h3-VServer_Masquerading_SNAT (THX, [MUPPETS]Gonzo)<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=If I shut down my vserver guest, the whole Internet interface ethX on the host is shut down. What happened?<br />
||Details=When you shut down a guest (''i.e. vserver foo stop''), the IP is brought down on the host also. If this IP happens to be the primary IP of the host, the kernel will not only bring down the primary IP, but also all secondary IP addresses. Similarly, if your guests bring up IPs of more than one subnet, all other IPs from a specific subnet will be shut down if you stop the guest which created the first ("parent") IP.<br />
<br />
You can check this on the host using the command "ip addr show". Example output:<br />
<pre><br />
1: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000<br />
link/ether 00:01:02:03:04:05 brd ff:ff:ff:ff:ff:ff<br />
inet 192.168.249.172/27 brd 192.168.249.191 scope global eth0<br />
inet 192.168.234.194/27 brd 192.168.234.223 scope global eth0<br />
inet 192.168.249.169/27 brd 192.168.249.191 scope global secondary eth0<br />
inet 192.168.234.195/27 brd 192.168.234.223 scope global secondary eth0<br />
</pre><br />
In this example, if you stop the guest which brings down the IP 192.168.249.172, the IP 192.168.249.169 will be brought down as well, because it is a secondary IP of the "parent" 192.168.249.172.<br />
<br />
But in very recent kernels, there is an option ''settable'' which prevents that nasty feature. It's called "alias promotion". You may set it via sysctl by adding ''net.ipv4.conf.all.promote_secondaries=1'' in /etc/sysctl.conf or via sysctl command line.<br />
|Signature=derjohn, Hurga}}<br />
<br />
{{Question<br />
|Question=Can I run an OpenVPN Server in a guest?<br />
||Details=<br />
Yes. To get a OpenVPN Server running in a guest, all networking setup has to be done on the host. This answer describes the common case and shows some pitfalls, for detailled information about OpenVPN, please consult the appropriate documentation on the OpenVPN homepage.<br />
This is the minimal OpenVPN configuration for the Server which will be used to demonstrate how to get it running in a client:<br />
<pre><br />
# Networking setup<br />
server 192.168.16.0 255.255.255.0<br />
dev tun16<br />
ifconfig-noexec<br />
comp-lzo<br />
# Certificates<br />
dh ...<br />
ca ...<br />
cert ...<br />
key ...<br />
# Management<br />
persist-key<br />
keepalive 10 60<br />
verb 4<br />
</pre><br />
First of all you have to prepare the host with a persistent interface in the right mode and with the right settings. This is easily done by using openvpn and the ip and route tools.<br />
<pre><br />
# openvpn --mktun --dev tun16<br />
# ip link set dev tun16 txqueuelen 100<br />
# ifconfig tun16 192.168.16.1 pointopoint 192.168.16.2 mtu 1500<br />
# route add -net 192.168.16.0 netmask 255.255.255.0 gw 192.168.16.2<br />
</pre><br />
If you need different settings, openvpn will tell you the ifconfig and route commands it uses to configure the interface when being started on the host with the original config file, but without ifconfig-noexec.<br />
Additionally, the guest needs /dev/net/tun to make OpenVPN happy. This can be created with MAKEDEV:<br />
<pre><br />
# cd /var/lib/vserver/<myopenvpnserver>/dev/<br />
# ./MAKEDEV tun<br />
(creates the dev/net/tun device accessible by the guest - even a tap interface needs /dev/net/tun !)<br />
</pre><br />
Finally, the guest needs to have the tun device assigned:<br />
<pre><br />
# head /etc/vservers/<myopenvpnserver>/interfaces/1/*<br />
==> /etc/vservers/<myopenvpnserver>/interfaces/1/ip <==<br />
192.168.16.1<br />
<br />
==> /etc/vservers/<myopenvpnserver>/interfaces/1/nodev <==<br />
tun16<br />
<br />
==> /etc/vservers/<myopenvpnserver>/interfaces/1/prefix <==<br />
24<br />
#<br />
</pre><br />
The client's conf may look like that:<br />
<pre><br />
# Basic setup<br />
client<br />
proto tcp-client<br />
dev tun<br />
remote <ipaddress><br />
comp-lzo<br />
verb 4<br />
<br />
# Certificate<br />
ca ...<br />
</pre><br />
<br />
[ Based on derJohn's original answer, all errors mine ] <br />
|Signature=DavidS}}<br />
<br />
{{Question<br />
|Question=Trying to connect to a vserver from the host or another vserver on the same host fails<br />
||Details=strace shows<br />
<pre> <br />
sin_addr=inet_addr("xx.xx.xx.xx")}, yy) = -1 EINVAL (Invalid argument)<br />
</pre><br />
A: The host/guest cannot communicate with another guest on same host.<br />
* check all netmasks on all interfaces (do they overlap) ?<br />
* check policy routing (disable it temporary) ?<br />
* check that lo is up (Networking within a host/guest always uses lo interface)<br />
|Signature=CommonProblems}}<br />
<br />
{{Question<br />
|Question=Can I use iptables ?<br />
||Details=Yes but right now only on the host (rootserver). Please realize that all traffic is local and will not touch the forward chain.<br />
<br>If you really, really, really need iptables on the guest and you are aware about loosing a big part of VServer isolation and security you could add the NET_ADMIN capability. Consider writing wrappers to manage iptables on the host instead.<br />
|Signature=_are_}}<br />
<br />
{{Question<br />
|Question=Is it possible to prevent guest from bringing down primary ip?<br />
||Details=Yes. Remove /etc/vservers/<guest>/interfaces/X/dev, and touch /etc/vservers/<guest>/interfaces/X/nodev<br />
|Signature=Daniel&Serge}}<br />
<br />
{{Question<br />
|Question=Is it possible to provide a different MAC address per vServer?<br />
||Details=Short answer - yes but it's a hassle.<br />
<br />
Real answer from '''_are_''':<br />
<pre><br />
When I once needed 'real' seperate MAC-addresses I used TAP-devices and VDE2 ([http://vde.sourceforge.net/ Virtual Distributed Ethernet]).<br />
Basically vServer is an isolation of existing resources, not a virtualization of 'new' devices.<br />
Without extra fuss you can't add a 'new' network interface to a vServer, no matter if it is eth* or tap*, you always add it to the host and give the vServer access to it.<br />
I got the TAP+VDE2 up and running, but I think it is too much trouble for basically the simple adding of IPs to a vServer unless you really need the MAC address separate.<br />
</pre><br />
<br />
<br />
You can also utilize MACVLAN ability from kernel.<br />
I.e. create ''macvlan0'' interface with:<br />
<pre>ip link add link eth0 address 00:19:d1:29:d2:58 macvlan0 type macvlan</pre><br />
[[http://jim.studt.net/depository/index.php/notes-on-linux-s-macvlan-module Reference]]<br />
|Signature=bobnormal&swenTjuln<br />
}}<br />
<br />
{{Question<br />
|Question=Is it possible to hide packet counters on the host network interface from vServer guests?<br />
||Details=Yes, see [[Networking_vserver_guests|Networking vServer Guests]]<br />
|Signature=bobnormal}}<br />
<br />
{{Question<br />
|Question=Services won't bind to 127.0.0.1 when I configure them to bind to all available IPs / (binding service to * doesn't bind to loopback)?<br />
||Details=You've configured single public IP and have kernel option "Linux VServer -> Automatic Single IP Special Casing" enabled.<br />
It means somehow "optimized" :D<br />
If you don't want this you have 3 possible solutions (quoting Bertl):<br />
* disable the auto single IP in the kernel<br />
* assign more than one IP to the guest<br />
* disable single ip special casing for that guest<br />
<br />
The later is done by : echo "~single_ip" >> /etc/vservers/<VSERVER>/nflags<br />
At runtime to avoid restarting the vserver: nattribute --set --nid <guest> --flag ~single_ip<br />
|Signature=swenTjuln}}<br />
<br />
{{Question<br />
|Question=When using network namespaces and vserver together, netstat does not work in the vserver. What's wrong? <br />
||Details=All proc entries are hidden by default in the guests. During startup of the host system a tool called vprocunhide makes some /proc files visible.<br />
<br />
If you create a new network namespace you have to do the same in the network namespace because the new /proc/net files are not available for the vprocunhide outside the new network namespace. So something like that should be sufficient to get netstat working in vservers with network namespaces:<br />
<br />
<pre><br />
ip netns exec $NAMESPACE /usr/lib/util-vserver/vprocunhide<br />
</pre><br />
|Signature=AlexanderS}}<br />
<br />
== Administration tools ==<br />
<br />
{{Question<br />
|Question=Which guest vservers are running?<br />
||Details=Use vserver-stat to find out. Example output:<br />
<pre><br />
CTX PROC VSZ RSS userTIME sysTIME UPTIME NAME<br />
0 77 965.1M 334.6M 14m14s18 2m28s69 1h33m46 root server<br />
49152 7 14M 5.2M 0m00s40 0m00s30 1h30m15 chiffon<br />
</pre><br />
|Signature=derjohn}}<br />
<br />
<br />
{{Question<br />
|Question=Is there a web-based interface for vserver that will allow creation/deletion/configuration etc. of vserver guests?<br />
||Details=<br />
* http://OpenVPS.org which is a set of scripts with a web-interface for webhosters/ISPs<br />
* http://Openvcp.org which is a distributed system (agent!) with a web-interface, with which you can build/remove guests<br />
* http://vsmon.revolutionlinux.com/ is a distributed monitoring-only solution that allows you to search for a particular vserver in your park.<br />
|Signature=derjohn}}<br />
<br />
== Hosting foreign distributions ==<br />
<br />
{{Question<br />
|Question=I run a Debian host and want to build an Ubuntu guest. Howto?<br />
||Details=Simple ;) Assume you want to build a breezy guest on a sid host with IP 192.168.0.2 and hostname vubuntu, then do:<br />
<pre><br />
vserver vubuntu build --force -m debootstrap --hostname vubuntu.myvservers.net --netdev eth0 --interface 192.168.0.2/24 \<br />
--context 42 -- -d breezy -m http://de.archive.ubuntu.com/ubuntu<br />
</pre><br />
<br />
[UPDATE] Currently there are problems in building breezy under unclear circumstances, which seems to have to do with udev. If the above didnt work, try:<br />
<pre><br />
vserver vubuntu build --force -m debootstrap --hostname vubuntu.myvservers.net --netdev eth0 --interface 192.168.0.2/24 \<br />
--context 42 -- -d breezy -m http://de.archive.ubuntu.com/ubuntu -- --exclude=udev<br />
</pre><br />
In very recent versions of the utils, the problem should not occur anymore (it has to do with the 'secure-mount' if you look in the MLs)<br />
<br />
Well, sid's debootstrap knows how to bootstrap Ubuntu linux. Make sure to have a current debootstrap package: <br />
<pre><br />
apt-get update<br />
apt-get install debootstrap<br />
</pre><br />
The knowledge how to build ubuntu 'breezy badger' (which you probably want to be your guest at the time of writing) has been added recently.<br />
|Signature=derjohn}}<br />
<br />
<br />
{{Question<br />
|Question=I want to build a Gentoo guest. Howto?<br />
||Details=Even simpler ;) See http://www.gentoo.org/proj/en/vps/vserver-howto.xml#doc_chap3 .<br />
|Signature=gcc}}<br />
<br />
== Application level problems ==<br />
<br />
{{Question<br />
|Question=I did everything right, but the application foo does not start. What's up there?<br />
||Details=Before asking on the IRC channel, please check out the 'problematic programs' page:<br />
[[Problematic Programs]]<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=When I try to ssh to the guest, I log into the host, even if I installed sshd on the guest. What's wrong here?<br />
||Details=Look at /etc/ssh/sshd_config of the host:<br />
<pre><br />
Port 22<br />
# Use these options to restrict which interfaces/protocols sshd will bind to<br />
#ListenAddress ::<br />
</pre><br />
And now change the setting to <br />
<pre><br />
Port 22<br />
# Use these options to restrict which interfaces/protocols sshd will bind to<br />
ListenAddress your.hosts.ip.here # not the guests IP! <br />
</pre><br />
Then '/etc/init.d/ssh restart' on the host, after that on the guest (if you did apt-get install ssh on the guest already.)<br />
Do I have to explain more? If the hosts sshd binds all available IP addresses on port 22 (The hosts 'sees' even all addresses of the guests!). So if the guest starts its sshd, it can't bind to port 22 any more. You need to change that setting only on the host. <br />
(BTW: A similar approach has to be done for a lot of daemons, e.g. Apache. If the daemon does not support an explicit bind, you may use the chbind command to 'hide' IP addresses from the daemon before starting.)|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=Bind9 does not like to start in my guest.<br />
||Details=Check out the [[Problematic Programs]] page and/or get my [http://linux-vserver.derjohn.de/bind9-packages/bind9-capacheck_9.3.2-2_i386.deb vserver-guest-ready Debian package] for Debian Sid guests and check out the [http://linux-vserver.derjohn.de/bind9-packages/README.txt readme]. (Hint: This is fresh stuff. Please give me feedback)<br />
<br />
[UPDATE] Since VServer Devel 2.1.1-rc18 you do not need to patch the userland tools anymore. The capabilities are masked.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=My mysqld running in a guest behaves strangely and is awfully slow/locks up<br />
||Details=This can be related to /tmp being too small. mysqld stores temporary tables in /tmp and as such, if a lot of queries happen and /tmp runs full this can cause one query to lock up whilst creating the tmp table and all other queries waiting to acquire the lock. There are two possible solutions to that problem: a.) Modify /etc/vservers/vserver-name/fstab and assign more memory to the tmpfs of /tmp and b.) remove the /tmp entry from /etc/vservers/vserver-name/fstab completly. Especially on database servers with a rather high load the second one might be the preferred method. <br />
If you prefer not to modify or disable tmpfs, you can reconfigure MySQL to use a different tmpdir such as "/var/tmp". For example, edit /etc/my.cnf (RHEL/CentOS) or create /etc/mysql/conf.d/mysqld_custom.conf (Debian) and add the following line: <br />
<pre><br />
tmpdir = /var/tmp<br />
</pre><br />
Afterwards, restart MySQL (/etc/init.d/mysqld restart) and then review MySQL variables (mysqladmin -uroot -p variables) to confirm "tmpdir" is no longer pointing to "/tmp". |Signature=sp, jrklein}}<br />
<br />
{{Question<br />
|Question=Pure-FTP does not run inside a VServer?<br />
||Details=That's because it has capabilities enabled, make sure you rebuild your distro's package passing also the `--without-capabilities` flag to configure.<br />
|Signature=Pedro Algarvio, aka, s0undt3ch}}<br />
<br />
{{Question<br />
|Question=Why do neither sshd nor crond (vixie-cron) work correctly in my CentOS / Fedora guest? I get 'pam_loginuid(crond:session): set_loginuid failed opening loginuid' and similar lines in my logs.<br />
||Details=Took me a while to figure this out, and it turned out to be mentioned in the old wiki. Here is the solution on how to solve a common problem with sshd / crond, somehow related to selinux and auditing:<br />
<br />
pam authentication (also used with openssh) enables "pam_loginuid.so" in the /etc/pam.d/* files. Comment those out as they are not necessary and will not load within a guest anyway. This probably is also necessary on updates later on, if the configs get changed. You therefore may add the following command line to a cronjob file or your software update script:<br />
<pre><br />
/bin/sed --in-place -e "s/^session.*required.*pam_loginuid.so/# session\trequired\tpam_loginuid.so/g" /etc/pam.d/*<br />
</pre><br />
<br />
'''UPDATE:''' If you are compiling your own kernel this can be fixed system-wide by setting CONFIG_AUDIT_LOGINUID_IMMUTABLE=n in kernels .config file.<br />
<br />
|Signature=patrick, SwenTjuln}}<br />
<br />
{{Question<br />
|Question=How do i install nagios-plugins on a Gentoo guest?<br />
||Details=Unfortunately, the nagios-plugins ./configure scripts wants to ping 127.0.0.1 which is not available inside a guest. Therefore you have to build nagios-plugins outside the guest.<br />
The easiest way to do this from the host (assuming the guest is running) is:<br />
<pre><br />
vnamespace -e <xid> -- chroot /vservers/<name> emerge nagios-plugins -va<br />
</pre><br />
|Signature=Hollow}}<br />
<br />
{{Question<br />
|Question=Somebody runs ntpd in guest and you can't use ntpdate in host?<br />
||Details=Try to run ntpdate with options -u :<br />
ntpdate -u ntp.domain.xy<br />
or you can use command:<br />
chbind --nid 42 --ip 1.2.3.4 -- ntpdate ntp.domain.xy<br />
where IP will be the IP of host.<br />
|Signature=Punkie/Bertl}}<br />
<br />
<br />
<br />
== Start / Stop a VServer ==<br />
<br />
{{Question<br />
|Question=How do I make a vserver guest start by default?<br />
||Details=At least on Debian, I can tell you how to do it with the new-style config. If your guest is called "derjohn" and you want it to be started somewhere at the of your bootstrap process, then do:<br />
<pre><br />
echo "default" > /etc/vservers/derjohn/apps/init/mark<br />
</pre><br />
If you want to start it earlier, please read the init script "/etc/init.d/util-vserver" to find out how to do it. In most cases you don't need to change this. On Debian the vservers are started at "20", so after most other stuff is up (networking etc.).<br />
<br />
Besides that I created a small helper script for managing the autostart foo: ((vserver-autostart))|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=How do I start all vservers with a <tt>mark</tt> value of something other than "default"?<br />
||Details=To start all vservers with a mark value of <tt>foo</tt>, you can use something like:<br />
<pre><br />
MARK=foo NUMPARALLEL=42 LOCKFILE=vserver-foo /path/to/util-vserver/vserver-wrapper start<br />
</pre><br />
<br />
If you want to automate this, you can create a copy of the <tt>/etc/init.d/vservers-default</tt> script called <tt>/etc/init.d/vservers-foo</tt>, set <tt>MARK</tt>, <tt>NUMPARALLEL</tt> and <tt>LOCKFILE</tt> appropriately in it, and have it start at whatever point in the boot process.|Signature=Guy-}}<br />
<br />
{{Question<br />
|Question=My host works, but when I start a guest it says that it has a problem with chbind.<br />
||Details=You are probably using util-vserver <= 0.30.209, which does use dynamic network contexts internally (With 0.30.210 this fact changed). So if you compiled your kernel without dynamic contexts, you may start guests, but you can't use the network context.The solution is either to switch to .210 util (or Hollow's toolset) or compile the kernel with dynamic network contexts.<br />
SE Keyword: invalid option `nid' testme.sh<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=What is old-style and new-style config?<br />
||Details=Old-style config refers to a single text-file that contains all the configuration settings. With new-style config the configuration is split into several directories and files. You should probably go for new-style config if you are asking.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=How can I reboot/halt guests?<br />
||Details=It depends. <br />
For legacy Linux-VServer (i.e. 1.2.x), you have to replace /sbin/halt in the guests with vreboot and start rebootmgr in the host. You also need to have a <guest>.conf file in /etc/vservers for each guest. Please have a look at /etc/init.d/rebootmgr.<br />
For Linux-VServer 2.0+, sys_reboot has been virtualized to do the right thing. No changes are needed in guests. Please note that some things depend on the init style used by the guest : read [[util-vserver:InitStyles]]<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=What is the initial PATH?<br />
||Details=By default, vserver uses the 'sysv' startup style, which mimics the init process by running the 3rd runlevel through '/etc/init.d/rc 3' (or '/etc/rc.d/rc 3'). Usually this 'rc' script uses a hard-coded PATH. In the case it doesn't, util-vserver also mimics init's default PATH through /etc/vservers/.defaults/apps/init/environment, or if not present /usr/local/lib/util-vserver/defaults/environment. Beware that all those default PATH usually do not include /usr/local.<br />
|Signature=daniel_hozac&Beuc}}<br />
<br />
{{Question<br />
|Question=When I try to start a guest i get this message "/proc/uptime can not be accessed. Usually, this is caused by procfs-security. Please read the FAQ for more details"?<br />
||Details=After a reboot you need to run the vprocunhide script. If running this script causes many errors to print on the screen, try checking the kernel you have booted with (perhaps it does not have the linux-vserver extensions enabled).<br />
|Signature=mattzerah}}<br />
<br />
{{Question<br />
|Question=When I try to start a guest i get this message "vsched: vc_set_sched(): Function not implemented". <br />
||Details=After an upgrade of the kernel/tools if you used the old scheduler function you must convert them to cgroup cpu limits. If you do not want limits search and remove/rename /etc/vservers/*/sched/ and the guest will start again. This might also happen when you use a newer kernel patch but did not yet update the vserver utils to a recent version (Thorsten).<br />
|Signature=aqueos}}<br />
<br />
== Kernel ==<br />
<br />
{{Question<br />
|Question=Is SMP Supported?<br />
||Details=Yes, on all SMP capable kernel architectures.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=Do I really need the legacy-interfaces? What are these legacy-interfaces?<br />
||Details=Since Linux-VServer is an ongoing project, new features might replace old ones, some might require a development version. Legacy-interfaces are available for backward compability (which might be removed someday) with Linux-VServer 1.2.x.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=I have a vserver running on a Linux kernel with preemption. Is VServer "preempt" safe?<br />
||Details=There are no known issues about running vserver on a preemption enabled kernel. I would like to add, that the vserver kernelhackers would probably exclude that option in 'make menuconfig' if there would be an incompatibility. Just my $.02 :)<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=32 vs 64 Bit? What should I take?<br />
||Details=If you have the choice make the host a 64 bit one. You can run a guest as 32 bit or as 64 bit on a 64 bit host. To run it as 32 bit, you need to compile the x86_64 (a.k.a. AMD64) with the following options:<br />
<pre><br />
[*] Kernel support for ELF binaries<br />
<M> Kernel support for MISC binaries<br />
[*] IA32 Emulation <---- without that, the entire 32bit API is not present<br />
<M> IA32 a.out support <br />
</pre><br />
You can force the guest to behave like a 32 environment like this:<br />
<pre><br />
echo linux_32bit > /etc/vservers/$NAME/personality<br />
echo i686 > /etc/vservers/$NAME/uts/machine<br />
</pre><br />
(thanks cehteh for the hint!)<br />
<br />
But you can force debootstrap to put 32 bit binaries into the guest by 'export ARCH=i386';<br />
<pre><br />
export ARCH=i386 ; vserver build .... <br />
</pre><br />
<br />
On debian when using the newvserver script "export ARCH=i386" has no effect, just use:<br />
<pre><br />
newvserver --arch i386 ...<br />
</pre><br />
<br />
On debian debootstrap can also be gived the arch option:<br />
<pre><br />
vserver myguest \<br />
build -m debootstrap -n myguest \<br />
--hostname myguest.mydomain.com \<br />
-- -d squeeze -- \<br />
--arch=amd64 (or i386 if you want 32bit)<br />
</pre><br />
<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=What does the guest privacy option do in the kernel settings ?<br />
||Details=<pre><br />
>i was wondering about the real thing that guest privacy does. <br />
#ifdef CONFIG_VSERVER_PRIVACY<br />
#define VS_ADMIN_P (0)<br />
#define VS_WATCH_P (0)<br />
#else<br />
<br />
> > Does it just prevent the spectator context ? <br />
<br />
it prevents the spectator context and the admin <br />
functionality in all cases which are privacy<br />
sensitive, which includes:<br />
<br />
- ptrace<br />
- devmapper<br />
- devpts<br />
- inode tag permissions<br />
- mountinfo<br />
- kill/signal<br />
- netlink dumps<br />
- tun control<br />
- iopriority<br />
<br />
> > What security do it bring to the system ?<br />
<br />
together with the VXF_STATE_ADMIN it can be<br />
used to secure a guest (to some degree) from<br />
unwanted access from the host admin, of course,<br />
as the admin can change the kernel, this is a<br />
voluntary feature which mostly prevents certain<br />
kinds of accidential peeking or guest modification<br />
<br />
</pre><br />
|Signature=ghislain}}<br />
<br />
<br />
== Distribution specific questions ==<br />
<br />
{{Question<br />
|Question=VServer is included in the stable Debian GNU/Linux for years now. What VS version did they include?<br />
||Details=There is no support in Debian for Linux-Vserver since the Wheezy release. Debian Squeeze included a 2.6.32 based kernel-package called 2.6.32-5-vserver-ARCH. This contained VServer 2.3.0.36.29.6 with some additional fixes.<br />
|Signature=scientes}}<br />
<br />
{{Question<br />
|Question=Were can I get newer versions of VServer as ready made packages for Debian?<br />
||Details= There are a number of locations<br />
* http://repo.psand.net/info/ has Debian Lenny, Squeeze and Wheezy repositories. Many kernel versions are present. Currently (Febraury 2013) 3.2 kernels are being maintained for Wheezy, with additional packages for 3.4 and 3.10 also available. Architectures available are i386 and amd64. This repository also contains curremt util-vserver builds. Build will shortly begin for Jessie.<br />
* http://www.lihas.de/anleitungen-und-service/linux-vserver-kernel-fuer-debian/linux-vserver-kernel-english details their automatically built repository currently for 3.4 kernels. Building, patching and testing for the kernels is automated.<br />
<br />
Older unmaintained repositories are/were here:<br />
<br />
* http://linux-vserver.derjohn.de/ - "my kernels are always 'devel' branch" (derjohn). This repo contain kernels up to 2.6.29 for amd64, 2.6.26 for i386.<br />
* http://backports.debian.org/ contains 2.6.32 backports for Lenny at time of writing (11th May 2010)<br />
* http://zbla.net/debian/ Unofficial debian vserver packages '''WARNING : i386 packets are compiled for 64bits !''' apt source line: ''deb http://zbla.net/debian/ ./'' (N/A as of 2011/12/27)<br />
|Signature=Gremble<br />
}}<br />
<br />
{{Question<br />
|Question=Were can I get newer versions of VServer as ready made packages for Ubuntu?<br />
||Details= There is only one location for <br />
*http://repo-ubuntu.psand.net/dists/ is the only repository maintained for Ubuntu. It covers the same builds as http://repo.psand.net/info/ - and information there should be used, replacing 'precise' as distro in your /etc/apt/source.list.<br />
|Signature=Gremble<br />
}}<br />
== Misc ==<br />
<br />
{{Question<br />
|Question=Why isn't there a device /dev/xyz within a guest?<br />
||Details=Device nodes allow userspace to access hardware (or virtual resources). Creating a device node inside the guest's namespace will give access to that device, so for security reasons, the number of 'given' devices is small.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=I want to (re)mount a virtual filesystem (like tmpfs) in a running guest ... but the guest has no rights (capability) to (re)mount?<br />
||Details=I take as example your /tmp partition within the guest is too small, what will be likely the case if you stay with the 16MB default (vserver build mounts /tmp as 16 MB tmpfs!).<br />
<pre><br />
# vnamespace -e XID mount -t tmpfs -o remount,size=256m,mode=1777 none /var/lib/vservers/<guest>/tmp/<br />
</pre><br />
(if there's a problem, try expanding the symlinks in the mount path)<br />
Be warned that the guest will not recognize the change, as the /etc/mtab file is not updated when you mount like this. To permanently change the mount, edit /etc/vserver/<guest>/fstab on the host.<br />
<br />
If you get:<br />
<pre><br />
mount: can't find /var/lib/vservers/<guest>/tmp in /etc/fstab or /etc/mtab<br />
</pre><br />
then try instead:<br />
<pre><br />
vnamespace -e builder chroot /var/lib/vservers/<guest>/ mount -o remount,size=64m,mode=1777 /tmp<br />
</pre><br />
|Signature=derjohn/BenjaminGreen}}<br />
<br />
{{Question<br />
|Question=How do I bind mount a host directory inside a running guest?<br />
||Details=There are two ways to do this: one is to enter the bind mount in the guest fstab and restart the guest.<br />
<br />
To understand the other way, let me explain how mount namespaces work.<br />
<br />
Every guest has two mount namespaces associated with it: one "''management namespace''" and one "''operational namespace''".<br />
<br />
On starting the guest, first the management namespace is created as a copy of the host namespace (which means that everything that was mounted on the host is mounted in the new namespace as well). This has unwelcome side effects: for example, if you had a cdrom mounted while starting the guest, you wouldn't be able to eject it until you stop the guest even if you umount it on the host, because it's still mounted in the guest. Therefore, the namespace is ''cleaned up'': filesystems that are mounted outside the root of the guest get unmounted in the guest namespace.<br />
<br />
Subsequently, the operational namespace of the guest is created as a copy of the management namespace, and the guest's processes are started in it.<br />
<br />
To bind mount a host directory in the guest, you must first make that host directory visible in the management namespace of the guest. This is automatically the case if the directory resides inside a mountpoint that exists in the guest namespace as well; however, if the guest config referenced no part of this mountpoint (or it didn't yet exist when you started the guest), then the cleanup mentioned above removed it from the guest's management namespace and you need to re-add it.<br />
<br />
Let's assume, as an example, that we want a guest to see a subdirectory, called <tt>foo</tt>, of the cdrom we just mounted on the host (e.g. under <tt>/media/cdrom</tt>).<br />
<br />
Let's enter the management namespace of the guest (that's what <tt>-i 0</tt> is for):<br />
<br />
<pre><br />
# vnamespace -i 0 -e <guest-xid> -- /bin/bash<br />
</pre><br />
<br />
Now you have access to all host devices; mount the device that contains your directory wherever you want, but you may prefer to mount it in the same location you used on the host. (Note, though, that it's not even necessary for the device to be mounted in the host namespace at all.)<br />
<br />
It's likely best to use <tt>mount -n</tt> lest your host <tt>/etc/mtab</tt> get polluted with mounts from other namespaces.<br />
<br />
<pre><br />
# mount -n /dev/sr0 /media/cdrom<br />
# exit<br />
</pre><br />
<br />
We're now back in the host namespace. <tt>vmount</tt> can now be used to bind mount <tt>/media/cdrom/foo</tt> inside a running guest (in this example, under <tt>/foo</tt> inside the vserver root):<br />
<br />
<pre><br />
# vmount guestname -- --bind /media/cdrom/foo /mnt/foo<br />
</pre><br />
|Signature=[[User:KornAndras|Guy-]] 01:31, 10 January 2012 (UTC)}}<br />
<br />
{{Question<br />
|Question=How do I mount a device present on the host under a directory in a running guest?<br />
||Details=Use something like:<br />
<pre><br />
vnamespace -e <guestname> mount -n /dev/<device> /vservers/<guest>/place/you/want/to/mount/it<br />
</pre><br />
<br />
This device can be unmounted with:<br />
<br />
<pre><br />
vnamespace -e <guestname> umount -n /vservers/<guest>/place/you/want/to/mount/it<br />
</pre><br />
<br />
|Signature=derjohn/BenjaminGreen}}<br />
<br />
{{Question<br />
|Question=Does anyone know how to increase the size of /tmp within a vserver w/o restarting?<br />
||Details=Use the remount option for mount.<br />
# vnamespace -e XID mount -n -t tmpfs -o remount,size=32m tmpfs /<vdir>/<guest>/tmp<br />
or something like that. The arguments are needed since mount is not going to be using /etc/fstab for the information and the version of /proc/mounts is best understood by<br />
# vnamespace -e XID cat /proc/mounts.<br />
See [[Frequently_Asked_Questions#I want to (re)mount a partition in a running guest ... but the guest has no rights (capability) to (re)mount?]]<br />
|Signature=derjohn/dhozac}}<br />
<br />
<br />
{{Question<br />
|Question=#1 ERROR: capset(): Operation not permitted<br />
||Details=capabilities are not enabled in kernel-setup<br />
please check that CONFIG_SECURITY_CAPABILITIES is loaded or included in the kernel. ( check with "cat /path_to_kernel/.config | grep -i cap ") <br />
(2.6.11.5-vs-1.9.5 + 0.30-205)<br />
|Signature=IrcQuestions}}<br />
<br />
{{Question<br />
|Question=How can I make 'vserver start' mount the root filesystem?<br />
||Details=Mount it via /etc/vservers/vserver-name/fstab, make sure to set the option 'dev' e.g.:<br />
<pre>/dev/drbd0 / xfs rw,dev 0 0</pre><br />
|Signature=AdrianReyer}}<br />
<br />
<br />
{{Question<br />
|Question=I deleted a guest's directory without shutting it down. Now I have a "ghost" running. Is there any possibility to get it out of proc without rebooting?<br />
||Details=<br />
vkill --xid <xid> -s 15; sleep 2; vkill --xid <xid> -s 9<br />
<br />
You will also need to remove guest's ip, for example with:<br />
ip addr del <ip> dev eth0<br />
|Signature=daniel_hozac & gebura }}<br />
<br />
{{Question<br />
|Question=When using nice and su (for example, in the updatedb cron job), I get: su: Permission denied. What does it mean?<br />
||Details=A guest cannot lower its nice value - and that's what 'su' does through pam_limits which sets a nice value of 0. You can see it through strace:<br />
$ strace nice su nobody<br />
[...]<br />
setpriority(PRIO_PROCESS, 0, 0) = -1 EACCES (Permission denied)<br />
You can use 'su nobody -c nice some_cmd' instead.<br />
<br />
The problem is caused by the fact that host system is setting limits for guests (when instructed to do so) and the dropped capability dissallows processess on guest systems to change and increase them later. That means no process on a guest can lower nice value above the limit set by host.<br />
<br />
If the pam_limits module is activated on a guest system it will first try to '''reset nice value to 0''' even if <tt>/etc/security/limits.conf</tt> file is empty or even if there are lower priority limits set in it. The pam_limits module does that since [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=241663 its developers decided] that it should reset some limits to defaults and start from scratch when applying new restrictions. Unfortunately, already limited guest system won't be able to do it since resetting nice value to 0 means increasing the limit which is forbidden. See [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=311058 Debian Bug report logs - #311058] for more information about that Debian bug.<br />
<br />
See also [[Frequently_Asked_Questions#Cron is not working on my guest system (which is Debian). How can I fix it?|Cron is not working…]]<br />
<br />
|Signature=daniel_hozac & Beuc & Paweł Wilk}}<br />
<br />
{{Question<br />
|Question=Cron is not working on my guest system (which is Debian). How can I fix it?<br />
||Details=On a guest system the cron daemon may not work properly. When looking into the log file (e.g. <tt>/var/log/syslog</tt>) the following message may appear repeatedly:<br />
CRON[xxxxx]: Permission denied<br />
<br />
Similar thing may happen with the <tt>su</tt> when trying to execute a command as root.<br />
<br />
It's not the problem in Cron but in the pam_limits module on a guest system (see [[Frequently_Asked_Questions#When using nice and su (for example, in the updatedb cron job), I get: su: Permission denied. What does it mean?|FAQ:When using nice and su…]] for more information about the cause).<br />
<br />
There are 4 ways to solve or work-around this problem:<br />
<br />
'''1. Allowing guests to reset resource limits:'''<br />
<br />
It's clean solution but you may expect some guest processes increasing their limits because not everything is controlled by PAM. It also breaks centralized resources limiting approach so a guest can do bad things that may cause other guests and host to be overloaded and unresponsive.<br />
<br />
To apply it you have to add <tt>CAP_SYS_RESOURCE</tt> flag to <tt>/etc/vservers/<server name>/bcapabilities</tt> (2.6 kernels).<br />
<br />
See [[util-vserver:Capabilities_and_Flags|Capabilities and Flags]] for more information.<br />
<br />
'''2. Disabling pam_limits on a guest systems:'''<br />
<br />
This workaround is easy and works fine when your guest systems aren't really multiuser but rather service boxes. It disables setting of the resource limits by PAM so the limits can only be set globally for the whole guest (using rlimits or cgroups on a host) but never increased inside of the guest system.<br />
<br />
To apply it just enter the guest and edit the files listed below, commenting out any line containing <tt>pam_limits</tt>:<br />
<br />
/etc/pam.d/su<br />
/etc/pam.d/sudo<br />
/etc/pam.d/cron<br />
<br />
You can also use this one-liner on a guest:<br />
<br />
<pre><br />
/bin/sed --in-place -e "s/^\s\?session.*pam_limits.so.*/\#\0/g" /etc/pam.d/{su,sudo,cron}<br />
</pre><br />
<br />
'''3. Allowing guest's pam_limits to set limits when possible:'''<br />
<br />
This workaround allows you to have working <tt>pam_limits</tt> inside a guest system and global limits set by a host system. What's the catch? The problematic PAM module won't fully work for the root user on a guest system as expected and there might appear some PAM's warnings in guest's <tt>auth.log</tt>. Since using pam_limits to limit regular user processes is far more frequent than using it to limit root processes, this solution may be a good compromise. It is about setting a proper limits in pam_limits configuration and about setting this PAM module in a way that its function is optional (instead of required). The last change makes PAM to continue with session even if pam_limits encounters some error during setting limits (it usually applies to superuser sessions).<br />
<br />
The not so nice news is that there might be a need of keeping guest's limits configuration up to date according to limits globally set for a guest. The limits set in pam_limits configuration file(s) shouldn't be higher (lower in case of nice value) than global guest's limits.<br />
<br />
To apply it enter the guest and edit the files listed below, replacing occurences of <tt>required</tt> by <tt>optional</tt> in the lines containing <tt>pam_limits</tt>:<br />
<br />
/etc/pam.d/su<br />
/etc/pam.d/sudo<br />
/etc/pam.d/cron<br />
<br />
For example:<br />
<br />
# Sets up user limits, please define limits for cron tasks<br />
# through /etc/security/limits.conf<br />
session optional pam_limits.so<br />
<br />
Then on a guest system create the file <tt>/etc/security/limits.d/01-fixpam.conf</tt> containing:<br />
<br />
<pre><br />
* - priority X # replace X with your guest's nice value <br />
</pre><br />
<br />
You can automate this process to happen automagically for any guest by creating the startup script named <tt>/etc/vservers/.defaults/scripts/post-start.d/01-pamfix</tt>:<br />
<br />
<pre><br />
#!/bin/sh<br />
<br />
# This script tries to fix pam_limits entries<br />
# to make it possible for PAM in a guest system to<br />
# set its own limits.<br />
<br />
PAM_DIR="etc/pam.d"<br />
PAM_SERVICES="su sudo cron"<br />
LIMITS_FILE="etc/security/limits.d/01-pamfix.conf"<br />
<br />
vname="$2"<br />
[ -z "$vname" ] && exit 0<br />
<br />
vcfg=$( /usr/sbin/vserver-info "$vname" CFGDIR )<br />
[ ! -d "$vcfg" ] && exit 0<br />
<br />
for s in $PAM_SERVICES<br />
do<br />
pamfile="${PAM_DIR#\/}/$s"<br />
[ -f "$pamfile" ] && /bin/sed --in-place -e "s/\(^\s\?session.*\)required\(.*pam_limits.so.*\)/\1optional\2/g" "$pamfile"<br />
done<br />
<br />
[ ! -f "${vcfg}/nice" ] && exit 0<br />
nval=$( /usr/bin/head -1 "${vcfg}/nice" )<br />
[ -n "$nval" ] && echo "* - priority $nval # (added by vserver startup script)" > "${LIMITS_FILE#\/}"<br />
<br />
exit 0<br />
</pre><br />
<br />
'''4. Disabling resource limits for a guest:'''<br />
<br />
It easy, clean and… unsafe solution. You just have to not set resource limits (e.g. priority, nice value) for a guest or set the nice value limit to 0 on a host system. Resetting it later by guest's <tt>pam_limits</tt> will not generate an error.<br />
<br />
|Signature=Paweł Wilk}}<br />
<br />
{{Question<br />
|Question=How do I handle NFS mounts within in a guest?<br />
||Details=There are at least four ways.<br />
<br />
In any case, you probably want to force the nfs version to 3 or lower to avoid id mapping issues (one symptom of having an id mapping issue is that <tt>no_root_squash</tt> appears to be ignored). You can check whether the mount uses nfsv4 by looking at <tt>/proc/mounts</tt> inside the guest. You can force the protocol version to 3 by passing the mount options <tt>nfsvers=3,mountvers=3</tt>.<br />
<br />
'''1)''' Mount the NFS share from the host OS and let vserver guest access it as part of it's file system.<br />
<br />
''mount --bind'' may also be beneficial in this scenario.<br />
<br />
'''2)''' Use util-vserver and create a ''fstab.remote'' file in the /etc/vserver/<vserver_name> directory. Populate this with the NFS shares and they will be mounted in the context of the vserver guest.<br />
<br />
See http://www.nongnu.org/util-vserver/doc/conf/configuration.html<br />
<br />
Note that as of 0.30.216-pre3000 and kernel 3.0.4-vs2.3.1-pre10.1, the mount request will appear to originate from the IP of the host, not the guest. It is unclear (to [[User:KornAndras|Guy-]]) whether this is a bug.<br />
<br />
'''3)''' Add capabilities to the vserver guest instance to grant sufficient rights to allow NFS mounts.<br />
<br />
Add the following to /etc/vserver/<vserver_name>/bcapabilities<br />
SYS_ADMIN<br />
Add the following to /etc/vserver/<vserver_name>/ccapabilities<br />
SECURE_MOUNT<br />
BINARY_MOUNT<br />
<br />
See [[Capabilities_and_Flags]] for more information about vserver capabilities.<br />
<br />
If you want the NFS shares to be mounted when the guest starts, add them to /etc/vserver/<vserver_name>/fstab.<br />
<br />
'''4)''' Before starting the guest, make a directory of the host "shared" using <tt>mount --make-shared /path/to/dir</tt>, then set up autofs to mount nfs shares under <tt>/path/to/dir/sharename</tt>.<br />
<br />
rbind mount subdirectories of <tt>/path/to/dir</tt> in the guest from its fstab.<br />
<br />
This setup is good if the nfs shares are not often needed, and especially if they're occasionally needed by more than one guest. (As of September 2011, running autofs inside a vserver guest didn't work for me. --[[User:KornAndras|Guy-]] 01:05, 30 October 2011 (UTC))<br />
<br />
||Signature=martindk}}<br />
<br />
<br />
{{Question<br />
|Question=vserver start/stop/enter fails with something like "vnamespace: execvp("/usr/sbin/vserver"): No such file or directory" ?<br />
||Details=Check whether ''/usr'' is mounted in the namespace you are working with.<br />
<pre>vnamespace -e <guest> cat /proc/mounts</pre><br />
If there is no ''/usr'', you can fix your problem with simply mounting it using the following command:<br />
<pre>vnamespace -e <guest> mount /dev/<device> /usr</pre><br />
<br />
||Signature=sim0n}}<br />
<br />
{{Question<br />
|Question=The command vserver <$server> start gives '/etc/init.d/rc: line 74: /etc/default/rcS: No such file or directory', what do I do? <br />
||Details=The vserver has not been correctly installed, this has several reasons<br />
check your install log and it should tell you something about that your server didn't get installed properly<br />
* use stable distribution of debian as server (debootstrap may be different over the versions)<br />
* deny_mount, deny_caps and deny_pivot should be off if your running grsec.<br />
<br />
||Signature=Dude}}<br />
<br />
<br />
{{Question<br />
|Question=How could I rename a vserver directory?<br />
||Details=Please note : this procedure renames the '''directory''', not the '''hostname''' !<br />
#Stop the vserver in question<br />
#rename the <tt>/vservers/<server name></tt> directory<br />
#rename the <tt>/etc/vservers/<server name></tt> directory<br />
#update link: <tt>/etc/vservers/<server name>/run</tt> → <tt>/var/run/vservers/<server name></tt><br />
#update link: <tt>/etc/vservers/<server name>/vdir</tt> → <tt>/etc/vservers/.defaults/vdirbase/<server name></tt><br />
#update link: <tt>/etc/vservers/<server name>/cache</tt> → <tt>/etc/vservers/.defaults/cachebase/<server name></tt><br />
#update link: <tt>/var/run/vservers.rev/<server XID></tt> → <tt>/etc/vservers/<server name></tt><br />
#Start the vserver in question. It should start properly.<br />
<br />
|Signature=FlorianD (from ''hillct'' page in old wiki)}}<br />
<br />
<br />
{{Question<br />
|Question=what if i see my vserver in vserver-stat but with no name ?<br />
||Details=the link in /var/run/vservers is missing<br />
Just do a : cat /etc/vservers/<guest>/context > /var/run/vservers/<guest><br />
check that the <guest> is the good one by using vuname --get --xid <context> with the context you have in the vserver-stat listing.<br />
|Signature=IrcQuestions}}<br />
<br />
== Upgrade from 2.0 to 2.2 ==<br />
<br />
{{Question<br />
|Question=I now get errors like "ncontext: vc_net_create(): Invalid argument; dynamic contexts disabled." on startup. Vservers are not started<br />
||Details=Dynamic context are disabled by default and are deprecated. For example, tagxid and network checks won't be useable with dynamic ids. Now you should manually assign a explicit context to your vservers, like<br />
echo 101 > /etc/vservers/myvserv/context<br />
ADDENDUM: please consider that valid static contexts are between 2 and 49151 ( daniel_hozac on IRC ) otherwise you will end up with unexplainable error "ncontext: vc_net_migrate(): No such process" when trying to start the vserver.<br />
<br />
|Signature=daniel_hozac&Beuc}}<br />
<br />
<br />
{{Question<br />
|Question=How do I assign a static context to an existing vserver?<br />
||Details=Simple ;) See the answer above. <br />
|Signature=gcc}}<br />
<br />
<br />
{{Question<br />
|Question=Since upgrading to a newer VS version my guest complains about "vsched: non-numeric value specified for '--priority_bias" at start time. What's wrong?<br />
||Details=The scheduler paramters changed.You can use this (ugly) script to convert them or do it by hand:<br />
<pre><br />
# cat /usr/local/sbin/vserver-convert-schedule-to-scheddir<br />
#/bin/sh<br />
mkdir /etc/vservers/$1/sched<br />
sed -e 1p -n /etc/vservers/$1/schedule > /etc/vservers/$1/sched/fill-rate<br />
sed -e 2p -n /etc/vservers/$1/schedule > /etc/vservers/$1/sched/interval<br />
sed -e 3p -n /etc/vservers/$1/schedule > /etc/vservers/$1/sched/tokens<br />
sed -e 4p -n /etc/vservers/$1/schedule > /etc/vservers/$1/sched/tokens-min<br />
sed -e 5p -n /etc/vservers/$1/schedule > /etc/vservers/$1/sched/tokens-max<br />
<br />
mv /etc/vservers/$1/schedule /etc/vservers/$1/schedule.converted.see.scheddir<br />
<br />
# see: http://oldwiki.linux-vserver.org/Scheduler+Parameters<br />
# see: http://www.nongnu.org/util-vserver/doc/conf/configuration.html#sched<br />
</pre><br />
||Signature=derjohn}}<br />
<br />
<br />
{{Question<br />
|Question=Since upgrading to a newer VS version my guest doesn't have the amount of shared memory (SHM / SHMMAX / SHMALL ) as it had in the former version. What changed?<br />
||Details=Every VS version that runs on a kernel >= 2.6.19 offers sysctl values per guest. This has to do with the 'ipc namespace' feature that was added to the mainline kernel in version 2.6.19. Linux-VServer uses that feature to give each guest a separate 'ipc namespace' and thus 'own' sysctl values per guest. Because shmmax is such a sysctl value, you have to set it per guest.<br />
Here is an example how to do so:<br />
<br />
<pre><br />
# mkdir /etc/vservers/<vserver>/sysctl/0 -p<br />
# echo kernel.shmall > /etc/vservers/<vserver>/sysctl/0/setting<br />
# echo 134217728 > /etc/vservers/<vserver>/sysctl/0/value<br />
# mkdir /etc/vservers/<vserver>/sysctl/1 -p<br />
# echo kernel.shmmax > /etc/vservers/<vserver>/sysctl/1/setting<br />
# echo 134217728 > /etc/vservers/<vserver>/sysctl/1/value<br />
</pre><br />
It's also explained on the geat flower page:<br />
# see: http://www.nongnu.org/util-vserver/doc/conf/configuration.html -> Look for "sysctl".<br />
<br />
After changing those values, restart your guest, enter it and check if the values are set:<br />
<pre><br />
# sysctl -a | grep shm<br />
...<br />
kernel.shmall = 134217728<br />
kernel.shmmax = 134217728<br />
</pre><br />
<br />
To change a value for a running guest, on the host use:<br />
<pre><br />
vspace -e CONTEXTID --ipc sysctl -w kernel.shmall=134217728<br />
vspace -e CONTEXTID --ipc sysctl -w kernel.shmmax=134217728<br />
</pre><br />
<br />
||Signature=derjohn<br />
}}<br />
<br />
[[Category:Community]]<br />
[[Category:Categories]]</div>KornAndrashttp://wiki.linux-vserver.org/Frequently_Asked_QuestionsFrequently Asked Questions2018-02-20T15:59:30Z<p>KornAndras: explain how to start guests with a nondefault mark value</p>
<hr />
<div><div style="margin: 2em auto 2em auto; padding: 10px; background-color: #F9ECCD; border: 1px solid #004433; text-align: center;"><br />
[[Image:Icon-Caution.png|left]]<br />
We currently migrate to MediaWiki from our old installation, but not all content has been migrated yet. Take a look at the [[Wiki Team]] page for instructions how to help or look at the [http://oldwiki.linux-vserver.org old wiki] to find the information not migrated yet.<br />
<br />
'''To ease migration we created a [[List of old Documentation pages]].'''<br />
</div><br />
<br />
CURRENTLY THE CONTENT OF THE OLD WIKI FAQ (AND MORE) IS BEING MIGRATED TO THIS PAGE (TASK: DERJOHN)<br />
<br />
<br />
__TOC__<br />
<br />
== General ==<br />
<br />
{{Question<br />
|Question=What is the status of Linux-VServer?<br />
||Details=Linux-VServer has more than a decade of maturity and is actively developed. Two projects are similar to Linux-VServer, [[http://lxc.sf.net LXC]], and [[http://openvz.org OpenVZ]]. Of the two, OpenVZ is the more mature and offers some similar functionality to Linux-VServer. LXC is solely based on the kernel mechanisms such as cgroups that are present in modern kernels. These kernel mechanisms will continue to be refined and isolation will mature. As that occurs, Linux-VServer will take advantage of those new features separately from LXC and continue to provide the same robust user interface that it does currently. Currently, LXC offers significantly less functionality and isolation than Linux-vserver. LXC will eventually be a robust wrapper around kernel mechanisms but is still under heavy development and not considered ready for production use.<br />
|Signature=beck}}<br />
<br />
<br />
<br />
{{Question<br />
|Question=What is a 'Guest'?<br />
||Details=To talk about stuff, we need some naming. The physical machine is called 'Host' and the 'main' context running the Host Distro is called 'Host Context'. The virtual machine/distro is called 'Guest' and basically is a Distribution (Userspace) running inside a 'Guest Context'.<br />
|Signature=derjohn}}<br />
<br />
<br />
{{Question<br />
|Question=What kind of Operating System (OS) can I run as guest?<br />
||Details= With VServer you can only run Linux guests. The trick is that a guest does not run a kernel on its own (as XEN and UML do), it merely uses a virtualized host kernel-interface. VServer offers so called security contexts which make it possible to separate one guest from each other, i.e. they cannot get data from each other. Imagine it as a chroot environment with much more security and features.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=Is this a new project? When was it started?<br />
||Details=The first public occurrence of Linux-VServer was Oct 2001. The initial mail can be found here: http://www.cs.helsinki.fi/linux/linux-kernel/2001-40/1065.html<br />
So you can expect a mature software product which does its magic quite well (And hey, we have a version > 2.0!)<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=Which distributions did you test?<br />
||Details=Some. Check out the wiki for ready-made guest images. But you can easily build own guest images, e.g. with Debian's debootstrap. Checkout [[Building Guest Systems]] how to do that.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=Is VServer comparable to XEN/UML/QEMU?<br />
||Details=Nope. XEN/UML/QEMU and VServer are just good friends. Because you ask, you probably know what XEN/UML/QEMU are. VServer in contrary to XEN/UML/QEMU does not "emulate" any hardware you run a kernel on. The purpose of Linux VServer is to isolate (groups of) applications. The isolation is done by the kernel (see [[Overview]] for a more detailed comparison). You can run a VServer kernel in a XEN/UML/QEMU guest. This is confirmed to work at least with Linux 2.6/vs2.0.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=With which version should I begin?<br />
||Details=If you are new to VServer I recommend to try the latest stable kernel patch, and the latest util-vserver "alpha" release.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=Is VServer secure?<br />
||Details=We hope so. It should be as least as secure as Linux is. We consider it much much more secure though.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=Performance?<br />
||Details=For a single guest, we basically have native performance. Some tests showed insignificant overhead (about 1-2%) others ran faster than on an unpatched kernel. This is IMVHO significantly less than other solutions waste, especially if you have more than a single guest (because of the resource sharing).<br />
|Signature=derjohn}}<br />
<br />
<br />
{{Question<br />
|Question=What is the "great flower page"?<br />
||Details=Well, [http://www.nongnu.org/util-vserver/doc/conf/configuration.html this page] contains all configuration options for util-vserver. The name of the page is derived from the stylesheet(s) it contains.<br />
|Signature=derjohn}}<br />
<br />
<br />
<br />
== Resources usage ==<br />
<br />
{{Question<br />
|Question=Resource sharing?<br />
||Details=Yes ....<br />
* memory: Dynamically.<br />
* CPU usage: Dynamically (token bucket)<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=Resource limiting?<br />
||Details=You can put limits per guest on different subsystems.<br />
* using ulimits and rlimits (rlimit is a new feature of kernel 2.6/vs2.0.) per guest, to limit the memory consumption, the number of processes or file-handles, ... : see [[Resource Limits]]<br />
* CPU usage : see [[CPU Scheduler]]<br />
* disk space usage : see [[Disk Limits and Quota]]<br />
Note that you can only offer guaranteed resource availability with some ticks at the time.<br />
|Signature=derjohn&xm}}<br />
<br />
{{Question<br />
|Question=How do I limit a guests RAM? I want to prevent OOM situations on the host!<br />
||Details=First you can read [http://linux-vserver.org/Memory+Allocation] and [[Memory Limits]].<br />
If you want a recipe, do this:<br />
# Check the size of memory pages. On x86 and x86_64 is usually 4 KB per page. (on linux "getconf -a|grep PAGE" will give you the information)<br />
# Create /etc/vserver/<guest>/rlimits/<br />
# Check your physical memory size on the host, e.g. with "free -m". maxram = kilobytes/pagesize.<br />
# Limit the guests physical RAM to value smaller then maxram:<pre>echo %%insertYourPagesHereSmallerThanMaxram%% > /etc/vserver/<guest>/rlimits/rss </pre><br />
# Check your swapspace, e.g. with 'swapon -s'. maxswap = swapkilobytes/pagesize.<br />
# Limit the guest's maximum number of as pages to a value smaller than (maxram+maxswap): <pre> echo %%desiredvalue%% > /etc/vserver/<guest>/rlimits/as </pre><br />
# Correctly display the memory information inside the guest:<pre>echo "VIRT_MEM" >> /etc/vservers/<guest>/flags</pre><br />
It should be clear this can still lead to OOM situations. Example: You have two guests and your as limit per guest is greater than 50% of (maxram+maxswap). If both guests request their maximum at the same point in time, there will be not enough mem .....<br />
|Signature=derjohn}}<br />
<br />
<br />
{{Question<br />
|Question=Disk I/O limiting? Is that possible?<br />
||Details=Well, since vs2.1.1 Linux-VServer supports a mechanism called 'I/O scheduling', which appeared in the 2.6 mainline some time ago. The mainline kernel offers several I/O schedulers:<br />
<pre><br />
# cat /sys/block/hdc/queue/scheduler<br />
noop [anticipatory] deadline cfq<br />
</pre><br />
<br />
The default since 2.6.18 in Sept 2006 is CFQ, described below, and prior to that was anticipatory a.k.a. "AS" ([[http://en.wikipedia.org/wiki/CFQ#Kernel_2.6.18_.2820_September_2006.29 Wikipedia]]). When running several guests on a host you probably want the I/O performance shared in a fair way among the different guests. The kernel comes with a "completely fair queueing" scheduler, CFQ, which can do that. (More on schedulers can be found at http://lwn.net/Articles/114770/)<br />
This is how to set the scheduler to "cfq" manually:<br />
<pre><br />
root# echo "cfq" > /sys/block/hdc/queue/scheduler<br />
root# cat /sys/block/hdc/queue/scheduler<br />
noop anticipatory deadline [cfq]<br />
</pre><br />
Keep in mind that you have to do it on all physical discs. So if you run an md-softraid, do it to all physical /dev/hdXYZ discs!<br />
If you run Debian there is a predefined way to set the /sys values at boot-time:<br />
<pre><br />
# apt-get install sysfsutils<br />
[...]<br />
<br />
# grep cfq /etc/sysfs.conf<br />
block/sda/queue/scheduler = cfq<br />
block/sdc/queue/scheduler = cfq<br />
<br />
# /etc/init.d/sysfsutils restart<br />
</pre><br />
<br />
For non-vserver processes and CFQ you can set by which key the kernel decides about the fairness:<br />
<pre><br />
cat /sys/block/hdc/queue/iosched/key_type<br />
pgid [tgid] uid gid<br />
</pre><br />
Hint: The 'key_type'-feature has been removed in the mainline kernel recently. Don't look for it any longer :(<br />
<br />
The default is tgid, which means to share fairly among process groups. Think every guest is treated like a own process group. It's not possible to set a scheduler strategy within a guest. All processes belonging to the same guest are treated like "noop" within the guest. So: If you run apache and some ftp-server within the _same_ guest, there is no fair scheduling between them, but there is fair scheduling between the whole guest and all other guests.<br />
<br />
And: It's possible to tune the scheduler parameters in several ways. Have a look at /sys/block/hdc/queue/....<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=Nice disk I/O scheduling, is that possible?<br />
||Details=Well, since linux 2.6.13 processess have another priority next to the cpu nice scheduling hint, it's called io nice.<br />
It's split into three groups, called real-time, best effort and idle. The default is best-effort, but within best-effort, you can have a niceness from 0 to and including 7.<br />
You can set this niceness by the tool ionice, which for debian is either in the package util-linux or schedutils.<br />
To change the io-niceness you need the <tt>CAP_SYS_NICE</tt>, '''and''' need to have the same uid as the processe you want to ionice.<br />
<br />
:'''Note:''' If you want to use any schedulung other than best-effort you will also need the <tt>CAP_SYS_ADMIN</tt>-flag. Be warned that this gives quite some capabilities to the vserver, not just for I/O scheduling!<br />
<br />
If you want to increase the niceness of an I/O hogging process within a vserver you need to do:<br />
<PRE><br />
chcontext --xid sponlp1 sudo -u '#2089' ionice -c2 -n5 -p24409<br />
</PRE><br />
with sudo and ionice installed on the root server to increase the *nice*ness of pid 24409, with uid 2089<br />
|Signature=Groteblup}}<br />
<br />
{{Question<br />
|Question=I want iotop to display all guest processes on host to give me a nice overview of I/O usage.<br />
||Details=You must allow iotop to read information from all guests. Add <br />
<br />
<PRE><br />
# setattr --watch /proc/vmstat<br />
</PRE><br />
to, for example, rc.local, and later run iotop:<br />
<PRE><br />
# vcontext --migrate --xid 1 -- iotop<br />
</PRE><br />
|Signature=corey via ser}}<br />
<br />
== Unification ==<br />
<br />
{{Question<br />
|Question=What is unification (vunify)?<br />
||Details=[[Unification]] is Hard Links on Steroids. Guests can 'share' common files (usually binaries and libraries) in a secure way, by creating hard links with special properties (immutable but unlinkable (removable)). The tool to identify common files and to unify them is called [[vunify]].<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=What is [[vhashify]]?<br />
||Details=The successor of [[vunify]], a tool which does unification based on hash values (which allows to find common files in arbitrary paths.)<br />
It creates hardlinks to files named after a hash of the content of the file. If you have a recent version of the vserver patch (2.2+), with CONFIG_VSERVER_COWBL enabled, you can even modify the hardlinked files inside the vservers and the links will be broken automatically.<br />
There seems to be a catch when a hashified file has multiple hardlinks inside a guest, or when another internal hardlink is added after hashification. Link breaking will remove all the internal hardlinks too, so the guest will end up with different copies of the original file. The correct solution would be to not hashify files that have multiple links prior to hashification, and to break the link to the hashified version when a new internal hardlink is created. Apparently, this is not implemented yet (?).<br />
<br/>|Signature=Guy-<br />
<br/><br />
Note: hashify cannot cross XFS project QUOTA because hardlinks cannot cross projects.<br />
}}<br />
<br />
{{Question<br />
|Question=How do I manage a multi-guest setup with vhashify?<br />
||Details=For '[[vhashify]]', just do these once:<br />
<pre><br />
mkdir /etc/vservers/.defaults/apps/vunify/hash /vservers/.hash<br />
ln -s /vservers/.hash /etc/vservers/.defaults/apps/vunify/hash/root<br />
</pre><br />
Then, do this one line per vserver:<br />
<pre><br />
mkdir /etc/vservers/<vservername>/apps/vunify # vhashify reuses vunify configuration<br />
</pre><br />
To hashify a running vserver, do (possibly from a cronjob):<br />
<pre><br />
vserver name-of-guest hashify<br />
</pre><br />
<br />
The guest needs to be running because vhashify tries to figure out what files not to hashify by calling the package manager of the guest via <tt>vserver enter</tt>.<br />
<br />
In order for the OS cache to benefit from the hardlinking, you'll have to restart the vservers.<br />
<br />
To clean up hashified files that are no longer referenced by any vserver, do (possibly from a cronjob):<br />
<pre><br />
find /vservers/.hash -type f -links 1 -print0 | xargs -0 rm<br />
</pre><br />
<br />
Until you do this, the files still take up place even though no vservers need them.<br />
|Signature=Guy-}}<br />
<br />
== Filesystem usage ==<br />
<br />
{{Question<br />
|Question=Is there a way to implement "user/group quota" per VServer?<br />
||Details=Yes, but not on a shared partition for now. You need to put the guest on a separate partition, setup a vroot device (to make the quota access secure), copy that into the guest, and adjust the mtab line inside the guest. If 8 vroot device is not enough for you, you can add more with the kernel parameter max_vroot (exemple for built in kernel vroot /vmlinuz-2.6.31.6-vs2.3.0.36.26aq root=/dev/md1 ro max_vroot=20 ). If vroot is a module you'd actually want to put for exemple "options vroot max_vroot=20" in /etc/modprobe.conf and then just do modprobe vroot<br />
|Signature=derjohn,gadnet}}<br />
<br />
{{Question<br />
|Question=What about "Quota" for a context? Howto limit disk usage?<br />
||Details=Context quotas are now called Disk Limits (so that we can tell them apart from the user/group quotas :). They are supported out of the box (with vs2.0+) for all major filesystems (ext2/3, ReiserFS, JFS). You need to tag the FS with XID (see below). Please read [[Disk Limits and Quota]] for more information.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=How do I tag a guest's directory with xid?<br />
||Details=Tagging the guest's files gives you several advantages, e.g. the accounting will work properly.<br />
Filesystem XID tagging only works on supported filesystem. Those are currently: ext2/3, reiserfs/reiser3, xfs and jfs.<br />
To activate the XID tagging you have to mount the filesystem with "-o tag" (former tagxid is outdated since VS2.2). Attention: It's _not_ possible to "-o remount,tag", you have to mount it freshly. The guests will tag their files automatiaclly. If you copy files in from the host, you have to tag them manually like this:<br />
<pre><br />
chxid -c xid -R /var/lib/vservers/<guest><br />
</pre><br />
Note: Context 0 and 1 will see all files, guests will only be able to access untagged files and their own XID. They can see other XID files but no information about the file, e.g. no owner, no group, no permissions.<br />
Note: It is not advised to tag the root filesystem, as [http://www.paul.sladen.org/vserver/archives/200602/0020.html explained by Herbert] : trying to do so will expose you to some troubles !<br />
|Signature=derjohn_and_gonzo_and_are}}<br />
<br />
{{Question<br />
|Question=How can I copy anything from host to guest partition, normally unvisible on host?<br />
||Details=You should just change namespace, e.g.:<br />
<pre><br />
vnamespace --enter <xid> -- /bin/bash<br />
</pre><br />
and then use standard cp or rsync programs.<br />
|Signature=SergiuszPawlowicz}}<br />
<br />
{{Question<br />
|Question=Why is the barrier attribute disappearing on reiserfs filesystem after umount or host reboot?<br />
||Details=The filesystem has to be mounted with explicitly defining the 'attrs' option, i.e. <br />
<pre><br />
mount /dev/reiserfsdev /vservers -oattrs<br />
setattr --barrier /vservers<br />
</pre><br />
to get the barrier survive after umount/reboot.<br />
|Signature=Nikolay Kichukov}}<br />
<br />
== Network ==<br />
<br />
{{Question<br />
|Question=Does it support IPv6?<br />
||Details=Currently it requires an additional patch, but the functionality should be available in 2.3+ soon. [[IPv6]] has more information.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=I can't do all I want with the network interfaces inside the guest?<br />
||Details=For now the networking is 'Host Business' -- the host is a router, and each guest is a server. You can set the capability ICMP_RAW in the context of the guest, or even the capability CAP_NET_RAW (which would even allow to sniff interfaces of other guests!). Likely to change with ngnet.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=How do I add several IPs to a vserver?<br />
||Details=First of all a single guest vserver only supports up to 16 IPs (There is a 64-IP patch available, which is in "derjohn's kernel").<br />
<pre><br />
Update from IRC (2011-08-22):<br />
<mmouse> quick question: what is the maximum count of IPs (v4) I can have in a single guest?<br />
<daniel_hozac> unlimited.<br />
</pre><br />
<br />
Here is a little helper-script that adds a list of IPs defined in a text file, one per line.<br />
<pre><br />
#!/bin/bash<br />
j=1<br />
for i in `cat myiplist`; do<br />
j=$(($j+1))<br />
mkdir $j<br />
echo $i > $j/ip<br />
echo "24" > $j/prefix<br />
done<br />
</pre><br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=How do I assign a new IP address to a running guest?<br />
||Details=This is done from the host server:<br />
* add the ip on the host, for example<br />
<pre><br />
ip addr add 194.169.123.23/24 dev eth0 <br />
</pre><br />
* add the ip to the guest's network context (a guests NID is the same as the XID {context ID})<br />
<pre><br />
naddress --add --nid <nid> --ip 194.169.123.23/24 <br />
</pre><br />
* enter the guest (best via ssh) <br />
* restart the services that need to make use of the new address if required <br />
* update the config in ''/etc/vserver/<servername>/interfaces'' to reflect the changes for the next guest restart (if desired)<br />
|Signature=BenjaminGreen}}<br />
<br />
{{Question<br />
|Question=If my host has only one a single public IP, can I use RFC1918 IP (e.g. 192.168.foo.bar) for the guest vservers?<br />
||Details=Yes, use iptables with SNAT to masquerade it. <br />
<pre><br />
iptables -t nat -I POSTROUTING -s $VSERVER_NETZ ! -d $VSERVER_NETZ -j SNAT --to $EXT_IP<br />
</pre><br />
See: [[HowtoPrivateNetworking]] and <br />
http://www.tgunkel.de/it/software/doc/linux_server.en#h3-VServer_Masquerading_SNAT (THX, [MUPPETS]Gonzo)<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=If I shut down my vserver guest, the whole Internet interface ethX on the host is shut down. What happened?<br />
||Details=When you shut down a guest (''i.e. vserver foo stop''), the IP is brought down on the host also. If this IP happens to be the primary IP of the host, the kernel will not only bring down the primary IP, but also all secondary IP addresses. Similarly, if your guests bring up IPs of more than one subnet, all other IPs from a specific subnet will be shut down if you stop the guest which created the first ("parent") IP.<br />
<br />
You can check this on the host using the command "ip addr show". Example output:<br />
<pre><br />
1: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000<br />
link/ether 00:01:02:03:04:05 brd ff:ff:ff:ff:ff:ff<br />
inet 192.168.249.172/27 brd 192.168.249.191 scope global eth0<br />
inet 192.168.234.194/27 brd 192.168.234.223 scope global eth0<br />
inet 192.168.249.169/27 brd 192.168.249.191 scope global secondary eth0<br />
inet 192.168.234.195/27 brd 192.168.234.223 scope global secondary eth0<br />
</pre><br />
In this example, if you stop the guest which brings down the IP 192.168.249.172, the IP 192.168.249.169 will be brought down as well, because it is a secondary IP of the "parent" 192.168.249.172.<br />
<br />
But in very recent kernels, there is an option ''settable'' which prevents that nasty feature. It's called "alias promotion". You may set it via sysctl by adding ''net.ipv4.conf.all.promote_secondaries=1'' in /etc/sysctl.conf or via sysctl command line.<br />
|Signature=derjohn, Hurga}}<br />
<br />
{{Question<br />
|Question=Can I run an OpenVPN Server in a guest?<br />
||Details=<br />
Yes. To get a OpenVPN Server running in a guest, all networking setup has to be done on the host. This answer describes the common case and shows some pitfalls, for detailled information about OpenVPN, please consult the appropriate documentation on the OpenVPN homepage.<br />
This is the minimal OpenVPN configuration for the Server which will be used to demonstrate how to get it running in a client:<br />
<pre><br />
# Networking setup<br />
server 192.168.16.0 255.255.255.0<br />
dev tun16<br />
ifconfig-noexec<br />
comp-lzo<br />
# Certificates<br />
dh ...<br />
ca ...<br />
cert ...<br />
key ...<br />
# Management<br />
persist-key<br />
keepalive 10 60<br />
verb 4<br />
</pre><br />
First of all you have to prepare the host with a persistent interface in the right mode and with the right settings. This is easily done by using openvpn and the ip and route tools.<br />
<pre><br />
# openvpn --mktun --dev tun16<br />
# ip link set dev tun16 txqueuelen 100<br />
# ifconfig tun16 192.168.16.1 pointopoint 192.168.16.2 mtu 1500<br />
# route add -net 192.168.16.0 netmask 255.255.255.0 gw 192.168.16.2<br />
</pre><br />
If you need different settings, openvpn will tell you the ifconfig and route commands it uses to configure the interface when being started on the host with the original config file, but without ifconfig-noexec.<br />
Additionally, the guest needs /dev/net/tun to make OpenVPN happy. This can be created with MAKEDEV:<br />
<pre><br />
# cd /var/lib/vserver/<myopenvpnserver>/dev/<br />
# ./MAKEDEV tun<br />
(creates the dev/net/tun device accessible by the guest - even a tap interface needs /dev/net/tun !)<br />
</pre><br />
Finally, the guest needs to have the tun device assigned:<br />
<pre><br />
# head /etc/vservers/<myopenvpnserver>/interfaces/1/*<br />
==> /etc/vservers/<myopenvpnserver>/interfaces/1/ip <==<br />
192.168.16.1<br />
<br />
==> /etc/vservers/<myopenvpnserver>/interfaces/1/nodev <==<br />
tun16<br />
<br />
==> /etc/vservers/<myopenvpnserver>/interfaces/1/prefix <==<br />
24<br />
#<br />
</pre><br />
The client's conf may look like that:<br />
<pre><br />
# Basic setup<br />
client<br />
proto tcp-client<br />
dev tun<br />
remote <ipaddress><br />
comp-lzo<br />
verb 4<br />
<br />
# Certificate<br />
ca ...<br />
</pre><br />
<br />
[ Based on derJohn's original answer, all errors mine ] <br />
|Signature=DavidS}}<br />
<br />
{{Question<br />
|Question=Trying to connect to a vserver from the host or another vserver on the same host fails<br />
||Details=strace shows<br />
<pre> <br />
sin_addr=inet_addr("xx.xx.xx.xx")}, yy) = -1 EINVAL (Invalid argument)<br />
</pre><br />
A: The host/guest cannot communicate with another guest on same host.<br />
* check all netmasks on all interfaces (do they overlap) ?<br />
* check policy routing (disable it temporary) ?<br />
* check that lo is up (Networking within a host/guest always uses lo interface)<br />
|Signature=CommonProblems}}<br />
<br />
{{Question<br />
|Question=Can I use iptables ?<br />
||Details=Yes but right now only on the host (rootserver). Please realize that all traffic is local and will not touch the forward chain.<br />
<br>If you really, really, really need iptables on the guest and you are aware about loosing a big part of VServer isolation and security you could add the NET_ADMIN capability. Consider writing wrappers to manage iptables on the host instead.<br />
|Signature=_are_}}<br />
<br />
{{Question<br />
|Question=Is it possible to prevent guest from bringing down primary ip?<br />
||Details=Yes. Remove /etc/vservers/<guest>/interfaces/X/dev, and touch /etc/vservers/<guest>/interfaces/X/nodev<br />
|Signature=Daniel&Serge}}<br />
<br />
{{Question<br />
|Question=Is it possible to provide a different MAC address per vServer?<br />
||Details=Short answer - yes but it's a hassle.<br />
<br />
Real answer from '''_are_''':<br />
<pre><br />
When I once needed 'real' seperate MAC-addresses I used TAP-devices and VDE2 ([http://vde.sourceforge.net/ Virtual Distributed Ethernet]).<br />
Basically vServer is an isolation of existing resources, not a virtualization of 'new' devices.<br />
Without extra fuss you can't add a 'new' network interface to a vServer, no matter if it is eth* or tap*, you always add it to the host and give the vServer access to it.<br />
I got the TAP+VDE2 up and running, but I think it is too much trouble for basically the simple adding of IPs to a vServer unless you really need the MAC address separate.<br />
</pre><br />
<br />
<br />
You can also utilize MACVLAN ability from kernel.<br />
I.e. create ''macvlan0'' interface with:<br />
<pre>ip link add link eth0 address 00:19:d1:29:d2:58 macvlan0 type macvlan</pre><br />
[[http://jim.studt.net/depository/index.php/notes-on-linux-s-macvlan-module Reference]]<br />
|Signature=bobnormal&swenTjuln<br />
}}<br />
<br />
{{Question<br />
|Question=Is it possible to hide packet counters on the host network interface from vServer guests?<br />
||Details=Yes, see [[Networking_vserver_guests|Networking vServer Guests]]<br />
|Signature=bobnormal}}<br />
<br />
{{Question<br />
|Question=Services won't bind to 127.0.0.1 when I configure them to bind to all available IPs / (binding service to * doesn't bind to loopback)?<br />
||Details=You've configured single public IP and have kernel option "Linux VServer -> Automatic Single IP Special Casing" enabled.<br />
It means somehow "optimized" :D<br />
If you don't want this you have 3 possible solutions (quoting Bertl):<br />
* disable the auto single IP in the kernel<br />
* assign more than one IP to the guest<br />
* disable single ip special casing for that guest<br />
<br />
The later is done by : echo "~single_ip" >> /etc/vservers/<VSERVER>/nflags<br />
At runtime to avoid restarting the vserver: nattribute --set --nid <guest> --flag ~single_ip<br />
|Signature=swenTjuln}}<br />
<br />
{{Question<br />
|Question=When using network namespaces and vserver together, netstat does not work in the vserver. What's wrong? <br />
||Details=All proc entries are hidden by default in the guests. During startup of the host system a tool called vprocunhide makes some /proc files visible.<br />
<br />
If you create a new network namespace you have to do the same in the network namespace because the new /proc/net files are not available for the vprocunhide outside the new network namespace. So something like that should be sufficient to get netstat working in vservers with network namespaces:<br />
<br />
<pre><br />
ip netns exec $NAMESPACE /usr/lib/util-vserver/vprocunhide<br />
</pre><br />
|Signature=AlexanderS}}<br />
<br />
== Administration tools ==<br />
<br />
{{Question<br />
|Question=Which guest vservers are running?<br />
||Details=Use vserver-stat to find out. Example output:<br />
<pre><br />
CTX PROC VSZ RSS userTIME sysTIME UPTIME NAME<br />
0 77 965.1M 334.6M 14m14s18 2m28s69 1h33m46 root server<br />
49152 7 14M 5.2M 0m00s40 0m00s30 1h30m15 chiffon<br />
</pre><br />
|Signature=derjohn}}<br />
<br />
<br />
{{Question<br />
|Question=Is there a web-based interface for vserver that will allow creation/deletion/configuration etc. of vserver guests?<br />
||Details=<br />
* http://OpenVPS.org which is a set of scripts with a web-interface for webhosters/ISPs<br />
* http://Openvcp.org which is a distributed system (agent!) with a web-interface, with which you can build/remove guests<br />
* http://vsmon.revolutionlinux.com/ is a distributed monitoring-only solution that allows you to search for a particular vserver in your park.<br />
|Signature=derjohn}}<br />
<br />
== Hosting foreign distributions ==<br />
<br />
{{Question<br />
|Question=I run a Debian host and want to build an Ubuntu guest. Howto?<br />
||Details=Simple ;) Assume you want to build a breezy guest on a sid host with IP 192.168.0.2 and hostname vubuntu, then do:<br />
<pre><br />
vserver vubuntu build --force -m debootstrap --hostname vubuntu.myvservers.net --netdev eth0 --interface 192.168.0.2/24 \<br />
--context 42 -- -d breezy -m http://de.archive.ubuntu.com/ubuntu<br />
</pre><br />
<br />
[UPDATE] Currently there are problems in building breezy under unclear circumstances, which seems to have to do with udev. If the above didnt work, try:<br />
<pre><br />
vserver vubuntu build --force -m debootstrap --hostname vubuntu.myvservers.net --netdev eth0 --interface 192.168.0.2/24 \<br />
--context 42 -- -d breezy -m http://de.archive.ubuntu.com/ubuntu -- --exclude=udev<br />
</pre><br />
In very recent versions of the utils, the problem should not occur anymore (it has to do with the 'secure-mount' if you look in the MLs)<br />
<br />
Well, sid's debootstrap knows how to bootstrap Ubuntu linux. Make sure to have a current debootstrap package: <br />
<pre><br />
apt-get update<br />
apt-get install debootstrap<br />
</pre><br />
The knowledge how to build ubuntu 'breezy badger' (which you probably want to be your guest at the time of writing) has been added recently.<br />
|Signature=derjohn}}<br />
<br />
<br />
{{Question<br />
|Question=I want to build a Gentoo guest. Howto?<br />
||Details=Even simpler ;) See http://www.gentoo.org/proj/en/vps/vserver-howto.xml#doc_chap3 .<br />
|Signature=gcc}}<br />
<br />
== Application level problems ==<br />
<br />
{{Question<br />
|Question=I did everything right, but the application foo does not start. What's up there?<br />
||Details=Before asking on the IRC channel, please check out the 'problematic programs' page:<br />
[[Problematic Programs]]<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=When I try to ssh to the guest, I log into the host, even if I installed sshd on the guest. What's wrong here?<br />
||Details=Look at /etc/ssh/sshd_config of the host:<br />
<pre><br />
Port 22<br />
# Use these options to restrict which interfaces/protocols sshd will bind to<br />
#ListenAddress ::<br />
</pre><br />
And now change the setting to <br />
<pre><br />
Port 22<br />
# Use these options to restrict which interfaces/protocols sshd will bind to<br />
ListenAddress your.hosts.ip.here # not the guests IP! <br />
</pre><br />
Then '/etc/init.d/ssh restart' on the host, after that on the guest (if you did apt-get install ssh on the guest already.)<br />
Do I have to explain more? If the hosts sshd binds all available IP addresses on port 22 (The hosts 'sees' even all addresses of the guests!). So if the guest starts its sshd, it can't bind to port 22 any more. You need to change that setting only on the host. <br />
(BTW: A similar approach has to be done for a lot of daemons, e.g. Apache. If the daemon does not support an explicit bind, you may use the chbind command to 'hide' IP addresses from the daemon before starting.)|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=Bind9 does not like to start in my guest.<br />
||Details=Check out the [[Problematic Programs]] page and/or get my [http://linux-vserver.derjohn.de/bind9-packages/bind9-capacheck_9.3.2-2_i386.deb vserver-guest-ready Debian package] for Debian Sid guests and check out the [http://linux-vserver.derjohn.de/bind9-packages/README.txt readme]. (Hint: This is fresh stuff. Please give me feedback)<br />
<br />
[UPDATE] Since VServer Devel 2.1.1-rc18 you do not need to patch the userland tools anymore. The capabilities are masked.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=My mysqld running in a guest behaves strangely and is awfully slow/locks up<br />
||Details=This can be related to /tmp being too small. mysqld stores temporary tables in /tmp and as such, if a lot of queries happen and /tmp runs full this can cause one query to lock up whilst creating the tmp table and all other queries waiting to acquire the lock. There are two possible solutions to that problem: a.) Modify /etc/vservers/vserver-name/fstab and assign more memory to the tmpfs of /tmp and b.) remove the /tmp entry from /etc/vservers/vserver-name/fstab completly. Especially on database servers with a rather high load the second one might be the preferred method. <br />
If you prefer not to modify or disable tmpfs, you can reconfigure MySQL to use a different tmpdir such as "/var/tmp". For example, edit /etc/my.cnf (RHEL/CentOS) or create /etc/mysql/conf.d/mysqld_custom.conf (Debian) and add the following line: <br />
<pre><br />
tmpdir = /var/tmp<br />
</pre><br />
Afterwards, restart MySQL (/etc/init.d/mysqld restart) and then review MySQL variables (mysqladmin -uroot -p variables) to confirm "tmpdir" is no longer pointing to "/tmp". |Signature=sp, jrklein}}<br />
<br />
{{Question<br />
|Question=Pure-FTP does not run inside a VServer?<br />
||Details=That's because it has capabilities enabled, make sure you rebuild your distro's package passing also the `--without-capabilities` flag to configure.<br />
|Signature=Pedro Algarvio, aka, s0undt3ch}}<br />
<br />
{{Question<br />
|Question=Why do neither sshd nor crond (vixie-cron) work correctly in my CentOS / Fedora guest? I get 'pam_loginuid(crond:session): set_loginuid failed opening loginuid' and similar lines in my logs.<br />
||Details=Took me a while to figure this out, and it turned out to be mentioned in the old wiki. Here is the solution on how to solve a common problem with sshd / crond, somehow related to selinux and auditing:<br />
<br />
pam authentication (also used with openssh) enables "pam_loginuid.so" in the /etc/pam.d/* files. Comment those out as they are not necessary and will not load within a guest anyway. This probably is also necessary on updates later on, if the configs get changed. You therefore may add the following command line to a cronjob file or your software update script:<br />
<pre><br />
/bin/sed --in-place -e "s/^session.*required.*pam_loginuid.so/# session\trequired\tpam_loginuid.so/g" /etc/pam.d/*<br />
</pre><br />
<br />
'''UPDATE:''' If you are compiling your own kernel this can be fixed system-wide by setting CONFIG_AUDIT_LOGINUID_IMMUTABLE=n in kernels .config file.<br />
<br />
|Signature=patrick, SwenTjuln}}<br />
<br />
{{Question<br />
|Question=How do i install nagios-plugins on a Gentoo guest?<br />
||Details=Unfortunately, the nagios-plugins ./configure scripts wants to ping 127.0.0.1 which is not available inside a guest. Therefore you have to build nagios-plugins outside the guest.<br />
The easiest way to do this from the host (assuming the guest is running) is:<br />
<pre><br />
vnamespace -e <xid> -- chroot /vservers/<name> emerge nagios-plugins -va<br />
</pre><br />
|Signature=Hollow}}<br />
<br />
{{Question<br />
|Question=Somebody runs ntpd in guest and you can't use ntpdate in host?<br />
||Details=Try to run ntpdate with options -u :<br />
ntpdate -u ntp.domain.xy<br />
or you can use command:<br />
chbind --nid 42 --ip 1.2.3.4 -- ntpdate ntp.domain.xy<br />
where IP will be the IP of host.<br />
|Signature=Punkie/Bertl}}<br />
<br />
<br />
<br />
== Start / Stop a VServer ==<br />
<br />
{{Question<br />
|Question=How do I make a vserver guest start by default?<br />
||Details=At least on Debian, I can tell you how to do it with the new-style config. If your guest is called "derjohn" and you want it to be started somewhere at the of your bootstrap process, then do:<br />
<pre><br />
echo "default" > /etc/vservers/derjohn/apps/init/mark<br />
</pre><br />
If you want to start it earlier, please read the init script "/etc/init.d/util-vserver" to find out how to do it. In most cases you don't need to change this. On Debian the vservers are started at "20", so after most other stuff is up (networking etc.).<br />
<br />
Besides that I created a small helper script for managing the autostart foo: ((vserver-autostart))|Signature=derjohn}}<br />
<br />
To start all vservers with a nondefault mark value of <tt>foo</tt>, you can use something like:<br />
<pre><br />
MARK=foo NUMPARALLEL=42 LOCKFILE=vserver-foo /path/to/util-vserver/vserver-wrapper start<br />
</pre><br />
<br />
If you want to automate this, you can create a copy of the <tt>/etc/init.d/vservers-default</tt> script called <tt>/etc/init.d/vservers-foo</tt>, set <tt>MARK</tt>, <tt>NUMPARALLEL</tt> and <tt>LOCKFILE</tt> appropriately in it, and have it start at whatever point in the boot process.<br />
<br />
{{Question<br />
|Question=My host works, but when I start a guest it says that it has a problem with chbind.<br />
||Details=You are probably using util-vserver <= 0.30.209, which does use dynamic network contexts internally (With 0.30.210 this fact changed). So if you compiled your kernel without dynamic contexts, you may start guests, but you can't use the network context.The solution is either to switch to .210 util (or Hollow's toolset) or compile the kernel with dynamic network contexts.<br />
SE Keyword: invalid option `nid' testme.sh<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=What is old-style and new-style config?<br />
||Details=Old-style config refers to a single text-file that contains all the configuration settings. With new-style config the configuration is split into several directories and files. You should probably go for new-style config if you are asking.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=How can I reboot/halt guests?<br />
||Details=It depends. <br />
For legacy Linux-VServer (i.e. 1.2.x), you have to replace /sbin/halt in the guests with vreboot and start rebootmgr in the host. You also need to have a <guest>.conf file in /etc/vservers for each guest. Please have a look at /etc/init.d/rebootmgr.<br />
For Linux-VServer 2.0+, sys_reboot has been virtualized to do the right thing. No changes are needed in guests. Please note that some things depend on the init style used by the guest : read [[util-vserver:InitStyles]]<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=What is the initial PATH?<br />
||Details=By default, vserver uses the 'sysv' startup style, which mimics the init process by running the 3rd runlevel through '/etc/init.d/rc 3' (or '/etc/rc.d/rc 3'). Usually this 'rc' script uses a hard-coded PATH. In the case it doesn't, util-vserver also mimics init's default PATH through /etc/vservers/.defaults/apps/init/environment, or if not present /usr/local/lib/util-vserver/defaults/environment. Beware that all those default PATH usually do not include /usr/local.<br />
|Signature=daniel_hozac&Beuc}}<br />
<br />
{{Question<br />
|Question=When I try to start a guest i get this message "/proc/uptime can not be accessed. Usually, this is caused by procfs-security. Please read the FAQ for more details"?<br />
||Details=After a reboot you need to run the vprocunhide script. If running this script causes many errors to print on the screen, try checking the kernel you have booted with (perhaps it does not have the linux-vserver extensions enabled).<br />
|Signature=mattzerah}}<br />
<br />
{{Question<br />
|Question=When I try to start a guest i get this message "vsched: vc_set_sched(): Function not implemented". <br />
||Details=After an upgrade of the kernel/tools if you used the old scheduler function you must convert them to cgroup cpu limits. If you do not want limits search and remove/rename /etc/vservers/*/sched/ and the guest will start again. This might also happen when you use a newer kernel patch but did not yet update the vserver utils to a recent version (Thorsten).<br />
|Signature=aqueos}}<br />
<br />
== Kernel ==<br />
<br />
{{Question<br />
|Question=Is SMP Supported?<br />
||Details=Yes, on all SMP capable kernel architectures.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=Do I really need the legacy-interfaces? What are these legacy-interfaces?<br />
||Details=Since Linux-VServer is an ongoing project, new features might replace old ones, some might require a development version. Legacy-interfaces are available for backward compability (which might be removed someday) with Linux-VServer 1.2.x.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=I have a vserver running on a Linux kernel with preemption. Is VServer "preempt" safe?<br />
||Details=There are no known issues about running vserver on a preemption enabled kernel. I would like to add, that the vserver kernelhackers would probably exclude that option in 'make menuconfig' if there would be an incompatibility. Just my $.02 :)<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=32 vs 64 Bit? What should I take?<br />
||Details=If you have the choice make the host a 64 bit one. You can run a guest as 32 bit or as 64 bit on a 64 bit host. To run it as 32 bit, you need to compile the x86_64 (a.k.a. AMD64) with the following options:<br />
<pre><br />
[*] Kernel support for ELF binaries<br />
<M> Kernel support for MISC binaries<br />
[*] IA32 Emulation <---- without that, the entire 32bit API is not present<br />
<M> IA32 a.out support <br />
</pre><br />
You can force the guest to behave like a 32 environment like this:<br />
<pre><br />
echo linux_32bit > /etc/vservers/$NAME/personality<br />
echo i686 > /etc/vservers/$NAME/uts/machine<br />
</pre><br />
(thanks cehteh for the hint!)<br />
<br />
But you can force debootstrap to put 32 bit binaries into the guest by 'export ARCH=i386';<br />
<pre><br />
export ARCH=i386 ; vserver build .... <br />
</pre><br />
<br />
On debian when using the newvserver script "export ARCH=i386" has no effect, just use:<br />
<pre><br />
newvserver --arch i386 ...<br />
</pre><br />
<br />
On debian debootstrap can also be gived the arch option:<br />
<pre><br />
vserver myguest \<br />
build -m debootstrap -n myguest \<br />
--hostname myguest.mydomain.com \<br />
-- -d squeeze -- \<br />
--arch=amd64 (or i386 if you want 32bit)<br />
</pre><br />
<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=What does the guest privacy option do in the kernel settings ?<br />
||Details=<pre><br />
>i was wondering about the real thing that guest privacy does. <br />
#ifdef CONFIG_VSERVER_PRIVACY<br />
#define VS_ADMIN_P (0)<br />
#define VS_WATCH_P (0)<br />
#else<br />
<br />
> > Does it just prevent the spectator context ? <br />
<br />
it prevents the spectator context and the admin <br />
functionality in all cases which are privacy<br />
sensitive, which includes:<br />
<br />
- ptrace<br />
- devmapper<br />
- devpts<br />
- inode tag permissions<br />
- mountinfo<br />
- kill/signal<br />
- netlink dumps<br />
- tun control<br />
- iopriority<br />
<br />
> > What security do it bring to the system ?<br />
<br />
together with the VXF_STATE_ADMIN it can be<br />
used to secure a guest (to some degree) from<br />
unwanted access from the host admin, of course,<br />
as the admin can change the kernel, this is a<br />
voluntary feature which mostly prevents certain<br />
kinds of accidential peeking or guest modification<br />
<br />
</pre><br />
|Signature=ghislain}}<br />
<br />
<br />
== Distribution specific questions ==<br />
<br />
{{Question<br />
|Question=VServer is included in the stable Debian GNU/Linux for years now. What VS version did they include?<br />
||Details=There is no support in Debian for Linux-Vserver since the Wheezy release. Debian Squeeze included a 2.6.32 based kernel-package called 2.6.32-5-vserver-ARCH. This contained VServer 2.3.0.36.29.6 with some additional fixes.<br />
|Signature=scientes}}<br />
<br />
{{Question<br />
|Question=Were can I get newer versions of VServer as ready made packages for Debian?<br />
||Details= There are a number of locations<br />
* http://repo.psand.net/info/ has Debian Lenny, Squeeze and Wheezy repositories. Many kernel versions are present. Currently (Febraury 2013) 3.2 kernels are being maintained for Wheezy, with additional packages for 3.4 and 3.10 also available. Architectures available are i386 and amd64. This repository also contains curremt util-vserver builds. Build will shortly begin for Jessie.<br />
* http://www.lihas.de/anleitungen-und-service/linux-vserver-kernel-fuer-debian/linux-vserver-kernel-english details their automatically built repository currently for 3.4 kernels. Building, patching and testing for the kernels is automated.<br />
<br />
Older unmaintained repositories are/were here:<br />
<br />
* http://linux-vserver.derjohn.de/ - "my kernels are always 'devel' branch" (derjohn). This repo contain kernels up to 2.6.29 for amd64, 2.6.26 for i386.<br />
* http://backports.debian.org/ contains 2.6.32 backports for Lenny at time of writing (11th May 2010)<br />
* http://zbla.net/debian/ Unofficial debian vserver packages '''WARNING : i386 packets are compiled for 64bits !''' apt source line: ''deb http://zbla.net/debian/ ./'' (N/A as of 2011/12/27)<br />
|Signature=Gremble<br />
}}<br />
<br />
{{Question<br />
|Question=Were can I get newer versions of VServer as ready made packages for Ubuntu?<br />
||Details= There is only one location for <br />
*http://repo-ubuntu.psand.net/dists/ is the only repository maintained for Ubuntu. It covers the same builds as http://repo.psand.net/info/ - and information there should be used, replacing 'precise' as distro in your /etc/apt/source.list.<br />
|Signature=Gremble<br />
}}<br />
== Misc ==<br />
<br />
{{Question<br />
|Question=Why isn't there a device /dev/xyz within a guest?<br />
||Details=Device nodes allow userspace to access hardware (or virtual resources). Creating a device node inside the guest's namespace will give access to that device, so for security reasons, the number of 'given' devices is small.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=I want to (re)mount a virtual filesystem (like tmpfs) in a running guest ... but the guest has no rights (capability) to (re)mount?<br />
||Details=I take as example your /tmp partition within the guest is too small, what will be likely the case if you stay with the 16MB default (vserver build mounts /tmp as 16 MB tmpfs!).<br />
<pre><br />
# vnamespace -e XID mount -t tmpfs -o remount,size=256m,mode=1777 none /var/lib/vservers/<guest>/tmp/<br />
</pre><br />
(if there's a problem, try expanding the symlinks in the mount path)<br />
Be warned that the guest will not recognize the change, as the /etc/mtab file is not updated when you mount like this. To permanently change the mount, edit /etc/vserver/<guest>/fstab on the host.<br />
<br />
If you get:<br />
<pre><br />
mount: can't find /var/lib/vservers/<guest>/tmp in /etc/fstab or /etc/mtab<br />
</pre><br />
then try instead:<br />
<pre><br />
vnamespace -e builder chroot /var/lib/vservers/<guest>/ mount -o remount,size=64m,mode=1777 /tmp<br />
</pre><br />
|Signature=derjohn/BenjaminGreen}}<br />
<br />
{{Question<br />
|Question=How do I bind mount a host directory inside a running guest?<br />
||Details=There are two ways to do this: one is to enter the bind mount in the guest fstab and restart the guest.<br />
<br />
To understand the other way, let me explain how mount namespaces work.<br />
<br />
Every guest has two mount namespaces associated with it: one "''management namespace''" and one "''operational namespace''".<br />
<br />
On starting the guest, first the management namespace is created as a copy of the host namespace (which means that everything that was mounted on the host is mounted in the new namespace as well). This has unwelcome side effects: for example, if you had a cdrom mounted while starting the guest, you wouldn't be able to eject it until you stop the guest even if you umount it on the host, because it's still mounted in the guest. Therefore, the namespace is ''cleaned up'': filesystems that are mounted outside the root of the guest get unmounted in the guest namespace.<br />
<br />
Subsequently, the operational namespace of the guest is created as a copy of the management namespace, and the guest's processes are started in it.<br />
<br />
To bind mount a host directory in the guest, you must first make that host directory visible in the management namespace of the guest. This is automatically the case if the directory resides inside a mountpoint that exists in the guest namespace as well; however, if the guest config referenced no part of this mountpoint (or it didn't yet exist when you started the guest), then the cleanup mentioned above removed it from the guest's management namespace and you need to re-add it.<br />
<br />
Let's assume, as an example, that we want a guest to see a subdirectory, called <tt>foo</tt>, of the cdrom we just mounted on the host (e.g. under <tt>/media/cdrom</tt>).<br />
<br />
Let's enter the management namespace of the guest (that's what <tt>-i 0</tt> is for):<br />
<br />
<pre><br />
# vnamespace -i 0 -e <guest-xid> -- /bin/bash<br />
</pre><br />
<br />
Now you have access to all host devices; mount the device that contains your directory wherever you want, but you may prefer to mount it in the same location you used on the host. (Note, though, that it's not even necessary for the device to be mounted in the host namespace at all.)<br />
<br />
It's likely best to use <tt>mount -n</tt> lest your host <tt>/etc/mtab</tt> get polluted with mounts from other namespaces.<br />
<br />
<pre><br />
# mount -n /dev/sr0 /media/cdrom<br />
# exit<br />
</pre><br />
<br />
We're now back in the host namespace. <tt>vmount</tt> can now be used to bind mount <tt>/media/cdrom/foo</tt> inside a running guest (in this example, under <tt>/foo</tt> inside the vserver root):<br />
<br />
<pre><br />
# vmount guestname -- --bind /media/cdrom/foo /mnt/foo<br />
</pre><br />
|Signature=[[User:KornAndras|Guy-]] 01:31, 10 January 2012 (UTC)}}<br />
<br />
{{Question<br />
|Question=How do I mount a device present on the host under a directory in a running guest?<br />
||Details=Use something like:<br />
<pre><br />
vnamespace -e <guestname> mount -n /dev/<device> /vservers/<guest>/place/you/want/to/mount/it<br />
</pre><br />
<br />
This device can be unmounted with:<br />
<br />
<pre><br />
vnamespace -e <guestname> umount -n /vservers/<guest>/place/you/want/to/mount/it<br />
</pre><br />
<br />
|Signature=derjohn/BenjaminGreen}}<br />
<br />
{{Question<br />
|Question=Does anyone know how to increase the size of /tmp within a vserver w/o restarting?<br />
||Details=Use the remount option for mount.<br />
# vnamespace -e XID mount -n -t tmpfs -o remount,size=32m tmpfs /<vdir>/<guest>/tmp<br />
or something like that. The arguments are needed since mount is not going to be using /etc/fstab for the information and the version of /proc/mounts is best understood by<br />
# vnamespace -e XID cat /proc/mounts.<br />
See [[Frequently_Asked_Questions#I want to (re)mount a partition in a running guest ... but the guest has no rights (capability) to (re)mount?]]<br />
|Signature=derjohn/dhozac}}<br />
<br />
<br />
{{Question<br />
|Question=#1 ERROR: capset(): Operation not permitted<br />
||Details=capabilities are not enabled in kernel-setup<br />
please check that CONFIG_SECURITY_CAPABILITIES is loaded or included in the kernel. ( check with "cat /path_to_kernel/.config | grep -i cap ") <br />
(2.6.11.5-vs-1.9.5 + 0.30-205)<br />
|Signature=IrcQuestions}}<br />
<br />
{{Question<br />
|Question=How can I make 'vserver start' mount the root filesystem?<br />
||Details=Mount it via /etc/vservers/vserver-name/fstab, make sure to set the option 'dev' e.g.:<br />
<pre>/dev/drbd0 / xfs rw,dev 0 0</pre><br />
|Signature=AdrianReyer}}<br />
<br />
<br />
{{Question<br />
|Question=I deleted a guest's directory without shutting it down. Now I have a "ghost" running. Is there any possibility to get it out of proc without rebooting?<br />
||Details=<br />
vkill --xid <xid> -s 15; sleep 2; vkill --xid <xid> -s 9<br />
<br />
You will also need to remove guest's ip, for example with:<br />
ip addr del <ip> dev eth0<br />
|Signature=daniel_hozac & gebura }}<br />
<br />
{{Question<br />
|Question=When using nice and su (for example, in the updatedb cron job), I get: su: Permission denied. What does it mean?<br />
||Details=A guest cannot lower its nice value - and that's what 'su' does through pam_limits which sets a nice value of 0. You can see it through strace:<br />
$ strace nice su nobody<br />
[...]<br />
setpriority(PRIO_PROCESS, 0, 0) = -1 EACCES (Permission denied)<br />
You can use 'su nobody -c nice some_cmd' instead.<br />
<br />
The problem is caused by the fact that host system is setting limits for guests (when instructed to do so) and the dropped capability dissallows processess on guest systems to change and increase them later. That means no process on a guest can lower nice value above the limit set by host.<br />
<br />
If the pam_limits module is activated on a guest system it will first try to '''reset nice value to 0''' even if <tt>/etc/security/limits.conf</tt> file is empty or even if there are lower priority limits set in it. The pam_limits module does that since [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=241663 its developers decided] that it should reset some limits to defaults and start from scratch when applying new restrictions. Unfortunately, already limited guest system won't be able to do it since resetting nice value to 0 means increasing the limit which is forbidden. See [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=311058 Debian Bug report logs - #311058] for more information about that Debian bug.<br />
<br />
See also [[Frequently_Asked_Questions#Cron is not working on my guest system (which is Debian). How can I fix it?|Cron is not working…]]<br />
<br />
|Signature=daniel_hozac & Beuc & Paweł Wilk}}<br />
<br />
{{Question<br />
|Question=Cron is not working on my guest system (which is Debian). How can I fix it?<br />
||Details=On a guest system the cron daemon may not work properly. When looking into the log file (e.g. <tt>/var/log/syslog</tt>) the following message may appear repeatedly:<br />
CRON[xxxxx]: Permission denied<br />
<br />
Similar thing may happen with the <tt>su</tt> when trying to execute a command as root.<br />
<br />
It's not the problem in Cron but in the pam_limits module on a guest system (see [[Frequently_Asked_Questions#When using nice and su (for example, in the updatedb cron job), I get: su: Permission denied. What does it mean?|FAQ:When using nice and su…]] for more information about the cause).<br />
<br />
There are 4 ways to solve or work-around this problem:<br />
<br />
'''1. Allowing guests to reset resource limits:'''<br />
<br />
It's clean solution but you may expect some guest processes increasing their limits because not everything is controlled by PAM. It also breaks centralized resources limiting approach so a guest can do bad things that may cause other guests and host to be overloaded and unresponsive.<br />
<br />
To apply it you have to add <tt>CAP_SYS_RESOURCE</tt> flag to <tt>/etc/vservers/<server name>/bcapabilities</tt> (2.6 kernels).<br />
<br />
See [[util-vserver:Capabilities_and_Flags|Capabilities and Flags]] for more information.<br />
<br />
'''2. Disabling pam_limits on a guest systems:'''<br />
<br />
This workaround is easy and works fine when your guest systems aren't really multiuser but rather service boxes. It disables setting of the resource limits by PAM so the limits can only be set globally for the whole guest (using rlimits or cgroups on a host) but never increased inside of the guest system.<br />
<br />
To apply it just enter the guest and edit the files listed below, commenting out any line containing <tt>pam_limits</tt>:<br />
<br />
/etc/pam.d/su<br />
/etc/pam.d/sudo<br />
/etc/pam.d/cron<br />
<br />
You can also use this one-liner on a guest:<br />
<br />
<pre><br />
/bin/sed --in-place -e "s/^\s\?session.*pam_limits.so.*/\#\0/g" /etc/pam.d/{su,sudo,cron}<br />
</pre><br />
<br />
'''3. Allowing guest's pam_limits to set limits when possible:'''<br />
<br />
This workaround allows you to have working <tt>pam_limits</tt> inside a guest system and global limits set by a host system. What's the catch? The problematic PAM module won't fully work for the root user on a guest system as expected and there might appear some PAM's warnings in guest's <tt>auth.log</tt>. Since using pam_limits to limit regular user processes is far more frequent than using it to limit root processes, this solution may be a good compromise. It is about setting a proper limits in pam_limits configuration and about setting this PAM module in a way that its function is optional (instead of required). The last change makes PAM to continue with session even if pam_limits encounters some error during setting limits (it usually applies to superuser sessions).<br />
<br />
The not so nice news is that there might be a need of keeping guest's limits configuration up to date according to limits globally set for a guest. The limits set in pam_limits configuration file(s) shouldn't be higher (lower in case of nice value) than global guest's limits.<br />
<br />
To apply it enter the guest and edit the files listed below, replacing occurences of <tt>required</tt> by <tt>optional</tt> in the lines containing <tt>pam_limits</tt>:<br />
<br />
/etc/pam.d/su<br />
/etc/pam.d/sudo<br />
/etc/pam.d/cron<br />
<br />
For example:<br />
<br />
# Sets up user limits, please define limits for cron tasks<br />
# through /etc/security/limits.conf<br />
session optional pam_limits.so<br />
<br />
Then on a guest system create the file <tt>/etc/security/limits.d/01-fixpam.conf</tt> containing:<br />
<br />
<pre><br />
* - priority X # replace X with your guest's nice value <br />
</pre><br />
<br />
You can automate this process to happen automagically for any guest by creating the startup script named <tt>/etc/vservers/.defaults/scripts/post-start.d/01-pamfix</tt>:<br />
<br />
<pre><br />
#!/bin/sh<br />
<br />
# This script tries to fix pam_limits entries<br />
# to make it possible for PAM in a guest system to<br />
# set its own limits.<br />
<br />
PAM_DIR="etc/pam.d"<br />
PAM_SERVICES="su sudo cron"<br />
LIMITS_FILE="etc/security/limits.d/01-pamfix.conf"<br />
<br />
vname="$2"<br />
[ -z "$vname" ] && exit 0<br />
<br />
vcfg=$( /usr/sbin/vserver-info "$vname" CFGDIR )<br />
[ ! -d "$vcfg" ] && exit 0<br />
<br />
for s in $PAM_SERVICES<br />
do<br />
pamfile="${PAM_DIR#\/}/$s"<br />
[ -f "$pamfile" ] && /bin/sed --in-place -e "s/\(^\s\?session.*\)required\(.*pam_limits.so.*\)/\1optional\2/g" "$pamfile"<br />
done<br />
<br />
[ ! -f "${vcfg}/nice" ] && exit 0<br />
nval=$( /usr/bin/head -1 "${vcfg}/nice" )<br />
[ -n "$nval" ] && echo "* - priority $nval # (added by vserver startup script)" > "${LIMITS_FILE#\/}"<br />
<br />
exit 0<br />
</pre><br />
<br />
'''4. Disabling resource limits for a guest:'''<br />
<br />
It easy, clean and… unsafe solution. You just have to not set resource limits (e.g. priority, nice value) for a guest or set the nice value limit to 0 on a host system. Resetting it later by guest's <tt>pam_limits</tt> will not generate an error.<br />
<br />
|Signature=Paweł Wilk}}<br />
<br />
{{Question<br />
|Question=How do I handle NFS mounts within in a guest?<br />
||Details=There are at least four ways.<br />
<br />
In any case, you probably want to force the nfs version to 3 or lower to avoid id mapping issues (one symptom of having an id mapping issue is that <tt>no_root_squash</tt> appears to be ignored). You can check whether the mount uses nfsv4 by looking at <tt>/proc/mounts</tt> inside the guest. You can force the protocol version to 3 by passing the mount options <tt>nfsvers=3,mountvers=3</tt>.<br />
<br />
'''1)''' Mount the NFS share from the host OS and let vserver guest access it as part of it's file system.<br />
<br />
''mount --bind'' may also be beneficial in this scenario.<br />
<br />
'''2)''' Use util-vserver and create a ''fstab.remote'' file in the /etc/vserver/<vserver_name> directory. Populate this with the NFS shares and they will be mounted in the context of the vserver guest.<br />
<br />
See http://www.nongnu.org/util-vserver/doc/conf/configuration.html<br />
<br />
Note that as of 0.30.216-pre3000 and kernel 3.0.4-vs2.3.1-pre10.1, the mount request will appear to originate from the IP of the host, not the guest. It is unclear (to [[User:KornAndras|Guy-]]) whether this is a bug.<br />
<br />
'''3)''' Add capabilities to the vserver guest instance to grant sufficient rights to allow NFS mounts.<br />
<br />
Add the following to /etc/vserver/<vserver_name>/bcapabilities<br />
SYS_ADMIN<br />
Add the following to /etc/vserver/<vserver_name>/ccapabilities<br />
SECURE_MOUNT<br />
BINARY_MOUNT<br />
<br />
See [[Capabilities_and_Flags]] for more information about vserver capabilities.<br />
<br />
If you want the NFS shares to be mounted when the guest starts, add them to /etc/vserver/<vserver_name>/fstab.<br />
<br />
'''4)''' Before starting the guest, make a directory of the host "shared" using <tt>mount --make-shared /path/to/dir</tt>, then set up autofs to mount nfs shares under <tt>/path/to/dir/sharename</tt>.<br />
<br />
rbind mount subdirectories of <tt>/path/to/dir</tt> in the guest from its fstab.<br />
<br />
This setup is good if the nfs shares are not often needed, and especially if they're occasionally needed by more than one guest. (As of September 2011, running autofs inside a vserver guest didn't work for me. --[[User:KornAndras|Guy-]] 01:05, 30 October 2011 (UTC))<br />
<br />
||Signature=martindk}}<br />
<br />
<br />
{{Question<br />
|Question=vserver start/stop/enter fails with something like "vnamespace: execvp("/usr/sbin/vserver"): No such file or directory" ?<br />
||Details=Check whether ''/usr'' is mounted in the namespace you are working with.<br />
<pre>vnamespace -e <guest> cat /proc/mounts</pre><br />
If there is no ''/usr'', you can fix your problem with simply mounting it using the following command:<br />
<pre>vnamespace -e <guest> mount /dev/<device> /usr</pre><br />
<br />
||Signature=sim0n}}<br />
<br />
{{Question<br />
|Question=The command vserver <$server> start gives '/etc/init.d/rc: line 74: /etc/default/rcS: No such file or directory', what do I do? <br />
||Details=The vserver has not been correctly installed, this has several reasons<br />
check your install log and it should tell you something about that your server didn't get installed properly<br />
* use stable distribution of debian as server (debootstrap may be different over the versions)<br />
* deny_mount, deny_caps and deny_pivot should be off if your running grsec.<br />
<br />
||Signature=Dude}}<br />
<br />
<br />
{{Question<br />
|Question=How could I rename a vserver directory?<br />
||Details=Please note : this procedure renames the '''directory''', not the '''hostname''' !<br />
#Stop the vserver in question<br />
#rename the <tt>/vservers/<server name></tt> directory<br />
#rename the <tt>/etc/vservers/<server name></tt> directory<br />
#update link: <tt>/etc/vservers/<server name>/run</tt> → <tt>/var/run/vservers/<server name></tt><br />
#update link: <tt>/etc/vservers/<server name>/vdir</tt> → <tt>/etc/vservers/.defaults/vdirbase/<server name></tt><br />
#update link: <tt>/etc/vservers/<server name>/cache</tt> → <tt>/etc/vservers/.defaults/cachebase/<server name></tt><br />
#update link: <tt>/var/run/vservers.rev/<server XID></tt> → <tt>/etc/vservers/<server name></tt><br />
#Start the vserver in question. It should start properly.<br />
<br />
|Signature=FlorianD (from ''hillct'' page in old wiki)}}<br />
<br />
<br />
{{Question<br />
|Question=what if i see my vserver in vserver-stat but with no name ?<br />
||Details=the link in /var/run/vservers is missing<br />
Just do a : cat /etc/vservers/<guest>/context > /var/run/vservers/<guest><br />
check that the <guest> is the good one by using vuname --get --xid <context> with the context you have in the vserver-stat listing.<br />
|Signature=IrcQuestions}}<br />
<br />
== Upgrade from 2.0 to 2.2 ==<br />
<br />
{{Question<br />
|Question=I now get errors like "ncontext: vc_net_create(): Invalid argument; dynamic contexts disabled." on startup. Vservers are not started<br />
||Details=Dynamic context are disabled by default and are deprecated. For example, tagxid and network checks won't be useable with dynamic ids. Now you should manually assign a explicit context to your vservers, like<br />
echo 101 > /etc/vservers/myvserv/context<br />
ADDENDUM: please consider that valid static contexts are between 2 and 49151 ( daniel_hozac on IRC ) otherwise you will end up with unexplainable error "ncontext: vc_net_migrate(): No such process" when trying to start the vserver.<br />
<br />
|Signature=daniel_hozac&Beuc}}<br />
<br />
<br />
{{Question<br />
|Question=How do I assign a static context to an existing vserver?<br />
||Details=Simple ;) See the answer above. <br />
|Signature=gcc}}<br />
<br />
<br />
{{Question<br />
|Question=Since upgrading to a newer VS version my guest complains about "vsched: non-numeric value specified for '--priority_bias" at start time. What's wrong?<br />
||Details=The scheduler paramters changed.You can use this (ugly) script to convert them or do it by hand:<br />
<pre><br />
# cat /usr/local/sbin/vserver-convert-schedule-to-scheddir<br />
#/bin/sh<br />
mkdir /etc/vservers/$1/sched<br />
sed -e 1p -n /etc/vservers/$1/schedule > /etc/vservers/$1/sched/fill-rate<br />
sed -e 2p -n /etc/vservers/$1/schedule > /etc/vservers/$1/sched/interval<br />
sed -e 3p -n /etc/vservers/$1/schedule > /etc/vservers/$1/sched/tokens<br />
sed -e 4p -n /etc/vservers/$1/schedule > /etc/vservers/$1/sched/tokens-min<br />
sed -e 5p -n /etc/vservers/$1/schedule > /etc/vservers/$1/sched/tokens-max<br />
<br />
mv /etc/vservers/$1/schedule /etc/vservers/$1/schedule.converted.see.scheddir<br />
<br />
# see: http://oldwiki.linux-vserver.org/Scheduler+Parameters<br />
# see: http://www.nongnu.org/util-vserver/doc/conf/configuration.html#sched<br />
</pre><br />
||Signature=derjohn}}<br />
<br />
<br />
{{Question<br />
|Question=Since upgrading to a newer VS version my guest doesn't have the amount of shared memory (SHM / SHMMAX / SHMALL ) as it had in the former version. What changed?<br />
||Details=Every VS version that runs on a kernel >= 2.6.19 offers sysctl values per guest. This has to do with the 'ipc namespace' feature that was added to the mainline kernel in version 2.6.19. Linux-VServer uses that feature to give each guest a separate 'ipc namespace' and thus 'own' sysctl values per guest. Because shmmax is such a sysctl value, you have to set it per guest.<br />
Here is an example how to do so:<br />
<br />
<pre><br />
# mkdir /etc/vservers/<vserver>/sysctl/0 -p<br />
# echo kernel.shmall > /etc/vservers/<vserver>/sysctl/0/setting<br />
# echo 134217728 > /etc/vservers/<vserver>/sysctl/0/value<br />
# mkdir /etc/vservers/<vserver>/sysctl/1 -p<br />
# echo kernel.shmmax > /etc/vservers/<vserver>/sysctl/1/setting<br />
# echo 134217728 > /etc/vservers/<vserver>/sysctl/1/value<br />
</pre><br />
It's also explained on the geat flower page:<br />
# see: http://www.nongnu.org/util-vserver/doc/conf/configuration.html -> Look for "sysctl".<br />
<br />
After changing those values, restart your guest, enter it and check if the values are set:<br />
<pre><br />
# sysctl -a | grep shm<br />
...<br />
kernel.shmall = 134217728<br />
kernel.shmmax = 134217728<br />
</pre><br />
<br />
To change a value for a running guest, on the host use:<br />
<pre><br />
vspace -e CONTEXTID --ipc sysctl -w kernel.shmall=134217728<br />
vspace -e CONTEXTID --ipc sysctl -w kernel.shmmax=134217728<br />
</pre><br />
<br />
||Signature=derjohn<br />
}}<br />
<br />
[[Category:Community]]<br />
[[Category:Categories]]</div>KornAndrashttp://wiki.linux-vserver.org/Report_a_BugReport a Bug2015-12-15T21:21:08Z<p>KornAndras: /* Where to send bug reports? */ Add github URL for util-vserver</p>
<hr />
<div>__NOTOC__<br />
<br />
There is a large number of Linux-VServer users. There is a much small number of people who actually develop Linux-VServer and fix bugs.<br />
<br />
What does this mean for you, an aspiring bug reporter? In order to catch the eye of one of these few volunteers, you'll need to take to heart a few tips on how to report a bug so that they can and will help you.<br />
<br />
By following these guidelines, you can help ensure that your bugs stay at the top of the developers' heap, and get fixed.<br />
<br />
== How to report bugs ==<br />
<br />
The people who are going to help you with a bug report are volunteers. Not only are you not paying them to help you, but nobody else is either. So, be nice to them. <br />
<br />
Beyond that golden rule, what follows are some additional tips on ways to make your bug report better so that someone will be able to help you.<br />
<br />
=== Basics: what you did, what you wanted to happen, and what actually happened. ===<br />
<br />
Those are the three basic elements of a bug report. You need to tell us exactly what you did (for example, "I right-clicked on "make happy meal"), what you expected to have happened (to continue the example, "I expected the kernel to serve me a happy meal with a hamburger and onion rings"), and what actually happened ("It gave me a happy meal with french fries.").<br />
<br />
Yes, the example is silly. But if your bug report simply said "The make_happy_meal function doesn't work," you will very likely get a reply saying "It works fine for me", because we can't guess what you were expecting to happen. By giving all the information you might get a reply like "That's because you can't have onion rings in a happy meal, you can only have french fries or curly fries." By telling us what you asked for, what you expected to get, and what you actually got, we don't have to guess what you mean.<br />
<br />
=== Useful information ===<br />
<br />
The following list gives an overview of information useful in bug reports. Note that you don't have to submit all information listed below, but you should do as long as it helps to discover the root of all evil.<br />
<br />
* One line summary of the problem<br />
* Full description of the problem<br />
* Kernel version (from /proc/version)<br />
* Output of test scripts (see below)<br />
* Output of the Oops.. message (if applicable) with symbolic information resolved (see Documentation/oops-tracing.txt in the kernel source)<br />
* A small shell script or example program which triggers the problem (if possible)<br />
* Processor information (from /proc/cpuinfo)<br />
* Module information (from /proc/modules)<br />
* Other information that might be relevant to the problem<br />
* Other notes, patches, fixes, workarounds<br />
<br />
=== Test scripts ===<br />
<br />
To ensure that your (VServer) setup works we have created two small test scripts. The testme.sh script ensures basic functionality whereas the testfs.sh script is for inode attribute testing for various filesystems.<br />
<br />
<pre><br />
# get the script<br />
wget http://vserver.13thfloor.at/Stuff/SCRIPT/testme.sh<br />
<br />
# make it executable<br />
chmod +x testme.sh<br />
<br />
# become root<br />
su<br />
<br />
# run the test script<br />
./testme.sh<br />
</pre><br />
<br />
'''Be careful! The testfs.sh script might easily reformat your hard disk :)'''<br />
<br />
<pre><br />
# get the script<br />
wget http://vserver.13thfloor.at/Stuff/SCRIPT/testfs.sh<br />
<br />
# make it executable<br />
chmod +x testfs.sh<br />
<br />
# make a loopback file (created as a sparse file to save time)<br />
touch 1gb.tesfile<br />
dd if=/dev/zero of=1gb.testfile bs=1 count=0 seek=1G<br />
<br />
# become root<br />
su<br />
<br />
# setup the loopback<br />
losetup /dev/loop0 1gb.testfile<br />
<br />
# run the test script for new-style config<br />
./testfs.sh -t -x -y -z -D /dev/loop0 -M /mnt<br />
</pre><br />
<br />
Attach the output of these two scripts to your bug report.<br />
<br />
'''If you need to figure out which line of code is causing an OOPS/RIP, the following script will parse your dmesg and output the lines and addresses formatted as shown below:'''<br />
<pre><br />
#!/bin/bash<br />
# output looks like: ffffffff80502a23:/usr/src/linux-2.6.25-vs/net/ipv4/raw.c:936<br />
# only arg is path to vmlinux (/usr/src/linux/vmlinux)<br />
CMD=`dmesg | egrep '<[[:xdigit:]]{16}>' | sed -r -e 's,^[^<]+?<,,g' -e 's,>[^<]+?<, ,g' -e 's,>.*$,,g'`<br />
if [ ${1} ]; then<br />
for i in ${CMD}; do echo -n $i: && addr2line -e $1 $i;done<br />
else<br />
echo please give me the path to your vmlinux<br />
fi<br />
</pre><br />
<br />
== Where to send bug reports? ==<br />
<br />
Bug reports about the kernel patch should be submitted to the mailing list or directly to one of our developers in IRC.<br />
<br />
Bug reports against util-vserver should be filed on [https://github.com/linux-vserver/util-vserver/ github].<br />
<br />
See the [[Communicate]] page to learn how to use the mailing list and/or IRC.<br />
<br />
[[Category:Community]]</div>KornAndrashttp://wiki.linux-vserver.org/Frequently_Asked_QuestionsFrequently Asked Questions2012-01-10T01:31:30Z<p>KornAndras: Add explanation of two mount namespaces per guest, as well as howto bind mount host dirs inside guest. Thanks to Bertl for explaining this on IRC.</p>
<hr />
<div><div style="margin: 2em auto 2em auto; padding: 10px; background-color: #F9ECCD; border: 1px solid #004433; text-align: center;"><br />
[[Image:Icon-Caution.png|left]]<br />
We currently migrate to MediaWiki from our old installation, but not all content has been migrated yet. Take a look at the [[Wiki Team]] page for instructions how to help or look at the [http://oldwiki.linux-vserver.org old wiki] to find the information not migrated yet.<br />
<br />
'''To ease migration we created a [[List of old Documentation pages]].'''<br />
</div><br />
<br />
CURRENTLY THE CONTENT OF THE OLD WIKI FAQ (AND MORE) IS BEING MIGRATED TO THIS PAGE (TASK: DERJOHN)<br />
<br />
<br />
__TOC__<br />
<br />
== General ==<br />
<br />
{{Question<br />
|Question=What is the status of Linux-VServer?<br />
||Details=Linux-VServer has more than a decade of maturity and is actively developed. Two projects are similar to Linux-VServer, [[http://lxc.sf.net LXC]], and [[http://openvz.org OpenVZ]]. Of the two, OpenVZ is the more mature and offers some similar functionality to Linux-VServer. LXC is solely based on the kernel mechanisms such as cgroups that are present in modern kernels. These kernel mechanisms will continue to be refined and isolation will mature. As that occurs, Linux-VServer will take advantage of those new features separately from LXC and continue to provide the same robust user interface that it does currently. Currently, LXC offers significantly less functionality and isolation than Linux-vserver. LXC will eventually be a robust wrapper around kernel mechanisms but is still under heavy development and not considered ready for production use.<br />
|Signature=beck}}<br />
<br />
<br />
<br />
{{Question<br />
|Question=What is a 'Guest'?<br />
||Details=To talk about stuff, we need some naming. The physical machine is called 'Host' and the 'main' context running the Host Distro is called 'Host Context'. The virtual machine/distro is called 'Guest' and basically is a Distribution (Userspace) running inside a 'Guest Context'.<br />
|Signature=derjohn}}<br />
<br />
<br />
{{Question<br />
|Question=What kind of Operating System (OS) can I run as guest?<br />
||Details= With VServer you can only run Linux guests. The trick is that a guest does not run a kernel on its own (as XEN and UML do), it merely uses a virtualized host kernel-interface. VServer offers so called security contexts which make it possible to separate one guest from each other, i.e. they cannot get data from each other. Imagine it as a chroot environment with much more security and features.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=Is this a new project? When was it started?<br />
||Details=The first public occurrence of Linux-VServer was Oct 2001. The initial mail can be found here: http://www.cs.helsinki.fi/linux/linux-kernel/2001-40/1065.html<br />
So you can expect a mature software product which does its magic quite well (And hey, we have a version > 2.0!)<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=Which distributions did you test?<br />
||Details=Some. Check out the wiki for ready-made guest images. But you can easily build own guest images, e.g. with Debian's debootstrap. Checkout [[Building Guest Systems]] how to do that.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=Is VServer comparable to XEN/UML/QEMU?<br />
||Details=Nope. XEN/UML/QEMU and VServer are just good friends. Because you ask, you probably know what XEN/UML/QEMU are. VServer in contrary to XEN/UML/QEMU does not "emulate" any hardware you run a kernel on. The purpose of Linux VServer is to isolate (groups of) applications. The isolation is done by the kernel (see [[Overview]] for a more detailed comparison). You can run a VServer kernel in a XEN/UML/QEMU guest. This is confirmed to work at least with Linux 2.6/vs2.0.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=With which version should I begin?<br />
||Details=If you are new to VServer I recommend to try the latest stable kernel patch, and the latest util-vserver "alpha" release.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=Is VServer secure?<br />
||Details=We hope so. It should be as least as secure as Linux is. We consider it much much more secure though.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=Performance?<br />
||Details=For a single guest, we basically have native performance. Some tests showed insignificant overhead (about 1-2%) others ran faster than on an unpatched kernel. This is IMVHO significantly less than other solutions waste, especially if you have more than a single guest (because of the resource sharing).<br />
|Signature=derjohn}}<br />
<br />
<br />
{{Question<br />
|Question=What is the "great flower page"?<br />
||Details=Well, [http://www.nongnu.org/util-vserver/doc/conf/configuration.html this page] contains all configuration options for util-vserver. The name of the page is derived from the stylesheet(s) it contains.<br />
|Signature=derjohn}}<br />
<br />
<br />
<br />
== Resources usage ==<br />
<br />
{{Question<br />
|Question=Resource sharing?<br />
||Details=Yes ....<br />
* memory: Dynamically.<br />
* CPU usage: Dynamically (token bucket)<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=Resource limiting?<br />
||Details=You can put limits per guest on different subsystems.<br />
* using ulimits and rlimits (rlimit is a new feature of kernel 2.6/vs2.0.) per guest, to limit the memory consumption, the number of processes or file-handles, ... : see [[Resource Limits]]<br />
* CPU usage : see [[CPU Scheduler]]<br />
* disk space usage : see [[Disk Limits and Quota]]<br />
Note that you can only offer guaranteed resource availability with some ticks at the time.<br />
|Signature=derjohn&xm}}<br />
<br />
{{Question<br />
|Question=How do I limit a guests RAM? I want to prevent OOM situations on the host!<br />
||Details=First you can read [http://linux-vserver.org/Memory+Allocation] and [[Memory Limits]].<br />
If you want a recipe, do this:<br />
# Check the size of memory pages. On x86 and x86_64 is usually 4 KB per page. (on linux "getconf -a|grep PAGE" will give you the information)<br />
# Create /etc/vserver/<guest>/rlimits/<br />
# Check your physical memory size on the host, e.g. with "free -m". maxram = kilobytes/pagesize.<br />
# Limit the guests physical RAM to value smaller then maxram:<pre>echo %%insertYourPagesHereSmallerThanMaxram%% > /etc/vserver/<guest>/rlimits/rss </pre><br />
# Check your swapspace, e.g. with 'swapon -s'. maxswap = swapkilobytes/pagesize.<br />
# Limit the guest's maximum number of as pages to a value smaller than (maxram+maxswap): <pre> echo %%desiredvalue%% > /etc/vserver/<guest>/rlimits/as </pre><br />
# Correctly display the memory information inside the guest:<pre>echo "VIRT_MEM" >> /etc/vservers/<guest>/flags</pre><br />
It should be clear this can still lead to OOM situations. Example: You have two guests and your as limit per guest is greater than 50% of (maxram+maxswap). If both guests request their maximum at the same point in time, there will be not enough mem .....<br />
|Signature=derjohn}}<br />
<br />
<br />
{{Question<br />
|Question=Disk I/O limiting? Is that possible?<br />
||Details=Well, since vs2.1.1 Linux-VServer supports a mechanism called 'I/O scheduling', which appeared in the 2.6 mainline some time ago. The mainline kernel offers several I/O schedulers:<br />
<pre><br />
# cat /sys/block/hdc/queue/scheduler<br />
noop [anticipatory] deadline cfq<br />
</pre><br />
<br />
The default since 2.6.18 in Sept 2006 is CFQ, described below, and prior to that was anticipatory a.k.a. "AS" ([[http://en.wikipedia.org/wiki/CFQ#Kernel_2.6.18_.2820_September_2006.29 Wikipedia]]). When running several guests on a host you probably want the I/O performance shared in a fair way among the different guests. The kernel comes with a "completely fair queueing" scheduler, CFQ, which can do that. (More on schedulers can be found at http://lwn.net/Articles/114770/)<br />
This is how to set the scheduler to "cfq" manually:<br />
<pre><br />
root# echo "cfq" > /sys/block/hdc/queue/scheduler<br />
root# cat /sys/block/hdc/queue/scheduler<br />
noop anticipatory deadline [cfq]<br />
</pre><br />
Keep in mind that you have to do it on all physical discs. So if you run an md-softraid, do it to all physical /dev/hdXYZ discs!<br />
If you run Debian there is a predefined way to set the /sys values at boot-time:<br />
<pre><br />
# apt-get install sysfsutils<br />
[...]<br />
<br />
# grep cfq /etc/sysfs.conf<br />
block/sda/queue/scheduler = cfq<br />
block/sdc/queue/scheduler = cfq<br />
<br />
# /etc/init.d/sysfsutils restart<br />
</pre><br />
<br />
For non-vserver processes and CFQ you can set by which key the kernel decides about the fairness:<br />
<pre><br />
cat /sys/block/hdc/queue/iosched/key_type<br />
pgid [tgid] uid gid<br />
</pre><br />
Hint: The 'key_type'-feature has been removed in the mainline kernel recently. Don't look for it any longer :(<br />
<br />
The default is tgid, which means to share fairly among process groups. Think every guest is treated like a own process group. It's not possible to set a scheduler strategy within a guest. All processes belonging to the same guest are treated like "noop" within the guest. So: If you run apache and some ftp-server within the _same_ guest, there is no fair scheduling between them, but there is fair scheduling between the whole guest and all other guests.<br />
<br />
And: It's possible to tune the scheduler parameters in several ways. Have a look at /sys/block/hdc/queue/....<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=Nice disk I/O scheduling, is that possible?<br />
||Details=Well, since linux 2.6.13 processess have another priority next to the cpu nice scheduling hint, it's called io nice.<br />
It's split into three groups, called real-time, best effort and idle. The default is best-effort, but within best-effort, you can have a niceness from 0 to and including 7.<br />
You can set this niceness by the tool ionice, which for debian is either in the package util-linux or schedutils.<br />
To change the io-niceness you need the <tt>CAP_SYS_NICE</tt>, '''and''' need to have the same uid as the processe you want to ionice.<br />
<br />
:'''Note:''' If you want to use any schedulung other than best-effort you will also need the <tt>CAP_SYS_ADMIN</tt>-flag. Be warned that this gives quite some capabilities to the vserver, not just for I/O scheduling!<br />
<br />
If you want to increase the niceness of an I/O hogging process within a vserver you need to do:<br />
<PRE><br />
chcontext --xid sponlp1 sudo -u '#2089' ionice -c2 -n5 -p24409<br />
</PRE><br />
with sudo and ionice installed on the root server to increase the *nice*ness of pid 24409, with uid 2089<br />
|Signature=Groteblup}}<br />
<br />
== Unification ==<br />
<br />
{{Question<br />
|Question=What is unification (vunify)?<br />
||Details=[[Unification]] is Hard Links on Steroids. Guests can 'share' common files (usually binaries and libraries) in a secure way, by creating hard links with special properties (immutable but unlinkable (removable)). The tool to identify common files and to unify them is called [[vunify]].<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=What is [[vhashify]]?<br />
||Details=The successor of [[vunify]], a tool which does unification based on hash values (which allows to find common files in arbitrary paths.)<br />
It creates hardlinks to files named after a hash of the content of the file. If you have a recent version of the vserver patch (2.2+), with CONFIG_VSERVER_COWBL enabled, you can even modify the hardlinked files inside the vservers and the links will be broken automatically.<br />
There seems to be a catch when a hashified file has multiple hardlinks inside a guest, or when another internal hardlink is added after hashification. Link breaking will remove all the internal hardlinks too, so the guest will end up with different copies of the original file. The correct solution would be to not hashify files that have multiple links prior to hashification, and to break the link to the hashified version when a new internal hardlink is created. Apparently, this is not implemented yet (?).<br />
|Signature=Guy-}}<br />
<br />
{{Question<br />
|Question=How do I manage a multi-guest setup with vhashify?<br />
||Details=For '[[vhashify]]', just do these once:<br />
<pre><br />
mkdir /etc/vservers/.defaults/apps/vunify/hash /vservers/.hash<br />
ln -s /vservers/.hash /etc/vservers/.defaults/apps/vunify/hash/root<br />
</pre><br />
Then, do this one line per vserver:<br />
<pre><br />
mkdir /etc/vservers/<vservername>/apps/vunify # vhashify reuses vunify configuration<br />
</pre><br />
To hashify a running vserver, do (possibly from a cronjob):<br />
<pre><br />
vserver name-of-guest hashify<br />
</pre><br />
<br />
The guest needs to be running because vhashify tries to figure out what files not to hashify by calling the package manager of the guest via <tt>vserver enter</tt>.<br />
<br />
In order for the OS cache to benefit from the hardlinking, you'll have to restart the vservers.<br />
<br />
To clean up hashified files that are no longer referenced by any vserver, do (possibly from a cronjob):<br />
<pre><br />
find /vservers/.hash -type f -links 1 -print0 | xargs -0 rm<br />
</pre><br />
<br />
Until you do this, the files still take up place even though no vservers need them.<br />
|Signature=Guy-}}<br />
<br />
== Filesystem usage ==<br />
<br />
{{Question<br />
|Question=Is there a way to implement "user/group quota" per VServer?<br />
||Details=Yes, but not on a shared partition for now. You need to put the guest on a separate partition, setup a vroot device (to make the quota access secure), copy that into the guest, and adjust the mtab line inside the guest. If 8 vroot device is not enough for you, you can add more with the kernel parameter max_vroot (exemple for built in kernel vroot /vmlinuz-2.6.31.6-vs2.3.0.36.26aq root=/dev/md1 ro max_vroot=20 ). If vroot is a module you'd actually want to put for exemple "options vroot max_vroot=20" in /etc/modprobe.conf and then just do modprobe vroot<br />
|Signature=derjohn,gadnet}}<br />
<br />
{{Question<br />
|Question=What about "Quota" for a context? Howto limit disk usage?<br />
||Details=Context quotas are now called Disk Limits (so that we can tell them apart from the user/group quotas :). They are supported out of the box (with vs2.0+) for all major filesystems (ext2/3, ReiserFS, JFS). You need to tag the FS with XID (see below). Please read [[Disk Limits and Quota]] for more information.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=How do I tag a guest's directory with xid?<br />
||Details=Tagging the guest's files gives you several advantages, e.g. the accounting will work properly.<br />
Filesystem XID tagging only works on supported filesystem. Those are currently: ext2/3, reiserfs/reiser3, xfs and jfs.<br />
To activate the XID tagging you have to mount the filesystem with "-o tag" (former tagxid is outdated since VS2.2). Attention: It's _not_ possible to "-o remount,tag", you have to mount it freshly. The guests will tag their files automatiaclly. If you copy files in from the host, you have to tag them manually like this:<br />
<pre><br />
chxid -c xid -R /var/lib/vservers/<guest><br />
</pre><br />
Note: Context 0 and 1 will see all files, guests will only be able to access untagged files and their own XID. They can see other XID files but no information about the file, e.g. no owner, no group, no permissions.<br />
Note: It is not advised to tag the root filesystem, as [http://www.paul.sladen.org/vserver/archives/200602/0020.html explained by Herbert] : trying to do so will expose you to some troubles !<br />
|Signature=derjohn_and_gonzo_and_are}}<br />
<br />
{{Question<br />
|Question=How can I copy anything from host to guest partition, normally unvisible on host?<br />
||Details=You should just change namespace, e.g.:<br />
<pre><br />
vnamespace --enter <xid> -- /bin/bash<br />
</pre><br />
and then use standard cp or rsync programs.<br />
|Signature=SergiuszPawlowicz}}<br />
<br />
{{Question<br />
|Question=Why is the barrier attribute disappearing on reiserfs filesystem after umount or host reboot?<br />
||Details=The filesystem has to be mounted with explicitly defining the 'attrs' option, i.e. <br />
<pre><br />
mount /dev/reiserfsdev /vservers -oattrs<br />
setattr --barrier /vservers<br />
</pre><br />
to get the barrier survive after umount/reboot.<br />
|Signature=Nikolay Kichukov}}<br />
<br />
== Network ==<br />
<br />
{{Question<br />
|Question=Does it support IPv6?<br />
||Details=Currently it requires an additional patch, but the functionality should be available in 2.3+ soon. [[IPv6]] has more information.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=I can't do all I want with the network interfaces inside the guest?<br />
||Details=For now the networking is 'Host Business' -- the host is a router, and each guest is a server. You can set the capability ICMP_RAW in the context of the guest, or even the capability CAP_NET_RAW (which would even allow to sniff interfaces of other guests!). Likely to change with ngnet.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=How do I add several IPs to a vserver?<br />
||Details=First of all a single guest vserver only supports up to 16 IPs (There is a 64-IP patch available, which is in "derjohn's kernel").<br />
<pre><br />
Update from IRC (2011-08-22):<br />
<mmouse> quick question: what is the maximum count of IPs (v4) I can have in a single guest?<br />
<daniel_hozac> unlimited.<br />
</pre><br />
<br />
Here is a little helper-script that adds a list of IPs defined in a text file, one per line.<br />
<pre><br />
#!/bin/bash<br />
j=1<br />
for i in `cat myiplist`; do<br />
j=$(($j+1))<br />
mkdir $j<br />
echo $i > $j/ip<br />
echo "24" > $j/prefix<br />
done<br />
</pre><br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=How do I assign a new IP address to a running guest?<br />
||Details=This is done from the host server:<br />
* add the ip on the host, for example<br />
<pre><br />
ip addr add 194.169.123.23/24 dev eth0 <br />
</pre><br />
* add the ip to the guest's network context (a guests NID is the same as the XID {context ID})<br />
<pre><br />
naddress --add --nid <nid> --ip 194.169.123.23/24 <br />
</pre><br />
* enter the guest (best via ssh) <br />
* restart the services that need to make use of the new address if required <br />
* update the config in ''/etc/vserver/<servername>/interfaces'' to reflect the changes for the next guest restart (if desired)<br />
|Signature=BenjaminGreen}}<br />
<br />
{{Question<br />
|Question=If my host has only one a single public IP, can I use RFC1918 IP (e.g. 192.168.foo.bar) for the guest vservers?<br />
||Details=Yes, use iptables with SNAT to masquerade it. <br />
<pre><br />
iptables -t nat -I POSTROUTING -s $VSERVER_NETZ ! -d $VSERVER_NETZ -j SNAT --to $EXT_IP<br />
</pre><br />
See: [[HowtoPrivateNetworking]] and <br />
http://www.tgunkel.de/it/software/doc/linux_server.en#h3-VServer_Masquerading_SNAT (THX, [MUPPETS]Gonzo)<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=If I shut down my vserver guest, the whole Internet interface ethX on the host is shut down. What happened?<br />
||Details=When you shut down a guest (''i.e. vserver foo stop''), the IP is brought down on the host also. If this IP happens to be the primary IP of the host, the kernel will not only bring down the primary IP, but also all secondary IP addresses. But in very recent kernels, there is an option ''settable'' which prevents that nasty feature. It's called "alias promotion". You may set it via sysctl by adding ''net.ipv4.conf.all.promote_secondaries=1'' in /etc/sysctl.conf or via sysctl command line.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=Can I run an OpenVPN Server in a guest?<br />
||Details=<br />
Yes. To get a OpenVPN Server running in a guest, all networking setup has to be done on the host. This answer describes the common case and shows some pitfalls, for detailled information about OpenVPN, please consult the appropriate documentation on the OpenVPN homepage.<br />
This is the minimal OpenVPN configuration for the Server which will be used to demonstrate how to get it running in a client:<br />
<pre><br />
# Networking setup<br />
server 192.168.16.0 255.255.255.0<br />
dev tun16<br />
ifconfig-noexec<br />
comp-lzo<br />
# Certificates<br />
dh ...<br />
ca ...<br />
cert ...<br />
key ...<br />
# Management<br />
persist-key<br />
keepalive 10 60<br />
verb 4<br />
</pre><br />
First of all you have to prepare the host with a persistent interface in the right mode and with the right settings. This is easily done by using openvpn and the ip and route tools.<br />
<pre><br />
# openvpn --mktun --dev tun16<br />
# ip link set dev tun16 txqueuelen 100<br />
# ifconfig tun16 192.168.16.1 pointopoint 192.168.16.2 mtu 1500<br />
# route add -net 192.168.16.0 netmask 255.255.255.0 gw 192.168.16.2<br />
</pre><br />
If you need different settings, openvpn will tell you the ifconfig and route commands it uses to configure the interface when being started on the host with the original config file, but without ifconfig-noexec.<br />
Additionally, the guest needs /dev/net/tun to make OpenVPN happy. This can be created with MAKEDEV:<br />
<pre><br />
# cd /var/lib/vserver/<myopenvpnserver>/dev/<br />
# ./MAKEDEV tun<br />
(creates the dev/net/tun device accessible by the guest - even a tap interface needs /dev/net/tun !)<br />
</pre><br />
Finally, the guest needs to have the tun device assigned:<br />
<pre><br />
# head /etc/vservers/<myopenvpnserver>/interfaces/1/*<br />
==> /etc/vservers/<myopenvpnserver>/interfaces/1/ip <==<br />
192.168.16.1<br />
<br />
==> /etc/vservers/<myopenvpnserver>/interfaces/1/nodev <==<br />
tun16<br />
<br />
==> /etc/vservers/<myopenvpnserver>/interfaces/1/prefix <==<br />
24<br />
#<br />
</pre><br />
The client's conf may look like that:<br />
<pre><br />
# Basic setup<br />
client<br />
proto tcp-client<br />
dev tun<br />
remote <ipaddress><br />
comp-lzo<br />
verb 4<br />
<br />
# Certificate<br />
ca ...<br />
</pre><br />
<br />
[ Based on derJohn's original answer, all errors mine ] <br />
|Signature=DavidS}}<br />
<br />
{{Question<br />
|Question=Trying to connect to a vserver from the host or another vserver on the same host fails<br />
||Details=strace shows<br />
<pre> <br />
sin_addr=inet_addr("xx.xx.xx.xx")}, yy) = -1 EINVAL (Invalid argument)<br />
</pre><br />
A: The host/guest cannot communicate with another guest on same host.<br />
* check all netmasks on all interfaces (do they overlap) ?<br />
* check policy routing (disable it temporary) ?<br />
* check that lo is up (Networking within a host/guest always uses lo interface)<br />
|Signature=CommonProblems}}<br />
<br />
{{Question<br />
|Question=Can I use iptables ?<br />
||Details=Yes but right now only on the host (rootserver). Please realize that all traffic is local and will not touch the forward chain.<br />
<br>If you really, really, really need iptables on the guest and you are aware about loosing a big part of VServer isolation and security you could add the NET_ADMIN capability. Consider writing wrappers to manage iptables on the host instead.<br />
|Signature=_are_}}<br />
<br />
{{Question<br />
|Question=Is it possible to prevent guest from bringing down primary ip?<br />
||Details=Yes. Remove /etc/vservers/<guest>/interfaces/X/dev, and touch /etc/vservers/<guest>/interfaces/X/nodev<br />
|Signature=Daniel&Serge}}<br />
<br />
{{Question<br />
|Question=Is it possible to provide a different MAC address per vServer?<br />
||Details=Short answer - yes but it's a hassle.<br />
<br />
Real answer from '''_are_''':<br />
<pre><br />
When I once needed 'real' seperate MAC-addresses I used TAP-devices and VDE2 ([http://vde.sourceforge.net/ Virtual Distributed Ethernet]).<br />
Basically vServer is an isolation of existing resources, not a virtualization of 'new' devices.<br />
Without extra fuss you can't add a 'new' network interface to a vServer, no matter if it is eth* or tap*, you always add it to the host and give the vServer access to it.<br />
I got the TAP+VDE2 up and running, but I think it is too much trouble for basically the simple adding of IPs to a vServer unless you really need the MAC address separate.<br />
</pre><br />
<br />
<br />
You can also utilize MACVLAN ability from kernel.<br />
I.e. create ''macvlan0'' interface with:<br />
<pre>ip link add link eth0 address 00:19:d1:29:d2:58 macvlan0 type macvlan</pre><br />
[[http://jim.studt.net/depository/index.php/notes-on-linux-s-macvlan-module Reference]]<br />
|Signature=bobnormal&swenTjuln<br />
}}<br />
<br />
{{Question<br />
|Question=Is it possible to hide packet counters on the host network interface from vServer guests?<br />
||Details=Yes, see [[Networking_vserver_guests|Networking vServer Guests]]<br />
|Signature=bobnormal}}<br />
<br />
{{Question<br />
|Question=Services won't bind to 127.0.0.1 when I configure them to bind to all available IPs / (binding service to * doesn't bind to loopback)?<br />
||Details=You've configured single public IP and have kernel option "Linux VServer -> Automatic Single IP Special Casing" enabled.<br />
It means somehow "optimized" :D<br />
If you don't want this you have 3 possible solutions (quoting Bertl):<br />
* disable the auto single IP in the kernel<br />
* assign more than one IP to the guest<br />
* disable single ip special casing for that guest<br />
<br />
The later is done by : echo "~single_ip" >> /etc/vservers/<VSERVER>/nflags<br />
At runtime to avoid restarting the vserver: nattribute --set --nid <guest> --flag ~single_ip<br />
|Signature=swenTjuln}}<br />
<br />
== Administration tools ==<br />
<br />
{{Question<br />
|Question=Which guest vservers are running?<br />
||Details=Use vserver-stat to find out. Example output:<br />
<pre><br />
CTX PROC VSZ RSS userTIME sysTIME UPTIME NAME<br />
0 77 965.1M 334.6M 14m14s18 2m28s69 1h33m46 root server<br />
49152 7 14M 5.2M 0m00s40 0m00s30 1h30m15 chiffon<br />
</pre><br />
|Signature=derjohn}}<br />
<br />
<br />
{{Question<br />
|Question=Is there a web-based interface for vserver that will allow creation/deletion/configuration etc. of vserver guests?<br />
||Details=<br />
* http://OpenVPS.org which is a set of scripts with a web-interface for webhosters/ISPs<br />
* http://Openvcp.org which is a distributed system (agent!) with a web-interface, with which you can build/remove guests<br />
* http://vsmon.revolutionlinux.com/ is a distributed monitoring-only solution that allows you to search for a particular vserver in your park.<br />
|Signature=derjohn}}<br />
<br />
== Hosting foreign distributions ==<br />
<br />
{{Question<br />
|Question=I run a Debian host and want to build an Ubuntu guest. Howto?<br />
||Details=Simple ;) Assume you want to build a breezy guest on a sid host with IP 192.168.0.2 and hostname vubuntu, then do:<br />
<pre><br />
vserver vubuntu build --force -m debootstrap --hostname vubuntu.myvservers.net --netdev eth0 --interface 192.168.0.2/24 \<br />
--context 42 -- -d breezy -m http://de.archive.ubuntu.com/ubuntu<br />
</pre><br />
<br />
[UPDATE] Currently there are problems in building breezy under unclear circumstances, which seems to have to do with udev. If the above didnt work, try:<br />
<pre><br />
vserver vubuntu build --force -m debootstrap --hostname vubuntu.myvservers.net --netdev eth0 --interface 192.168.0.2/24 \<br />
--context 42 -- -d breezy -m http://de.archive.ubuntu.com/ubuntu -- --exclude=udev<br />
</pre><br />
In very recent versions of the utils, the problem should not occur anymore (it has to do with the 'secure-mount' if you look in the MLs)<br />
<br />
Well, sid's debootstrap knows how to bootstrap Ubuntu linux. Make sure to have a current debootstrap package: <br />
<pre><br />
apt-get update<br />
apt-get install debootstrap<br />
</pre><br />
The knowledge how to build ubuntu 'breezy badger' (which you probably want to be your guest at the time of writing) has been added recently.<br />
|Signature=derjohn}}<br />
<br />
<br />
{{Question<br />
|Question=I want to build a Gentoo guest. Howto?<br />
||Details=Even simpler ;) See http://www.gentoo.org/proj/en/vps/vserver-howto.xml#doc_chap3 .<br />
|Signature=gcc}}<br />
<br />
== Application level problems ==<br />
<br />
{{Question<br />
|Question=I did everything right, but the application foo does not start. What's up there?<br />
||Details=Before asking on the IRC channel, please check out the 'problematic programs' page:<br />
[[Problematic Programs]]<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=When I try to ssh to the guest, I log into the host, even if I installed sshd on the guest. What's wrong here?<br />
||Details=Look at /etc/ssh/sshd_config of the host:<br />
<pre><br />
Port 22<br />
# Use these options to restrict which interfaces/protocols sshd will bind to<br />
#ListenAddress ::<br />
</pre><br />
And now change the setting to <br />
<pre><br />
Port 22<br />
# Use these options to restrict which interfaces/protocols sshd will bind to<br />
ListenAddress your.hosts.ip.here # not the guests IP! <br />
</pre><br />
Then '/etc/init.d/ssh restart' on the host, after that on the guest (if you did apt-get install ssh on the guest already.)<br />
Do I have to explain more? If the hosts sshd binds all available IP addresses on port 22 (The hosts 'sees' even all addresses of the guests!). So if the guest starts its sshd, it can't bind to port 22 any more. You need to change that setting only on the host. <br />
(BTW: A similar approach has to be done for a lot of daemons, e.g. Apache. If the daemon does not support an explicit bind, you may use the chbind command to 'hide' IP addresses from the daemon before starting.)|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=Bind9 does not like to start in my guest.<br />
||Details=Check out the [[Problematic Programs]] page and/or get my [http://linux-vserver.derjohn.de/bind9-packages/bind9-capacheck_9.3.2-2_i386.deb vserver-guest-ready Debian package] for Debian Sid guests and check out the [http://linux-vserver.derjohn.de/bind9-packages/README.txt readme]. (Hint: This is fresh stuff. Please give me feedback)<br />
<br />
[UPDATE] Since VServer Devel 2.1.1-rc18 you do not need to patch the userland tools anymore. The capabilities are masked.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=My mysqld running in a guest behaves strangely and is awfully slow/locks up<br />
||Details=This can be related to /tmp being too small. mysqld stores temporary tables in /tmp and as such, if a lot of queries happen and /tmp runs full this can cause one query to lock up whilst creating the tmp table and all other queries waiting to acquire the lock. There are two possible solutions to that problem: a.) Modify /etc/vservers/vserver-name/fstab and assign more memory to the tmpfs of /tmp and b.) remove the /tmp entry from /etc/vservers/vserver-name/fstab completly. Especially on database servers with a rather high load the second one might be the preferred method.|Signature=sp}}<br />
<br />
{{Question<br />
|Question=Pure-FTP does not run inside a VServer?<br />
||Details=That's because it has capabilities enabled, make sure you rebuild your distro's package passing also the `--without-capabilities` flag to configure.<br />
|Signature=Pedro Algarvio, aka, s0undt3ch}}<br />
<br />
{{Question<br />
|Question=Why do neither sshd nor crond (vixie-cron) work correctly in my CentOS / Fedora guest? I get 'pam_loginuid(crond:session): set_loginuid failed opening loginuid' and similar lines in my logs.<br />
||Details=Took me a while to figure this out, and it turned out to be mentioned in the old wiki. Here is the solution on how to solve a common problem with sshd / crond, somehow related to selinux and auditing:<br />
<br />
pam authentication (also used with openssh) enables "pam_loginuid.so" in the /etc/pam.d/* files. Comment those out as they are not necessary and will not load within a guest anyway. This probably is also necessary on updates later on, if the configs get changed. You therefore may add the following command line to a cronjob file or your software update script:<br />
<pre><br />
/bin/sed --in-place -e "s/^session.*required.*pam_loginuid.so/# session\trequired\tpam_loginuid.so/g" /etc/pam.d/*<br />
</pre><br />
|Signature=patrick}}<br />
<br />
{{Question<br />
|Question=How do i install nagios-plugins on a Gentoo guest?<br />
||Details=Unfortunately, the nagios-plugins ./configure scripts wants to ping 127.0.0.1 which is not available inside a guest. Therefore you have to build nagios-plugins outside the guest.<br />
The easiest way to do this from the host (assuming the guest is running) is:<br />
<pre><br />
vnamespace -e <xid> -- chroot /vservers/<name> emerge nagios-plugins -va<br />
</pre><br />
|Signature=Hollow}}<br />
<br />
{{Question<br />
|Question=Somebody runs ntpd in guest and you can't use ntpdate in host?<br />
||Details=Try to run ntpdate with options -u :<br />
ntpdate -u ntp.domain.xy<br />
or you can use command:<br />
chbind --nid 42 --ip 1.2.3.4 -- ntpdate ntp.domain.xy<br />
where IP will be the IP of host.<br />
|Signature=Punkie/Bertl}}<br />
<br />
<br />
<br />
== Start / Stop a VServer ==<br />
<br />
{{Question<br />
|Question=How do I make a vserver guest start by default?<br />
||Details=At least on Debian, I can tell you how to do it with the new-style config. If your guest is called "derjohn" and you want it to be started somewhere at the of your bootstrap process, then do:<br />
<pre><br />
echo "default" > /etc/vservers/derjohn/apps/init/mark<br />
</pre><br />
If you want to start it earlier, please read the init script "/etc/init.d/util-vserver" to find out how to do it. In most cases you don't need to change this. On Debian the vservers are started at "20", so after most other stuff is up (networking etc.).<br />
<br />
Besides that I created a small helper script for managing the autostart foo: ((vserver-autostart))|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=My host works, but when I start a guest it says that it has a problem with chbind.<br />
||Details=You are probably using util-vserver <= 0.30.209, which does use dynamic network contexts internally (With 0.30.210 this fact changed). So if you compiled your kernel without dynamic contexts, you may start guests, but you can't use the network context.The solution is either to switch to .210 util (or Hollow's toolset) or compile the kernel with dynamic network contexts.<br />
SE Keyword: invalid option `nid' testme.sh<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=What is old-style and new-style config?<br />
||Details=Old-style config refers to a single text-file that contains all the configuration settings. With new-style config the configuration is split into several directories and files. You should probably go for new-style config if you are asking.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=How can I reboot/halt guests?<br />
||Details=It depends. <br />
For legacy Linux-VServer (i.e. 1.2.x), you have to replace /sbin/halt in the guests with vreboot and start rebootmgr in the host. You also need to have a <guest>.conf file in /etc/vservers for each guest. Please have a look at /etc/init.d/rebootmgr.<br />
For Linux-VServer 2.0+, sys_reboot has been virtualized to do the right thing. No changes are needed in guests. Please note that some things depend on the init style used by the guest : read [[util-vserver:InitStyles]]<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=What is the initial PATH?<br />
||Details=By default, vserver uses the 'sysv' startup style, which mimics the init process by running the 3rd runlevel through '/etc/init.d/rc 3' (or '/etc/rc.d/rc 3'). Usually this 'rc' script uses a hard-coded PATH. In the case it doesn't, util-vserver also mimics init's default PATH through /etc/vservers/.defaults/apps/init/environment, or if not present /usr/local/lib/util-vserver/defaults/environment. Beware that all those default PATH usually do not include /usr/local.<br />
|Signature=daniel_hozac&Beuc}}<br />
<br />
{{Question<br />
|Question=When I try to start a guest i get this message "/proc/uptime can not be accessed. Usually, this is caused by procfs-security. Please read the FAQ for more details"?<br />
||Details=After a reboot you need to run the vprocunhide script. If running this script causes many errors to print on the screen, try checking the kernel you have booted with (perhaps it does not have the linux-vserver extensions enabled).<br />
|Signature=mattzerah}}<br />
<br />
== Kernel ==<br />
<br />
{{Question<br />
|Question=Is SMP Supported?<br />
||Details=Yes, on all SMP capable kernel architectures.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=Do I really need the legacy-interfaces? What are these legacy-interfaces?<br />
||Details=Since Linux-VServer is an ongoing project, new features might replace old ones, some might require a development version. Legacy-interfaces are available for backward compability (which might be removed someday) with Linux-VServer 1.2.x.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=I have a vserver running on a Linux kernel with preemption. Is VServer "preempt" safe?<br />
||Details=There are no known issues about running vserver on a preemption enabled kernel. I would like to add, that the vserver kernelhackers would probably exclude that option in 'make menuconfig' if there would be an incompatibility. Just my $.02 :)<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=32 vs 64 Bit? What should I take?<br />
||Details=If you have the choice make the host a 64 bit one. You can run a guest as 32 bit or as 64 bit on a 64 bit host. To run it as 32 bit, you need to compile the x86_64 (a.k.a. AMD64) with the following options:<br />
<pre><br />
[*] Kernel support for ELF binaries<br />
<M> Kernel support for MISC binaries<br />
[*] IA32 Emulation <---- without that, the entire 32bit API is not present<br />
<M> IA32 a.out support <br />
</pre><br />
You can force the guest to behave like a 32 environment like this:<br />
<pre><br />
echo linux_32bit > /etc/vservers/$NAME/personality<br />
echo i686 > /etc/vservers/$NAME/uts/machine<br />
</pre><br />
(thanks cehteh for the hint!)<br />
<br />
But you can force debootstrap to put 32 bit binaries into the guest by 'export ARCH=i386';<br />
<pre><br />
export ARCH=i386 ; vserver build .... <br />
</pre><br />
<br />
On debian when using the newvserver script "export ARCH=i386" has no effect, just use:<br />
<pre><br />
newvserver --arch i386 ...<br />
</pre><br />
<br />
On debian debootstrap can also be gived the arch option:<br />
<pre><br />
vserver myguest \<br />
build -m debootstrap -n myguest \<br />
--hostname myguest.mydomain.com \<br />
-- -d squeeze -- \<br />
--arch=amd64 (or i386 if you want 32bit)<br />
</pre><br />
<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=What does the guest privacy option do in the kernel settings ?<br />
||Details=<pre><br />
>i was wondering about the real thing that guest privacy does. <br />
#ifdef CONFIG_VSERVER_PRIVACY<br />
#define VS_ADMIN_P (0)<br />
#define VS_WATCH_P (0)<br />
#else<br />
<br />
> > Does it just prevent the spectator context ? <br />
<br />
it prevents the spectator context and the admin <br />
functionality in all cases which are privacy<br />
sensitive, which includes:<br />
<br />
- ptrace<br />
- devmapper<br />
- devpts<br />
- inode tag permissions<br />
- mountinfo<br />
- kill/signal<br />
- netlink dumps<br />
- tun control<br />
- iopriority<br />
<br />
> > What security do it bring to the system ?<br />
<br />
together with the VXF_STATE_ADMIN it can be<br />
used to secure a guest (to some degree) from<br />
unwanted access from the host admin, of course,<br />
as the admin can change the kernel, this is a<br />
voluntary feature which mostly prevents certain<br />
kinds of accidential peeking or guest modification<br />
<br />
</pre><br />
|Signature=ghislain}}<br />
<br />
<br />
== Distribution specific questions ==<br />
<br />
{{Question<br />
|Question=VServer is included in the stable Debian GNU/Linux for years now. What VS version did they include?<br />
||Details=At the time of writing, Debian Squeeze is the stable release of Debian and includes a 2.6.32 based kernel-package called 2.6.32-5-vserver-ARCH. This currently contains VServer 2.3.0.36.29.6 with some additional fixes.<br />
|Signature=scientes}}<br />
<br />
{{Question<br />
|Question=Were can I get newer versions of VServer as ready made packages for Debian?<br />
||Details= There are a number of locations<br />
* http://repo.psand.net/info/ has Debian Lenny and Squeeze packages for 2.6.31 (i368 and amd64), 2.6.33, 2.6.35, 2.6.36 (amd64). It also contains newer util-vserver builds.<br />
* http://linux-vserver.derjohn.de/ - "my kernels are always 'devel' branch" (derjohn). This repo contain kernels up to 2.6.29 for amd64, 2.6.26 for i386.<br />
* http://backports.debian.org/ contains 2.6.32 backports for Lenny at time of writing (11th May 2010)<br />
* http://zbla.net/debian/ Unofficial debian vserver packages '''WARNING : i386 packets are compiled for 64bits !''' apt source line: ''deb http://zbla.net/debian/ ./'' (N/A as of 2011/12/27)<br />
|Signature=Gremble<br />
}}<br />
<br />
<br />
<br />
== Misc ==<br />
<br />
{{Question<br />
|Question=Why isn't there a device /dev/xyz within a guest?<br />
||Details=Device nodes allow userspace to access hardware (or virtual resources). Creating a device node inside the guest's namespace will give access to that device, so for security reasons, the number of 'given' devices is small.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=I want to (re)mount a virtual filesystem (like tmpfs) in a running guest ... but the guest has no rights (capability) to (re)mount?<br />
||Details=I take as example your /tmp partition within the guest is too small, what will be likely the case if you stay with the 16MB default (vserver build mounts /tmp as 16 MB tmpfs!).<br />
<pre><br />
# vnamespace -e XID mount -t tmpfs -o remount,size=256m,mode=1777 none /var/lib/vservers/<guest>/tmp/<br />
</pre><br />
(if there's a problem, try expanding the symlinks in the mount path)<br />
Be warned that the guest will not recognize the change, as the /etc/mtab file is not updated when you mount like this. To permanently change the mount, edit /etc/vserver/<guest>/fstab on the host.<br />
<br />
If you get:<br />
<pre><br />
mount: can't find /var/lib/vservers/<guest>/tmp in /etc/fstab or /etc/mtab<br />
</pre><br />
then try instead:<br />
<pre><br />
vnamespace -e builder chroot /var/lib/vservers/<guest>/ mount -o remount,size=64m,mode=1777 /tmp<br />
</pre><br />
|Signature=derjohn/BenjaminGreen}}<br />
<br />
{{Question<br />
|Question=How do I bind mount a host directory inside a running guest?<br />
||Details=There are two ways to do this: one is to enter the bind mount in the guest fstab and restart the guest.<br />
<br />
To understand the other way, let me explain how mount namespaces work.<br />
<br />
Every guest has two mount namespaces associated with it: one "''management namespace''" and one "''operational namespace''".<br />
<br />
On starting the guest, first the management namespace is created as a copy of the host namespace (which means that everything that was mounted on the host is mounted in the new namespace as well). This has unwelcome side effects: for example, if you had a cdrom mounted while starting the guest, you wouldn't be able to eject it until you stop the guest even if you umount it on the host, because it's still mounted in the guest. Therefore, the namespace is ''cleaned up'': filesystems that are mounted outside the root of the guest get unmounted in the guest namespace.<br />
<br />
Subsequently, the operational namespace of the guest is created as a copy of the management namespace, and the guest's processes are started in it.<br />
<br />
To bind mount a host directory in the guest, you must first make that host directory visible in the management namespace of the guest. This is automatically the case if the directory resides inside a mountpoint that exists in the guest namespace as well; however, if the guest config referenced no part of this mountpoint (or it didn't yet exist when you started the guest), then the cleanup mentioned above removed it from the guest's management namespace and you need to re-add it.<br />
<br />
Let's assume, as an example, that we want a guest to see a subdirectory, called <tt>foo</tt>, of the cdrom we just mounted on the host (e.g. under <tt>/media/cdrom</tt>).<br />
<br />
Let's enter the management namespace of the guest (that's what <tt>-i 0</tt> is for):<br />
<br />
<pre><br />
# vnamespace -i 0 -e <guest-xid> -- /bin/bash<br />
</pre><br />
<br />
Now you have access to all host devices; mount the device that contains your directory wherever you want, but you may prefer to mount it in the same location you used on the host. (Note, though, that it's not even necessary for the device to be mounted in the host namespace at all.)<br />
<br />
It's likely best to use <tt>mount -n</tt> lest your host <tt>/etc/mtab</tt> get polluted with mounts from other namespaces.<br />
<br />
<pre><br />
# mount -n /dev/sr0 /media/cdrom<br />
# exit<br />
</pre><br />
<br />
We're now back in the host namespace. <tt>vmount</tt> can now be used to bind mount <tt>/media/cdrom/foo</tt> inside a running guest (in this example, under <tt>/foo</tt> inside the vserver root):<br />
<br />
<pre><br />
# vmount guestname -- --bind /media/cdrom/foo /mnt/foo<br />
</pre><br />
|Signature=[[User:KornAndras|Guy-]] 01:31, 10 January 2012 (UTC)}}<br />
<br />
{{Question<br />
|Question=How do I mount a device present on the host under a directory in a running guest?<br />
||Details=Use something like:<br />
<pre><br />
vnamespace -e <guestname> mount -n /dev/<device> /vservers/<guest>/place/you/want/to/mount/it<br />
</pre><br />
<br />
This device can be unmounted with:<br />
<br />
<pre><br />
vnamespace -e <guestname> umount -n /vservers/<guest>/place/you/want/to/mount/it<br />
</pre><br />
<br />
|Signature=derjohn/BenjaminGreen}}<br />
<br />
{{Question<br />
|Question=Does anyone know how to increase the size of /tmp within a vserver w/o restarting?<br />
||Details=Use the remount option for mount.<br />
# vnamespace -e XID mount -n -t tmpfs -o remount,size=32m tmpfs /<vdir>/<guest>/tmp<br />
or something like that. The arguments are needed since mount is not going to be using /etc/fstab for the information and the version of /proc/mounts is best understood by<br />
# vnamespace -e XID cat /proc/mounts.<br />
See [[Frequently_Asked_Questions#I want to (re)mount a partition in a running guest ... but the guest has no rights (capability) to (re)mount?]]<br />
|Signature=derjohn/dhozac}}<br />
<br />
<br />
{{Question<br />
|Question=#1 ERROR: capset(): Operation not permitted<br />
||Details=capabilities are not enabled in kernel-setup<br />
please check that CONFIG_SECURITY_CAPABILITIES is loaded or included in the kernel. ( check with "cat /path_to_kernel/.config | grep -i cap ") <br />
(2.6.11.5-vs-1.9.5 + 0.30-205)<br />
|Signature=IrcQuestions}}<br />
<br />
{{Question<br />
|Question=How can I make 'vserver start' mount the root filesystem?<br />
||Details=Mount it via /etc/vservers/vserver-name/fstab, make sure to set the option 'dev' e.g.:<br />
<pre>/dev/drbd0 / xfs rw,dev 0 0</pre><br />
|Signature=AdrianReyer}}<br />
<br />
<br />
{{Question<br />
|Question=I deleted a guest's directory without shutting it down. Now I have a "ghost" running. Is there any possibility to get it out of proc without rebooting?<br />
||Details=<br />
vkill --xid <xid> -s 15; sleep 2; vkill --xid <xid> -s 9<br />
<br />
You will also need to remove guest's ip, for example with:<br />
ip addr del <ip> dev eth0<br />
|Signature=daniel_hozac & gebura }}<br />
<br />
{{Question<br />
|Question=When using nice and su (for example, in the updatedb cron job), I get: su: Permission denied. What does it mean?<br />
||Details=A guest cannot lower its nice value - and that's what 'su' does through pam_limits which sets a nice value of 0. You can see it through strace:<br />
$ strace nice su nobody<br />
[...]<br />
setpriority(PRIO_PROCESS, 0, 0) = -1 EACCES (Permission denied)<br />
You can use 'su nobody -c nice some_cmd' instead.<br />
<br />
The problem is caused by the fact that host system is setting limits for guests (when instructed to do so) and the dropped capability dissallows processess on guest systems to change and increase them later. That means no process on a guest can lower nice value above the limit set by host.<br />
<br />
If the pam_limits module is activated on a guest system it will first try to '''reset nice value to 0''' even if <tt>/etc/security/limits.conf</tt> file is empty or even if there are lower priority limits set in it. The pam_limits module does that since [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=241663 its developers decided] that it should reset some limits to defaults and start from scratch when applying new restrictions. Unfortunately, already limited guest system won't be able to do it since resetting nice value to 0 means increasing the limit which is forbidden. See [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=311058 Debian Bug report logs - #311058] for more information about that Debian bug.<br />
<br />
See also [[Frequently_Asked_Questions#Cron is not working on my guest system (which is Debian). How can I fix it?|Cron is not working…]]<br />
<br />
|Signature=daniel_hozac & Beuc & Paweł Wilk}}<br />
<br />
{{Question<br />
|Question=Cron is not working on my guest system (which is Debian). How can I fix it?<br />
||Details=On a guest system the cron daemon may not work properly. When looking into the log file (e.g. <tt>/var/log/syslog</tt>) the following message may appear repeatedly:<br />
CRON[xxxxx]: Permission denied<br />
<br />
Similar thing may happen with the <tt>su</tt> when trying to execute a command as root.<br />
<br />
It's not the problem in Cron but in the pam_limits module on a guest system (see [[Frequently_Asked_Questions#When using nice and su (for example, in the updatedb cron job), I get: su: Permission denied. What does it mean?|FAQ:When using nice and su…]] for more information about the cause).<br />
<br />
There are 4 ways to solve or work-around this problem:<br />
<br />
'''1. Allowing guests to reset resource limits:'''<br />
<br />
It's clean solution but you may expect some guest processes increasing their limits because not everything is controlled by PAM. It also breaks centralized resources limiting approach so a guest can do bad things that may cause other guests and host to be overloaded and unresponsive.<br />
<br />
To apply it you have to add <tt>CAP_SYS_RESOURCE</tt> flag to <tt>/etc/vservers/<server name>/bcapabilities</tt> (2.6 kernels).<br />
<br />
See [[util-vserver:Capabilities_and_Flags|Capabilities and Flags]] for more information.<br />
<br />
'''2. Disabling pam_limits on a guest systems:'''<br />
<br />
This workaround is easy and works fine when your guest systems aren't really multiuser but rather service boxes. It disables setting of the resource limits by PAM so the limits can only be set globally for the whole guest (using rlimits or cgroups on a host) but never increased inside of the guest system.<br />
<br />
To apply it just enter the guest and edit the files listed below, commenting out any line containing <tt>pam_limits</tt>:<br />
<br />
/etc/pam.d/su<br />
/etc/pam.d/sudo<br />
/etc/pam.d/cron<br />
<br />
You can also use this one-liner on a guest:<br />
<br />
<pre><br />
/bin/sed --in-place -e "s/^\s\?session.*pam_limits.so.*/\#\0/g" /etc/pam.d/{su,sudo,cron}<br />
</pre><br />
<br />
'''3. Allowing guest's pam_limits to set limits when possible:'''<br />
<br />
This workaround allows you to have working <tt>pam_limits</tt> inside a guest system and global limits set by a host system. What's the catch? The problematic PAM module won't fully work for the root user on a guest system as expected and there might appear some PAM's warnings in guest's <tt>auth.log</tt>. Since using pam_limits to limit regular user processes is far more frequent than using it to limit root processes, this solution may be a good compromise. It is about setting a proper limits in pam_limits configuration and about setting this PAM module in a way that its function is optional (instead of required). The last change makes PAM to continue with session even if pam_limits encounters some error during setting limits (it usually applies to superuser sessions).<br />
<br />
The not so nice news is that there might be a need of keeping guest's limits configuration up to date according to limits globally set for a guest. The limits set in pam_limits configuration file(s) shouldn't be higher (lower in case of nice value) than global guest's limits.<br />
<br />
To apply it enter the guest and edit the files listed below, replacing occurences of <tt>required</tt> by <tt>optional</tt> in the lines containing <tt>pam_limits</tt>:<br />
<br />
/etc/pam.d/su<br />
/etc/pam.d/sudo<br />
/etc/pam.d/cron<br />
<br />
For example:<br />
<br />
# Sets up user limits, please define limits for cron tasks<br />
# through /etc/security/limits.conf<br />
session optional pam_limits.so<br />
<br />
Then on a guest system create the file <tt>/etc/security/limits.d/01-fixpam.conf</tt> containing:<br />
<br />
<pre><br />
* - priority X # replace X with your guest's nice value <br />
</pre><br />
<br />
You can automate this process to happen automagically for any guest by creating the startup script named <tt>/etc/vservers/.defaults/scripts/post-start.d/01-pamfix</tt>:<br />
<br />
<pre><br />
#!/bin/sh<br />
<br />
# This script tries to fix pam_limits entries<br />
# to make it possible for PAM in a guest system to<br />
# set its own limits.<br />
<br />
PAM_DIR="etc/pam.d"<br />
PAM_SERVICES="su sudo cron"<br />
LIMITS_FILE="etc/security/limits.d/01-pamfix.conf"<br />
<br />
vname="$2"<br />
[ -z "$vname" ] && exit 0<br />
<br />
vcfg=$( /usr/sbin/vserver-info "$vname" CFGDIR )<br />
[ ! -d "$vcfg" ] && exit 0<br />
<br />
for s in $PAM_SERVICES<br />
do<br />
pamfile="${PAM_DIR#\/}/$s"<br />
[ -f "$pamfile" ] && /bin/sed --in-place -e "s/\(^\s\?session.*\)required\(.*pam_limits.so.*\)/\1optional\2/g" "$pamfile"<br />
done<br />
<br />
[ ! -f "${vcfg}/nice" ] && exit 0<br />
nval=$( /usr/bin/head -1 "${vcfg}/nice" )<br />
[ -n "$nval" ] && echo "* - priority $nval # (added by vserver startup script)" > "${LIMITS_FILE#\/}"<br />
<br />
exit 0<br />
</pre><br />
<br />
'''4. Disabling resource limits for a guest:'''<br />
<br />
It easy, clean and… unsafe solution. You just have to not set resource limits (e.g. priority, nice value) for a guest or set the nice value limit to 0 on a host system. Resetting it later by guest's <tt>pam_limits</tt> will not generate an error.<br />
<br />
|Signature=Paweł Wilk}}<br />
<br />
{{Question<br />
|Question=How do I handle NFS mounts within in a guest?<br />
||Details=There are at least four ways.<br />
<br />
In any case, you probably want to force the nfs version to 3 or lower to avoid id mapping issues (one symptom of having an id mapping issue is that <tt>no_root_squash</tt> appears to be ignored). You can check whether the mount uses nfsv4 by looking at <tt>/proc/mounts</tt> inside the guest. You can force the protocol version to 3 by passing the mount options <tt>nfsvers=3,mountvers=3</tt>.<br />
<br />
'''1)''' Mount the NFS share from the host OS and let vserver guest access it as part of it's file system.<br />
<br />
''mount --bind'' may also be beneficial in this scenario.<br />
<br />
'''2)''' Use util-vserver and create a ''fstab.remote'' file in the /etc/vserver/<vserver_name> directory. Populate this with the NFS shares and they will be mounted in the context of the vserver guest.<br />
<br />
See http://www.nongnu.org/util-vserver/doc/conf/configuration.html<br />
<br />
Note that as of 0.30.216-pre3000 and kernel 3.0.4-vs2.3.1-pre10.1, the mount request will appear to originate from the IP of the host, not the guest. It is unclear (to [[User:KornAndras|Guy-]]) whether this is a bug.<br />
<br />
'''3)''' Add capabilities to the vserver guest instance to grant sufficient rights to allow NFS mounts.<br />
<br />
Add the following to /etc/vserver/<vserver_name>/bcapabilities<br />
SYS_ADMIN<br />
Add the following to /etc/vserver/<vserver_name>/ccapabilities<br />
SECURE_MOUNT<br />
BINARY_MOUNT<br />
<br />
See [[Capabilities_and_Flags]] for more information about vserver capabilities.<br />
<br />
If you want the NFS shares to be mounted when the guest starts, add them to /etc/vserver/<vserver_name>/fstab.<br />
<br />
'''4)''' Before starting the guest, make a directory of the host "shared" using <tt>mount --make-shared /path/to/dir</tt>, then set up autofs to mount nfs shares under <tt>/path/to/dir/sharename</tt>.<br />
<br />
rbind mount subdirectories of <tt>/path/to/dir</tt> in the guest from its fstab.<br />
<br />
This setup is good if the nfs shares are not often needed, and especially if they're occasionally needed by more than one guest. (As of September 2011, running autofs inside a vserver guest didn't work for me. --[[User:KornAndras|Guy-]] 01:05, 30 October 2011 (UTC))<br />
<br />
||Signature=martindk}}<br />
<br />
<br />
{{Question<br />
|Question=vserver start/stop/enter fails with something like "vnamespace: execvp("/usr/sbin/vserver"): No such file or directory" ?<br />
||Details=Check whether ''/usr'' is mounted in the namespace you are working with.<br />
<pre>vnamespace -e <guest> cat /proc/mounts</pre><br />
If there is no ''/usr'', you can fix your problem with simply mounting it using the following command:<br />
<pre>vnamespace -e <guest> mount /dev/<device> /usr</pre><br />
<br />
||Signature=sim0n}}<br />
<br />
{{Question<br />
|Question=The command vserver <$server> start gives '/etc/init.d/rc: line 74: /etc/default/rcS: No such file or directory', what do I do? <br />
||Details=The vserver has not been correctly installed, this has several reasons<br />
check your install log and it should tell you something about that your server didn't get installed properly<br />
* use stable distribution of debian as server (debootstrap may be different over the versions)<br />
* deny_mount, deny_caps and deny_pivot should be off if your running grsec.<br />
<br />
||Signature=Dude}}<br />
<br />
<br />
{{Question<br />
|Question=How could I rename a vserver directory?<br />
||Details=Please note : this procedure renames the '''directory''', not the '''hostname''' !<br />
#Stop the vserver in question<br />
#rename the <tt>/vservers/<server name></tt> directory<br />
#rename the <tt>/etc/vservers/<server name></tt> directory<br />
#update link: <tt>/etc/vservers/<server name>/run</tt> → <tt>/var/run/vservers/<server name></tt><br />
#update link: <tt>/etc/vservers/<server name>/vdir</tt> → <tt>/etc/vservers/.defaults/vdirbase/<server name></tt><br />
#update link: <tt>/etc/vservers/<server name>/cache</tt> → <tt>/etc/vservers/.defaults/cachebase/<server name></tt><br />
#update link: <tt>/var/run/vservers.rev/<server XID></tt> → <tt>/etc/vservers/<server name></tt><br />
#Start the vserver in question. It should start properly.<br />
<br />
|Signature=FlorianD (from ''hillct'' page in old wiki)}}<br />
<br />
<br />
{{Question<br />
|Question=what if i see my vserver in vserver-stat but with no name ?<br />
||Details=the link in /var/run/vservers is missing<br />
Just do a : cat /etc/vservers/<guest>/context > /var/run/vservers/<guest><br />
check that the <guest> is the good one by using vuname --get --xid <context> with the context you have in the vserver-stat listing.<br />
|Signature=IrcQuestions}}<br />
<br />
== Upgrade from 2.0 to 2.2 ==<br />
<br />
{{Question<br />
|Question=I now get errors like "ncontext: vc_net_create(): Invalid argument; dynamic contexts disabled." on startup. Vservers are not started<br />
||Details=Dynamic context are disabled by default and are deprecated. For example, tagxid and network checks won't be useable with dynamic ids. Now you should manually assign a explicit context to your vservers, like<br />
echo 101 > /etc/vservers/myvserv/context<br />
ADDENDUM: please consider that valid static contexts are between 2 and 49151 ( daniel_hozac on IRC ) otherwise you will end up with unexplainable error "ncontext: vc_net_migrate(): No such process" when trying to start the vserver.<br />
<br />
|Signature=daniel_hozac&Beuc}}<br />
<br />
<br />
{{Question<br />
|Question=How do I assign a static context to an existing vserver?<br />
||Details=Simple ;) See the answer above. <br />
|Signature=gcc}}<br />
<br />
<br />
{{Question<br />
|Question=Since upgrading to a newer VS version my guest complains about "vsched: non-numeric value specified for '--priority_bias" at start time. What's wrong?<br />
||Details=The scheduler paramters changed.You can use this (ugly) script to convert them or do it by hand:<br />
<pre><br />
# cat /usr/local/sbin/vserver-convert-schedule-to-scheddir<br />
#/bin/sh<br />
mkdir /etc/vservers/$1/sched<br />
sed -e 1p -n /etc/vservers/$1/schedule > /etc/vservers/$1/sched/fill-rate<br />
sed -e 2p -n /etc/vservers/$1/schedule > /etc/vservers/$1/sched/interval<br />
sed -e 3p -n /etc/vservers/$1/schedule > /etc/vservers/$1/sched/tokens<br />
sed -e 4p -n /etc/vservers/$1/schedule > /etc/vservers/$1/sched/tokens-min<br />
sed -e 5p -n /etc/vservers/$1/schedule > /etc/vservers/$1/sched/tokens-max<br />
<br />
mv /etc/vservers/$1/schedule /etc/vservers/$1/schedule.converted.see.scheddir<br />
<br />
# see: http://oldwiki.linux-vserver.org/Scheduler+Parameters<br />
# see: http://www.nongnu.org/util-vserver/doc/conf/configuration.html#sched<br />
</pre><br />
||Signature=derjohn}}<br />
<br />
<br />
{{Question<br />
|Question=Since upgrading to a newer VS version my guest doesn't have the amount of shared memory (SHM / SHMMAX / SHMALL ) as it had in the former version. What changed?<br />
||Details=Every VS version that runs on a kernel >= 2.6.19 offers sysctl values per guest. This has to do with the 'ipc namespace' feature that was added to the mainline kernel in version 2.6.19. Linux-VServer uses that feature to give each guest a separate 'ipc namespace' and thus 'own' sysctl values per guest. Because shmmax is such a sysctl value, you have to set it per guest.<br />
Here is an example how to do so:<br />
<br />
<pre><br />
# mkdir /etc/vservers/<vserver>/sysctl/0 -p<br />
# echo kernel.shmall > /etc/vservers/<vserver>/sysctl/0/setting<br />
# echo 134217728 > /etc/vservers/<vserver>/sysctl/0/value<br />
# mkdir /etc/vservers/<vserver>/sysctl/1 -p<br />
# echo kernel.shmmax > /etc/vservers/<vserver>/sysctl/1/setting<br />
# echo 134217728 > /etc/vservers/<vserver>/sysctl/1/value<br />
</pre><br />
It's also explained on the geat flower page:<br />
# see: http://www.nongnu.org/util-vserver/doc/conf/configuration.html -> Look for "sysctl".<br />
<br />
After changing those values, restart your guest, enter it and check if the values are set:<br />
<pre><br />
# sysctl -a | grep shm<br />
...<br />
kernel.shmall = 134217728<br />
kernel.shmmax = 134217728<br />
</pre><br />
<br />
To change a value for a running guest, on the host use:<br />
<pre><br />
vspace -e CONTEXTID --ipc sysctl -w kernel.shmall=134217728<br />
vspace -e CONTEXTID --ipc sysctl -w kernel.shmmax=134217728<br />
</pre><br />
<br />
||Signature=derjohn<br />
}}<br />
<br />
[[Category:Community]]<br />
[[Category:Categories]]</div>KornAndrashttp://wiki.linux-vserver.org/Frequently_Asked_QuestionsFrequently Asked Questions2011-10-30T01:05:01Z<p>KornAndras: extend nfs bit</p>
<hr />
<div><div style="margin: 2em auto 2em auto; padding: 10px; background-color: #F9ECCD; border: 1px solid #004433; text-align: center;"><br />
[[Image:Icon-Caution.png|left]]<br />
We currently migrate to MediaWiki from our old installation, but not all content has been migrated yet. Take a look at the [[Wiki Team]] page for instructions how to help or look at the [http://oldwiki.linux-vserver.org old wiki] to find the information not migrated yet.<br />
<br />
'''To ease migration we created a [[List of old Documentation pages]].'''<br />
</div><br />
<br />
CURRENTLY THE CONTENT OF THE OLD WIKI FAQ (AND MORE) IS BEING MIGRATED TO THIS PAGE (TASK: DERJOHN)<br />
<br />
<br />
__TOC__<br />
<br />
== General ==<br />
<br />
{{Question<br />
|Question=What is the status of Linux-VServer?<br />
||Details=Linux-VServer has more than a decade of maturity and is actively developed. Two projects are similar to Linux-VServer, [[http://lxc.sf.net LXC]], and [[http://openvz.org OpenVZ]]. Of the two, OpenVZ is the more mature and offers some similar functionality to Linux-VServer. LXC is solely based on the kernel mechanisms such as cgroups that are present in modern kernels. These kernel mechanisms will continue to be refined and isolation will mature. As that occurs, Linux-VServer will take advantage of those new features separately from LXC and continue to provide the same robust user interface that it does currently. Currently, LXC offers significantly less functionality and isolation than Linux-vserver. LXC will eventually be a robust wrapper around kernel mechanisms but is still under heavy development and not considered ready for production use.<br />
|Signature=beck}}<br />
<br />
<br />
<br />
{{Question<br />
|Question=What is a 'Guest'?<br />
||Details=To talk about stuff, we need some naming. The physical machine is called 'Host' and the 'main' context running the Host Distro is called 'Host Context'. The virtual machine/distro is called 'Guest' and basically is a Distribution (Userspace) running inside a 'Guest Context'.<br />
|Signature=derjohn}}<br />
<br />
<br />
{{Question<br />
|Question=What kind of Operating System (OS) can I run as guest?<br />
||Details= With VServer you can only run Linux guests. The trick is that a guest does not run a kernel on its own (as XEN and UML do), it merely uses a virtualized host kernel-interface. VServer offers so called security contexts which make it possible to separate one guest from each other, i.e. they cannot get data from each other. Imagine it as a chroot environment with much more security and features.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=Is this a new project? When was it started?<br />
||Details=The first public occurrence of Linux-VServer was Oct 2001. The initial mail can be found here: http://www.cs.helsinki.fi/linux/linux-kernel/2001-40/1065.html<br />
So you can expect a mature software product which does its magic quite well (And hey, we have a version > 2.0!)<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=Which distributions did you test?<br />
||Details=Some. Check out the wiki for ready-made guest images. But you can easily build own guest images, e.g. with Debian's debootstrap. Checkout [[Building Guest Systems]] how to do that.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=Is VServer comparable to XEN/UML/QEMU?<br />
||Details=Nope. XEN/UML/QEMU and VServer are just good friends. Because you ask, you probably know what XEN/UML/QEMU are. VServer in contrary to XEN/UML/QEMU does not "emulate" any hardware you run a kernel on. The purpose of Linux VServer is to isolate (groups of) applications. The isolation is done by the kernel (see [[Overview]] for a more detailed comparison). You can run a VServer kernel in a XEN/UML/QEMU guest. This is confirmed to work at least with Linux 2.6/vs2.0.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=With which version should I begin?<br />
||Details=If you are new to VServer I recommend to try the latest stable kernel patch, and the latest util-vserver "alpha" release.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=Is VServer secure?<br />
||Details=We hope so. It should be as least as secure as Linux is. We consider it much much more secure though.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=Performance?<br />
||Details=For a single guest, we basically have native performance. Some tests showed insignificant overhead (about 1-2%) others ran faster than on an unpatched kernel. This is IMVHO significantly less than other solutions waste, especially if you have more than a single guest (because of the resource sharing).<br />
|Signature=derjohn}}<br />
<br />
<br />
{{Question<br />
|Question=What is the "great flower page"?<br />
||Details=Well, [http://www.nongnu.org/util-vserver/doc/conf/configuration.html this page] contains all configuration options for util-vserver. The name of the page is derived from the stylesheet(s) it contains.<br />
|Signature=derjohn}}<br />
<br />
<br />
<br />
== Resources usage ==<br />
<br />
{{Question<br />
|Question=Resource sharing?<br />
||Details=Yes ....<br />
* memory: Dynamically.<br />
* CPU usage: Dynamically (token bucket)<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=Resource limiting?<br />
||Details=You can put limits per guest on different subsystems.<br />
* using ulimits and rlimits (rlimit is a new feature of kernel 2.6/vs2.0.) per guest, to limit the memory consumption, the number of processes or file-handles, ... : see [[Resource Limits]]<br />
* CPU usage : see [[CPU Scheduler]]<br />
* disk space usage : see [[Disk Limits and Quota]]<br />
Note that you can only offer guaranteed resource availability with some ticks at the time.<br />
|Signature=derjohn&xm}}<br />
<br />
{{Question<br />
|Question=How do I limit a guests RAM? I want to prevent OOM situations on the host!<br />
||Details=First you can read [http://linux-vserver.org/Memory+Allocation] and [[Memory Limits]].<br />
If you want a recipe, do this:<br />
# Check the size of memory pages. On x86 and x86_64 is usually 4 KB per page. (on linux "getconf -a|grep PAGE" will give you the information)<br />
# Create /etc/vserver/<guest>/rlimits/<br />
# Check your physical memory size on the host, e.g. with "free -m". maxram = kilobytes/pagesize.<br />
# Limit the guests physical RAM to value smaller then maxram:<pre>echo %%insertYourPagesHereSmallerThanMaxram%% > /etc/vserver/<guest>/rlimits/rss </pre><br />
# Check your swapspace, e.g. with 'swapon -s'. maxswap = swapkilobytes/pagesize.<br />
# Limit the guest's maximum number of as pages to a value smaller than (maxram+maxswap): <pre> echo %%desiredvalue%% > /etc/vserver/<guest>/rlimits/as </pre><br />
# Correctly display the memory information inside the guest:<pre>echo "VIRT_MEM" >> /etc/vservers/<guest>/flags</pre><br />
It should be clear this can still lead to OOM situations. Example: You have two guests and your as limit per guest is greater than 50% of (maxram+maxswap). If both guests request their maximum at the same point in time, there will be not enough mem .....<br />
|Signature=derjohn}}<br />
<br />
<br />
{{Question<br />
|Question=Disk I/O limiting? Is that possible?<br />
||Details=Well, since vs2.1.1 Linux-VServer supports a mechanism called 'I/O scheduling', which appeared in the 2.6 mainline some time ago. The mainline kernel offers several I/O schedulers:<br />
<pre><br />
# cat /sys/block/hdc/queue/scheduler<br />
noop [anticipatory] deadline cfq<br />
</pre><br />
<br />
The default since 2.6.18 in Sept 2006 is CFQ, described below, and prior to that was anticipatory a.k.a. "AS" ([[http://en.wikipedia.org/wiki/CFQ#Kernel_2.6.18_.2820_September_2006.29 Wikipedia]]). When running several guests on a host you probably want the I/O performance shared in a fair way among the different guests. The kernel comes with a "completely fair queueing" scheduler, CFQ, which can do that. (More on schedulers can be found at http://lwn.net/Articles/114770/)<br />
This is how to set the scheduler to "cfq" manually:<br />
<pre><br />
root# echo "cfq" > /sys/block/hdc/queue/scheduler<br />
root# cat /sys/block/hdc/queue/scheduler<br />
noop anticipatory deadline [cfq]<br />
</pre><br />
Keep in mind that you have to do it on all physical discs. So if you run an md-softraid, do it to all physical /dev/hdXYZ discs!<br />
If you run Debian there is a predefined way to set the /sys values at boot-time:<br />
<pre><br />
# apt-get install sysfsutils<br />
[...]<br />
<br />
# grep cfq /etc/sysfs.conf<br />
block/sda/queue/scheduler = cfq<br />
block/sdc/queue/scheduler = cfq<br />
<br />
# /etc/init.d/sysfsutils restart<br />
</pre><br />
<br />
For non-vserver processes and CFQ you can set by which key the kernel decides about the fairness:<br />
<pre><br />
cat /sys/block/hdc/queue/iosched/key_type<br />
pgid [tgid] uid gid<br />
</pre><br />
Hint: The 'key_type'-feature has been removed in the mainline kernel recently. Don't look for it any longer :(<br />
<br />
The default is tgid, which means to share fairly among process groups. Think every guest is treated like a own process group. It's not possible to set a scheduler strategy within a guest. All processes belonging to the same guest are treated like "noop" within the guest. So: If you run apache and some ftp-server within the _same_ guest, there is no fair scheduling between them, but there is fair scheduling between the whole guest and all other guests.<br />
<br />
And: It's possible to tune the scheduler parameters in several ways. Have a look at /sys/block/hdc/queue/....<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=Nice disk I/O scheduling, is that possible?<br />
||Details=Well, since linux 2.6.13 processess have another priority next to the cpu nice scheduling hint, it's called io nice.<br />
It's split into three groups, called real-time, best effort and idle. The default is best-effort, but within best-effort, you can have a niceness from 0 to and including 7.<br />
You can set this niceness by the tool ionice, which for debian is either in the package util-linux or schedutils.<br />
To change the io-niceness you need the <tt>CAP_SYS_NICE</tt>, '''and''' need to have the same uid as the processe you want to ionice.<br />
<br />
:'''Note:''' If you want to use any schedulung other than best-effort you will also need the <tt>CAP_SYS_ADMIN</tt>-flag. Be warned that this gives quite some capabilities to the vserver, not just for I/O scheduling!<br />
<br />
If you want to increase the niceness of an I/O hogging process within a vserver you need to do:<br />
<PRE><br />
chcontext --xid sponlp1 sudo -u '#2089' ionice -c2 -n5 -p24409<br />
</PRE><br />
with sudo and ionice installed on the root server to increase the *nice*ness of pid 24409, with uid 2089<br />
|Signature=Groteblup}}<br />
<br />
== Unification ==<br />
<br />
{{Question<br />
|Question=What is unification (vunify)?<br />
||Details=[[Unification]] is Hard Links on Steroids. Guests can 'share' common files (usually binaries and libraries) in a secure way, by creating hard links with special properties (immutable but unlinkable (removable)). The tool to identify common files and to unify them is called [[vunify]].<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=What is [[vhashify]]?<br />
||Details=The successor of [[vunify]], a tool which does unification based on hash values (which allows to find common files in arbitrary paths.)<br />
It creates hardlinks to files named after a hash of the content of the file. If you have a recent version of the vserver patch (2.2+), with CONFIG_VSERVER_COWBL enabled, you can even modify the hardlinked files inside the vservers and the links will be broken automatically.<br />
There seems to be a catch when a hashified file has multiple hardlinks inside a guest, or when another internal hardlink is added after hashification. Link breaking will remove all the internal hardlinks too, so the guest will end up with different copies of the original file. The correct solution would be to not hashify files that have multiple links prior to hashification, and to break the link to the hashified version when a new internal hardlink is created. Apparently, this is not implemented yet (?).<br />
|Signature=Guy-}}<br />
<br />
{{Question<br />
|Question=How do I manage a multi-guest setup with vhashify?<br />
||Details=For '[[vhashify]]', just do these once:<br />
<pre><br />
mkdir /etc/vservers/.defaults/apps/vunify/hash /vservers/.hash<br />
ln -s /vservers/.hash /etc/vservers/.defaults/apps/vunify/hash/root<br />
</pre><br />
Then, do this one line per vserver:<br />
<pre><br />
mkdir /etc/vservers/<vservername>/apps/vunify # vhashify reuses vunify configuration<br />
</pre><br />
To hashify a running vserver, do (possibly from a cronjob):<br />
<pre><br />
vserver name-of-guest hashify<br />
</pre><br />
<br />
The guest needs to be running because vhashify tries to figure out what files not to hashify by calling the package manager of the guest via <tt>vserver enter</tt>.<br />
<br />
In order for the OS cache to benefit from the hardlinking, you'll have to restart the vservers.<br />
<br />
To clean up hashified files that are no longer referenced by any vserver, do (possibly from a cronjob):<br />
<pre><br />
find /vservers/.hash -type f -links 1 -print0 | xargs -0 rm<br />
</pre><br />
<br />
Until you do this, the files still take up place even though no vservers need them.<br />
|Signature=Guy-}}<br />
<br />
== Filesystem usage ==<br />
<br />
{{Question<br />
|Question=Is there a way to implement "user/group quota" per VServer?<br />
||Details=Yes, but not on a shared partition for now. You need to put the guest on a separate partition, setup a vroot device (to make the quota access secure), copy that into the guest, and adjust the mtab line inside the guest. If 8 vroot device is not enough for you, you can add more with the kernel parameter max_vroot (exemple for built in kernel vroot /vmlinuz-2.6.31.6-vs2.3.0.36.26aq root=/dev/md1 ro max_vroot=20 ). If vroot is a module you'd actually want to put for exemple "options vroot max_vroot=20" in /etc/modprobe.conf and then just do modprobe vroot<br />
|Signature=derjohn,gadnet}}<br />
<br />
{{Question<br />
|Question=What about "Quota" for a context? Howto limit disk usage?<br />
||Details=Context quotas are now called Disk Limits (so that we can tell them apart from the user/group quotas :). They are supported out of the box (with vs2.0+) for all major filesystems (ext2/3, ReiserFS, JFS). You need to tag the FS with XID (see below). Please read [[Disk Limits and Quota]] for more information.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=How do I tag a guest's directory with xid?<br />
||Details=Tagging the guest's files gives you several advantages, e.g. the accounting will work properly.<br />
Filesystem XID tagging only works on supported filesystem. Those are currently: ext2/3, reiserfs/reiser3, xfs and jfs.<br />
To activate the XID tagging you have to mount the filesystem with "-o tag" (former tagxid is outdated since VS2.2). Attention: It's _not_ possible to "-o remount,tag", you have to mount it freshly. The guests will tag their files automatiaclly. If you copy files in from the host, you have to tag them manually like this:<br />
<pre><br />
chxid -c xid -R /var/lib/vservers/<guest><br />
</pre><br />
Note: Context 0 and 1 will see all files, guests will only be able to access untagged files and their own XID. They can see other XID files but no information about the file, e.g. no owner, no group, no permissions.<br />
Note: It is not advised to tag the root filesystem, as [http://www.paul.sladen.org/vserver/archives/200602/0020.html explained by Herbert] : trying to do so will expose you to some troubles !<br />
|Signature=derjohn_and_gonzo_and_are}}<br />
<br />
{{Question<br />
|Question=How can I copy anything from host to guest partition, normally unvisible on host?<br />
||Details=You should just change namespace, e.g.:<br />
<pre><br />
vnamespace --enter <xid> -- /bin/bash<br />
</pre><br />
and then use standard cp or rsync programs.<br />
|Signature=SergiuszPawlowicz}}<br />
<br />
{{Question<br />
|Question=Why is the barrier attribute disappearing on reiserfs filesystem after umount or host reboot?<br />
||Details=The filesystem has to be mounted with explicitly defining the 'attrs' option, i.e. <br />
<pre><br />
mount /dev/reiserfsdev /vservers -oattrs<br />
setattr --barrier /vservers<br />
</pre><br />
to get the barrier survive after umount/reboot.<br />
|Signature=Nikolay Kichukov}}<br />
<br />
== Network ==<br />
<br />
{{Question<br />
|Question=Does it support IPv6?<br />
||Details=Currently it requires an additional patch, but the functionality should be available in 2.3+ soon. [[IPv6]] has more information.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=I can't do all I want with the network interfaces inside the guest?<br />
||Details=For now the networking is 'Host Business' -- the host is a router, and each guest is a server. You can set the capability ICMP_RAW in the context of the guest, or even the capability CAP_NET_RAW (which would even allow to sniff interfaces of other guests!). Likely to change with ngnet.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=How do I add several IPs to a vserver?<br />
||Details=First of all a single guest vserver only supports up to 16 IPs (There is a 64-IP patch available, which is in "derjohn's kernel").<br />
<pre><br />
Update from IRC (2011-08-22):<br />
<mmouse> quick question: what is the maximum count of IPs (v4) I can have in a single guest?<br />
<daniel_hozac> unlimited.<br />
</pre><br />
<br />
Here is a little helper-script that adds a list of IPs defined in a text file, one per line.<br />
<pre><br />
#!/bin/bash<br />
j=1<br />
for i in `cat myiplist`; do<br />
j=$(($j+1))<br />
mkdir $j<br />
echo $i > $j/ip<br />
echo "24" > $j/prefix<br />
done<br />
</pre><br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=How do I assign a new IP address to a running guest?<br />
||Details=This is done from the host server:<br />
* add the ip on the host, for example<br />
<pre><br />
ip addr add 194.169.123.23/24 dev eth0 <br />
</pre><br />
* add the ip to the guest's network context (a guests NID is the same as the XID {context ID})<br />
<pre><br />
naddress --add --nid <nid> --ip 194.169.123.23/24 <br />
</pre><br />
* enter the guest (best via ssh) <br />
* restart the services that need to make use of the new address if required <br />
* update the config in ''/etc/vserver/<servername>/interfaces'' to reflect the changes for the next guest restart (if desired)<br />
|Signature=BenjaminGreen}}<br />
<br />
{{Question<br />
|Question=If my host has only one a single public IP, can I use RFC1918 IP (e.g. 192.168.foo.bar) for the guest vservers?<br />
||Details=Yes, use iptables with SNAT to masquerade it. <br />
<pre><br />
iptables -t nat -I POSTROUTING -s $VSERVER_NETZ ! -d $VSERVER_NETZ -j SNAT --to $EXT_IP<br />
</pre><br />
See: [[HowtoPrivateNetworking]] and <br />
http://www.tgunkel.de/it/software/doc/linux_server.en#h3-VServer_Masquerading_SNAT (THX, [MUPPETS]Gonzo)<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=If I shut down my vserver guest, the whole Internet interface ethX on the host is shut down. What happened?<br />
||Details=When you shut down a guest (''i.e. vserver foo stop''), the IP is brought down on the host also. If this IP happens to be the primary IP of the host, the kernel will not only bring down the primary IP, but also all secondary IP addresses. But in very recent kernels, there is an option ''settable'' which prevents that nasty feature. It's called "alias promotion". You may set it via sysctl by adding ''net.ipv4.conf.all.promote_secondaries=1'' in /etc/sysctl.conf or via sysctl command line.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=Can I run an OpenVPN Server in a guest?<br />
||Details=<br />
Yes. To get a OpenVPN Server running in a guest, all networking setup has to be done on the host. This answer describes the common case and shows some pitfalls, for detailled information about OpenVPN, please consult the appropriate documentation on the OpenVPN homepage.<br />
This is the minimal OpenVPN configuration for the Server which will be used to demonstrate how to get it running in a client:<br />
<pre><br />
# Networking setup<br />
server 192.168.16.0 255.255.255.0<br />
dev tun16<br />
ifconfig-noexec<br />
comp-lzo<br />
# Certificates<br />
dh ...<br />
ca ...<br />
cert ...<br />
key ...<br />
# Management<br />
persist-key<br />
keepalive 10 60<br />
verb 4<br />
</pre><br />
First of all you have to prepare the host with a persistent interface in the right mode and with the right settings. This is easily done by using openvpn and the ip and route tools.<br />
<pre><br />
# openvpn --mktun --dev tun16<br />
# ip link set dev tun16 txqueuelen 100<br />
# ifconfig tun16 192.168.16.1 pointopoint 192.168.16.2 mtu 1500<br />
# route add -net 192.168.16.0 netmask 255.255.255.0 gw 192.168.16.2<br />
</pre><br />
If you need different settings, openvpn will tell you the ifconfig and route commands it uses to configure the interface when being started on the host with the original config file, but without ifconfig-noexec.<br />
Additionally, the guest needs /dev/net/tun to make OpenVPN happy. This can be created with MAKEDEV:<br />
<pre><br />
# cd /var/lib/vserver/<myopenvpnserver>/dev/<br />
# ./MAKEDEV tun<br />
(creates the dev/net/tun device accessible by the guest - even a tap interface needs /dev/net/tun !)<br />
</pre><br />
Finally, the guest needs to have the tun device assigned:<br />
<pre><br />
# head /etc/vservers/<myopenvpnserver>/interfaces/1/*<br />
==> /etc/vservers/<myopenvpnserver>/interfaces/1/ip <==<br />
192.168.16.1<br />
<br />
==> /etc/vservers/<myopenvpnserver>/interfaces/1/nodev <==<br />
tun16<br />
<br />
==> /etc/vservers/<myopenvpnserver>/interfaces/1/prefix <==<br />
24<br />
#<br />
</pre><br />
The client's conf may look like that:<br />
<pre><br />
# Basic setup<br />
client<br />
proto tcp-client<br />
dev tun<br />
remote <ipaddress><br />
comp-lzo<br />
verb 4<br />
<br />
# Certificate<br />
ca ...<br />
</pre><br />
<br />
[ Based on derJohn's original answer, all errors mine ] <br />
|Signature=DavidS}}<br />
<br />
{{Question<br />
|Question=Trying to connect to a vserver from the host or another vserver on the same host fails<br />
||Details=strace shows<br />
<pre> <br />
sin_addr=inet_addr("xx.xx.xx.xx")}, yy) = -1 EINVAL (Invalid argument)<br />
</pre><br />
A: The host/guest cannot communicate with another guest on same host.<br />
* check all netmasks on all interfaces (do they overlap) ?<br />
* check policy routing (disable it temporary) ?<br />
* check that lo is up (Networking within a host/guest always uses lo interface)<br />
|Signature=CommonProblems}}<br />
<br />
{{Question<br />
|Question=Can I use iptables ?<br />
||Details=Yes but right now only on the host (rootserver). Please realize that all traffic is local and will not touch the forward chain.<br />
<br>If you really, really, really need iptables on the guest and you are aware about loosing a big part of VServer isolation and security you could add the NET_ADMIN capability. Consider writing wrappers to manage iptables on the host instead.<br />
|Signature=_are_}}<br />
<br />
{{Question<br />
|Question=Is it possible to prevent guest from bringing down primary ip?<br />
||Details=Yes. Remove /etc/vservers/<guest>/interfaces/X/dev, and touch /etc/vservers/<guest>/interfaces/X/nodev<br />
|Signature=Daniel&Serge}}<br />
<br />
{{Question<br />
|Question=Is it possible to provide a different MAC address per vServer?<br />
||Details=Short answer - yes but it's a hassle.<br />
<br />
Real answer from '''_are_''':<br />
<pre><br />
When I once needed 'real' seperate MAC-addresses I used TAP-devices and VDE2 ([http://vde.sourceforge.net/ Virtual Distributed Ethernet]).<br />
Basically vServer is an isolation of existing resources, not a virtualization of 'new' devices.<br />
Without extra fuss you can't add a 'new' network interface to a vServer, no matter if it is eth* or tap*, you always add it to the host and give the vServer access to it.<br />
I got the TAP+VDE2 up and running, but I think it is too much trouble for basically the simple adding of IPs to a vServer unless you really need the MAC address separate.<br />
</pre><br />
<br />
<br />
You can also utilize MACVLAN ability from kernel.<br />
I.e. create ''macvlan0'' interface with:<br />
<pre>ip link add link eth0 address 00:19:d1:29:d2:58 macvlan0 type macvlan</pre><br />
[[http://jim.studt.net/depository/index.php/notes-on-linux-s-macvlan-module Reference]]<br />
|Signature=bobnormal&swenTjuln<br />
}}<br />
<br />
{{Question<br />
|Question=Is it possible to hide packet counters on the host network interface from vServer guests?<br />
||Details=Yes, see [[Networking_vserver_guests|Networking vServer Guests]]<br />
|Signature=bobnormal}}<br />
<br />
{{Question<br />
|Question=Services won't bind to 127.0.0.1 when I configure them to bind to all available IPs / (binding service to * doesn't bind to loopback)?<br />
||Details=You've configured single public IP and have kernel option "Linux VServer -> Automatic Single IP Special Casing" enabled.<br />
It means somehow "optimized" :D<br />
If you don't want this you have 3 possible solutions (quoting Bertl):<br />
* disable the auto single IP in the kernel<br />
* assign more than one IP to the guest<br />
* disable single ip special casing for that guest<br />
<br />
The later is done by : echo "~single_ip" >> /etc/vservers/<VSERVER>/nflags<br />
At runtime to avoid restarting the vserver: nattribute --set --nid <guest> --flag ~single_ip<br />
|Signature=swenTjuln}}<br />
<br />
== Administration tools ==<br />
<br />
{{Question<br />
|Question=Which guest vservers are running?<br />
||Details=Use vserver-stat to find out. Example output:<br />
<pre><br />
CTX PROC VSZ RSS userTIME sysTIME UPTIME NAME<br />
0 77 965.1M 334.6M 14m14s18 2m28s69 1h33m46 root server<br />
49152 7 14M 5.2M 0m00s40 0m00s30 1h30m15 chiffon<br />
</pre><br />
|Signature=derjohn}}<br />
<br />
<br />
{{Question<br />
|Question=Is there a web-based interface for vserver that will allow creation/deletion/configuration etc. of vserver guests?<br />
||Details=<br />
* http://OpenVPS.org which is a set of scripts with a web-interface for webhosters/ISPs<br />
* http://Openvcp.org which is a distributed system (agent!) with a web-interface, with which you can build/remove guests<br />
* http://vsmon.revolutionlinux.com/ is a distributed monitoring-only solution that allows you to search for a particular vserver in your park.<br />
|Signature=derjohn}}<br />
<br />
== Hosting foreign distributions ==<br />
<br />
{{Question<br />
|Question=I run a Debian host and want to build an Ubuntu guest. Howto?<br />
||Details=Simple ;) Assume you want to build a breezy guest on a sid host with IP 192.168.0.2 and hostname vubuntu, then do:<br />
<pre><br />
vserver vubuntu build --force -m debootstrap --hostname vubuntu.myvservers.net --netdev eth0 --interface 192.168.0.2/24 \<br />
--context 42 -- -d breezy -m http://de.archive.ubuntu.com/ubuntu<br />
</pre><br />
<br />
[UPDATE] Currently there are problems in building breezy under unclear circumstances, which seems to have to do with udev. If the above didnt work, try:<br />
<pre><br />
vserver vubuntu build --force -m debootstrap --hostname vubuntu.myvservers.net --netdev eth0 --interface 192.168.0.2/24 \<br />
--context 42 -- -d breezy -m http://de.archive.ubuntu.com/ubuntu -- --exclude=udev<br />
</pre><br />
In very recent versions of the utils, the problem should not occur anymore (it has to do with the 'secure-mount' if you look in the MLs)<br />
<br />
Well, sid's debootstrap knows how to bootstrap Ubuntu linux. Make sure to have a current debootstrap package: <br />
<pre><br />
apt-get update<br />
apt-get install debootstrap<br />
</pre><br />
The knowledge how to build ubuntu 'breezy badger' (which you probably want to be your guest at the time of writing) has been added recently.<br />
|Signature=derjohn}}<br />
<br />
<br />
{{Question<br />
|Question=I want to build a Gentoo guest. Howto?<br />
||Details=Even simpler ;) See http://www.gentoo.org/proj/en/vps/vserver-howto.xml#doc_chap3 .<br />
|Signature=gcc}}<br />
<br />
== Application level problems ==<br />
<br />
{{Question<br />
|Question=I did everything right, but the application foo does not start. What's up there?<br />
||Details=Before asking on the IRC channel, please check out the 'problematic programs' page:<br />
[[Problematic Programs]]<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=When I try to ssh to the guest, I log into the host, even if I installed sshd on the guest. What's wrong here?<br />
||Details=Look at /etc/ssh/sshd_config of the host:<br />
<pre><br />
Port 22<br />
# Use these options to restrict which interfaces/protocols sshd will bind to<br />
#ListenAddress ::<br />
</pre><br />
And now change the setting to <br />
<pre><br />
Port 22<br />
# Use these options to restrict which interfaces/protocols sshd will bind to<br />
ListenAddress your.hosts.ip.here # not the guests IP! <br />
</pre><br />
Then '/etc/init.d/ssh restart' on the host, after that on the guest (if you did apt-get install ssh on the guest already.)<br />
Do I have to explain more? If the hosts sshd binds all available IP addresses on port 22 (The hosts 'sees' even all addresses of the guests!). So if the guest starts its sshd, it can't bind to port 22 any more. You need to change that setting only on the host. <br />
(BTW: A similar approach has to be done for a lot of daemons, e.g. Apache. If the daemon does not support an explicit bind, you may use the chbind command to 'hide' IP addresses from the daemon before starting.)|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=Bind9 does not like to start in my guest.<br />
||Details=Check out the [[Problematic Programs]] page and/or get my [http://linux-vserver.derjohn.de/bind9-packages/bind9-capacheck_9.3.2-2_i386.deb vserver-guest-ready Debian package] for Debian Sid guests and check out the [http://linux-vserver.derjohn.de/bind9-packages/README.txt readme]. (Hint: This is fresh stuff. Please give me feedback)<br />
<br />
[UPDATE] Since VServer Devel 2.1.1-rc18 you do not need to patch the userland tools anymore. The capabilities are masked.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=My mysqld running in a guest behaves strangely and is awfully slow/locks up<br />
||Details=This can be related to /tmp being too small. mysqld stores temporary tables in /tmp and as such, if a lot of queries happen and /tmp runs full this can cause one query to lock up whilst creating the tmp table and all other queries waiting to acquire the lock. There are two possible solutions to that problem: a.) Modify /etc/vservers/vserver-name/fstab and assign more memory to the tmpfs of /tmp and b.) remove the /tmp entry from /etc/vservers/vserver-name/fstab completly. Especially on database servers with a rather high load the second one might be the preferred method.|Signature=sp}}<br />
<br />
{{Question<br />
|Question=Pure-FTP does not run inside a VServer?<br />
||Details=That's because it has capabilities enabled, make sure you rebuild your distro's package passing also the `--without-capabilities` flag to configure.<br />
|Signature=Pedro Algarvio, aka, s0undt3ch}}<br />
<br />
{{Question<br />
|Question=Why do neither sshd nor crond (vixie-cron) work correctly in my CentOS / Fedora guest? I get 'pam_loginuid(crond:session): set_loginuid failed opening loginuid' and similar lines in my logs.<br />
||Details=Took me a while to figure this out, and it turned out to be mentioned in the old wiki. Here is the solution on how to solve a common problem with sshd / crond, somehow related to selinux and auditing:<br />
<br />
pam authentication (also used with openssh) enables "pam_loginuid.so" in the /etc/pam.d/* files. Comment those out as they are not necessary and will not load within a guest anyway. This probably is also necessary on updates later on, if the configs get changed. You therefore may add the following command line to a cronjob file or your software update script:<br />
<pre><br />
/bin/sed --in-place -e "s/^session.*required.*pam_loginuid.so/# session\trequired\tpam_loginuid.so/g" /etc/pam.d/*<br />
</pre><br />
|Signature=patrick}}<br />
<br />
{{Question<br />
|Question=How do i install nagios-plugins on a Gentoo guest?<br />
||Details=Unfortunately, the nagios-plugins ./configure scripts wants to ping 127.0.0.1 which is not available inside a guest. Therefore you have to build nagios-plugins outside the guest.<br />
The easiest way to do this from the host (assuming the guest is running) is:<br />
<pre><br />
vnamespace -e <xid> -- chroot /vservers/<name> emerge nagios-plugins -va<br />
</pre><br />
|Signature=Hollow}}<br />
<br />
{{Question<br />
|Question=Somebody runs ntpd in guest and you can't use ntpdate in host?<br />
||Details=Try to run ntpdate with options -u :<br />
ntpdate -u ntp.domain.xy<br />
or you can use command:<br />
chbind --nid 42 --ip 1.2.3.4 -- ntpdate ntp.domain.xy<br />
where IP will be the IP of host.<br />
|Signature=Punkie/Bertl}}<br />
<br />
<br />
<br />
== Start / Stop a VServer ==<br />
<br />
{{Question<br />
|Question=How do I make a vserver guest start by default?<br />
||Details=At least on Debian, I can tell you how to do it with the new-style config. If your guest is called "derjohn" and you want it to be started somewhere at the of your bootstrap process, then do:<br />
<pre><br />
echo "default" > /etc/vservers/derjohn/apps/init/mark<br />
</pre><br />
If you want to start it earlier, please read the init script "/etc/init.d/util-vserver" to find out how to do it. In most cases you don't need to change this. On Debian the vservers are started at "20", so after most other stuff is up (networking etc.).<br />
<br />
Besides that I created a small helper script for managing the autostart foo: ((vserver-autostart))|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=My host works, but when I start a guest it says that it has a problem with chbind.<br />
||Details=You are probably using util-vserver <= 0.30.209, which does use dynamic network contexts internally (With 0.30.210 this fact changed). So if you compiled your kernel without dynamic contexts, you may start guests, but you can't use the network context.The solution is either to switch to .210 util (or Hollow's toolset) or compile the kernel with dynamic network contexts.<br />
SE Keyword: invalid option `nid' testme.sh<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=What is old-style and new-style config?<br />
||Details=Old-style config refers to a single text-file that contains all the configuration settings. With new-style config the configuration is split into several directories and files. You should probably go for new-style config if you are asking.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=How can I reboot/halt guests?<br />
||Details=It depends. <br />
For legacy Linux-VServer (i.e. 1.2.x), you have to replace /sbin/halt in the guests with vreboot and start rebootmgr in the host. You also need to have a <guest>.conf file in /etc/vservers for each guest. Please have a look at /etc/init.d/rebootmgr.<br />
For Linux-VServer 2.0+, sys_reboot has been virtualized to do the right thing. No changes are needed in guests. Please note that some things depend on the init style used by the guest : read [[util-vserver:InitStyles]]<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=What is the initial PATH?<br />
||Details=By default, vserver uses the 'sysv' startup style, which mimics the init process by running the 3rd runlevel through '/etc/init.d/rc 3' (or '/etc/rc.d/rc 3'). Usually this 'rc' script uses a hard-coded PATH. In the case it doesn't, util-vserver also mimics init's default PATH through /etc/vservers/.defaults/apps/init/environment, or if not present /usr/local/lib/util-vserver/defaults/environment. Beware that all those default PATH usually do not include /usr/local.<br />
|Signature=daniel_hozac&Beuc}}<br />
<br />
{{Question<br />
|Question=When I try to start a guest i get this message "/proc/uptime can not be accessed. Usually, this is caused by procfs-security. Please read the FAQ for more details"?<br />
||Details=After a reboot you need to run the vprocunhide script. If running this script causes many errors to print on the screen, try checking the kernel you have booted with (perhaps it does not have the linux-vserver extensions enabled).<br />
|Signature=mattzerah}}<br />
<br />
== Kernel ==<br />
<br />
{{Question<br />
|Question=Is SMP Supported?<br />
||Details=Yes, on all SMP capable kernel architectures.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=Do I really need the legacy-interfaces? What are these legacy-interfaces?<br />
||Details=Since Linux-VServer is an ongoing project, new features might replace old ones, some might require a development version. Legacy-interfaces are available for backward compability (which might be removed someday) with Linux-VServer 1.2.x.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=I have a vserver running on a Linux kernel with preemption. Is VServer "preempt" safe?<br />
||Details=There are no known issues about running vserver on a preemption enabled kernel. I would like to add, that the vserver kernelhackers would probably exclude that option in 'make menuconfig' if there would be an incompatibility. Just my $.02 :)<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=32 vs 64 Bit? What should I take?<br />
||Details=If you have the choice make the host a 64 bit one. You can run a guest as 32 bit or as 64 bit on a 64 bit host. To run it as 32 bit, you need to compile the x86_64 (a.k.a. AMD64) with the following options:<br />
<pre><br />
[*] Kernel support for ELF binaries<br />
<M> Kernel support for MISC binaries<br />
[*] IA32 Emulation <---- without that, the entire 32bit API is not present<br />
<M> IA32 a.out support <br />
</pre><br />
You can force the guest to behave like a 32 environment like this:<br />
<pre><br />
echo linux_32bit > /etc/vservers/$NAME/personality<br />
echo i686 > /etc/vservers/$NAME/uts/machine<br />
</pre><br />
(thanks cehteh for the hint!)<br />
<br />
But you can force debootstrap to put 32 bit binaries into the guest by 'export ARCH=i386';<br />
<pre><br />
export ARCH=i386 ; vserver build .... <br />
</pre><br />
<br />
On debian when using the newvserver script "export ARCH=i386" has no effect, just use:<br />
<pre><br />
newvserver --arch i386 ...<br />
</pre><br />
<br />
On debian debootstrap can also be gived the arch option:<br />
<pre><br />
vserver myguest \<br />
build -m debootstrap -n myguest \<br />
--hostname myguest.mydomain.com \<br />
-- -d squeeze -- \<br />
--arch=amd64 (or i386 if you want 32bit)<br />
</pre><br />
<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=What does the guest privacy option do in the kernel settings ?<br />
||Details=<pre><br />
>i was wondering about the real thing that guest privacy does. <br />
#ifdef CONFIG_VSERVER_PRIVACY<br />
#define VS_ADMIN_P (0)<br />
#define VS_WATCH_P (0)<br />
#else<br />
<br />
> > Does it just prevent the spectator context ? <br />
<br />
it prevents the spectator context and the admin <br />
functionality in all cases which are privacy<br />
sensitive, which includes:<br />
<br />
- ptrace<br />
- devmapper<br />
- devpts<br />
- inode tag permissions<br />
- mountinfo<br />
- kill/signal<br />
- netlink dumps<br />
- tun control<br />
- iopriority<br />
<br />
> > What security do it bring to the system ?<br />
<br />
together with the VXF_STATE_ADMIN it can be<br />
used to secure a guest (to some degree) from<br />
unwanted access from the host admin, of course,<br />
as the admin can change the kernel, this is a<br />
voluntary feature which mostly prevents certain<br />
kinds of accidential peeking or guest modification<br />
<br />
</pre><br />
|Signature=ghislain}}<br />
<br />
<br />
== Distribution specific questions ==<br />
<br />
{{Question<br />
|Question=VServer is included in the stable Debian GNU/Linux for years now. What VS version did they include?<br />
||Details=At the time of writing, Debian Squeeze is the stable release of Debian and includes a 2.6.32 based kernel-package called 2.6.32-5-vserver-ARCH. This currently contains VServer 2.3.0.36.29.6 with some additional fixes.<br />
|Signature=scientes}}<br />
<br />
{{Question<br />
|Question=Were can I get newer versions of VServer as ready made packages for Debian?<br />
||Details= There are a number of locations<br />
* http://linux-vserver.derjohn.de/ - "my kernels are always 'devel' branch" (derjohn). This repo contain kernels up to 2.6.29 for amd64, 2.6.26 for i386.<br />
* http://repo.psand.net/info/ has Debian Lenny and Squeeze packages for 2.6.31 (i368 and amd64), 2.6.33, 2.6.35, 2.6.36 (amd64). It also contains newer util-vserver builds.<br />
* http://backports.org/ contains 2.6.32 backports for Lenny at time of writing (11th May 2010)<br />
* http://zbla.net/debian/ Unofficial debian vserver packages '''WARNING : i386 packets are compiled for 64bits !''' apt source line: ''deb http://zbla.net/debian/ ./''<br />
|Signature=Gremble<br />
}}<br />
<br />
<br />
<br />
== Misc ==<br />
<br />
{{Question<br />
|Question=Why isn't there a device /dev/xyz within a guest?<br />
||Details=Device nodes allow userspace to access hardware (or virtual resources). Creating a device node inside the guest's namespace will give access to that device, so for security reasons, the number of 'given' devices is small.<br />
|Signature=derjohn}}<br />
<br />
{{Question<br />
|Question=I want to (re)mount a partition in a running guest ... but the guest has no rights (capability) to (re)mount?<br />
||Details=I'll explain. I take as example your /tmp partition within the guest is too small, what will be likely the case if you stay with the 16MB default (vserver build mounts /tmp as 16 MB tmpfs!).<br />
<pre><br />
# vnamespace -e XID mount -t tmpfs -o remount,size=256m,mode=1777 none /var/lib/vservers/<guest>/tmp/<br />
</pre><br />
(if there's a problem, try expanding the symlinks in the mount path)<br />
Be warned that the guest will not recognize the change, as the /etc/mtab file is not updated when you mount like this. To permanently change the mount, edit /etc/vserver/<guest>/fstab on the host.<br />
<br />
If you get:<br />
<pre><br />
mount: can't find /var/lib/vservers/<guest>/tmp in /etc/fstab or /etc/mtab<br />
</pre><br />
then try instead:<br />
<pre><br />
vnamespace -e builder chroot /var/lib/vservers/<guest>/ mount -o remount,size=64m,mode=1777 /tmp<br />
</pre><br />
<br />
Note that this not work for adding a bindmount (<tt>-o bind</tt>) of a directory outside of a vserver into the vserver. For this, there is no alternative but restarting the vserver.<br />
<br />
In order to mount a device present on the host to a directory on the guest use something like:<br />
<br />
<pre><br />
vnamespace -e <guestname> mount -n /dev/<device> /vservers/<guest>/place/you/want/to/mount/it<br />
</pre><br />
<br />
This device can be unmount thus:<br />
<br />
<pre><br />
vnamespace -e <guestname> umount -n /vservers/<guest>/place/you/want/to/mount/it<br />
</pre><br />
<br />
|Signature=derjohn/BenjaminGreen}}<br />
<br />
{{Question<br />
|Question=Does anyone know how to increase the size of /tmp within a vserver w/o restarting?<br />
||Details=Use the remount option for mount.<br />
# vnamespace -e XID mount -n -t tmpfs -o remount,size=32m tmpfs /<vdir>/<guest>/tmp<br />
or something like that. The arguments are needed since mount is not going to be using /etc/fstab for the information and the version of /proc/mounts is best understood by<br />
# vnamespace -e XID cat /proc/mounts.<br />
See [[Frequently_Asked_Questions#I want to (re)mount a partition in a running guest ... but the guest has no rights (capability) to (re)mount?]]<br />
|Signature=derjohn/dhozac}}<br />
<br />
<br />
{{Question<br />
|Question=#1 ERROR: capset(): Operation not permitted<br />
||Details=capabilities are not enabled in kernel-setup<br />
please check that CONFIG_SECURITY_CAPABILITIES is loaded or included in the kernel. ( check with "cat /path_to_kernel/.config | grep -i cap ") <br />
(2.6.11.5-vs-1.9.5 + 0.30-205)<br />
|Signature=IrcQuestions}}<br />
<br />
{{Question<br />
|Question=How can I make 'vserver start' mount the root filesystem?<br />
||Details=Mount it via /etc/vservers/vserver-name/fstab, make sure to set the option 'dev' e.g.:<br />
<pre>/dev/drbd0 / xfs rw,dev 0 0</pre><br />
|Signature=AdrianReyer}}<br />
<br />
<br />
{{Question<br />
|Question=I deleted a guest's directory without shutting it down. Now I have a "ghost" running. Is there any possibility to get it out of proc without rebooting?<br />
||Details=<br />
vkill --xid <xid> -s 15; sleep 2; vkill --xid <xid> -s 9<br />
<br />
You will also need to remove guest's ip, for example with:<br />
ip addr del <ip> dev eth0<br />
|Signature=daniel_hozac & gebura }}<br />
<br />
{{Question<br />
|Question=When using nice and su (for example, in the updatedb cron job), I get: su: Permission denied. What does it mean?<br />
||Details=A guest cannot lower its nice value - and that's what 'su' does through pam_limits which sets a nice value of 0. You can see it through strace:<br />
$ strace nice su nobody<br />
[...]<br />
setpriority(PRIO_PROCESS, 0, 0) = -1 EACCES (Permission denied)<br />
You can use 'su nobody -c nice some_cmd' instead.<br />
<br />
The problem is caused by the fact that host system is setting limits for guests (when instructed to do so) and the dropped capability dissallows processess on guest systems to change and increase them later. That means no process on a guest can lower nice value above the limit set by host.<br />
<br />
If the pam_limits module is activated on a guest system it will first try to '''reset nice value to 0''' even if <tt>/etc/security/limits.conf</tt> file is empty or even if there are lower priority limits set in it. The pam_limits module does that since [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=241663 its developers decided] that it should reset some limits to defaults and start from scratch when applying new restrictions. Unfortunately, already limited guest system won't be able to do it since resetting nice value to 0 means increasing the limit which is forbidden. See [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=311058 Debian Bug report logs - #311058] for more information about that Debian bug.<br />
<br />
See also [[Frequently_Asked_Questions#Cron is not working on my guest system (which is Debian). How can I fix it?|Cron is not working…]]<br />
<br />
|Signature=daniel_hozac & Beuc & Paweł Wilk}}<br />
<br />
{{Question<br />
|Question=Cron is not working on my guest system (which is Debian). How can I fix it?<br />
||Details=On a guest system the cron daemon may not work properly. When looking into the log file (e.g. <tt>/var/log/syslog</tt>) the following message may appear repeatedly:<br />
CRON[xxxxx]: Permission denied<br />
<br />
Similar thing may happen with the <tt>su</tt> when trying to execute a command as root.<br />
<br />
It's not the problem in Cron but in the pam_limits module on a guest system (see [[Frequently_Asked_Questions#When using nice and su (for example, in the updatedb cron job), I get: su: Permission denied. What does it mean?|FAQ:When using nice and su…]] for more information about the cause).<br />
<br />
There are 4 ways to solve or work-around this problem:<br />
<br />
'''1. Allowing guests to reset resource limits:'''<br />
<br />
It's clean solution but you may expect some guest processes increasing their limits because not everything is controlled by PAM. It also breaks centralized resources limiting approach so a guest can do bad things that may cause other guests and host to be overloaded and unresponsive.<br />
<br />
To apply it you have to add <tt>CAP_SYS_RESOURCE</tt> flag to <tt>/etc/vservers/<server name>/bcapabilities</tt> (2.6 kernels).<br />
<br />
See [[util-vserver:Capabilities_and_Flags|Capabilities and Flags]] for more information.<br />
<br />
'''2. Disabling pam_limits on a guest systems:'''<br />
<br />
This workaround is easy and works fine when your guest systems aren't really multiuser but rather service boxes. It disables setting of the resource limits by PAM so the limits can only be set globally for the whole guest (using rlimits or cgroups on a host) but never increased inside of the guest system.<br />
<br />
To apply it just enter the guest and edit the files listed below, commenting out any line containing <tt>pam_limits</tt>:<br />
<br />
/etc/pam.d/su<br />
/etc/pam.d/sudo<br />
/etc/pam.d/cron<br />
<br />
You can also use this one-liner on a guest:<br />
<br />
<pre><br />
/bin/sed --in-place -e "s/^\s\?session.*pam_limits.so.*/\#\0/g" /etc/pam.d/{su,sudo,cron}<br />
</pre><br />
<br />
'''3. Allowing guest's pam_limits to set limits when possible:'''<br />
<br />
This workaround allows you to have working <tt>pam_limits</tt> inside a guest system and global limits set by a host system. What's the catch? The problematic PAM module won't fully work for the root user on a guest system as expected and there might appear some PAM's warnings in guest's <tt>auth.log</tt>. Since using pam_limits to limit regular user processes is far more frequent than using it to limit root processes, this solution may be a good compromise. It is about setting a proper limits in pam_limits configuration and about setting this PAM module in a way that its function is optional (instead of required). The last change makes PAM to continue with session even if pam_limits encounters some error during setting limits (it usually applies to superuser sessions).<br />
<br />
The not so nice news is that there might be a need of keeping guest's limits configuration up to date according to limits globally set for a guest. The limits set in pam_limits configuration file(s) shouldn't be higher (lower in case of nice value) than global guest's limits.<br />
<br />
To apply it enter the guest and edit the files listed below, replacing occurences of <tt>required</tt> by <tt>optional</tt> in the lines containing <tt>pam_limits</tt>:<br />
<br />
/etc/pam.d/su<br />
/etc/pam.d/sudo<br />
/etc/pam.d/cron<br />
<br />
For example:<br />
<br />
# Sets up user limits, please define limits for cron tasks<br />
# through /etc/security/limits.conf<br />
session optional pam_limits.so<br />
<br />
Then on a guest system create the file <tt>/etc/security/limits.d/01-fixpam.conf</tt> containing:<br />
<br />
<pre><br />
* - priority X # replace X with your guest's nice value <br />
</pre><br />
<br />
You can automate this process to happen automagically for any guest by creating the startup script named <tt>/etc/vservers/.defaults/scripts/post-start.d/01-pamfix</tt>:<br />
<br />
<pre><br />
#!/bin/sh<br />
<br />
# This script tries to fix pam_limits entries<br />
# to make it possible for PAM in a guest system to<br />
# set its own limits.<br />
<br />
PAM_DIR="etc/pam.d"<br />
PAM_SERVICES="su sudo cron"<br />
LIMITS_FILE="etc/security/limits.d/01-pamfix.conf"<br />
<br />
vname="$2"<br />
[ -z "$vname" ] && exit 0<br />
<br />
vcfg=$( /usr/sbin/vserver-info "$vname" CFGDIR )<br />
[ ! -d "$vcfg" ] && exit 0<br />
<br />
for s in $PAM_SERVICES<br />
do<br />
pamfile="${PAM_DIR#\/}/$s"<br />
[ -f "$pamfile" ] && /bin/sed --in-place -e "s/\(^\s\?session.*\)required\(.*pam_limits.so.*\)/\1optional\2/g" "$pamfile"<br />
done<br />
<br />
[ ! -f "${vcfg}/nice" ] && exit 0<br />
nval=$( /usr/bin/head -1 "${vcfg}/nice" )<br />
[ -n "$nval" ] && echo "* - priority $nval # (added by vserver startup script)" > "${LIMITS_FILE#\/}"<br />
<br />
exit 0<br />
</pre><br />
<br />
'''4. Disabling resource limits for a guest:'''<br />
<br />
It easy, clean and… unsafe solution. You just have to not set resource limits (e.g. priority, nice value) for a guest or set the nice value limit to 0 on a host system. Resetting it later by guest's <tt>pam_limits</tt> will not generate an error.<br />
<br />
|Signature=Paweł Wilk}}<br />
<br />
{{Question<br />
|Question=How do I handle NFS mounts within in a guest?<br />
||Details=There are at least four ways.<br />
<br />
In any case, you probably want to force the nfs version to 3 or lower to avoid id mapping issues (one symptom of having an id mapping issue is that <tt>no_root_squash</tt> appears to be ignored). You can check whether the mount uses nfsv4 by looking at <tt>/proc/mounts</tt> inside the guest. You can force the protocol version to 3 by passing the mount options <tt>nfsvers=3,mountvers=3</tt>.<br />
<br />
'''1)''' Mount the NFS share from the host OS and let vserver guest access it as part of it's file system.<br />
<br />
''mount --bind'' may also be beneficial in this scenario.<br />
<br />
'''2)''' Use util-vserver and create a ''fstab.remote'' file in the /etc/vserver/<vserver_name> directory. Populate this with the NFS shares and they will be mounted in the context of the vserver guest.<br />
<br />
See http://www.nongnu.org/util-vserver/doc/conf/configuration.html<br />
<br />
Note that as of 0.30.216-pre3000 and kernel 3.0.4-vs2.3.1-pre10.1, the mount request will appear to originate from the IP of the host, not the guest. It is unclear (to [[User:KornAndras|Guy-]]) whether this is a bug.<br />
<br />
'''3)''' Add capabilities to the vserver guest instance to grant sufficient rights to allow NFS mounts.<br />
<br />
Add the following to /etc/vserver/<vserver_name>/bcapabilities<br />
SYS_ADMIN<br />
Add the following to /etc/vserver/<vserver_name>/ccapabilities<br />
SECURE_MOUNT<br />
BINARY_MOUNT<br />
<br />
See [[Capabilities_and_Flags]] for more information about vserver capabilities.<br />
<br />
If you want the NFS shares to be mounted when the guest starts, add them to /etc/vserver/<vserver_name>/fstab.<br />
<br />
'''4)''' Before starting the guest, make a directory of the host "shared" using <tt>mount --make-shared /path/to/dir</tt>, then set up autofs to mount nfs shares under <tt>/path/to/dir/sharename</tt>.<br />
<br />
rbind mount subdirectories of <tt>/path/to/dir</tt> in the guest from its fstab.<br />
<br />
This setup is good if the nfs shares are not often needed, and especially if they're occasionally needed by more than one guest. (As of September 2011, running autofs inside a vserver guest didn't work for me. --[[User:KornAndras|Guy-]] 01:05, 30 October 2011 (UTC))<br />
<br />
||Signature=martindk}}<br />
<br />
<br />
{{Question<br />
|Question=vserver start/stop/enter fails with something like "vnamespace: execvp("/usr/sbin/vserver"): No such file or directory" ?<br />
||Details=Check whether ''/usr'' is mounted in the namespace you are working with.<br />
<pre>vnamespace -e <guest> cat /proc/mounts</pre><br />
If there is no ''/usr'', you can fix your problem with simply mounting it using the following command:<br />
<pre>vnamespace -e <guest> mount /dev/<device> /usr</pre><br />
<br />
||Signature=sim0n}}<br />
<br />
{{Question<br />
|Question=The command vserver <$server> start gives '/etc/init.d/rc: line 74: /etc/default/rcS: No such file or directory', what do I do? <br />
||Details=The vserver has not been correctly installed, this has several reasons<br />
check your install log and it should tell you something about that your server didn't get installed properly<br />
* use stable distribution of debian as server (debootstrap may be different over the versions)<br />
* deny_mount, deny_caps and deny_pivot should be off if your running grsec.<br />
<br />
||Signature=Dude}}<br />
<br />
<br />
{{Question<br />
|Question=How could I rename a vserver directory?<br />
||Details=Please note : this procedure renames the '''directory''', not the '''hostname''' !<br />
#Stop the vserver in question<br />
#rename the <tt>/vservers/<server name></tt> directory<br />
#rename the <tt>/etc/vservers/<server name></tt> directory<br />
#update link: <tt>/etc/vservers/<server name>/run</tt> → <tt>/var/run/vservers/<server name></tt><br />
#update link: <tt>/etc/vservers/<server name>/vdir</tt> → <tt>/etc/vservers/.defaults/vdirbase/<server name></tt><br />
#update link: <tt>/etc/vservers/<server name>/cache</tt> → <tt>/etc/vservers/.defaults/cachebase/<server name></tt><br />
#update link: <tt>/var/run/vservers.rev/<server XID></tt> → <tt>/etc/vservers/<server name></tt><br />
#Start the vserver in question. It should start properly.<br />
<br />
|Signature=FlorianD (from ''hillct'' page in old wiki)}}<br />
<br />
<br />
{{Question<br />
|Question=what if i see my vserver in vserver-stat but with no name ?<br />
||Details=the link in /var/run/vservers is missing<br />
Just do a : cat /etc/vservers/<guest>/context > /var/run/vservers/<guest><br />
check that the <guest> is the good one by using vuname --get --xid <context> with the context you have in the vserver-stat listing.<br />
|Signature=IrcQuestions}}<br />
<br />
== Upgrade from 2.0 to 2.2 ==<br />
<br />
{{Question<br />
|Question=I now get errors like "ncontext: vc_net_create(): Invalid argument; dynamic contexts disabled." on startup. Vservers are not started<br />
||Details=Dynamic context are disabled by default and are deprecated. For example, tagxid and network checks won't be useable with dynamic ids. Now you should manually assign a explicit context to your vservers, like<br />
echo 101 > /etc/vservers/myvserv/context<br />
ADDENDUM: please consider that valid static contexts are between 2 and 49151 ( daniel_hozac on IRC ) otherwise you will end up with unexplainable error "ncontext: vc_net_migrate(): No such process" when trying to start the vserver.<br />
<br />
|Signature=daniel_hozac&Beuc}}<br />
<br />
<br />
{{Question<br />
|Question=How do I assign a static context to an existing vserver?<br />
||Details=Simple ;) See the answer above. <br />
|Signature=gcc}}<br />
<br />
<br />
{{Question<br />
|Question=Since upgrading to a newer VS version my guest complains about "vsched: non-numeric value specified for '--priority_bias" at start time. What's wrong?<br />
||Details=The scheduler paramters changed.You can use this (ugly) script to convert them or do it by hand:<br />
<pre><br />
# cat /usr/local/sbin/vserver-convert-schedule-to-scheddir<br />
#/bin/sh<br />
mkdir /etc/vservers/$1/sched<br />
sed -e 1p -n /etc/vservers/$1/schedule > /etc/vservers/$1/sched/fill-rate<br />
sed -e 2p -n /etc/vservers/$1/schedule > /etc/vservers/$1/sched/interval<br />
sed -e 3p -n /etc/vservers/$1/schedule > /etc/vservers/$1/sched/tokens<br />
sed -e 4p -n /etc/vservers/$1/schedule > /etc/vservers/$1/sched/tokens-min<br />
sed -e 5p -n /etc/vservers/$1/schedule > /etc/vservers/$1/sched/tokens-max<br />
<br />
mv /etc/vservers/$1/schedule /etc/vservers/$1/schedule.converted.see.scheddir<br />
<br />
# see: http://oldwiki.linux-vserver.org/Scheduler+Parameters<br />
# see: http://www.nongnu.org/util-vserver/doc/conf/configuration.html#sched<br />
</pre><br />
||Signature=derjohn}}<br />
<br />
<br />
{{Question<br />
|Question=Since upgrading to a newer VS version my guest doesn't have the amount of shared memory (SHM / SHMMAX / SHMALL ) as it had in the former version. What changed?<br />
||Details=Every VS version that runs on a kernel >= 2.6.19 offers sysctl values per guest. This has to do with the 'ipc namespace' feature that was added to the mainline kernel in version 2.6.19. Linux-VServer uses that feature to give each guest a separate 'ipc namespace' and thus 'own' sysctl values per guest. Because shmmax is such a sysctl value, you have to set it per guest.<br />
Here is an example how to do so:<br />
<br />
<pre><br />
# mkdir /etc/vservers/<vserver>/sysctl/0 -p<br />
# echo kernel.shmall > /etc/vservers/<vserver>/sysctl/0/setting<br />
# echo 134217728 > /etc/vservers/<vserver>/sysctl/0/value<br />
# mkdir /etc/vservers/<vserver>/sysctl/1 -p<br />
# echo kernel.shmmax > /etc/vservers/<vserver>/sysctl/1/setting<br />
# echo 134217728 > /etc/vservers/<vserver>/sysctl/1/value<br />
</pre><br />
It's also explained on the geat flower page:<br />
# see: http://www.nongnu.org/util-vserver/doc/conf/configuration.html -> Look for "sysctl".<br />
<br />
After changing those values, restart your guest, enter it and check if the values are set:<br />
<pre><br />
# sysctl -a | grep shm<br />
...<br />
kernel.shmall = 134217728<br />
kernel.shmmax = 134217728<br />
</pre><br />
<br />
To change a value for a running guest, on the host use:<br />
<pre><br />
vspace -e CONTEXTID --ipc sysctl -w kernel.shmall=134217728<br />
vspace -e CONTEXTID --ipc sysctl -w kernel.shmmax=134217728<br />
</pre><br />
<br />
||Signature=derjohn<br />
}}<br />
<br />
[[Category:Community]]<br />
[[Category:Categories]]</div>KornAndrashttp://wiki.linux-vserver.org/Installation_on_Linux_2.6Installation on Linux 2.62010-09-20T08:25:25Z<p>KornAndras: /* Getting the Sources */ removed uv-testing URL from text</p>
<hr />
<div>This guide will explain how to install a Linux-VServer kernel and util-vserver manually from source. It is assumed that you have basic knowledge about building a custom kernel, i.e. that you know which stuff to turn on in the kernel configuration. Of course some Linux-VServer specific options are explained here.<br />
<br />
== Manual Kernel Compilation ==<br />
<br />
You might ask yourself, why should I build a custom kernel? Manually configuring a kernel is often seen as the most difficult procedure a Linux user ever has to perform. Nothing is less true -- after configuring a couple of kernels you don't even remember that it was difficult ;)<br />
<br />
However, one thing is true: you must know your system when you start configuring a kernel manually. <br />
<br />
There are good reasons to build your kernel manually:<br />
<br />
* Your distribution does not have a prebuilt Linux-VServer kernel<br />
** or maybe it does, but it hasn't been compiled with the options you need<br />
* Your distribution does not have the latest and greatest<br />
* You don't want to install bloated prebuilt kernels<br />
* You want a monolithic kernel and your distribution uses modules<br />
* You can tell everyone that you built your kernels manually ;)<br />
<br />
If you still don't want to build your own kernel, have a look at our [[Documentation]] section for how to install a prebuilt Linux-VServer kernel for your distribution. Otherwise, read on.<br />
<br />
=== Getting the Sources ===<br />
<br />
You'll need the vanilla kernel sources (i.e. those from [http://www.kernel.org kernel.org]) and (of course) a Linux-VServer patch for the kernel version you intend to use. You can find links to both files in our [[Downloads]] section. (Note that for recent kernels, only development versions of the vserver patch exist. You can obtain these from [http://vserver.13thfloor.at/Experimental http://vserver.13thfloor.at/Experimental].)<br />
<br />
<br />
In this document we will use Linux 2.6.22.19 with Linux-VServer 2.2.0.7.<br />
<br />
First, you have to create a directory for the sources, if you already have one, feel free to skip this step and/or adjust the paths to your needs.<br />
<br />
<pre><br />
# Create a directory for our sources<br />
mkdir ~/src<br />
<br />
# Switch to that directory<br />
cd ~/src<br />
</pre><br />
<br />
Now that we have a place to store our sources, we need to fetch them. We start with the vanilla sources.<br />
<br />
<pre><br />
# Get Linux 2.6.22.19 sources<br />
wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.22.19.tar.bz2<br />
<br />
# Extract them<br />
tar xjf linux-2.6.22.19.tar.bz2<br />
</pre><br />
<br />
Now it is time to get the Linux-VServer patch and apply it to the sources. While we're at it, I tell you a nice trick I learned from Bertl, that allows you to keep a lot of source trees on your disk without using up lots of disk space (and this also speeds up 'diff' a lot, which is really nice if you do kernel-hacking). What we do is creating a hard-linked copy of our sources and patch this copy with the Linux-VServer patch. That way, only the patched files use additional disk space (and because hard-linked files are equal by definition, diff doesn't need to compare them).<br />
<br />
<pre><br />
# Get the Linux-VServer 2.2.0.7 patch<br />
wget http://ftp.linux-vserver.org/pub/kernel/vs2.2/patch-2.6.22.19-vs2.2.0.7.diff<br />
<br />
# Create a hard-linked copy of the vanilla sources, this will get the Linux-VServer patch applied<br />
cp -la linux-2.6.22.19 linux-2.6.22.19-vs2.2.0.7<br />
<br />
# Switch to that new directory<br />
cd linux-2.6.22.19-vs2.2.0.7<br />
<br />
# Patch the sources<br />
cat ../patch-2.6.22.19-vs2.2.0.7.diff | patch -p1<br />
</pre><br />
<br />
Now you have two sources, the vanilla sources for 2.6.22.19 and the Linux-VServer sources for 2.6.22.19-vs2.2.0.7. You might ask "Why do I need two source trees at all? I only want one kernel!" and that's a good question.<br />
<br />
Here's one answer: Updates! If a new vanilla kernel is released, you can just download the patch from your version to the new version. Otherwise, if you would have applied the patch to your one and only vanilla source tree, you would not be able to do this. The same applies for new Linux-VServer releases. That is, if a new Linux-VServer patch is available, you can simply create another hardlinked copy of your vanilla sources and apply the new patch using the copy. This can really save you time (and bandwidth), since you can keep everything you might need, without wasting a lot of disk space.<br />
<br />
But be aware that this needs some discipline when hacking the source. Because hard-linked files share the same data on the disk, you need to make sure that your editor does ''The Right Thing'', otherwise you might mess up all your source trees...<br />
<br />
An even better way of dealing with this, if using more disk space is not a big issue, is to use a version control system. [http://git-scm.com/ Git], for example, is specifically designed for dealing with a project with many different but similar versions, and is in fact used to handle the source code of the Linux kernel itself. Rather than downloading and extract a tarfile, it's possible to directly copy the kernel sources from the Git repository at [git.kernel.org] into your own local repository.<br />
<br />
=== Configuring the Kernel ===<br />
<br />
Under Ubuntu (on 8.04 Hardy x86_64 tested) the configuration files of the existing kernel can be found in the /boot directory with a name similar to: config-'uname -r'-general. This file can be used if copied to the source dir of the kernel as a starting point to configure the rest of the kernel. The filename must be <tt>.config</tt>.<br />
<br />
Now go to your kernel source directory and execute <tt>make menuconfig</tt>. This will fire up an ncurses-based configuration menu. (Of course you can use whatever configuration method you like, there is a text based one (make config), a GTK based one (make gconfig), and even a QT based one (make xconfig)). <tt>make oldconfig</tt> is particularly useful because it only asks you about kernel options that are supported by the kernel but that don't already have a value assigned to them in your <tt>.config</tt>. Looking through all the available options can be tedious; <tt>make oldconfig</tt> saves you time by only showing new the new ones (in this case, vserver-related options).<br />
<br />
<pre><br />
# Configure the kernel using a ncurses based menu<br />
make menuconfig<br />
</pre><br />
<br />
It is out of the scope of this guide to explain all the available configuration options. If you feel unsure about certain options, either use the default value, or consult your distribution manuals and the documentation shipped with the kernel for help.<br />
<br />
Nevertheless, we will explain the Linux-VServer configuration options, of course. Depending on your version your configuration options may look similar to the following:<br />
<br />
<pre><br />
Linux VServer ---><br />
[*] Enable Legacy Kernel API (<2.3)<br />
[ ] Show a Legacy Version ID<br />
[*] Enable dynamic context IDs (2.1 - 2.2)<br />
[ ] Disable Legacy Networking Kernel API (2.0.x only)<br />
[*] Enable Legacy Networking Kernel API (2.1 - 2.2)<br />
[*] Automatically Assign Loopback IP (2.3+)<br />
[*] Automatic Single IP Special Casing (2.3+)<br />
[ ] Remap Source IP Address (<2.3)<br />
[*] Enable COW Immutable Link Breaking (2.1+)<br />
[ ] Enable Virtualized Guest Time (2.1+)<br />
[ ] Enable Guest Device Mapping (2.1, 2.3)<br />
[*] Enable Proc Security<br />
[ ] Enable Hard CPU Limits<br />
[ ] Avoid idle CPUs by skipping Time (2.1+)<br />
[ ] Limit the IDLE task<br />
Persistent Inode Tagging (UID24/GID24) ---><br />
[ ] Tag NFSD User Auth and Files<br />
[ ] Enable Inode Tag Propagation (2.1+)<br />
[ ] Honor Privacy Aspects of Guests (2.1+)<br />
[256] Maximum number of Contexts (1-65533) (2.2+)<br />
[*] VServer Warnings (2.2+)<br />
[ ] VServer Debugging Code<br />
[ ] VServer History Tracing<br />
(64) Per-CPU History Size (32-65536)<br />
[ ] VServer Scheduling Monitor (2.1+)<br />
(1024) Per-CPU Monitor Queue Size (32-65536) (2.1+)<br />
(256) Per-CPU Monitor Sync Interval (0-65536) (2.1+)<br />
</pre><br />
<br />
; Enable Legacy Kernel API<br />
: This enables the legacy API used in vs1.xx, maintaining compatibility with older vserver tools, and guest images that are configured using the legacy method. You shouldn't enable it for new linux-vserver installations.<br />
<br />
; Show a Legacy Version ID<br />
: This shows a special legacy version to very old tools which do not handle the current version correctly. This will probably disable some features of newer tools so better avoid it, unless you really, really need it for backwards compatibility.<br />
<br />
; Enable dynamic context IDs<br />
: This enables support for in-kernel dynamic context IDs which are deprecated and soon to be removed.<br />
<br />
; Enable/Disable Legacy Networking Kernel API<br />
: This enables/disables the legacy networking API which is required by the chbind tool in util-vserver <= 0.30.209. That is a fairly old version of util-vserver, so unless you know you'll be using something that ancient, feel free to disable this option.<br />
<br />
; Automatically Assign Loopback IP<br />
: Enable this to get a unique 127.x.y.1(x.y matches the context id) address for each network context automatically, and enable the NXF_LBACK_REMAP and NXF_HIDE_LBACK flags. This creates a per-guest, isolated 127.0.0.1 address. This has the side effect that services bound to 127.0.0.1 on the host will be inaccessible from guests by default; be sure this is what you want before enabling this option.<br />
<br />
; Automatic Single IP Special Casing<br />
: Enabling this option will make the kernel automatically set NXF_SINGLE_IP for contexts which have only one IP address (note: a loopback address does not count). (TODO: add a link here to a page that explains what NXF_SINGLE_IP does, or briefly explain it here.)<br />
<br />
; Remap Source IP Address<br />
: This allows to remap the source IP address of 'local' connections from 127.0.0.1 to the first assigned guest IP.<br />
<br />
; Enable COW Immutable Link Breaking<br />
: This enables the COW (Copy-On-Write) link break code. It allows you to treat [[Unification|unified files]] like normal files when writing to them (which will implicitly break the link and create a copy of the unified file). Note that this currently doesn't work on xfs; on xfs, the new copy of the unified file will contain only binary zeroes.<br />
<br />
; Enable Virtualized Guest Time<br />
: This enables per guest time offsets to allow for adjusting the system clock individually per guest. This adds some overhead to the time functions and therefore should not be enabled without good reason.<br />
<br />
; Enable Guest Device Mapping<br />
: This enables a generic remapping/access control interface for device nodes used inside the guest. For example, you could rewrite a guest's attempts to use /dev/hda to /dev/sda. This is normally not needed; guests don't normally use device nodes associated with physical hardware at all. (Of course, remapping can also be applied to device nodes that don't correspond to physical hardware.)<br />
<br />
; Enable Proc Security<br />
: This configures [[Secure ProcFS Entries|ProcFS security]] to initially hide non-process entries for all contexts except the main and spectator context (i.e. for all guests), which is a secure default.<br />
<br />
; Enable Hard CPU Limits<br />
: This will compile in code that allows the [[CPU Scheduler|Token Bucket Scheduler]] to put processes on hold when a context's tokens are depleted (provided that its per-context sched_hard flag is set).<br />
<br />
; Avoid idle CPUs by skipping Time<br />
: This option allows the scheduler to artificially advance time (per cpu) when otherwise the idle task would be scheduled, thus keeping the cpu busy and sharing the available resources among certain contexts.<br />
<br />
; Limit the IDLE task<br />
: Limit the idle slices, so the the next context will be scheduled as soon as possible. This might improve interactivity and latency, but will also marginally increase scheduling overhead.<br />
<br />
; Persistent Inode Tagging<br />
: This adds persistent context information to filesystems mounted with the tagxid option. [[Filesystem Tagging|Tagging]] is a requirement for per-context [[Disk Limits and Quota]].<br />
<br />
; Tag NFSD User Auth and Files<br />
: Enable this if you do want the in-kernel NFS Server to use the xid tagging specified above.<br />
<br />
; Enable Inode Tag Propagation<br />
: This allows for the tagid= mount option to specify a tagid which is to be used for the entire mount tree.<br />
<br />
; Honor Privacy Aspects of Guests<br />
: When enabled, most context checks will disallow access to structures assigned to a specific context, like ptys or loop devices.<br />
<br />
; Maximum number of Contexts<br />
: This makes sure that at least this many contexts can be created, by making sure that this much per-CPU memory is available.<br />
<br />
; VServer Warnings<br />
: Enables warnings (sent to the kernel log during runtime). There's really no good reason to disable this.<br />
<br />
; VServer Debugging Code<br />
: Set this to yes if you want to be able to activate debugging output at runtime. It adds a probably small overhead to all vserver related functions and increases the kernel size by about 20k.<br />
<br />
; VServer History Tracing<br />
: This records a history of Linux-VServer events that can be replayed in the event of a panic or an oops.<br />
<br />
; Per-CPU History Size<br />
: This allows you to set the size of the per-CPU history buffer.<br />
<br />
; VServer Scheduling Monitor<br />
: Set this to yes if you want to record the scheduling decisions, so that they can be relayed to userspace for detailed analysis.<br />
<br />
; Per-CPU Monitor Queue Size<br />
: This allows you to specify the number of entries in the per-CPU scheduling monitor buffer.<br />
<br />
; Per-CPU Monitor Sync Interval<br />
: This allows you to specify the interval in ticks when a time sync entry is inserted.<br />
<br />
=== Compiling and Installing ===<br />
<br />
Now that your kernel is configured, it is time to compile and install it. Exit the configuration and start the compilation process: <br />
<br />
<pre><br />
# make && make modules_install<br />
</pre><br />
<br />
(Note: this will copy the resulting modules to your filesystem directly, bypassing any package manager you may have. It may be a better idea to build a kernel package you can install using your package manager. For rpm-based distributions, <tt>make rpm</tt> might work; dpkg-based distributions provide a package called <tt>kernel-package</tt> which you can use. We won't be covering these methods here.)<br />
<br />
If you don't happen to have a really fast box, it is a good time to get a new cup of coffee now ;)<br />
<br />
When the kernel has finished compiling, you have to copy the kernel image to your /boot partition and configure your boot loader. If you don't know how to do this, please consult your distribution manual or ask [http://www.google.com Google] for help.<br />
<br />
== Manual util-vserver Compilation ==<br />
<br />
The kernel alone does not help you, you also need some tools to exploit all those new features you got, so let's get them.<br />
<br />
=== Getting the Sources ===<br />
<br />
You will have to download the latest util-vserver source tarball from our [[Downloads]] section. In this guide we will use util-vserver-0.30.215, but note that for recent kernels and especially development versions of the vserver kernel patch, you'll need a much more recent [http://people.linux-vserver.org/~dhozac/t/uv-testing/ development version].<br />
<br />
As a first step, of course, we need to get the sources.<br />
<br />
<pre><br />
# Go to our source directory<br />
cd ~/src<br />
<br />
# Get the sources for util-vserver<br />
wget http://ftp.linux-vserver.org/pub/utils/util-vserver/util-vserver-0.30.215.tar.bz2<br />
<br />
# Extract the sources<br />
tar xjf util-vserver-0.30.215.tar.bz2<br />
</pre><br />
<br />
=== Compiling and Installing ===<br />
<br />
Now that we have extracted the util-vserver source we have to do the usual configure, make, make install chain. While configuring the tools you may get some error messages about missing stuff, for example dietlibc, vconfig and e2fs headers. The error messages are accompanied by explanations what you should do, so read them carefully.<br />
<br />
<pre><br />
# Switch to the util-vserver source directory<br />
cd util-vserver-0.30.215<br />
<br />
# Configure the sources (you may want to adjust settings here, the defaults work, but may not suit your needs)<br />
./configure --prefix=... --sysconfdir=... --localstatedir=...<br />
<br />
# Build the tools<br />
make<br />
<br />
# Install the tools<br />
make install install-distribution<br />
<br />
# It's a good point to fix the /proc entries for the guests<br />
/etc/init.d/vprocunhide restart (this path depends on configuration, see output of 'vserver-info')<br />
</pre><br />
<br />
=== Enabling VServers on startup ===<br />
<br />
You need to enable 2 initscripts:<br />
* <code>vprocunhide</code> - does necessary stuff in <code>/proc</code><br />
* <code>vservers-default</code> - runs vservers marked as 'default' (<code>echo "default" > /etc/vservers/XXX/apps/init/mark</code>) on startup<br />
<br />
To do so, you can use 'update-rc.d' or 'rcconf' (Debian), 'chkconfig' or 'ntsysv' (Fedora).<br />
<br />
If you get errors like:<br />
<pre><br />
/proc/uptime can not be accessed. Usually, this is caused by<br />
procfs-security. Please read the FAQ for more details<br />
http://linux-vserver.org/Proc-Security<br />
</pre><br />
then you probably need to enable <code>vprocunhide</code>.<br />
<br />
=== Testing your setup ===<br />
<br />
To ensure that your setup works we have created two small test scripts. The testme.sh script ensures basic functionality whereas the testfs.sh script is for inode attribute testing for various filesystems.<br />
<br />
<pre><br />
# get the script<br />
wget http://vserver.13thfloor.at/Stuff/SCRIPT/testme.sh<br />
<br />
# make it executable<br />
chmod +x testme.sh<br />
<br />
# run the test script<br />
./testme.sh<br />
</pre><br />
<br />
'''Be careful! The testfs.sh script might easily reformat your hard disk :)'''<br />
<br />
<pre><br />
# get the script<br />
wget http://vserver.13thfloor.at/Stuff/SCRIPT/testfs.sh<br />
<br />
# make it executable<br />
chmod +x testfs.sh<br />
<br />
# make a loopback file<br />
dd bs=1024k count=1024 if=/dev/zero of=1gb.testfile<br />
<br />
# setup the loopback<br />
losetup /dev/loop0 1gb.testfile<br />
<br />
# run the test script for legacy mode<br />
./testfs.sh -l -t -D /dev/loop0 -M /mnt<br />
<br />
# run the test script for new-style config<br />
./testfs.sh -t -D /dev/loop0 -M /mnt<br />
</pre><br />
<br />
If the scripts show any error, be sure to read [[Report a Bug|how to report a bug]] and contact the Linux-VServer Developers for help. See [[Communicate]] for details.<br />
<br />
== Where to go from here ==<br />
<br />
Now that your setup is complete and working as expected, it is time to create your first guest system. Read on at [[Building Guest Systems]].</div>KornAndrashttp://wiki.linux-vserver.org/Installation_on_Linux_2.6Installation on Linux 2.62010-09-20T07:33:50Z<p>KornAndras: /* Getting the Sources */ fix broken link</p>
<hr />
<div>This guide will explain how to install a Linux-VServer kernel and util-vserver manually from source. It is assumed that you have basic knowledge about building a custom kernel, i.e. that you know which stuff to turn on in the kernel configuration. Of course some Linux-VServer specific options are explained here.<br />
<br />
== Manual Kernel Compilation ==<br />
<br />
You might ask yourself, why should I build a custom kernel? Manually configuring a kernel is often seen as the most difficult procedure a Linux user ever has to perform. Nothing is less true -- after configuring a couple of kernels you don't even remember that it was difficult ;)<br />
<br />
However, one thing is true: you must know your system when you start configuring a kernel manually. <br />
<br />
There are good reasons to build your kernel manually:<br />
<br />
* Your distribution does not have a prebuilt Linux-VServer kernel<br />
** or maybe it does, but it hasn't been compiled with the options you need<br />
* Your distribution does not have the latest and greatest<br />
* You don't want to install bloated prebuilt kernels<br />
* You want a monolithic kernel and your distribution uses modules<br />
* You can tell everyone that you built your kernels manually ;)<br />
<br />
If you still don't want to build your own kernel, have a look at our [[Documentation]] section for how to install a prebuilt Linux-VServer kernel for your distribution. Otherwise, read on.<br />
<br />
=== Getting the Sources ===<br />
<br />
You'll need the vanilla kernel sources (i.e. those from [http://www.kernel.org kernel.org]) and (of course) a Linux-VServer patch for the kernel version you intend to use. You can find links to both files in our [[Downloads]] section. (Note that for recent kernels, only development versions of the vserver patch exist. You can obtain these from [http://vserver.13thfloor.at/Experimental http://vserver.13thfloor.at/Experimental].)<br />
<br />
<br />
In this document we will use Linux 2.6.22.19 with Linux-VServer 2.2.0.7.<br />
<br />
First, you have to create a directory for the sources, if you already have one, feel free to skip this step and/or adjust the paths to your needs.<br />
<br />
<pre><br />
# Create a directory for our sources<br />
mkdir ~/src<br />
<br />
# Switch to that directory<br />
cd ~/src<br />
</pre><br />
<br />
Now that we have a place to store our sources, we need to fetch them. We start with the vanilla sources.<br />
<br />
<pre><br />
# Get Linux 2.6.22.19 sources<br />
wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.22.19.tar.bz2<br />
<br />
# Extract them<br />
tar xjf linux-2.6.22.19.tar.bz2<br />
</pre><br />
<br />
Now it is time to get the Linux-VServer patch and apply it to the sources. While we're at it, I tell you a nice trick I learned from Bertl, that allows you to keep a lot of source trees on your disk without using up lots of disk space (and this also speeds up 'diff' a lot, which is really nice if you do kernel-hacking). What we do is creating a hard-linked copy of our sources and patch this copy with the Linux-VServer patch. That way, only the patched files use additional disk space (and because hard-linked files are equal by definition, diff doesn't need to compare them).<br />
<br />
<pre><br />
# Get the Linux-VServer 2.2.0.7 patch<br />
wget http://ftp.linux-vserver.org/pub/kernel/vs2.2/patch-2.6.22.19-vs2.2.0.7.diff<br />
<br />
# Create a hard-linked copy of the vanilla sources, this will get the Linux-VServer patch applied<br />
cp -la linux-2.6.22.19 linux-2.6.22.19-vs2.2.0.7<br />
<br />
# Switch to that new directory<br />
cd linux-2.6.22.19-vs2.2.0.7<br />
<br />
# Patch the sources<br />
cat ../patch-2.6.22.19-vs2.2.0.7.diff | patch -p1<br />
</pre><br />
<br />
Now you have two sources, the vanilla sources for 2.6.22.19 and the Linux-VServer sources for 2.6.22.19-vs2.2.0.7. You might ask "Why do I need two source trees at all? I only want one kernel!" and that's a good question.<br />
<br />
Here's one answer: Updates! If a new vanilla kernel is released, you can just download the patch from your version to the new version. Otherwise, if you would have applied the patch to your one and only vanilla source tree, you would not be able to do this. The same applies for new Linux-VServer releases. That is, if a new Linux-VServer patch is available, you can simply create another hardlinked copy of your vanilla sources and apply the new patch using the copy. This can really save you time (and bandwidth), since you can keep everything you might need, without wasting a lot of disk space.<br />
<br />
But be aware that this needs some discipline when hacking the source. Because hard-linked files share the same data on the disk, you need to make sure that your editor does ''The Right Thing'', otherwise you might mess up all your source trees...<br />
<br />
An even better way of dealing with this, if using more disk space is not a big issue, is to use a version control system. [http://git-scm.com/ Git], for example, is specifically designed for dealing with a project with many different but similar versions, and is in fact used to handle the source code of the Linux kernel itself. Rather than downloading and extract a tarfile, it's possible to directly copy the kernel sources from the Git repository at [git.kernel.org] into your own local repository.<br />
<br />
=== Configuring the Kernel ===<br />
<br />
Under Ubuntu (on 8.04 Hardy x86_64 tested) the configuration files of the existing kernel can be found in the /boot directory with a name similar to: config-'uname -r'-general. This file can be used if copied to the source dir of the kernel as a starting point to configure the rest of the kernel. The filename must be <tt>.config</tt>.<br />
<br />
Now go to your kernel source directory and execute <tt>make menuconfig</tt>. This will fire up an ncurses-based configuration menu. (Of course you can use whatever configuration method you like, there is a text based one (make config), a GTK based one (make gconfig), and even a QT based one (make xconfig)). <tt>make oldconfig</tt> is particularly useful because it only asks you about kernel options that are supported by the kernel but that don't already have a value assigned to them in your <tt>.config</tt>. Looking through all the available options can be tedious; <tt>make oldconfig</tt> saves you time by only showing new the new ones (in this case, vserver-related options).<br />
<br />
<pre><br />
# Configure the kernel using a ncurses based menu<br />
make menuconfig<br />
</pre><br />
<br />
It is out of the scope of this guide to explain all the available configuration options. If you feel unsure about certain options, either use the default value, or consult your distribution manuals and the documentation shipped with the kernel for help.<br />
<br />
Nevertheless, we will explain the Linux-VServer configuration options, of course. Depending on your version your configuration options may look similar to the following:<br />
<br />
<pre><br />
Linux VServer ---><br />
[*] Enable Legacy Kernel API (<2.3)<br />
[ ] Show a Legacy Version ID<br />
[*] Enable dynamic context IDs (2.1 - 2.2)<br />
[ ] Disable Legacy Networking Kernel API (2.0.x only)<br />
[*] Enable Legacy Networking Kernel API (2.1 - 2.2)<br />
[*] Automatically Assign Loopback IP (2.3+)<br />
[*] Automatic Single IP Special Casing (2.3+)<br />
[ ] Remap Source IP Address (<2.3)<br />
[*] Enable COW Immutable Link Breaking (2.1+)<br />
[ ] Enable Virtualized Guest Time (2.1+)<br />
[ ] Enable Guest Device Mapping (2.1, 2.3)<br />
[*] Enable Proc Security<br />
[ ] Enable Hard CPU Limits<br />
[ ] Avoid idle CPUs by skipping Time (2.1+)<br />
[ ] Limit the IDLE task<br />
Persistent Inode Tagging (UID24/GID24) ---><br />
[ ] Tag NFSD User Auth and Files<br />
[ ] Enable Inode Tag Propagation (2.1+)<br />
[ ] Honor Privacy Aspects of Guests (2.1+)<br />
[256] Maximum number of Contexts (1-65533) (2.2+)<br />
[*] VServer Warnings (2.2+)<br />
[ ] VServer Debugging Code<br />
[ ] VServer History Tracing<br />
(64) Per-CPU History Size (32-65536)<br />
[ ] VServer Scheduling Monitor (2.1+)<br />
(1024) Per-CPU Monitor Queue Size (32-65536) (2.1+)<br />
(256) Per-CPU Monitor Sync Interval (0-65536) (2.1+)<br />
</pre><br />
<br />
; Enable Legacy Kernel API<br />
: This enables the legacy API used in vs1.xx, maintaining compatibility with older vserver tools, and guest images that are configured using the legacy method. You shouldn't enable it for new linux-vserver installations.<br />
<br />
; Show a Legacy Version ID<br />
: This shows a special legacy version to very old tools which do not handle the current version correctly. This will probably disable some features of newer tools so better avoid it, unless you really, really need it for backwards compatibility.<br />
<br />
; Enable dynamic context IDs<br />
: This enables support for in-kernel dynamic context IDs which are deprecated and soon to be removed.<br />
<br />
; Enable/Disable Legacy Networking Kernel API<br />
: This enables/disables the legacy networking API which is required by the chbind tool in util-vserver <= 0.30.209. That is a fairly old version of util-vserver, so unless you know you'll be using something that ancient, feel free to disable this option.<br />
<br />
; Automatically Assign Loopback IP<br />
: Enable this to get a unique 127.x.y.1(x.y matches the context id) address for each network context automatically, and enable the NXF_LBACK_REMAP and NXF_HIDE_LBACK flags. This creates a per-guest, isolated 127.0.0.1 address. This has the side effect that services bound to 127.0.0.1 on the host will be inaccessible from guests by default; be sure this is what you want before enabling this option.<br />
<br />
; Automatic Single IP Special Casing<br />
: Enabling this option will make the kernel automatically set NXF_SINGLE_IP for contexts which have only one IP address (note: a loopback address does not count). (TODO: add a link here to a page that explains what NXF_SINGLE_IP does, or briefly explain it here.)<br />
<br />
; Remap Source IP Address<br />
: This allows to remap the source IP address of 'local' connections from 127.0.0.1 to the first assigned guest IP.<br />
<br />
; Enable COW Immutable Link Breaking<br />
: This enables the COW (Copy-On-Write) link break code. It allows you to treat [[Unification|unified files]] like normal files when writing to them (which will implicitly break the link and create a copy of the unified file). Note that this currently doesn't work on xfs; on xfs, the new copy of the unified file will contain only binary zeroes.<br />
<br />
; Enable Virtualized Guest Time<br />
: This enables per guest time offsets to allow for adjusting the system clock individually per guest. This adds some overhead to the time functions and therefore should not be enabled without good reason.<br />
<br />
; Enable Guest Device Mapping<br />
: This enables a generic remapping/access control interface for device nodes used inside the guest. For example, you could rewrite a guest's attempts to use /dev/hda to /dev/sda. This is normally not needed; guests don't normally use device nodes associated with physical hardware at all. (Of course, remapping can also be applied to device nodes that don't correspond to physical hardware.)<br />
<br />
; Enable Proc Security<br />
: This configures [[Secure ProcFS Entries|ProcFS security]] to initially hide non-process entries for all contexts except the main and spectator context (i.e. for all guests), which is a secure default.<br />
<br />
; Enable Hard CPU Limits<br />
: This will compile in code that allows the [[CPU Scheduler|Token Bucket Scheduler]] to put processes on hold when a context's tokens are depleted (provided that its per-context sched_hard flag is set).<br />
<br />
; Avoid idle CPUs by skipping Time<br />
: This option allows the scheduler to artificially advance time (per cpu) when otherwise the idle task would be scheduled, thus keeping the cpu busy and sharing the available resources among certain contexts.<br />
<br />
; Limit the IDLE task<br />
: Limit the idle slices, so the the next context will be scheduled as soon as possible. This might improve interactivity and latency, but will also marginally increase scheduling overhead.<br />
<br />
; Persistent Inode Tagging<br />
: This adds persistent context information to filesystems mounted with the tagxid option. [[Filesystem Tagging|Tagging]] is a requirement for per-context [[Disk Limits and Quota]].<br />
<br />
; Tag NFSD User Auth and Files<br />
: Enable this if you do want the in-kernel NFS Server to use the xid tagging specified above.<br />
<br />
; Enable Inode Tag Propagation<br />
: This allows for the tagid= mount option to specify a tagid which is to be used for the entire mount tree.<br />
<br />
; Honor Privacy Aspects of Guests<br />
: When enabled, most context checks will disallow access to structures assigned to a specific context, like ptys or loop devices.<br />
<br />
; Maximum number of Contexts<br />
: This makes sure that at least this many contexts can be created, by making sure that this much per-CPU memory is available.<br />
<br />
; VServer Warnings<br />
: Enables warnings (sent to the kernel log during runtime). There's really no good reason to disable this.<br />
<br />
; VServer Debugging Code<br />
: Set this to yes if you want to be able to activate debugging output at runtime. It adds a probably small overhead to all vserver related functions and increases the kernel size by about 20k.<br />
<br />
; VServer History Tracing<br />
: This records a history of Linux-VServer events that can be replayed in the event of a panic or an oops.<br />
<br />
; Per-CPU History Size<br />
: This allows you to set the size of the per-CPU history buffer.<br />
<br />
; VServer Scheduling Monitor<br />
: Set this to yes if you want to record the scheduling decisions, so that they can be relayed to userspace for detailed analysis.<br />
<br />
; Per-CPU Monitor Queue Size<br />
: This allows you to specify the number of entries in the per-CPU scheduling monitor buffer.<br />
<br />
; Per-CPU Monitor Sync Interval<br />
: This allows you to specify the interval in ticks when a time sync entry is inserted.<br />
<br />
=== Compiling and Installing ===<br />
<br />
Now that your kernel is configured, it is time to compile and install it. Exit the configuration and start the compilation process: <br />
<br />
<pre><br />
# make && make modules_install<br />
</pre><br />
<br />
(Note: this will copy the resulting modules to your filesystem directly, bypassing any package manager you may have. It may be a better idea to build a kernel package you can install using your package manager. For rpm-based distributions, <tt>make rpm</tt> might work; dpkg-based distributions provide a package called <tt>kernel-package</tt> which you can use. We won't be covering these methods here.)<br />
<br />
If you don't happen to have a really fast box, it is a good time to get a new cup of coffee now ;)<br />
<br />
When the kernel has finished compiling, you have to copy the kernel image to your /boot partition and configure your boot loader. If you don't know how to do this, please consult your distribution manual or ask [http://www.google.com Google] for help.<br />
<br />
== Manual util-vserver Compilation ==<br />
<br />
The kernel alone does not help you, you also need some tools to exploit all those new features you got, so let's get them.<br />
<br />
=== Getting the Sources ===<br />
<br />
You will have to download the latest util-vserver source tarball from our [[Downloads]] section. In this guide we will use util-vserver-0.30.215, but note that for recent kernels and especially development versions of the vserver kernel patch, you'll need a much more recent development version from [http://people.linux-vserver.org/~dhozac/t/uv-testing/ http://people.linux-vserver.org/~dhozac/t/uv-testing/].<br />
<br />
As a first step, of course, we need to get the sources.<br />
<br />
<pre><br />
# Go to our source directory<br />
cd ~/src<br />
<br />
# Get the sources for util-vserver<br />
wget http://ftp.linux-vserver.org/pub/utils/util-vserver/util-vserver-0.30.215.tar.bz2<br />
<br />
# Extract the sources<br />
tar xjf util-vserver-0.30.215.tar.bz2<br />
</pre><br />
<br />
=== Compiling and Installing ===<br />
<br />
Now that we have extracted the util-vserver source we have to do the usual configure, make, make install chain. While configuring the tools you may get some error messages about missing stuff, for example dietlibc, vconfig and e2fs headers. The error messages are accompanied by explanations what you should do, so read them carefully.<br />
<br />
<pre><br />
# Switch to the util-vserver source directory<br />
cd util-vserver-0.30.215<br />
<br />
# Configure the sources (you may want to adjust settings here, the defaults work, but may not suit your needs)<br />
./configure --prefix=... --sysconfdir=... --localstatedir=...<br />
<br />
# Build the tools<br />
make<br />
<br />
# Install the tools<br />
make install install-distribution<br />
<br />
# It's a good point to fix the /proc entries for the guests<br />
/etc/init.d/vprocunhide restart (this path depends on configuration, see output of 'vserver-info')<br />
</pre><br />
<br />
=== Enabling VServers on startup ===<br />
<br />
You need to enable 2 initscripts:<br />
* <code>vprocunhide</code> - does necessary stuff in <code>/proc</code><br />
* <code>vservers-default</code> - runs vservers marked as 'default' (<code>echo "default" > /etc/vservers/XXX/apps/init/mark</code>) on startup<br />
<br />
To do so, you can use 'update-rc.d' or 'rcconf' (Debian), 'chkconfig' or 'ntsysv' (Fedora).<br />
<br />
If you get errors like:<br />
<pre><br />
/proc/uptime can not be accessed. Usually, this is caused by<br />
procfs-security. Please read the FAQ for more details<br />
http://linux-vserver.org/Proc-Security<br />
</pre><br />
then you probably need to enable <code>vprocunhide</code>.<br />
<br />
=== Testing your setup ===<br />
<br />
To ensure that your setup works we have created two small test scripts. The testme.sh script ensures basic functionality whereas the testfs.sh script is for inode attribute testing for various filesystems.<br />
<br />
<pre><br />
# get the script<br />
wget http://vserver.13thfloor.at/Stuff/SCRIPT/testme.sh<br />
<br />
# make it executable<br />
chmod +x testme.sh<br />
<br />
# run the test script<br />
./testme.sh<br />
</pre><br />
<br />
'''Be careful! The testfs.sh script might easily reformat your hard disk :)'''<br />
<br />
<pre><br />
# get the script<br />
wget http://vserver.13thfloor.at/Stuff/SCRIPT/testfs.sh<br />
<br />
# make it executable<br />
chmod +x testfs.sh<br />
<br />
# make a loopback file<br />
dd bs=1024k count=1024 if=/dev/zero of=1gb.testfile<br />
<br />
# setup the loopback<br />
losetup /dev/loop0 1gb.testfile<br />
<br />
# run the test script for legacy mode<br />
./testfs.sh -l -t -D /dev/loop0 -M /mnt<br />
<br />
# run the test script for new-style config<br />
./testfs.sh -t -D /dev/loop0 -M /mnt<br />
</pre><br />
<br />
If the scripts show any error, be sure to read [[Report a Bug|how to report a bug]] and contact the Linux-VServer Developers for help. See [[Communicate]] for details.<br />
<br />
== Where to go from here ==<br />
<br />
Now that your setup is complete and working as expected, it is time to create your first guest system. Read on at [[Building Guest Systems]].</div>KornAndrashttp://wiki.linux-vserver.org/Installation_on_Linux_2.6Installation on Linux 2.62010-09-20T07:33:05Z<p>KornAndras: /* Getting the Sources */ move and fix broken link to experimental patch versions</p>
<hr />
<div>This guide will explain how to install a Linux-VServer kernel and util-vserver manually from source. It is assumed that you have basic knowledge about building a custom kernel, i.e. that you know which stuff to turn on in the kernel configuration. Of course some Linux-VServer specific options are explained here.<br />
<br />
== Manual Kernel Compilation ==<br />
<br />
You might ask yourself, why should I build a custom kernel? Manually configuring a kernel is often seen as the most difficult procedure a Linux user ever has to perform. Nothing is less true -- after configuring a couple of kernels you don't even remember that it was difficult ;)<br />
<br />
However, one thing is true: you must know your system when you start configuring a kernel manually. <br />
<br />
There are good reasons to build your kernel manually:<br />
<br />
* Your distribution does not have a prebuilt Linux-VServer kernel<br />
** or maybe it does, but it hasn't been compiled with the options you need<br />
* Your distribution does not have the latest and greatest<br />
* You don't want to install bloated prebuilt kernels<br />
* You want a monolithic kernel and your distribution uses modules<br />
* You can tell everyone that you built your kernels manually ;)<br />
<br />
If you still don't want to build your own kernel, have a look at our [[Documentation]] section for how to install a prebuilt Linux-VServer kernel for your distribution. Otherwise, read on.<br />
<br />
=== Getting the Sources ===<br />
<br />
You'll need the vanilla kernel sources (i.e. those from [http://www.kernel.org kernel.org]) and (of course) a Linux-VServer patch for the kernel version you intend to use. You can find links to both files in our [[Downloads]] section. (Note that for recent kernels, only development versions of the vserver patch exist. You can obtain these from [http://vserver.13thfloor.at/Experimental http://vserver.13thfloor.at/Experimental].)<br />
<br />
<br />
In this document we will use Linux 2.6.22.19 with Linux-VServer 2.2.0.7.<br />
<br />
First, you have to create a directory for the sources, if you already have one, feel free to skip this step and/or adjust the paths to your needs.<br />
<br />
<pre><br />
# Create a directory for our sources<br />
mkdir ~/src<br />
<br />
# Switch to that directory<br />
cd ~/src<br />
</pre><br />
<br />
Now that we have a place to store our sources, we need to fetch them. We start with the vanilla sources.<br />
<br />
<pre><br />
# Get Linux 2.6.22.19 sources<br />
wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.22.19.tar.bz2<br />
<br />
# Extract them<br />
tar xjf linux-2.6.22.19.tar.bz2<br />
</pre><br />
<br />
Now it is time to get the Linux-VServer patch and apply it to the sources. While we're at it, I tell you a nice trick I learned from Bertl, that allows you to keep a lot of source trees on your disk without using up lots of disk space (and this also speeds up 'diff' a lot, which is really nice if you do kernel-hacking). What we do is creating a hard-linked copy of our sources and patch this copy with the Linux-VServer patch. That way, only the patched files use additional disk space (and because hard-linked files are equal by definition, diff doesn't need to compare them).<br />
<br />
<pre><br />
# Get the Linux-VServer 2.2.0.7 patch<br />
wget http://ftp.linux-vserver.org/pub/kernel/vs2.2/patch-2.6.22.19-vs2.2.0.7.diff<br />
<br />
# Create a hard-linked copy of the vanilla sources, this will get the Linux-VServer patch applied<br />
cp -la linux-2.6.22.19 linux-2.6.22.19-vs2.2.0.7<br />
<br />
# Switch to that new directory<br />
cd linux-2.6.22.19-vs2.2.0.7<br />
<br />
# Patch the sources<br />
cat ../patch-2.6.22.19-vs2.2.0.7.diff | patch -p1<br />
</pre><br />
<br />
Now you have two sources, the vanilla sources for 2.6.22.19 and the Linux-VServer sources for 2.6.22.19-vs2.2.0.7. You might ask "Why do I need two source trees at all? I only want one kernel!" and that's a good question.<br />
<br />
Here's one answer: Updates! If a new vanilla kernel is released, you can just download the patch from your version to the new version. Otherwise, if you would have applied the patch to your one and only vanilla source tree, you would not be able to do this. The same applies for new Linux-VServer releases. That is, if a new Linux-VServer patch is available, you can simply create another hardlinked copy of your vanilla sources and apply the new patch using the copy. This can really save you time (and bandwidth), since you can keep everything you might need, without wasting a lot of disk space.<br />
<br />
But be aware that this needs some discipline when hacking the source. Because hard-linked files share the same data on the disk, you need to make sure that your editor does ''The Right Thing'', otherwise you might mess up all your source trees...<br />
<br />
An even better way of dealing with this, if using more disk space is not a big issue, is to use a version control system. [http://git-scm.com/ Git], for example, is specifically designed for dealing with a project with many different but similar versions, and is in fact used to handle the source code of the Linux kernel itself. Rather than downloading and extract a tarfile, it's possible to directly copy the kernel sources from the Git repository at [git.kernel.org] into your own local repository.<br />
<br />
=== Configuring the Kernel ===<br />
<br />
Under Ubuntu (on 8.04 Hardy x86_64 tested) the configuration files of the existing kernel can be found in the /boot directory with a name similar to: config-'uname -r'-general. This file can be used if copied to the source dir of the kernel as a starting point to configure the rest of the kernel. The filename must be <tt>.config</tt>.<br />
<br />
Now go to your kernel source directory and execute <tt>make menuconfig</tt>. This will fire up an ncurses-based configuration menu. (Of course you can use whatever configuration method you like, there is a text based one (make config), a GTK based one (make gconfig), and even a QT based one (make xconfig)). <tt>make oldconfig</tt> is particularly useful because it only asks you about kernel options that are supported by the kernel but that don't already have a value assigned to them in your <tt>.config</tt>. Looking through all the available options can be tedious; <tt>make oldconfig</tt> saves you time by only showing new the new ones (in this case, vserver-related options).<br />
<br />
<pre><br />
# Configure the kernel using a ncurses based menu<br />
make menuconfig<br />
</pre><br />
<br />
It is out of the scope of this guide to explain all the available configuration options. If you feel unsure about certain options, either use the default value, or consult your distribution manuals and the documentation shipped with the kernel for help.<br />
<br />
Nevertheless, we will explain the Linux-VServer configuration options, of course. Depending on your version your configuration options may look similar to the following:<br />
<br />
<pre><br />
Linux VServer ---><br />
[*] Enable Legacy Kernel API (<2.3)<br />
[ ] Show a Legacy Version ID<br />
[*] Enable dynamic context IDs (2.1 - 2.2)<br />
[ ] Disable Legacy Networking Kernel API (2.0.x only)<br />
[*] Enable Legacy Networking Kernel API (2.1 - 2.2)<br />
[*] Automatically Assign Loopback IP (2.3+)<br />
[*] Automatic Single IP Special Casing (2.3+)<br />
[ ] Remap Source IP Address (<2.3)<br />
[*] Enable COW Immutable Link Breaking (2.1+)<br />
[ ] Enable Virtualized Guest Time (2.1+)<br />
[ ] Enable Guest Device Mapping (2.1, 2.3)<br />
[*] Enable Proc Security<br />
[ ] Enable Hard CPU Limits<br />
[ ] Avoid idle CPUs by skipping Time (2.1+)<br />
[ ] Limit the IDLE task<br />
Persistent Inode Tagging (UID24/GID24) ---><br />
[ ] Tag NFSD User Auth and Files<br />
[ ] Enable Inode Tag Propagation (2.1+)<br />
[ ] Honor Privacy Aspects of Guests (2.1+)<br />
[256] Maximum number of Contexts (1-65533) (2.2+)<br />
[*] VServer Warnings (2.2+)<br />
[ ] VServer Debugging Code<br />
[ ] VServer History Tracing<br />
(64) Per-CPU History Size (32-65536)<br />
[ ] VServer Scheduling Monitor (2.1+)<br />
(1024) Per-CPU Monitor Queue Size (32-65536) (2.1+)<br />
(256) Per-CPU Monitor Sync Interval (0-65536) (2.1+)<br />
</pre><br />
<br />
; Enable Legacy Kernel API<br />
: This enables the legacy API used in vs1.xx, maintaining compatibility with older vserver tools, and guest images that are configured using the legacy method. You shouldn't enable it for new linux-vserver installations.<br />
<br />
; Show a Legacy Version ID<br />
: This shows a special legacy version to very old tools which do not handle the current version correctly. This will probably disable some features of newer tools so better avoid it, unless you really, really need it for backwards compatibility.<br />
<br />
; Enable dynamic context IDs<br />
: This enables support for in-kernel dynamic context IDs which are deprecated and soon to be removed.<br />
<br />
; Enable/Disable Legacy Networking Kernel API<br />
: This enables/disables the legacy networking API which is required by the chbind tool in util-vserver <= 0.30.209. That is a fairly old version of util-vserver, so unless you know you'll be using something that ancient, feel free to disable this option.<br />
<br />
; Automatically Assign Loopback IP<br />
: Enable this to get a unique 127.x.y.1(x.y matches the context id) address for each network context automatically, and enable the NXF_LBACK_REMAP and NXF_HIDE_LBACK flags. This creates a per-guest, isolated 127.0.0.1 address. This has the side effect that services bound to 127.0.0.1 on the host will be inaccessible from guests by default; be sure this is what you want before enabling this option.<br />
<br />
; Automatic Single IP Special Casing<br />
: Enabling this option will make the kernel automatically set NXF_SINGLE_IP for contexts which have only one IP address (note: a loopback address does not count). (TODO: add a link here to a page that explains what NXF_SINGLE_IP does, or briefly explain it here.)<br />
<br />
; Remap Source IP Address<br />
: This allows to remap the source IP address of 'local' connections from 127.0.0.1 to the first assigned guest IP.<br />
<br />
; Enable COW Immutable Link Breaking<br />
: This enables the COW (Copy-On-Write) link break code. It allows you to treat [[Unification|unified files]] like normal files when writing to them (which will implicitly break the link and create a copy of the unified file). Note that this currently doesn't work on xfs; on xfs, the new copy of the unified file will contain only binary zeroes.<br />
<br />
; Enable Virtualized Guest Time<br />
: This enables per guest time offsets to allow for adjusting the system clock individually per guest. This adds some overhead to the time functions and therefore should not be enabled without good reason.<br />
<br />
; Enable Guest Device Mapping<br />
: This enables a generic remapping/access control interface for device nodes used inside the guest. For example, you could rewrite a guest's attempts to use /dev/hda to /dev/sda. This is normally not needed; guests don't normally use device nodes associated with physical hardware at all. (Of course, remapping can also be applied to device nodes that don't correspond to physical hardware.)<br />
<br />
; Enable Proc Security<br />
: This configures [[Secure ProcFS Entries|ProcFS security]] to initially hide non-process entries for all contexts except the main and spectator context (i.e. for all guests), which is a secure default.<br />
<br />
; Enable Hard CPU Limits<br />
: This will compile in code that allows the [[CPU Scheduler|Token Bucket Scheduler]] to put processes on hold when a context's tokens are depleted (provided that its per-context sched_hard flag is set).<br />
<br />
; Avoid idle CPUs by skipping Time<br />
: This option allows the scheduler to artificially advance time (per cpu) when otherwise the idle task would be scheduled, thus keeping the cpu busy and sharing the available resources among certain contexts.<br />
<br />
; Limit the IDLE task<br />
: Limit the idle slices, so the the next context will be scheduled as soon as possible. This might improve interactivity and latency, but will also marginally increase scheduling overhead.<br />
<br />
; Persistent Inode Tagging<br />
: This adds persistent context information to filesystems mounted with the tagxid option. [[Filesystem Tagging|Tagging]] is a requirement for per-context [[Disk Limits and Quota]].<br />
<br />
; Tag NFSD User Auth and Files<br />
: Enable this if you do want the in-kernel NFS Server to use the xid tagging specified above.<br />
<br />
; Enable Inode Tag Propagation<br />
: This allows for the tagid= mount option to specify a tagid which is to be used for the entire mount tree.<br />
<br />
; Honor Privacy Aspects of Guests<br />
: When enabled, most context checks will disallow access to structures assigned to a specific context, like ptys or loop devices.<br />
<br />
; Maximum number of Contexts<br />
: This makes sure that at least this many contexts can be created, by making sure that this much per-CPU memory is available.<br />
<br />
; VServer Warnings<br />
: Enables warnings (sent to the kernel log during runtime). There's really no good reason to disable this.<br />
<br />
; VServer Debugging Code<br />
: Set this to yes if you want to be able to activate debugging output at runtime. It adds a probably small overhead to all vserver related functions and increases the kernel size by about 20k.<br />
<br />
; VServer History Tracing<br />
: This records a history of Linux-VServer events that can be replayed in the event of a panic or an oops.<br />
<br />
; Per-CPU History Size<br />
: This allows you to set the size of the per-CPU history buffer.<br />
<br />
; VServer Scheduling Monitor<br />
: Set this to yes if you want to record the scheduling decisions, so that they can be relayed to userspace for detailed analysis.<br />
<br />
; Per-CPU Monitor Queue Size<br />
: This allows you to specify the number of entries in the per-CPU scheduling monitor buffer.<br />
<br />
; Per-CPU Monitor Sync Interval<br />
: This allows you to specify the interval in ticks when a time sync entry is inserted.<br />
<br />
=== Compiling and Installing ===<br />
<br />
Now that your kernel is configured, it is time to compile and install it. Exit the configuration and start the compilation process: <br />
<br />
<pre><br />
# make && make modules_install<br />
</pre><br />
<br />
(Note: this will copy the resulting modules to your filesystem directly, bypassing any package manager you may have. It may be a better idea to build a kernel package you can install using your package manager. For rpm-based distributions, <tt>make rpm</tt> might work; dpkg-based distributions provide a package called <tt>kernel-package</tt> which you can use. We won't be covering these methods here.)<br />
<br />
If you don't happen to have a really fast box, it is a good time to get a new cup of coffee now ;)<br />
<br />
When the kernel has finished compiling, you have to copy the kernel image to your /boot partition and configure your boot loader. If you don't know how to do this, please consult your distribution manual or ask [http://www.google.com Google] for help.<br />
<br />
== Manual util-vserver Compilation ==<br />
<br />
The kernel alone does not help you, you also need some tools to exploit all those new features you got, so let's get them.<br />
<br />
=== Getting the Sources ===<br />
<br />
You will have to download the latest util-vserver source tarball from our [[Downloads]] section. In this guide we will use util-vserver-0.30.215, but note that for recent kernels and especially development versions of the vserver kernel patch, you'll need a much more recent development version from [http://people.linux-vserver.org/~dhozac/t/uv-testing/|http://people.linux-vserver.org/~dhozac/t/uv-testing/].<br />
<br />
As a first step, of course, we need to get the sources.<br />
<br />
<pre><br />
# Go to our source directory<br />
cd ~/src<br />
<br />
# Get the sources for util-vserver<br />
wget http://ftp.linux-vserver.org/pub/utils/util-vserver/util-vserver-0.30.215.tar.bz2<br />
<br />
# Extract the sources<br />
tar xjf util-vserver-0.30.215.tar.bz2<br />
</pre><br />
<br />
=== Compiling and Installing ===<br />
<br />
Now that we have extracted the util-vserver source we have to do the usual configure, make, make install chain. While configuring the tools you may get some error messages about missing stuff, for example dietlibc, vconfig and e2fs headers. The error messages are accompanied by explanations what you should do, so read them carefully.<br />
<br />
<pre><br />
# Switch to the util-vserver source directory<br />
cd util-vserver-0.30.215<br />
<br />
# Configure the sources (you may want to adjust settings here, the defaults work, but may not suit your needs)<br />
./configure --prefix=... --sysconfdir=... --localstatedir=...<br />
<br />
# Build the tools<br />
make<br />
<br />
# Install the tools<br />
make install install-distribution<br />
<br />
# It's a good point to fix the /proc entries for the guests<br />
/etc/init.d/vprocunhide restart (this path depends on configuration, see output of 'vserver-info')<br />
</pre><br />
<br />
=== Enabling VServers on startup ===<br />
<br />
You need to enable 2 initscripts:<br />
* <code>vprocunhide</code> - does necessary stuff in <code>/proc</code><br />
* <code>vservers-default</code> - runs vservers marked as 'default' (<code>echo "default" > /etc/vservers/XXX/apps/init/mark</code>) on startup<br />
<br />
To do so, you can use 'update-rc.d' or 'rcconf' (Debian), 'chkconfig' or 'ntsysv' (Fedora).<br />
<br />
If you get errors like:<br />
<pre><br />
/proc/uptime can not be accessed. Usually, this is caused by<br />
procfs-security. Please read the FAQ for more details<br />
http://linux-vserver.org/Proc-Security<br />
</pre><br />
then you probably need to enable <code>vprocunhide</code>.<br />
<br />
=== Testing your setup ===<br />
<br />
To ensure that your setup works we have created two small test scripts. The testme.sh script ensures basic functionality whereas the testfs.sh script is for inode attribute testing for various filesystems.<br />
<br />
<pre><br />
# get the script<br />
wget http://vserver.13thfloor.at/Stuff/SCRIPT/testme.sh<br />
<br />
# make it executable<br />
chmod +x testme.sh<br />
<br />
# run the test script<br />
./testme.sh<br />
</pre><br />
<br />
'''Be careful! The testfs.sh script might easily reformat your hard disk :)'''<br />
<br />
<pre><br />
# get the script<br />
wget http://vserver.13thfloor.at/Stuff/SCRIPT/testfs.sh<br />
<br />
# make it executable<br />
chmod +x testfs.sh<br />
<br />
# make a loopback file<br />
dd bs=1024k count=1024 if=/dev/zero of=1gb.testfile<br />
<br />
# setup the loopback<br />
losetup /dev/loop0 1gb.testfile<br />
<br />
# run the test script for legacy mode<br />
./testfs.sh -l -t -D /dev/loop0 -M /mnt<br />
<br />
# run the test script for new-style config<br />
./testfs.sh -t -D /dev/loop0 -M /mnt<br />
</pre><br />
<br />
If the scripts show any error, be sure to read [[Report a Bug|how to report a bug]] and contact the Linux-VServer Developers for help. See [[Communicate]] for details.<br />
<br />
== Where to go from here ==<br />
<br />
Now that your setup is complete and working as expected, it is time to create your first guest system. Read on at [[Building Guest Systems]].</div>KornAndrashttp://wiki.linux-vserver.org/Installation_on_Linux_2.6Installation on Linux 2.62010-09-20T07:31:25Z<p>KornAndras: Many added comments and explanations; fix grammar in some places; reference http://people.linux-vserver.org/~dhozac/t/uv-testing/</p>
<hr />
<div>This guide will explain how to install a Linux-VServer kernel and util-vserver manually from source. It is assumed that you have basic knowledge about building a custom kernel, i.e. that you know which stuff to turn on in the kernel configuration. Of course some Linux-VServer specific options are explained here.<br />
<br />
== Manual Kernel Compilation ==<br />
<br />
You might ask yourself, why should I build a custom kernel? Manually configuring a kernel is often seen as the most difficult procedure a Linux user ever has to perform. Nothing is less true -- after configuring a couple of kernels you don't even remember that it was difficult ;)<br />
<br />
However, one thing is true: you must know your system when you start configuring a kernel manually. <br />
<br />
There are good reasons to build your kernel manually:<br />
<br />
* Your distribution does not have a prebuilt Linux-VServer kernel<br />
** or maybe it does, but it hasn't been compiled with the options you need<br />
* Your distribution does not have the latest and greatest<br />
* You don't want to install bloated prebuilt kernels<br />
* You want a monolithic kernel and your distribution uses modules<br />
* You can tell everyone that you built your kernels manually ;)<br />
<br />
If you still don't want to build your own kernel, have a look at our [[Documentation]] section for how to install a prebuilt Linux-VServer kernel for your distribution. Otherwise, read on.<br />
<br />
=== Getting the Sources ===<br />
<br />
You'll need the vanilla kernel sources (i.e. those from [http://www.kernel.org kernel.org]) and (of course) a Linux-VServer patch for the kernel version you intend to use. You can find links to both files in our [[Downloads]] section.<br />
<br />
In this document we will use Linux 2.6.22.19 with Linux-VServer 2.2.0.7.<br />
<br />
First, you have to create a directory for the sources, if you already have one, feel free to skip this step and/or adjust the paths to your needs.<br />
<br />
<pre><br />
# Create a directory for our sources<br />
mkdir ~/src<br />
<br />
# Switch to that directory<br />
cd ~/src<br />
</pre><br />
<br />
Now that we have a place to store our sources, we need to fetch them. We start with the vanilla sources.<br />
<br />
<pre><br />
# Get Linux 2.6.22.19 sources<br />
wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.22.19.tar.bz2<br />
<br />
# Extract them<br />
tar xjf linux-2.6.22.19.tar.bz2<br />
</pre><br />
<br />
Now it is time to get the Linux-VServer patch and apply it to the sources. While we're at it, I tell you a nice trick I learned from Bertl, that allows you to keep a lot of source trees on your disk without using up lots of disk space (and this also speeds up 'diff' a lot, which is really nice if you do kernel-hacking). What we do is creating a hard-linked copy of our sources and patch this copy with the Linux-VServer patch. That way, only the patched files use additional disk space (and because hard-linked files are equal by definition, diff doesn't need to compare them).<br />
<br />
<pre><br />
# Get the Linux-VServer 2.2.0.7 patch<br />
wget http://ftp.linux-vserver.org/pub/kernel/vs2.2/patch-2.6.22.19-vs2.2.0.7.diff<br />
<br />
# Create a hard-linked copy of the vanilla sources, this will get the Linux-VServer patch applied<br />
cp -la linux-2.6.22.19 linux-2.6.22.19-vs2.2.0.7<br />
<br />
# Switch to that new directory<br />
cd linux-2.6.22.19-vs2.2.0.7<br />
<br />
# Patch the sources<br />
cat ../patch-2.6.22.19-vs2.2.0.7.diff | patch -p1<br />
</pre><br />
<br />
(Note that for recent kernels, only development versions of the vserver patch exist. You can obtain these from [http://vserver.13thfloor.at/Experimental|http://vserver.13thfloor.at/Experimental].)<br />
<br />
Now you have two sources, the vanilla sources for 2.6.22.19 and the Linux-VServer sources for 2.6.22.19-vs2.2.0.7. You might ask "Why do I need two source trees at all? I only want one kernel!" and that's a good question.<br />
<br />
Here's one answer: Updates! If a new vanilla kernel is released, you can just download the patch from your version to the new version. Otherwise, if you would have applied the patch to your one and only vanilla source tree, you would not be able to do this. The same applies for new Linux-VServer releases. That is, if a new Linux-VServer patch is available, you can simply create another hardlinked copy of your vanilla sources and apply the new patch using the copy. This can really save you time (and bandwidth), since you can keep everything you might need, without wasting a lot of disk space.<br />
<br />
But be aware that this needs some discipline when hacking the source. Because hard-linked files share the same data on the disk, you need to make sure that your editor does ''The Right Thing'', otherwise you might mess up all your source trees...<br />
<br />
An even better way of dealing with this, if using more disk space is not a big issue, is to use a version control system. [http://git-scm.com/ Git], for example, is specifically designed for dealing with a project with many different but similar versions, and is in fact used to handle the source code of the Linux kernel itself. Rather than downloading and extract a tarfile, it's possible to directly copy the kernel sources from the Git repository at [git.kernel.org] into your own local repository.<br />
<br />
=== Configuring the Kernel ===<br />
<br />
Under Ubuntu (on 8.04 Hardy x86_64 tested) the configuration files of the existing kernel can be found in the /boot directory with a name similar to: config-'uname -r'-general. This file can be used if copied to the source dir of the kernel as a starting point to configure the rest of the kernel. The filename must be <tt>.config</tt>.<br />
<br />
Now go to your kernel source directory and execute <tt>make menuconfig</tt>. This will fire up an ncurses-based configuration menu. (Of course you can use whatever configuration method you like, there is a text based one (make config), a GTK based one (make gconfig), and even a QT based one (make xconfig)). <tt>make oldconfig</tt> is particularly useful because it only asks you about kernel options that are supported by the kernel but that don't already have a value assigned to them in your <tt>.config</tt>. Looking through all the available options can be tedious; <tt>make oldconfig</tt> saves you time by only showing new the new ones (in this case, vserver-related options).<br />
<br />
<pre><br />
# Configure the kernel using a ncurses based menu<br />
make menuconfig<br />
</pre><br />
<br />
It is out of the scope of this guide to explain all the available configuration options. If you feel unsure about certain options, either use the default value, or consult your distribution manuals and the documentation shipped with the kernel for help.<br />
<br />
Nevertheless, we will explain the Linux-VServer configuration options, of course. Depending on your version your configuration options may look similar to the following:<br />
<br />
<pre><br />
Linux VServer ---><br />
[*] Enable Legacy Kernel API (<2.3)<br />
[ ] Show a Legacy Version ID<br />
[*] Enable dynamic context IDs (2.1 - 2.2)<br />
[ ] Disable Legacy Networking Kernel API (2.0.x only)<br />
[*] Enable Legacy Networking Kernel API (2.1 - 2.2)<br />
[*] Automatically Assign Loopback IP (2.3+)<br />
[*] Automatic Single IP Special Casing (2.3+)<br />
[ ] Remap Source IP Address (<2.3)<br />
[*] Enable COW Immutable Link Breaking (2.1+)<br />
[ ] Enable Virtualized Guest Time (2.1+)<br />
[ ] Enable Guest Device Mapping (2.1, 2.3)<br />
[*] Enable Proc Security<br />
[ ] Enable Hard CPU Limits<br />
[ ] Avoid idle CPUs by skipping Time (2.1+)<br />
[ ] Limit the IDLE task<br />
Persistent Inode Tagging (UID24/GID24) ---><br />
[ ] Tag NFSD User Auth and Files<br />
[ ] Enable Inode Tag Propagation (2.1+)<br />
[ ] Honor Privacy Aspects of Guests (2.1+)<br />
[256] Maximum number of Contexts (1-65533) (2.2+)<br />
[*] VServer Warnings (2.2+)<br />
[ ] VServer Debugging Code<br />
[ ] VServer History Tracing<br />
(64) Per-CPU History Size (32-65536)<br />
[ ] VServer Scheduling Monitor (2.1+)<br />
(1024) Per-CPU Monitor Queue Size (32-65536) (2.1+)<br />
(256) Per-CPU Monitor Sync Interval (0-65536) (2.1+)<br />
</pre><br />
<br />
; Enable Legacy Kernel API<br />
: This enables the legacy API used in vs1.xx, maintaining compatibility with older vserver tools, and guest images that are configured using the legacy method. You shouldn't enable it for new linux-vserver installations.<br />
<br />
; Show a Legacy Version ID<br />
: This shows a special legacy version to very old tools which do not handle the current version correctly. This will probably disable some features of newer tools so better avoid it, unless you really, really need it for backwards compatibility.<br />
<br />
; Enable dynamic context IDs<br />
: This enables support for in-kernel dynamic context IDs which are deprecated and soon to be removed.<br />
<br />
; Enable/Disable Legacy Networking Kernel API<br />
: This enables/disables the legacy networking API which is required by the chbind tool in util-vserver <= 0.30.209. That is a fairly old version of util-vserver, so unless you know you'll be using something that ancient, feel free to disable this option.<br />
<br />
; Automatically Assign Loopback IP<br />
: Enable this to get a unique 127.x.y.1(x.y matches the context id) address for each network context automatically, and enable the NXF_LBACK_REMAP and NXF_HIDE_LBACK flags. This creates a per-guest, isolated 127.0.0.1 address. This has the side effect that services bound to 127.0.0.1 on the host will be inaccessible from guests by default; be sure this is what you want before enabling this option.<br />
<br />
; Automatic Single IP Special Casing<br />
: Enabling this option will make the kernel automatically set NXF_SINGLE_IP for contexts which have only one IP address (note: a loopback address does not count). (TODO: add a link here to a page that explains what NXF_SINGLE_IP does, or briefly explain it here.)<br />
<br />
; Remap Source IP Address<br />
: This allows to remap the source IP address of 'local' connections from 127.0.0.1 to the first assigned guest IP.<br />
<br />
; Enable COW Immutable Link Breaking<br />
: This enables the COW (Copy-On-Write) link break code. It allows you to treat [[Unification|unified files]] like normal files when writing to them (which will implicitly break the link and create a copy of the unified file). Note that this currently doesn't work on xfs; on xfs, the new copy of the unified file will contain only binary zeroes.<br />
<br />
; Enable Virtualized Guest Time<br />
: This enables per guest time offsets to allow for adjusting the system clock individually per guest. This adds some overhead to the time functions and therefore should not be enabled without good reason.<br />
<br />
; Enable Guest Device Mapping<br />
: This enables a generic remapping/access control interface for device nodes used inside the guest. For example, you could rewrite a guest's attempts to use /dev/hda to /dev/sda. This is normally not needed; guests don't normally use device nodes associated with physical hardware at all. (Of course, remapping can also be applied to device nodes that don't correspond to physical hardware.)<br />
<br />
; Enable Proc Security<br />
: This configures [[Secure ProcFS Entries|ProcFS security]] to initially hide non-process entries for all contexts except the main and spectator context (i.e. for all guests), which is a secure default.<br />
<br />
; Enable Hard CPU Limits<br />
: This will compile in code that allows the [[CPU Scheduler|Token Bucket Scheduler]] to put processes on hold when a context's tokens are depleted (provided that its per-context sched_hard flag is set).<br />
<br />
; Avoid idle CPUs by skipping Time<br />
: This option allows the scheduler to artificially advance time (per cpu) when otherwise the idle task would be scheduled, thus keeping the cpu busy and sharing the available resources among certain contexts.<br />
<br />
; Limit the IDLE task<br />
: Limit the idle slices, so the the next context will be scheduled as soon as possible. This might improve interactivity and latency, but will also marginally increase scheduling overhead.<br />
<br />
; Persistent Inode Tagging<br />
: This adds persistent context information to filesystems mounted with the tagxid option. [[Filesystem Tagging|Tagging]] is a requirement for per-context [[Disk Limits and Quota]].<br />
<br />
; Tag NFSD User Auth and Files<br />
: Enable this if you do want the in-kernel NFS Server to use the xid tagging specified above.<br />
<br />
; Enable Inode Tag Propagation<br />
: This allows for the tagid= mount option to specify a tagid which is to be used for the entire mount tree.<br />
<br />
; Honor Privacy Aspects of Guests<br />
: When enabled, most context checks will disallow access to structures assigned to a specific context, like ptys or loop devices.<br />
<br />
; Maximum number of Contexts<br />
: This makes sure that at least this many contexts can be created, by making sure that this much per-CPU memory is available.<br />
<br />
; VServer Warnings<br />
: Enables warnings (sent to the kernel log during runtime). There's really no good reason to disable this.<br />
<br />
; VServer Debugging Code<br />
: Set this to yes if you want to be able to activate debugging output at runtime. It adds a probably small overhead to all vserver related functions and increases the kernel size by about 20k.<br />
<br />
; VServer History Tracing<br />
: This records a history of Linux-VServer events that can be replayed in the event of a panic or an oops.<br />
<br />
; Per-CPU History Size<br />
: This allows you to set the size of the per-CPU history buffer.<br />
<br />
; VServer Scheduling Monitor<br />
: Set this to yes if you want to record the scheduling decisions, so that they can be relayed to userspace for detailed analysis.<br />
<br />
; Per-CPU Monitor Queue Size<br />
: This allows you to specify the number of entries in the per-CPU scheduling monitor buffer.<br />
<br />
; Per-CPU Monitor Sync Interval<br />
: This allows you to specify the interval in ticks when a time sync entry is inserted.<br />
<br />
=== Compiling and Installing ===<br />
<br />
Now that your kernel is configured, it is time to compile and install it. Exit the configuration and start the compilation process: <br />
<br />
<pre><br />
# make && make modules_install<br />
</pre><br />
<br />
(Note: this will copy the resulting modules to your filesystem directly, bypassing any package manager you may have. It may be a better idea to build a kernel package you can install using your package manager. For rpm-based distributions, <tt>make rpm</tt> might work; dpkg-based distributions provide a package called <tt>kernel-package</tt> which you can use. We won't be covering these methods here.)<br />
<br />
If you don't happen to have a really fast box, it is a good time to get a new cup of coffee now ;)<br />
<br />
When the kernel has finished compiling, you have to copy the kernel image to your /boot partition and configure your boot loader. If you don't know how to do this, please consult your distribution manual or ask [http://www.google.com Google] for help.<br />
<br />
== Manual util-vserver Compilation ==<br />
<br />
The kernel alone does not help you, you also need some tools to exploit all those new features you got, so let's get them.<br />
<br />
=== Getting the Sources ===<br />
<br />
You will have to download the latest util-vserver source tarball from our [[Downloads]] section. In this guide we will use util-vserver-0.30.215, but note that for recent kernels and especially development versions of the vserver kernel patch, you'll need a much more recent development version from [http://people.linux-vserver.org/~dhozac/t/uv-testing/|http://people.linux-vserver.org/~dhozac/t/uv-testing/].<br />
<br />
As a first step, of course, we need to get the sources.<br />
<br />
<pre><br />
# Go to our source directory<br />
cd ~/src<br />
<br />
# Get the sources for util-vserver<br />
wget http://ftp.linux-vserver.org/pub/utils/util-vserver/util-vserver-0.30.215.tar.bz2<br />
<br />
# Extract the sources<br />
tar xjf util-vserver-0.30.215.tar.bz2<br />
</pre><br />
<br />
=== Compiling and Installing ===<br />
<br />
Now that we have extracted the util-vserver source we have to do the usual configure, make, make install chain. While configuring the tools you may get some error messages about missing stuff, for example dietlibc, vconfig and e2fs headers. The error messages are accompanied by explanations what you should do, so read them carefully.<br />
<br />
<pre><br />
# Switch to the util-vserver source directory<br />
cd util-vserver-0.30.215<br />
<br />
# Configure the sources (you may want to adjust settings here, the defaults work, but may not suit your needs)<br />
./configure --prefix=... --sysconfdir=... --localstatedir=...<br />
<br />
# Build the tools<br />
make<br />
<br />
# Install the tools<br />
make install install-distribution<br />
<br />
# It's a good point to fix the /proc entries for the guests<br />
/etc/init.d/vprocunhide restart (this path depends on configuration, see output of 'vserver-info')<br />
</pre><br />
<br />
=== Enabling VServers on startup ===<br />
<br />
You need to enable 2 initscripts:<br />
* <code>vprocunhide</code> - does necessary stuff in <code>/proc</code><br />
* <code>vservers-default</code> - runs vservers marked as 'default' (<code>echo "default" > /etc/vservers/XXX/apps/init/mark</code>) on startup<br />
<br />
To do so, you can use 'update-rc.d' or 'rcconf' (Debian), 'chkconfig' or 'ntsysv' (Fedora).<br />
<br />
If you get errors like:<br />
<pre><br />
/proc/uptime can not be accessed. Usually, this is caused by<br />
procfs-security. Please read the FAQ for more details<br />
http://linux-vserver.org/Proc-Security<br />
</pre><br />
then you probably need to enable <code>vprocunhide</code>.<br />
<br />
=== Testing your setup ===<br />
<br />
To ensure that your setup works we have created two small test scripts. The testme.sh script ensures basic functionality whereas the testfs.sh script is for inode attribute testing for various filesystems.<br />
<br />
<pre><br />
# get the script<br />
wget http://vserver.13thfloor.at/Stuff/SCRIPT/testme.sh<br />
<br />
# make it executable<br />
chmod +x testme.sh<br />
<br />
# run the test script<br />
./testme.sh<br />
</pre><br />
<br />
'''Be careful! The testfs.sh script might easily reformat your hard disk :)'''<br />
<br />
<pre><br />
# get the script<br />
wget http://vserver.13thfloor.at/Stuff/SCRIPT/testfs.sh<br />
<br />
# make it executable<br />
chmod +x testfs.sh<br />
<br />
# make a loopback file<br />
dd bs=1024k count=1024 if=/dev/zero of=1gb.testfile<br />
<br />
# setup the loopback<br />
losetup /dev/loop0 1gb.testfile<br />
<br />
# run the test script for legacy mode<br />
./testfs.sh -l -t -D /dev/loop0 -M /mnt<br />
<br />
# run the test script for new-style config<br />
./testfs.sh -t -D /dev/loop0 -M /mnt<br />
</pre><br />
<br />
If the scripts show any error, be sure to read [[Report a Bug|how to report a bug]] and contact the Linux-VServer Developers for help. See [[Communicate]] for details.<br />
<br />
== Where to go from here ==<br />
<br />
Now that your setup is complete and working as expected, it is time to create your first guest system. Read on at [[Building Guest Systems]].</div>KornAndrashttp://wiki.linux-vserver.org/Running_runit-supervised_services_inside_a_vserverRunning runit-supervised services inside a vserver2009-11-23T19:57:09Z<p>KornAndras: Undo vandalism: revision 4084 by 200.166.248.132 (Talk)</p>
<hr />
<div>This page describes a setup where you have a [http://smarden.org/runit runit] installation on the host and use it to directly supervise services running in vserver guests.<br />
<br />
== Motivation and goals ==<br />
<br />
This is what I wanted to achieve:<br />
<br />
* Partition a physical server with many responsibilities into vservers that can easily be upgraded individually without breaking any unrelated stuff.<br />
* Each service or small set of services should run in its own vserver.<br />
* Services should be supervised (started, stopped and managed) by [http://smarden.org/runit runit].<br />
* Service logs should accumulate on the host, not the guests.<br />
** <tt>svlogd</tt> rotates them nicely and can invoke my <tt>multilogcheck</tt> script to alert me of unusual events as a postprocessor, but<br />
** I don't want to install <tt>multilogcheck</tt> inside every vserver because it's messy.<br />
** I don't like syslog. There are many problems with it, but I won't go into that here.<br />
*** Therefore, services mostly log to stdout and thus to svlogd.<br />
*** For services that absolutely must use syslog, I provide [http://smarden.org/socklog socklog].<br />
*** Again, I don't want a separate <tt>socklog</tt> instance in every vserver.<br />
*** Alas, <tt>socklog</tt> is unable to listen on more than one Unix domain socket.<br />
**** Luckily, <tt>socat</tt> can be used to relay syslog messages from the vservers to the master <tt>socklog</tt> on the host. (<tt>syslog-ng</tt> would also have done the job nicely.)<br />
**** It's also possible to bind mount the <tt>/dev/log</tt> socket in every guest; however, I'm afraid this breaks if you restart socklog after a guest is up. Workaround: make <tt>/dev/log</tt> a symlink to, say, <tt>/var/run/syslog/socket</tt> everywhere and bind mount the host's <tt>/var/run/syslog</tt> directory in the guests; that way the socket will still be available even if socklog unlinks and recreates it.<br />
* It should be straightforward and next to transparent to manage the services running in vservers.<br />
** With <tt>runit</tt>, it's easy to delegate management rights of a service to users (chown and chmod some files in the pertinent <tt>supervise</tt> directory). This should continue to work.<br />
<br />
== Prerequisites ==<br />
<br />
# A fairly recent vserver kernel with support for persistent contexts (I used 2.6.19.2-vs2.2.0-rc8.7).<br />
# A recent version of util-vserver that supports persistent contexts correctly (I used [http://people.linux-vserver.org/~dhozac/p/uv/experimental/util-vserver-0.30.213-rc1.tar.bz2 0.30.213-rc1]).<br />
# Daniel_Hozac's [http://people.linux-vserver.org/~dhozac/t/signal-relay.c signal-relay] program.<br />
<br />
== The big picture ==<br />
<br />
Let's see how it all fits together.<br />
<br />
We'd like to achieve something like this (output of <tt>vps axfu</tt>):<br />
<br />
<pre><br />
USER PID CONTEXT %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND<br />
root 1 0 MAIN 0.0 0.0 104 16 ? Ss Jan29 0:06 runit<br />
root 4188 0 MAIN 0.0 0.0 132 32 ? Ss Jan29 0:10 runsvdir -P /var/service log: .......................................................<br />
root 4250 0 MAIN 0.0 0.0 108 28 ? Ss Jan29 0:00 \_ runsv vserver-logrelay-squid<br />
log 4256 0 MAIN 0.0 0.0 128 44 ? S Jan29 0:00 | \_ svlogd -t /var/log/sv/vserver-logrelay-squid<br />
logrelay 3106 0 MAIN 0.0 0.1 25428 1944 ? S 00:44 0:00 | \_ socat -d -d -d -D -ls -u UNIX-LISTEN:/etc/vservers/squid/vdir/dev/log,unlink-early,nonblock,mode=666,setuid=logrelay UNIX-CONNECT:/dev/log,type=2,nonblock,forever<br />
root 19272 0 MAIN 0.0 0.0 108 28 ? Ss Feb01 0:00 \_ runsv squid<br />
log 19273 0 MAIN 0.0 0.0 128 44 ? S Feb01 0:00 | \_ svlogd -t /var/log/sv/squid<br />
root 10324 0 MAIN 0.0 0.0 5728 364 ? S Feb01 0:00 | \_ signal-relay vserver squid exec squid -N -D -sYC<br />
proxy 10334 2 squid 0.0 0.5 24968 8036 ? Sl Feb01 0:01 | \_ squid -N -D -sYC<br />
root 24219 0 MAIN 0.0 0.0 108 32 ? Ss 02:02 0:00 \_ runsv nmbd<br />
root 24220 0 MAIN 0.0 0.0 5732 376 ? S 02:02 0:00 | \_ signal-relay vserver samba exec /usr/sbin/nmbd -F<br />
root 24230 3 samba 0.0 0.1 30080 2360 ? Ss 02:02 0:00 | \_ /usr/sbin/nmbd -F<br />
root 24251 3 samba 0.0 0.0 32172 1496 ? S 02:02 0:00 | \_ /usr/sbin/nmbd -F<br />
root 24253 0 MAIN 0.0 0.0 108 28 ? Ss 02:02 0:00 \_ runsv smbd<br />
root 24254 0 MAIN 0.0 0.0 5732 376 ? S 02:02 0:00 | \_ signal-relay vserver samba exec /usr/sbin/smbd -F<br />
root 24268 3 samba 0.0 0.2 41888 3404 ? Ss 02:02 0:00 | \_ /usr/sbin/smbd -F<br />
root 24289 3 samba 0.0 0.0 41888 1232 ? S 02:02 0:00 | \_ /usr/sbin/smbd -F<br />
root 29625 0 MAIN 0.0 0.0 104 28 ? Ss 02:22 0:00 \_ runsv cron-squid<br />
root 29626 0 MAIN 0.0 0.0 5732 376 ? S 02:22 0:00 \_ signal-relay vserver squid exec cron -f<br />
root 29637 2 squid 0.0 0.0 11492 1060 ? S 02:22 0:00 \_ cron -f<br />
</pre><br />
<br />
For service supervision to work, we must be able to send signals to our services. Specifically, <tt>runsv</tt> must be able to send signals to its children.<br />
Alas, it's not prepared to send signals across context boundaries, which is where <tt>signal-relay</tt> comes in.<br />
<br />
=== <tt>signal-relay</tt> ===<br />
<br />
<tt>signal-relay</tt> is a small program not unlike <tt>runit</tt>'s <tt>chpst</tt> that does the following:<br />
<br />
* it forks a child;<br />
** inside the child, it execs the program specified on its command line;<br />
* in the parent, it sets up signal handlers for every signal that relay the signal to the child, even if the child is running in a different context;<br />
* if the child exits, <tt>signal-relay</tt> exits.<br />
* (It can also put the child into its own process group; use the <tt>-P</tt> switch. Sending signals to process groups in a different context doesn't work yet, though.)<br />
<br />
=== Setting up the vservers ===<br />
<br />
When we start a service for runit, we want the command that starts the service to stay in the foreground until the moment the service dies. <tt>vserver exec</tt> looks just right, but there is a catch: it only works for vservers that have been "started". <tt>vserver start</tt>, however, doesn't fit very well into the <tt>runit</tt> way of doing things. You can set it up as a service (this is discussed in [[util-vserver:InitStyles]]), but it seems superfluous to leave some processes around just to keep a vserver "started" so that we can run services in it.<br />
<br />
What we need is a way of basically doing "start vserver <guest> if it's not started, then exec program <service> inside it". Normally, a context with no processes running inside it is destroyed by the kernel; thus, just setting <tt>/etc/vservers/guest/apps/init/cmd.start</tt> to <tt>/bin/true</tt> isn't going to work; we would need something that stays around for a while, like a script that calls <tt>sleep 1m &</tt>. This would make <tt>vserver start</tt> happy, so in our service run script, we could do something like<br />
<br />
<pre><br />
vserver guest status || vserver guest start<br />
exec signal-relay vserver guest exec /path/to/service-program<br />
</pre><br />
<br />
A more elegant solution is to make the guest context ''persistent''. This way it sticks around even if there are no processes left in it.<br />
<br />
<pre><br />
cd /etc/vservers/guest<br />
echo persistent >>flags<br />
echo persistent >>nflags<br />
echo /bin/true >apps/init/cmd.start<br />
</pre><br />
<br />
(I ''guess'' <tt>nflags</tt> is for the network context.)<br />
<br />
Now, <tt>vserver guest start</tt> should be able to "start" our vserver (set up all of its state), and exit without leaving stray processes around.<br />
<br />
== Running services ==<br />
<br />
Say you have a vserver called <tt>squid</tt>, and you want to run your <tt>squid</tt> proxy inside it to keep it insulated from the other processes on the system, and vice versa.<br />
<br />
In our current setup, the following run script will do the trick (it borrows a bit from Debian's initscript and uses the Debian defaults file):<br />
<br />
<pre><br />
#!/bin/sh<br />
exec 2>&1<br />
<br />
# Set a default for max. filedescriptors<br />
SQUID_MAXFD=4096<br />
<br />
# Figure out the name of the service we're running as<br />
SVNAME=$(basename $(pwd))<br />
<br />
# Read the configfile of this service; if it sets VSERVERNAME, we'll assume we have to run inside the specified vserver<br />
CONFIG=/etc/default/"$SVNAME"<br />
[ -r "$CONFIG" ] && . "$CONFIG"<br />
<br />
# Source Debian defaults<br />
[ -n "$VSERVERNAME" ] && VROOT="/etc/vservers/$VSERVERNAME/vdir" || VROOT=/<br />
[ -r "$VROOT/etc/default/squid" ] && . "$VROOT/etc/default/squid"<br />
<br />
[ "$SQUID_MAXFD" -gt 4096 ] && SQUID_MAXFD=4096<br />
<br />
if test -f /proc/sys/fs/file-max; then<br />
global_file_max=$(cat /proc/sys/fs/file-max)<br />
minimal_file_max=$(($SQUID_MAXFD + 4096))<br />
[ "$global_file_max" -lt "$minimal_file_max" ] && echo "$minimal_file_max" >/proc/sys/fs/file-max<br />
fi<br />
<br />
if [ ! "$VSERVERNAME" = "" ]; then<br />
VSERVERARGS="signal-relay vserver $VSERVERNAME exec"<br />
vserver "$VSERVERNAME" status || vserver "$VSERVERNAME" start # start the vserver if necessary<br />
fi<br />
<br />
exec chpst -o"$SQUID_MAXFD" $VSERVERARGS squid -N -D -sYC<br />
</pre><br />
<br />
This script is generic in the sense that it works with or without a vserver setup.<br />
<br />
You can run an <tt>svlogd</tt> for this service like you normally would; or you could have all your <tt>svlogd</tt>s run in a different vserver.<br />
<br />
A run script for <tt>cron</tt> that automatically figures out if it should run in a vserver:<br />
<br />
<pre><br />
#!/bin/sh<br />
exec 2>&1<br />
DEPENDENCIES=""<br />
RLIMIT="chpst -t 172800"<br />
SVNAME=$(basename $(pwd))<br />
CONFIG=/etc/default/"$SVNAME"<br />
<br />
# Assume part after dash is name of vserver<br />
if [ ! "${SVNAME/*-/}" = "$SVNAME" ]; then<br />
VSERVERNAME="${SVNAME/*-/}"<br />
fi<br />
<br />
# By default, we depend on the socklog service if it exists<br />
[ -e /service/socklog ] && DEPENDENCIES=socklog<br />
<br />
# And also on the logrelay service of the pertinent vserver<br />
[ -e /service/vserver-logrelay-"$VSERVERNAME" ] && DEPENDENCIES="$DEPENDENCIES vserver-logrelay-$VSERVERNAME"<br />
<br />
# Can override VSERVERNAME, RLIMIT and DEPENDENCIES here if necessary<br />
[ -r "$CONFIG" ] && . "$CONFIG"<br />
<br />
if [ ! "$VSERVERNAME" = "" ]; then<br />
VSERVERARGS="signal-relay vserver $VSERVERNAME exec"<br />
vserver "$VSERVERNAME" status || vserver "$VSERVERNAME" start<br />
fi<br />
<br />
if [ -n "$DEPENDENCIES" ]; then<br />
sv start $DEPENDENCIES || exit 1<br />
fi<br />
<br />
exec $RLIMIT $VSERVERARGS cron -f<br />
</pre><br />
<br />
Now, if you place this run script in a service directory called <tt>cron-squid</tt>, it will run a cron daemon in the <tt>squid</tt> guest. This takes care of rotating the squid logs under <tt>/var/log/squid</tt>, for example; although this could also be done on the host with a few kludges.<br />
<br />
The vserver-logrelay-template/run script looks like this:<br />
<br />
<pre><br />
#!/bin/sh<br />
exec 2>&1<br />
SVNAME=$(basename $(pwd))<br />
RUNASUSER=logrelay<br />
MODE=666<br />
VSERVERNAME=$(echo $SVNAME | sed 's/vserver-logrelay-//')<br />
[ -r "/etc/default/$SVNAME" ] && . "/etc/default/$SVNAME"<br />
<br />
exec socat -d -d -d -D -ls -u \<br />
UNIX-LISTEN:/etc/vservers/$VSERVERNAME/vdir/dev/log,unlink-early,nonblock,mode=$MODE,setuid=$RUNASUSER \<br />
UNIX-CONNECT:/dev/log,type=2,nonblock,forever<br />
</pre><br />
<br />
This will pass syslog messages from a vserver to the syslog of the host by acting as a syslog server for the <tt>/dev/log</tt> socket of the guest. Thus, you don't need to run a <tt>syslogd</tt> inside the vserver and you don't need to migrate to <tt>syslog-ng</tt> from <tt>socklog</tt> on the host.<br />
<br />
Symlink this run script into a service directory called <tt>vserver-logrelay-squid</tt>.<br />
<br />
Unfortunately, <tt>socat</tt> has a largish memory footprint; something more lightweight could, perhaps, be used.<br />
<br />
Comments and additions welcome.<br />
<br />
== Disadvantages ==<br />
<br />
The most significant problem with this approach (as opposed to using initstyle plain and a separate runit instance in each vserver) is that it's no longer straightforward to manage the services running in vservers from inside the vservers; package management scripts can't stop them for upgrades, for example (unless you modify the initscripts in quite horrible ways).<br />
<br />
Initial setup is also slightly more complicated.<br />
<br />
These have to be weighed against the advantages of:<br />
<br />
* having fewer superfluous processes (like a separate <tt>runit</tt> and <tt>runsvdir</tt> in each vserver);<br />
* being able to manage the services easily from the host;<br />
* avoiding the need to run <tt>sshd</tt> inside each guest in order to be able to easily delegate service management privileges to others.<br />
<br />
Nowadays I tend to think the initstyle plain method is better after all.<br />
<br />
--[[User:KornAndras|Guy-]] 12:18, 28 September 2008 (CET)</div>KornAndrashttp://wiki.linux-vserver.org/Template:ExperimentalPatchTableMatrixTemplate:ExperimentalPatchTableMatrix2009-05-03T21:14:28Z<p>KornAndras: http://vserver.13thfloor.at/Experimental/patch-2.6.29.2-vs2.3.0.36.10.diff is for 2.6.29.2</p>
<hr />
<div>{| class="wikitable" style="margin: 2em auto 2em auto;"<br />
! Linux-VServer branch<br />
Linux kernel<br />
!class="devel"| 2.3<br />
Experimental<br />
! 2.3 + grsecurity<br />
Experimental<br />
|-<br />
| [http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.29.2.tar.bz2 2.6.29.2]<br />
| [http://vserver.13thfloor.at/Experimental/patch-2.6.29.2-vs2.3.0.36.10.diff vs2.3.0.36.10]<br />
|<br />
|-<br />
| [http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.28.9.tar.bz2 2.6.28.9]<br />
| [http://vserver.13thfloor.at/Experimental/patch-2.6.28.9-vs2.3.0.36.10.diff vs2.3.0.36.10]<br />
|<br />
|-<br />
| [http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.28.7.tar.bz2 2.6.28.7]<br />
| [http://vserver.13thfloor.at/Experimental/patch-2.6.28.7-vs2.3.0.36.8.diff vs2.3.0.36.8]<br />
| [http://harry.enzoverder.be/patch-2.6.28.7-vs2.3.0.36.7-grsec2.1.13-20090303.diff vs2.3.0.36.7-grsec2.1.13]<br />
|-<br />
| [http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.27.21.tar.bz2 2.6.27.21]<br />
| [http://vserver.13thfloor.at/Experimental/patch-2.6.27.21-vs2.3.0.36.4.diff vs2.3.0.36.4]<br />
|<br />
|-<br />
| [http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.27.15.tar.bz2 2.6.27.15]<br />
|<br />
| [http://harry.enzoverder.be/patch-2.6.27.15-vs2.3.0.36.4-grsec2.1.12-20090210.diff vs2.3.0.36.4-grsec2.1.12-20090210]<br />
|}</div>KornAndrashttp://wiki.linux-vserver.org/Template:ExperimentalPatchTableMatrixTemplate:ExperimentalPatchTableMatrix2009-05-03T21:14:00Z<p>KornAndras: updated to http://vserver.13thfloor.at/Experimental/patch-2.6.29.2-vs2.3.0.36.10.diff</p>
<hr />
<div>{| class="wikitable" style="margin: 2em auto 2em auto;"<br />
! Linux-VServer branch<br />
Linux kernel<br />
!class="devel"| 2.3<br />
Experimental<br />
! 2.3 + grsecurity<br />
Experimental<br />
|-<br />
| [http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.29.2.tar.bz2 2.6.29]<br />
| [http://vserver.13thfloor.at/Experimental/patch-2.6.29.2-vs2.3.0.36.10.diff vs2.3.0.36.10]<br />
|<br />
|-<br />
| [http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.28.9.tar.bz2 2.6.28.9]<br />
| [http://vserver.13thfloor.at/Experimental/patch-2.6.28.9-vs2.3.0.36.10.diff vs2.3.0.36.10]<br />
|<br />
|-<br />
| [http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.28.7.tar.bz2 2.6.28.7]<br />
| [http://vserver.13thfloor.at/Experimental/patch-2.6.28.7-vs2.3.0.36.8.diff vs2.3.0.36.8]<br />
| [http://harry.enzoverder.be/patch-2.6.28.7-vs2.3.0.36.7-grsec2.1.13-20090303.diff vs2.3.0.36.7-grsec2.1.13]<br />
|-<br />
| [http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.27.21.tar.bz2 2.6.27.21]<br />
| [http://vserver.13thfloor.at/Experimental/patch-2.6.27.21-vs2.3.0.36.4.diff vs2.3.0.36.4]<br />
|<br />
|-<br />
| [http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.27.15.tar.bz2 2.6.27.15]<br />
|<br />
| [http://harry.enzoverder.be/patch-2.6.27.15-vs2.3.0.36.4-grsec2.1.12-20090210.diff vs2.3.0.36.4-grsec2.1.12-20090210]<br />
|}</div>KornAndrashttp://wiki.linux-vserver.org/util-vserver:InitStylesutil-vserver:InitStyles2009-04-22T08:50:10Z<p>KornAndras: /* Using runit */ rewording</p>
<hr />
<div>Guests can be started using one of the following init styles:<br />
<br />
* plain<br />
** Launches a unique init process for the guest that appears to run as PID 1.<br />
** Guest's init process executes the rc scripts.<br />
** Therefore, you cannot watch the startup process.<br />
** However, any shutdown or restart command should work<br />
* sysv (default)<br />
** Executes the runlevel scripts directly.<br />
** You can watch the startup process.<br />
** Slightly lighter weight since no additional init process is needed.<br />
** The vserver sees a fake init with PID 1 that has the same properties as the real init on the host.<br />
** You must use "reboot -f" or "halt -f" to restart or shut down from within the guest.<br />
** Default start runlevel is 3, and stop is 6<br />
* gentoo<br />
** Like sysv but works on Gentoo-based guests.<br />
** Was deprecated but has been reinstated around util-vserver 0.30.212.<br />
* minit<br />
** Like plain init but smaller.<br />
** minit must be installed on the guest.<br />
** http://www.fefe.de/minit/<br />
<br />
=== Configuration ===<br />
<br />
The init style should go in a file containing a single word: sysv, plain, etc.<br />
<br />
/etc/vservers/<NAME>/apps/init/style<br />
<br />
If the file doesn't exist, sysv will be used. If the word isn't recognized, the guest will not be started and an error will be printed.<br />
<br />
=== Using runit ===<br />
<br />
[http://smarden.org/runit/ runit] is an init replacement that provides service monitoring. There currently are at least three ways to use it with vserver:<br />
<br />
* Set initstyle to plain; this allows you to launch your own <tt>runit</tt> inside the vserver.<br />
** This is the most straightforward way. Guests can shut themselves down and restart as usual. Disadvantage: once extra runit-init process per guest.<br />
* Use a persistent context for the guest, and just run the services inside it, not runit itself. This is discussed in [[Running runit-supervised services inside a vserver]].<br />
* Set initstyle to <tt>sysv</tt>, but <tt>cmd.start</tt> to "<tt>/etc/runit/2</tt>" and <tt>cmd.stop</tt> to "<tt>/etc/runit/3</tt>".<br />
** Advantage: you can run a vserver supervised by <tt>runit</tt> running on the host.<br />
<br />
For this to work, you must customize <tt>/etc/runit/2</tt> in the vserver as follows:<br />
<br />
<pre><br />
#!/bin/sh<br />
<br />
trap ":" HUP INT QUIT ILL TRAP ABRT BUS FPE USR1 SEGV USR2 PIPE ALRM TERM CHLD CONT STOP TSTP TTIN TTOU URG XCPU XFSZ VTALRM PROF WINCH IO PWR SYS<br />
<br />
PATH=/usr/local/bin:/usr/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin<br />
<br />
runsvchdir default >/dev/null<br />
<br />
env - PATH=$PATH \<br />
runsvdir -P /var/service 'log: ...........................................................................................................................................................................................................................................................................................................................................................................................................'<br />
<br />
exec /etc/runit/3<br />
</pre><br />
<br />
Now, you can set up a <tt>runit</tt> service on the host with a <tt>run</tt> script like this one:<br />
<br />
<pre><br />
#!/bin/sh<br />
exec 2>&1<br />
exec vserver name-of-vserver start<br />
</pre><br />
<br />
This way:<br />
<br />
* <tt>vserver start</tt> doesn't exit until <tt>runsvdir</tt> terminates.<br />
* If <tt>runsvdir</tt> terminates, all services running inside the vserver are stopped.<br />
* <tt>vserver stop</tt> works as expected.<br />
** Update: with util-vserver 0.30.212 on amd64, it doesn't. The signal never reaches <tt>runsvdir</tt>.<br />
* You can control the vserver using <tt>sv</tt> like any other service, provided all processes running inside it are managed by <tt>runit</tt>.<br />
** If there are processes left inside after all the services exited, <tt>runit</tt> running on the host won't be able to restart the vserver until those stray processes are killed somehow.<br />
** You may want to add something to this effect to the <tt>finish</tt> script of the vserver service, but it may not be a good idea. Be sure you know what you are doing, as always.<br />
<br />
Still, this may not be the best way to integrate <tt>runit</tt> with vserver. [[Running runit-supervised services inside a vserver]] may be better if you only run a specific service in a guest and it seems wasteful to keep extra processes around. Using the plain initstyle and starting runit-init in each guest is best if you want to make your guests behave like a physical system. It's also the most hassle-free approach.<br />
<br />
--[[User:KornAndras|Guy-]] 02:30, 2 February 2007 (CET)</div>KornAndrashttp://wiki.linux-vserver.org/util-vserver:Cheatsheetutil-vserver:Cheatsheet2008-10-28T23:21:09Z<p>KornAndras: Remove main title (page has it anyway); rephrase introduction to be more neutral/formal.</p>
<hr />
<div>This is a cheatsheet for util-vserver. Some of these recipes have been arrived at by users, using trial and error, so they may not always be the "official" solutions.<br />
<br />
== How to add an IP address to a guest ==<br />
<br />
# create the address on the host: <pre>ifconfig eth0:10 172.16.0.145/12</pre> or <pre>ip addr add dev eth0 172.16.0.145/12</pre> or even <pre>ip addr add dev dummy0 172.16.0.145/12</pre><br />
# add the adress:<pre>naddress --nid guestname --add --ip 172.16.0.145 --bcast 172.31.255.255</pre><br />
#* Depending on what you use the vserver for, you may not want the broadcast thing at all; you can also use a /32 mask for the IP in this case.<br />
# add the ip to the config directory to make it stick if you restart <br />
# enter the guest and verify services that need to listen on the ip, restart if necessary (for me it was not).</div>KornAndrashttp://wiki.linux-vserver.org/util-vserver:Cheatsheetutil-vserver:Cheatsheet2008-10-28T23:19:18Z<p>KornAndras: /* util-vserver cheatsheet */ typo fixing, beautification, some additional command lines</p>
<hr />
<div>= util-vserver cheatsheet =<br />
<br />
ok,<br />
<br />
here is my cheatsheet for util-vserver. I figured a lot by hand so i would like to share some here. This is a draft:<br />
<br />
== How to add an IP address to a guest ==<br />
<br />
# create the address on the host: <pre>ifconfig eth0:10 172.16.0.145/12</pre> or <pre>ip addr add dev eth0 172.16.0.145/12</pre> or even <pre>ip addr add dev dummy0 172.16.0.145/12</pre><br />
# add the adress:<pre>naddress --nid guestname --add --ip 172.16.0.145 --bcast 172.31.255.255</pre><br />
#* Depending on what you use the vserver for, you may not want the broadcast thing at all; you can also use a /32 mask for the IP in this case.<br />
# add the ip to the config directory to make it stick if you restart <br />
# enter the guest and verify services that need to listen on the ip, restart if necessary (for me it was not).</div>KornAndrashttp://wiki.linux-vserver.org/Running_runit-supervised_services_inside_a_vserverRunning runit-supervised services inside a vserver2008-09-28T10:19:09Z<p>KornAndras: /* Running services */ disadvantages</p>
<hr />
<div>This page describes a setup where you have a [http://smarden.org/runit runit] installation on the host and use it to directly supervise services running in vserver guests.<br />
<br />
== Motivation and goals ==<br />
<br />
This is what I wanted to achieve:<br />
<br />
* Partition a physical server with many responsibilities into vservers that can easily be upgraded individually without breaking any unrelated stuff.<br />
* Each service or small set of services should run in its own vserver.<br />
* Services should be supervised (started, stopped and managed) by [http://smarden.org/runit runit].<br />
* Service logs should accumulate on the host, not the guests.<br />
** <tt>svlogd</tt> rotates them nicely and can invoke my <tt>multilogcheck</tt> script to alert me of unusual events as a postprocessor, but<br />
** I don't want to install <tt>multilogcheck</tt> inside every vserver because it's messy.<br />
** I don't like syslog. There are many problems with it, but I won't go into that here.<br />
*** Therefore, services mostly log to stdout and thus to svlogd.<br />
*** For services that absolutely must use syslog, I provide [http://smarden.org/socklog socklog].<br />
*** Again, I don't want a separate <tt>socklog</tt> instance in every vserver.<br />
*** Alas, <tt>socklog</tt> is unable to listen on more than one Unix domain socket.<br />
**** Luckily, <tt>socat</tt> can be used to relay syslog messages from the vservers to the master <tt>socklog</tt> on the host. (<tt>syslog-ng</tt> would also have done the job nicely.)<br />
**** It's also possible to bind mount the <tt>/dev/log</tt> socket in every guest; however, I'm afraid this breaks if you restart socklog after a guest is up. Workaround: make <tt>/dev/log</tt> a symlink to, say, <tt>/var/run/syslog/socket</tt> everywhere and bind mount the host's <tt>/var/run/syslog</tt> directory in the guests; that way the socket will still be available even if socklog unlinks and recreates it.<br />
* It should be straightforward and next to transparent to manage the services running in vservers.<br />
** With <tt>runit</tt>, it's easy to delegate management rights of a service to users (chown and chmod some files in the pertinent <tt>supervise</tt> directory). This should continue to work.<br />
<br />
== Prerequisites ==<br />
<br />
# A fairly recent vserver kernel with support for persistent contexts (I used 2.6.19.2-vs2.2.0-rc8.7).<br />
# A recent version of util-vserver that supports persistent contexts correctly (I used [http://people.linux-vserver.org/~dhozac/p/uv/experimental/util-vserver-0.30.213-rc1.tar.bz2 0.30.213-rc1]).<br />
# Daniel_Hozac's [http://people.linux-vserver.org/~dhozac/t/signal-relay.c signal-relay] program.<br />
<br />
== The big picture ==<br />
<br />
Let's see how it all fits together.<br />
<br />
We'd like to achieve something like this (output of <tt>vps axfu</tt>):<br />
<br />
<pre><br />
USER PID CONTEXT %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND<br />
root 1 0 MAIN 0.0 0.0 104 16 ? Ss Jan29 0:06 runit<br />
root 4188 0 MAIN 0.0 0.0 132 32 ? Ss Jan29 0:10 runsvdir -P /var/service log: .......................................................<br />
root 4250 0 MAIN 0.0 0.0 108 28 ? Ss Jan29 0:00 \_ runsv vserver-logrelay-squid<br />
log 4256 0 MAIN 0.0 0.0 128 44 ? S Jan29 0:00 | \_ svlogd -t /var/log/sv/vserver-logrelay-squid<br />
logrelay 3106 0 MAIN 0.0 0.1 25428 1944 ? S 00:44 0:00 | \_ socat -d -d -d -D -ls -u UNIX-LISTEN:/etc/vservers/squid/vdir/dev/log,unlink-early,nonblock,mode=666,setuid=logrelay UNIX-CONNECT:/dev/log,type=2,nonblock,forever<br />
root 19272 0 MAIN 0.0 0.0 108 28 ? Ss Feb01 0:00 \_ runsv squid<br />
log 19273 0 MAIN 0.0 0.0 128 44 ? S Feb01 0:00 | \_ svlogd -t /var/log/sv/squid<br />
root 10324 0 MAIN 0.0 0.0 5728 364 ? S Feb01 0:00 | \_ signal-relay vserver squid exec squid -N -D -sYC<br />
proxy 10334 2 squid 0.0 0.5 24968 8036 ? Sl Feb01 0:01 | \_ squid -N -D -sYC<br />
root 24219 0 MAIN 0.0 0.0 108 32 ? Ss 02:02 0:00 \_ runsv nmbd<br />
root 24220 0 MAIN 0.0 0.0 5732 376 ? S 02:02 0:00 | \_ signal-relay vserver samba exec /usr/sbin/nmbd -F<br />
root 24230 3 samba 0.0 0.1 30080 2360 ? Ss 02:02 0:00 | \_ /usr/sbin/nmbd -F<br />
root 24251 3 samba 0.0 0.0 32172 1496 ? S 02:02 0:00 | \_ /usr/sbin/nmbd -F<br />
root 24253 0 MAIN 0.0 0.0 108 28 ? Ss 02:02 0:00 \_ runsv smbd<br />
root 24254 0 MAIN 0.0 0.0 5732 376 ? S 02:02 0:00 | \_ signal-relay vserver samba exec /usr/sbin/smbd -F<br />
root 24268 3 samba 0.0 0.2 41888 3404 ? Ss 02:02 0:00 | \_ /usr/sbin/smbd -F<br />
root 24289 3 samba 0.0 0.0 41888 1232 ? S 02:02 0:00 | \_ /usr/sbin/smbd -F<br />
root 29625 0 MAIN 0.0 0.0 104 28 ? Ss 02:22 0:00 \_ runsv cron-squid<br />
root 29626 0 MAIN 0.0 0.0 5732 376 ? S 02:22 0:00 \_ signal-relay vserver squid exec cron -f<br />
root 29637 2 squid 0.0 0.0 11492 1060 ? S 02:22 0:00 \_ cron -f<br />
</pre><br />
<br />
For service supervision to work, we must be able to send signals to our services. Specifically, <tt>runsv</tt> must be able to send signals to its children.<br />
Alas, it's not prepared to send signals across context boundaries, which is where <tt>signal-relay</tt> comes in.<br />
<br />
=== <tt>signal-relay</tt> ===<br />
<br />
<tt>signal-relay</tt> is a small program not unlike <tt>runit</tt>'s <tt>chpst</tt> that does the following:<br />
<br />
* it forks a child;<br />
** inside the child, it execs the program specified on its command line;<br />
* in the parent, it sets up signal handlers for every signal that relay the signal to the child, even if the child is running in a different context;<br />
* if the child exits, <tt>signal-relay</tt> exits.<br />
* (It can also put the child into its own process group; use the <tt>-P</tt> switch. Sending signals to process groups in a different context doesn't work yet, though.)<br />
<br />
=== Setting up the vservers ===<br />
<br />
When we start a service for runit, we want the command that starts the service to stay in the foreground until the moment the service dies. <tt>vserver exec</tt> looks just right, but there is a catch: it only works for vservers that have been "started". <tt>vserver start</tt>, however, doesn't fit very well into the <tt>runit</tt> way of doing things. You can set it up as a service (this is discussed in [[util-vserver:InitStyles]]), but it seems superfluous to leave some processes around just to keep a vserver "started" so that we can run services in it.<br />
<br />
What we need is a way of basically doing "start vserver <guest> if it's not started, then exec program <service> inside it". Normally, a context with no processes running inside it is destroyed by the kernel; thus, just setting <tt>/etc/vservers/guest/apps/init/cmd.start</tt> to <tt>/bin/true</tt> isn't going to work; we would need something that stays around for a while, like a script that calls <tt>sleep 1m &</tt>. This would make <tt>vserver start</tt> happy, so in our service run script, we could do something like<br />
<br />
<pre><br />
vserver guest status || vserver guest start<br />
exec signal-relay vserver guest exec /path/to/service-program<br />
</pre><br />
<br />
A more elegant solution is to make the guest context ''persistent''. This way it sticks around even if there are no processes left in it.<br />
<br />
<pre><br />
cd /etc/vservers/guest<br />
echo persistent >>flags<br />
echo persistent >>nflags<br />
echo /bin/true >apps/init/cmd.start<br />
</pre><br />
<br />
(I ''guess'' <tt>nflags</tt> is for the network context.)<br />
<br />
Now, <tt>vserver guest start</tt> should be able to "start" our vserver (set up all of its state), and exit without leaving stray processes around.<br />
<br />
== Running services ==<br />
<br />
Say you have a vserver called <tt>squid</tt>, and you want to run your <tt>squid</tt> proxy inside it to keep it insulated from the other processes on the system, and vice versa.<br />
<br />
In our current setup, the following run script will do the trick (it borrows a bit from Debian's initscript and uses the Debian defaults file):<br />
<br />
<pre><br />
#!/bin/sh<br />
exec 2>&1<br />
<br />
# Set a default for max. filedescriptors<br />
SQUID_MAXFD=4096<br />
<br />
# Figure out the name of the service we're running as<br />
SVNAME=$(basename $(pwd))<br />
<br />
# Read the configfile of this service; if it sets VSERVERNAME, we'll assume we have to run inside the specified vserver<br />
CONFIG=/etc/default/"$SVNAME"<br />
[ -r "$CONFIG" ] && . "$CONFIG"<br />
<br />
# Source Debian defaults<br />
[ -n "$VSERVERNAME" ] && VROOT="/etc/vservers/$VSERVERNAME/vdir" || VROOT=/<br />
[ -r "$VROOT/etc/default/squid" ] && . "$VROOT/etc/default/squid"<br />
<br />
[ "$SQUID_MAXFD" -gt 4096 ] && SQUID_MAXFD=4096<br />
<br />
if test -f /proc/sys/fs/file-max; then<br />
global_file_max=$(cat /proc/sys/fs/file-max)<br />
minimal_file_max=$(($SQUID_MAXFD + 4096))<br />
[ "$global_file_max" -lt "$minimal_file_max" ] && echo "$minimal_file_max" >/proc/sys/fs/file-max<br />
fi<br />
<br />
if [ ! "$VSERVERNAME" = "" ]; then<br />
VSERVERARGS="signal-relay vserver $VSERVERNAME exec"<br />
vserver "$VSERVERNAME" status || vserver "$VSERVERNAME" start # start the vserver if necessary<br />
fi<br />
<br />
exec chpst -o"$SQUID_MAXFD" $VSERVERARGS squid -N -D -sYC<br />
</pre><br />
<br />
This script is generic in the sense that it works with or without a vserver setup.<br />
<br />
You can run an <tt>svlogd</tt> for this service like you normally would; or you could have all your <tt>svlogd</tt>s run in a different vserver.<br />
<br />
A run script for <tt>cron</tt> that automatically figures out if it should run in a vserver:<br />
<br />
<pre><br />
#!/bin/sh<br />
exec 2>&1<br />
DEPENDENCIES=""<br />
RLIMIT="chpst -t 172800"<br />
SVNAME=$(basename $(pwd))<br />
CONFIG=/etc/default/"$SVNAME"<br />
<br />
# Assume part after dash is name of vserver<br />
if [ ! "${SVNAME/*-/}" = "$SVNAME" ]; then<br />
VSERVERNAME="${SVNAME/*-/}"<br />
fi<br />
<br />
# By default, we depend on the socklog service if it exists<br />
[ -e /service/socklog ] && DEPENDENCIES=socklog<br />
<br />
# And also on the logrelay service of the pertinent vserver<br />
[ -e /service/vserver-logrelay-"$VSERVERNAME" ] && DEPENDENCIES="$DEPENDENCIES vserver-logrelay-$VSERVERNAME"<br />
<br />
# Can override VSERVERNAME, RLIMIT and DEPENDENCIES here if necessary<br />
[ -r "$CONFIG" ] && . "$CONFIG"<br />
<br />
if [ ! "$VSERVERNAME" = "" ]; then<br />
VSERVERARGS="signal-relay vserver $VSERVERNAME exec"<br />
vserver "$VSERVERNAME" status || vserver "$VSERVERNAME" start<br />
fi<br />
<br />
if [ -n "$DEPENDENCIES" ]; then<br />
sv start $DEPENDENCIES || exit 1<br />
fi<br />
<br />
exec $RLIMIT $VSERVERARGS cron -f<br />
</pre><br />
<br />
Now, if you place this run script in a service directory called <tt>cron-squid</tt>, it will run a cron daemon in the <tt>squid</tt> guest. This takes care of rotating the squid logs under <tt>/var/log/squid</tt>, for example; although this could also be done on the host with a few kludges.<br />
<br />
The vserver-logrelay-template/run script looks like this:<br />
<br />
<pre><br />
#!/bin/sh<br />
exec 2>&1<br />
SVNAME=$(basename $(pwd))<br />
RUNASUSER=logrelay<br />
MODE=666<br />
VSERVERNAME=$(echo $SVNAME | sed 's/vserver-logrelay-//')<br />
[ -r "/etc/default/$SVNAME" ] && . "/etc/default/$SVNAME"<br />
<br />
exec socat -d -d -d -D -ls -u \<br />
UNIX-LISTEN:/etc/vservers/$VSERVERNAME/vdir/dev/log,unlink-early,nonblock,mode=$MODE,setuid=$RUNASUSER \<br />
UNIX-CONNECT:/dev/log,type=2,nonblock,forever<br />
</pre><br />
<br />
This will pass syslog messages from a vserver to the syslog of the host by acting as a syslog server for the <tt>/dev/log</tt> socket of the guest. Thus, you don't need to run a <tt>syslogd</tt> inside the vserver and you don't need to migrate to <tt>syslog-ng</tt> from <tt>socklog</tt> on the host.<br />
<br />
Symlink this run script into a service directory called <tt>vserver-logrelay-squid</tt>.<br />
<br />
Unfortunately, <tt>socat</tt> has a largish memory footprint; something more lightweight could, perhaps, be used.<br />
<br />
Comments and additions welcome.<br />
<br />
== Disadvantages ==<br />
<br />
The most significant problem with this approach (as opposed to using initstyle plain and a separate runit instance in each vserver) is that it's no longer straightforward to manage the services running in vservers from inside the vservers; package management scripts can't stop them for upgrades, for example (unless you modify the initscripts in quite horrible ways).<br />
<br />
Initial setup is also slightly more complicated.<br />
<br />
These have to be weighed against the advantages of:<br />
<br />
* having fewer superfluous processes (like a separate <tt>runit</tt> and <tt>runsvdir</tt> in each vserver);<br />
* being able to manage the services easily from the host;<br />
* avoiding the need to run <tt>sshd</tt> inside each guest in order to be able to easily delegate service management privileges to others.<br />
<br />
Nowadays I tend to think the initstyle plain method is better after all.<br />
<br />
--[[User:KornAndras|Guy-]] 12:18, 28 September 2008 (CET)</div>KornAndrashttp://wiki.linux-vserver.org/Running_runit-supervised_services_inside_a_vserverRunning runit-supervised services inside a vserver2008-09-28T10:05:48Z<p>KornAndras: /* Motivation and goals */ bind mounting /dev/log socket is also possible</p>
<hr />
<div>This page describes a setup where you have a [http://smarden.org/runit runit] installation on the host and use it to directly supervise services running in vserver guests.<br />
<br />
== Motivation and goals ==<br />
<br />
This is what I wanted to achieve:<br />
<br />
* Partition a physical server with many responsibilities into vservers that can easily be upgraded individually without breaking any unrelated stuff.<br />
* Each service or small set of services should run in its own vserver.<br />
* Services should be supervised (started, stopped and managed) by [http://smarden.org/runit runit].<br />
* Service logs should accumulate on the host, not the guests.<br />
** <tt>svlogd</tt> rotates them nicely and can invoke my <tt>multilogcheck</tt> script to alert me of unusual events as a postprocessor, but<br />
** I don't want to install <tt>multilogcheck</tt> inside every vserver because it's messy.<br />
** I don't like syslog. There are many problems with it, but I won't go into that here.<br />
*** Therefore, services mostly log to stdout and thus to svlogd.<br />
*** For services that absolutely must use syslog, I provide [http://smarden.org/socklog socklog].<br />
*** Again, I don't want a separate <tt>socklog</tt> instance in every vserver.<br />
*** Alas, <tt>socklog</tt> is unable to listen on more than one Unix domain socket.<br />
**** Luckily, <tt>socat</tt> can be used to relay syslog messages from the vservers to the master <tt>socklog</tt> on the host. (<tt>syslog-ng</tt> would also have done the job nicely.)<br />
**** It's also possible to bind mount the <tt>/dev/log</tt> socket in every guest; however, I'm afraid this breaks if you restart socklog after a guest is up. Workaround: make <tt>/dev/log</tt> a symlink to, say, <tt>/var/run/syslog/socket</tt> everywhere and bind mount the host's <tt>/var/run/syslog</tt> directory in the guests; that way the socket will still be available even if socklog unlinks and recreates it.<br />
* It should be straightforward and next to transparent to manage the services running in vservers.<br />
** With <tt>runit</tt>, it's easy to delegate management rights of a service to users (chown and chmod some files in the pertinent <tt>supervise</tt> directory). This should continue to work.<br />
<br />
== Prerequisites ==<br />
<br />
# A fairly recent vserver kernel with support for persistent contexts (I used 2.6.19.2-vs2.2.0-rc8.7).<br />
# A recent version of util-vserver that supports persistent contexts correctly (I used [http://people.linux-vserver.org/~dhozac/p/uv/experimental/util-vserver-0.30.213-rc1.tar.bz2 0.30.213-rc1]).<br />
# Daniel_Hozac's [http://people.linux-vserver.org/~dhozac/t/signal-relay.c signal-relay] program.<br />
<br />
== The big picture ==<br />
<br />
Let's see how it all fits together.<br />
<br />
We'd like to achieve something like this (output of <tt>vps axfu</tt>):<br />
<br />
<pre><br />
USER PID CONTEXT %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND<br />
root 1 0 MAIN 0.0 0.0 104 16 ? Ss Jan29 0:06 runit<br />
root 4188 0 MAIN 0.0 0.0 132 32 ? Ss Jan29 0:10 runsvdir -P /var/service log: .......................................................<br />
root 4250 0 MAIN 0.0 0.0 108 28 ? Ss Jan29 0:00 \_ runsv vserver-logrelay-squid<br />
log 4256 0 MAIN 0.0 0.0 128 44 ? S Jan29 0:00 | \_ svlogd -t /var/log/sv/vserver-logrelay-squid<br />
logrelay 3106 0 MAIN 0.0 0.1 25428 1944 ? S 00:44 0:00 | \_ socat -d -d -d -D -ls -u UNIX-LISTEN:/etc/vservers/squid/vdir/dev/log,unlink-early,nonblock,mode=666,setuid=logrelay UNIX-CONNECT:/dev/log,type=2,nonblock,forever<br />
root 19272 0 MAIN 0.0 0.0 108 28 ? Ss Feb01 0:00 \_ runsv squid<br />
log 19273 0 MAIN 0.0 0.0 128 44 ? S Feb01 0:00 | \_ svlogd -t /var/log/sv/squid<br />
root 10324 0 MAIN 0.0 0.0 5728 364 ? S Feb01 0:00 | \_ signal-relay vserver squid exec squid -N -D -sYC<br />
proxy 10334 2 squid 0.0 0.5 24968 8036 ? Sl Feb01 0:01 | \_ squid -N -D -sYC<br />
root 24219 0 MAIN 0.0 0.0 108 32 ? Ss 02:02 0:00 \_ runsv nmbd<br />
root 24220 0 MAIN 0.0 0.0 5732 376 ? S 02:02 0:00 | \_ signal-relay vserver samba exec /usr/sbin/nmbd -F<br />
root 24230 3 samba 0.0 0.1 30080 2360 ? Ss 02:02 0:00 | \_ /usr/sbin/nmbd -F<br />
root 24251 3 samba 0.0 0.0 32172 1496 ? S 02:02 0:00 | \_ /usr/sbin/nmbd -F<br />
root 24253 0 MAIN 0.0 0.0 108 28 ? Ss 02:02 0:00 \_ runsv smbd<br />
root 24254 0 MAIN 0.0 0.0 5732 376 ? S 02:02 0:00 | \_ signal-relay vserver samba exec /usr/sbin/smbd -F<br />
root 24268 3 samba 0.0 0.2 41888 3404 ? Ss 02:02 0:00 | \_ /usr/sbin/smbd -F<br />
root 24289 3 samba 0.0 0.0 41888 1232 ? S 02:02 0:00 | \_ /usr/sbin/smbd -F<br />
root 29625 0 MAIN 0.0 0.0 104 28 ? Ss 02:22 0:00 \_ runsv cron-squid<br />
root 29626 0 MAIN 0.0 0.0 5732 376 ? S 02:22 0:00 \_ signal-relay vserver squid exec cron -f<br />
root 29637 2 squid 0.0 0.0 11492 1060 ? S 02:22 0:00 \_ cron -f<br />
</pre><br />
<br />
For service supervision to work, we must be able to send signals to our services. Specifically, <tt>runsv</tt> must be able to send signals to its children.<br />
Alas, it's not prepared to send signals across context boundaries, which is where <tt>signal-relay</tt> comes in.<br />
<br />
=== <tt>signal-relay</tt> ===<br />
<br />
<tt>signal-relay</tt> is a small program not unlike <tt>runit</tt>'s <tt>chpst</tt> that does the following:<br />
<br />
* it forks a child;<br />
** inside the child, it execs the program specified on its command line;<br />
* in the parent, it sets up signal handlers for every signal that relay the signal to the child, even if the child is running in a different context;<br />
* if the child exits, <tt>signal-relay</tt> exits.<br />
* (It can also put the child into its own process group; use the <tt>-P</tt> switch. Sending signals to process groups in a different context doesn't work yet, though.)<br />
<br />
=== Setting up the vservers ===<br />
<br />
When we start a service for runit, we want the command that starts the service to stay in the foreground until the moment the service dies. <tt>vserver exec</tt> looks just right, but there is a catch: it only works for vservers that have been "started". <tt>vserver start</tt>, however, doesn't fit very well into the <tt>runit</tt> way of doing things. You can set it up as a service (this is discussed in [[util-vserver:InitStyles]]), but it seems superfluous to leave some processes around just to keep a vserver "started" so that we can run services in it.<br />
<br />
What we need is a way of basically doing "start vserver <guest> if it's not started, then exec program <service> inside it". Normally, a context with no processes running inside it is destroyed by the kernel; thus, just setting <tt>/etc/vservers/guest/apps/init/cmd.start</tt> to <tt>/bin/true</tt> isn't going to work; we would need something that stays around for a while, like a script that calls <tt>sleep 1m &</tt>. This would make <tt>vserver start</tt> happy, so in our service run script, we could do something like<br />
<br />
<pre><br />
vserver guest status || vserver guest start<br />
exec signal-relay vserver guest exec /path/to/service-program<br />
</pre><br />
<br />
A more elegant solution is to make the guest context ''persistent''. This way it sticks around even if there are no processes left in it.<br />
<br />
<pre><br />
cd /etc/vservers/guest<br />
echo persistent >>flags<br />
echo persistent >>nflags<br />
echo /bin/true >apps/init/cmd.start<br />
</pre><br />
<br />
(I ''guess'' <tt>nflags</tt> is for the network context.)<br />
<br />
Now, <tt>vserver guest start</tt> should be able to "start" our vserver (set up all of its state), and exit without leaving stray processes around.<br />
<br />
== Running services ==<br />
<br />
Say you have a vserver called <tt>squid</tt>, and you want to run your <tt>squid</tt> proxy inside it to keep it insulated from the other processes on the system, and vice versa.<br />
<br />
In our current setup, the following run script will do the trick (it borrows a bit from Debian's initscript and uses the Debian defaults file):<br />
<br />
<pre><br />
#!/bin/sh<br />
exec 2>&1<br />
<br />
# Set a default for max. filedescriptors<br />
SQUID_MAXFD=4096<br />
<br />
# Figure out the name of the service we're running as<br />
SVNAME=$(basename $(pwd))<br />
<br />
# Read the configfile of this service; if it sets VSERVERNAME, we'll assume we have to run inside the specified vserver<br />
CONFIG=/etc/default/"$SVNAME"<br />
[ -r "$CONFIG" ] && . "$CONFIG"<br />
<br />
# Source Debian defaults<br />
[ -n "$VSERVERNAME" ] && VROOT="/etc/vservers/$VSERVERNAME/vdir" || VROOT=/<br />
[ -r "$VROOT/etc/default/squid" ] && . "$VROOT/etc/default/squid"<br />
<br />
[ "$SQUID_MAXFD" -gt 4096 ] && SQUID_MAXFD=4096<br />
<br />
if test -f /proc/sys/fs/file-max; then<br />
global_file_max=$(cat /proc/sys/fs/file-max)<br />
minimal_file_max=$(($SQUID_MAXFD + 4096))<br />
[ "$global_file_max" -lt "$minimal_file_max" ] && echo "$minimal_file_max" >/proc/sys/fs/file-max<br />
fi<br />
<br />
if [ ! "$VSERVERNAME" = "" ]; then<br />
VSERVERARGS="signal-relay vserver $VSERVERNAME exec"<br />
vserver "$VSERVERNAME" status || vserver "$VSERVERNAME" start # start the vserver if necessary<br />
fi<br />
<br />
exec chpst -o"$SQUID_MAXFD" $VSERVERARGS squid -N -D -sYC<br />
</pre><br />
<br />
This script is generic in the sense that it works with or without a vserver setup.<br />
<br />
You can run an <tt>svlogd</tt> for this service like you normally would; or you could have all your <tt>svlogd</tt>s run in a different vserver.<br />
<br />
A run script for <tt>cron</tt> that automatically figures out if it should run in a vserver:<br />
<br />
<pre><br />
#!/bin/sh<br />
exec 2>&1<br />
DEPENDENCIES=""<br />
RLIMIT="chpst -t 172800"<br />
SVNAME=$(basename $(pwd))<br />
CONFIG=/etc/default/"$SVNAME"<br />
<br />
# Assume part after dash is name of vserver<br />
if [ ! "${SVNAME/*-/}" = "$SVNAME" ]; then<br />
VSERVERNAME="${SVNAME/*-/}"<br />
fi<br />
<br />
# By default, we depend on the socklog service if it exists<br />
[ -e /service/socklog ] && DEPENDENCIES=socklog<br />
<br />
# And also on the logrelay service of the pertinent vserver<br />
[ -e /service/vserver-logrelay-"$VSERVERNAME" ] && DEPENDENCIES="$DEPENDENCIES vserver-logrelay-$VSERVERNAME"<br />
<br />
# Can override VSERVERNAME, RLIMIT and DEPENDENCIES here if necessary<br />
[ -r "$CONFIG" ] && . "$CONFIG"<br />
<br />
if [ ! "$VSERVERNAME" = "" ]; then<br />
VSERVERARGS="signal-relay vserver $VSERVERNAME exec"<br />
vserver "$VSERVERNAME" status || vserver "$VSERVERNAME" start<br />
fi<br />
<br />
if [ -n "$DEPENDENCIES" ]; then<br />
sv start $DEPENDENCIES || exit 1<br />
fi<br />
<br />
exec $RLIMIT $VSERVERARGS cron -f<br />
</pre><br />
<br />
Now, if you place this run script in a service directory called <tt>cron-squid</tt>, it will run a cron daemon in the <tt>squid</tt> guest. This takes care of rotating the squid logs under <tt>/var/log/squid</tt>, for example; although this could also be done on the host with a few kludges.<br />
<br />
The vserver-logrelay-template/run script looks like this:<br />
<br />
<pre><br />
#!/bin/sh<br />
exec 2>&1<br />
SVNAME=$(basename $(pwd))<br />
RUNASUSER=logrelay<br />
MODE=666<br />
VSERVERNAME=$(echo $SVNAME | sed 's/vserver-logrelay-//')<br />
[ -r "/etc/default/$SVNAME" ] && . "/etc/default/$SVNAME"<br />
<br />
exec socat -d -d -d -D -ls -u \<br />
UNIX-LISTEN:/etc/vservers/$VSERVERNAME/vdir/dev/log,unlink-early,nonblock,mode=$MODE,setuid=$RUNASUSER \<br />
UNIX-CONNECT:/dev/log,type=2,nonblock,forever<br />
</pre><br />
<br />
This will pass syslog messages from a vserver to the syslog of the host by acting as a syslog server for the <tt>/dev/log</tt> socket of the guest. Thus, you don't need to run a <tt>syslogd</tt> inside the vserver and you don't need to migrate to <tt>syslog-ng</tt> from <tt>socklog</tt> on the host.<br />
<br />
Symlink this run script into a service directory called <tt>vserver-logrelay-squid</tt>.<br />
<br />
Unfortunately, <tt>socat</tt> has a largish memory footprint; something more lightweight could, perhaps, be used.<br />
<br />
Comments and additions welcome.<br />
--[[User:KornAndras|Guy-]] 03:29, 2 February 2007 (CET)</div>KornAndrashttp://wiki.linux-vserver.org/util-vserver:Vhashifyutil-vserver:Vhashify2008-07-25T22:52:07Z<p>KornAndras: /* Mini FAQ */ clarify "all at once"</p>
<hr />
<div>== All about vunify / vhashify ==<br />
<br />
Some collected wisdom about the vunify/vhashify functionality:<br />
<br />
* "unification" is the process of replacing files with hardlinks to identical files in other vservers (or, in the case of vhashify, more precisely to a common base); for security, the files are then supplied with immutable-but-unlinkable flags (a vserver speciality), and recently COW link capability has been added to vserver (2.2+), which means that when such a file is being modified, the hardlink is automatically dissolved and the contents copied (CONFIG_VSERVER_COWBL).<br />
<br />
* vhashify is the successor to vunify; vunify only looks at files at identical relative paths and links them if they are identical; vhashify builds hash values over the contents of ''all'' (non-excluded) files and links them into a common base directory, or unifies them with pre-existing links there. So running hashification on multiple vservers will effectively hard link their identical files.<br />
<br />
* You don't call the vhashify tool directly (which lives in lib/util-vserver/), but let the "vserver" multipurpose script do the work:<br />
<br />
vserver <vserver-name> hashify<br />
<br />
* The guest needs to be running for the above because vhashify may try to figure out what files not to hashify by calling the package manager of the guest via <tt>vserver exec</tt>; the reason for this is that it tries not to unify config files because they couldn't be written to afterwards unless COW links are supported (which is a recent addition), which may be a hassle (unlike with program/library files which are not overwritten but replaced on upgrades). The details of how the list of config files is retrieved can be found in <tt>scripts/vpkg</tt> (<tt>lib/util-vserver/vpkg</tt> after installation), which is called by the vhashify program (through MatchList_initManually). Currently this means redhat|mandrake and debian are supported. It is looking at a XXX/style file (what's XXX?) for finding out which distribution a guest is running (can this be a problem?) -> open questions to be looked at.<br />
<br />
(* If one configures exclude lists, vhashify is supposed ''not'' to use package management for getting the config file list ''-> actually it turns out this is not the case, vserver exec is even being called with an exclude file present''. (One can check whether vpkg is being run by adding an <tt>echo "$0 $@ called.." >&2</tt> statement at the top of that script. Note the redirection to stderr.))<br />
<br />
=== Backups ===<br />
<br />
Be careful to restore the link flags when making or restoring from backups, or vservers won't be safely parted anymore. Do either of the following:<br />
<br />
* use tools which backup and restore the link flags ("dump" and "restore" might work, the writer of these lines has not tested them)<br />
<br />
* back up the directory containing the hashes, too (<tt>/vservers/.hash</tt> when following the suggested configuration directives); for restoring from the backup, also restore the .hash directory, then run setattr over all files contained therein; this should work (not yet tested!):<br />
<br />
find /vservers/.hash -type f -print0|xargs -0 setattr --iunlink --<br />
<br />
* (back up and) restore each vserver individually, so no hardlinks to other vservers are created. Then run hashify. (Be aware that you need more space until hashify has run, so restoring from a backup onto a partition of equal size might not work.)<br />
<br />
=== Mini FAQ ===<br />
<br />
1Q: <serek> so after cloning, i need to dist-upgrade each vserver separately but finally they will use the same files, right?<br />
<br />
1A: <Bertl> you can upgrade all at once or separately, whenever you run vhashify on them, identical data will be linked together<br />
<br />
2Q: <serek> may vhashify two existing hosts as well, right?<br />
<br />
2A: <Bertl> yep, anytime<br />
<br />
3Q: <fluor-> < Bertl> you can upgrade all at once or separately <- what would the "all at once" method be?<br />
<br />
3A: <Bertl> depends on the package management, for most common management mechanisms, there is vapt, vyum, and vrpm<br />
<br />
Note that "all at once" doesn't mean "simultaneously", just "with a single command". When you mass upgrade your vservers, their identical files won't be hardlinked together until you run vserver hashify again on each of them. This means you'll need a lot more disk space until you vhashify. And don't forget to remove hashed files that no longer have other hard links.<br />
<br />
=== See also ===<br />
<br />
* [[util-vserver:Documentation]] or maybe rather the [http://www.nongnu.org/util-vserver/doc/conf/configuration.html "Flower Page"]<br />
* [[Frequently_Asked_Questions#What_is_unification_.28vunify.29.3F]]</div>KornAndrashttp://wiki.linux-vserver.org/Problematic_ProgramsProblematic Programs2008-07-19T11:39:19Z<p>KornAndras: undo vandalism</p>
<hr />
<div>Some programs do things that might work on a normal host but not inside a V-Server. This is often not a fault of V-Server itself, the programs are doing automagic things which fail and no proper error handling is done. Also sometimes the actions need special rights which are not permitted by default in V-Servers. Allowing CAPs is often not necessary since those special CAPs are only required once (e.g. when the program initializes the directories/settings/whatever).<br />
<br />
<br />
=== OpenGroupware Apache Module ===<br />
If your V-Server doesn't have access to localhost, then the connection to the OpenGroupware server will fail with a "Internal Server Error". The apache module for OpenGroupware called mod_ngobjweb uses a hardcoded "127.0.0.1" IP address in the source (handler.c line 339), this line you need to change to the IP address that should be used (the IP of the V-Server that runs the OpenGroupware? server)<br />
<br />
=== Hylafax (with CAPI) ===<br />
If you want to run hylafax in a V-Server, you will get a CAP and device problem which can be easily solved. First you need your capi20 devices in your V-Server, which can't be created by ./MAKEDEV (requires special CAPs) so copy the devices into the V-Server, like this (command run on the host):<pre>cp -aR /dev/capi* /vservers/your_vserver/dev</pre><br />
<br />
Now hylafax can access your CAPI ISDN card but will exit after a few seconds, the problem is it tries to create a /dev/null nod in the hylafax chroot. This fails because of missing CAPs, so lets help hylafax again with copying the nod into the hylafax chroot in the V-Server. Like this (command run on the host):<pre>cp -aR /dev/null /vservers/your_vserver/var/spool/hylafax/dev</pre> <br />
Allright, now hylafax should have CAPI access and run properly.<br />
<br />
=== Links inside screen inside a V-Server ===<br />
Don't know why, but links crashes systematically being inside a screen session inside a V-Server started outside a V-Server. (please elaborate!) <br />
<br />
=== screen inside a VServer ===<br />
<br />
<pre>[root@ge root]# vserver zoe enter<br />
<br />
zoe:/# screen<br />
Cannot open your terminal '/dev/pts/5' - please check.<br />
<br />
zoe:/# strace screen <br />
...<br />
stat64("/dev/pts/5", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 5), ...}) = 0<br />
open("/dev/pts/5", O_RDWR|O_NONBLOCK) = -1 EACCES (Permission denied)</pre><br />
<br />
is neither a bug nor an issue with screen, it just shows that a vserver context is not allowed to mess with host terminals. either use ssh/telnet to reach the 'guest' or start the screen session before you do the 'enter' (i.e. on the host)<br />
<br />
util-vserver 0.30.211+ includes a workaround for the issue (vlogin), which allocates a tty inside the guest.<br />
<br />
=== OpenLDAP Startup ===<br />
slapd needs name resolution available in order to start up, otherwise it appears to hang. Make sure you have working DNS (or whatever) available to your vserver before starting one with slapd. This behavior is confirmed in my setup, no confirmation from others yet. My Setup: vservers all bind to an interface on a DMZ-like network segment, BIND runs on a vserver. slapd would hang at startup if the BIND vserver had not been started first. <br />
<br />
=== rndc ===<br />
Bind's rndc has a hardcoded 127.0.0.1 somewhere so any command to rndc will fail with connection refused. You should have a reachable localhost address defined in /etc/hosts and then you can use <pre>rndc -s localhost</pre> command. You can make a rndc.conf and set the default-server option, like that the '-s localhost' isn't necessary.<br />
<br />
=== Asterisk ===<br />
Since some version of Asterisk (at least since 1.0.2), it will not run anymore. On start it fails with: "Unable to set high priority". <br />
This can be solved by allowing CAP_SYS_NICE for that V-Server. You can also not run Asterisk with the realtime priority - Just pass the '-p' command line argument to disable the read-time priority. Good doc on setting up Asterisk devices in the vserver: http://www.telephreak.org/papers/vpa/ (additional documentation for Asterisk 1.4 installation available here: https://customer.lylix.net/knowledgebase.php?action=displayarticle&catid=2&id=27)<br />
<br />
=== Open/FreeSwan ===<br />
No patch needed, openswan gives out some errors about writing to /proc, but those can be ignored.<br />
<br />
=== Samba ===<br />
Oplocks don't work as smbd insists on receiving break requests from 127.0.0.1<br />
Just patch source/smbd/oplock.c (commenting paranoid code)<br />
<pre><br />
+++ oplock.c.orig 2005-02-14 14:27:51.000000000 +0200<br />
--- oplock.c 2005-02-02 12:27:50.000000000 +0200<br />
@@ -181,14 +181,12 @@<br />
return False;<br />
}<br />
<br />
+#if 0<br />
/* Validate message from address (must be localhost). */<br />
if(from.sin_addr.s_addr != htonl(INADDR_LOOPBACK)) {<br />
DEBUG(0,("receive_local_message: invalid 'from' address \<br />
(was %lx should be 127.0.0.1)\n", (long)from.sin_addr.s_addr));<br />
return False;<br />
}<br />
+#endif<br />
<br />
/* Setup the message header */<br />
SIVAL(buffer,OPBRK_CMD_LEN_OFFSET,msg_len);<br />
</pre><br />
or if you don't want to patch the samba source code you can disable oplock in Samba and it will work too!<br />
<br />
Just put the following in your smb.conf:<br />
<pre><br />
kernel oplocks = no<br />
oplocks = no<br />
</pre><br />
Note: The Vserver using Samba should also listen on the broadcast address. Thereby you will not be able to have two samba servers in the same net (on the same broadcast).<br />
<br />
To assign the broadcast address to a vserver guest you need to create a new directory inside the /etc/vservers/<guest name>/interfaces/ directory. The directory is a number not used by this vserver guest. Inside the directory should be normal information and a file called nodev (see util-vserver for information). The contents of the dev file can be identical between directories.<br />
<br />
==== Samba from Debian 3.1 ====<br />
<br />
The samba deb in sarge (3.1) provided file sharing. The only oddity observed is that the vserver guest running samba did not appear in a windows box's 'My Network Places'<br />
<br />
Use a WINS server. The SMB browsing protocol relies heavily on broadcasts on the local net, which are problematic with vservers. WINS resolution on the other hand is unicast and works flawlessly under vserver.<br />
<br />
==== Samba printer and file server with cups ====<br />
Samba runs correctly in a Mandriva (Mdk) 10.1 Vserver, (Apart from the above oplock problem ?).First, edit your ''/etc/sysconfig/network'' file, and set ''networking'' to ''yes'' (This will solve problems for other services !):<br />
<pre><br />
# cat /etc/sysconfig/network<br />
NETWORKING=yes<br />
</pre><br />
Some more tweaking is needeed in ''/etc/smb.conf''<br />
<pre><br />
# cat /etc/smb.conf<br />
...<br />
# YOUR VSERVER IP/MASK HERE<br />
interfaces = xxx.xxx.xxx.xxx/mask<br />
...<br />
</pre><br />
<br />
But if you're using Samba + Cups to provide printing for Windows clients, AND if you want to use the ''Point and Print'' feature, there is more: In the ''[printers]'' section of your ''smb.conf'', you should have the ''use client drivers'' directive set to ''no'', or the driver upload procedure will fail !<br />
<pre><br />
# cat /etc/smb.conf<br />
...<br />
use client driver = no<br />
...<br />
</pre><br />
So, here is a full ''smb.conf'' file: <br />
<pre><br />
# cat /etc/samba/smb.conf | awk '!/^$/ && !/^\s*(#|;)/ {print $0}'<br />
[global]<br />
workgroup = MYDOMAIN<br />
netbios name = MYHOSTNAME<br />
server string = MYCOMMENT (Samba %v)<br />
printcap name = cups<br />
load printers = yes<br />
printing = cups<br />
printer admin = @adm<br />
log file = /var/log/samba/log.%m<br />
max log size = 50<br />
map to guest = bad user<br />
security = domain<br />
password server = *<br />
encrypt passwords = yes<br />
smb passwd file = /etc/samba/smbpasswd<br />
username map = /etc/samba/smbusers<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192<br />
interfaces = 127. MYVSERVERIP/MYVSERVERMASK<br />
wins server = MYWINSIP<br />
dns proxy = no<br />
# for french users:<br />
dos charset = 850<br />
unix charset = ISO8859-1<br />
[homes]<br />
comment = Home Directories<br />
browseable = no<br />
writable = no<br />
[printers]<br />
comment = All Printers<br />
path = /var/spool/samba<br />
browseable = no<br />
guest ok = no<br />
writable = no<br />
printable = yes<br />
create mode = 0700<br />
print command = lpr-cups -P %p -o raw %s -r # using client side printer drivers.<br />
use client driver = no<br />
[print$]<br />
path = /var/lib/samba/printers<br />
browseable = yes<br />
write list = @adm root<br />
guest ok = yes<br />
inherit permissions = yes<br />
</pre><br />
...And a working smbusers:<br />
<pre><br />
# Unix_name = SMB_name1 SMB_name2 ...<br />
root = administrator MYDOMAIN\administrator<br />
nobody = guest pcguest smbguest<br />
</pre><br />
<br />
=== Cups print server ===<br />
Symptoms: The Cups init script exits with:<br />
<pre><br />
Starting CUPS printing system: cupsd: Child exited with status 98!<br />
</pre> <br />
And the logs (''/var/log/cups/error_log'') show:<br />
<pre> <br />
E [date:hour...] StartListening: Unable to bind socket for address 0.0.0.0:631 - Address already in use.<br />
</pre> <br />
...Or something like this. <br />
<br />
With a correct "cupsd.conf file" (Tested version 1.1.21-0.rc1.7mdk, on Mandrake 10.1 - Now Mandriva), it works; All we need is to remove references to ''127.0.0.1'' or ''localhost'' from the file, as well as correctly unsetting the ''Listen'' directive:<br />
<pre> <br />
LogLevel info<br />
TempDir /var/spool/cups/tmp<br />
# No 'Listen' directive !<br />
Port 631<br />
BrowseAddress @LOCAL<br />
BrowseDeny All<br />
BrowseAllow @LOCAL<br />
BrowseOrder deny,allow<br />
<Location /><br />
Order Deny,Allow<br />
Deny From All<br />
Allow From @LOCAL<br />
</Location><br />
<Location /admin><br />
AuthType Basic<br />
AuthClass System<br />
Order Deny,Allow<br />
Deny From All<br />
Allow From YOUR_NETWORK_ADDRESS/YOUR_NETMASK # Example: 172.16.0.0/24<br />
# Or<br />
Allow From @LOCAL<br />
</Location><br />
</pre> <br />
Then you'll need to modify the ''/etc/init.d/cups'' script, to comment any section referring to ''127.0.0.1'' lookup and configuration. This section exists at least on Mandrake 10.1, and is pretty long (Lines 35 to 55 and/or 79), and additionnaly four "''else...if''" lines must be commented far below (Lines 161 to 164) ! <br />
<br />
Remember to stop any Cupsd running in the host server, or to start it via a wrapper ''/etc/init.d/v_cups'' script: <br />
<pre> <br />
#!/bin/sh<br />
# chkconfig: 2345 15 60<br />
# description: Wrapper to start cups bound to a single IP<br />
USR_LIB_VSERVER=/usr/lib/util-vserver<br />
exec $USR_LIB_VSERVER/vsysvwrapper cups $*<br />
</pre> <br />
Do not forget to give a password to the root user, if you want to be able to manage your printers from the web interface (http://yourcupsvserver:631)!<br />
<pre> <br />
# passwd root<br />
...<br />
</pre> <br />
If you use Mandriva 10.1 (And maybe some other distros), you&#8217;ll need to add the printers drivers for Cups, and reload it:<br />
<pre> <br />
# urpmi --root /vservers/yourcupsvserver/ cups-drivers<br />
# /etc/init.d/cups reload<br />
</pre> <br />
&#8230;It added 67 Mb of packages for me. <br />
<br />
Then use ''/etc/init.d/v_cups (re)start'' to launch Cups on the host server. <br />
You will now be able to make Cupsd start in the vserver , but more tweaking on the ACLs may be necessary to avoid authentification problems...<br />
<br />
=== Bind9 on Debian GNU/Linux Woody (3.0), Sarge (3.1), Etch (4.0) ===<br />
named provided by the bind9 binary packages fails to start because it is compiled with CAPs option. <br />
<br />
The debian way is to build** your own package without CAPs:<br />
<pre><br />
su -<br />
cd /usr/src<br />
apt-get build-dep bind9<br />
apt-get source bind9<br />
cd bind9-x.x.x<br />
vi debian/rules<br />
</pre> <br />
Insert the following line after "./configure --prefix=/usr \":<br />
<pre><br />
--disable-linux-caps \ <br />
</pre> <br />
On a NPTL-enabled system you alse have to replace <br />
<pre> <br />
--enable-threads \<br />
</pre> <br />
with<br />
<pre> <br />
--disable-threads \<br />
</pre> <br />
or bind might refuse to run with an other user than root. <br />
<br />
Save the file and go ahead with compiling/installing: <br />
<pre> <br />
dpkg-buildpackage<br />
dpkg -i ../bind9-x.x.x.deb<br />
echo "bind9 hold" | dpkg --set-selections<br />
</pre> <br />
The last line is to set the package "on hold", so it is not touched by the update process. you have to take care of security holes by yourself now! <br />
<br />
The Xs in "bind9-x.x.x" denote the version number of bind9. Alternatively you can allow the CAP_SYS_RESOURCE for that V-Server. The best way would be to fix bind, which is somehow broken when it comes to capabilities. Daniel Hokka Zakrisson repaired it. His patch is to be found here:<br />
<br />
[http://daniel.hozac.com/stuff/bind-9.3.2-caps-when-available.patch bind-9.3.2-caps-when-available.patch]<br />
<br />
So, if you recompile, it would be the cleanest way to apply that patch. Thanks Daniel! It would be also nice, if someone submits that patch to the bind people or maybe to your distribution's package maintainers in the first step.<br />
<br />
Get my [http://linux-vserver.derjohn.de/bind9-packages/bind9-capacheck_9.3.2-2_i386.deb vserver-guest-ready Debian bind9 package] for Debian Sid guests. Feedback welcome: aj@net-lab.net<br />
<br />
''Problems getting this to work in an x86_64 vserver. Any hints? From what I can tell from stracing, turning off threads doesn't fix everything related to it. It also caused a juicy Ksymoops.''<br />
<br />
''- Apparently this does work when running bind as user root. I Installed a bare Debian Etch vserver without granting any special capabilities on my x86_64 system, apt-get install bind9, kill any started named-processes and edit /etc/default/bind, changing the user (-u) from bind to root. Bind starts now starts when using /etc/init.d/bind9 start and resolving seems to work. Mind you, the usual warnings and rants about running stuff as root still applies! - 2007-08-06 MGS''<br />
<br />
=== Zimbra Mail ===<br />
Zimbra is many applications (including Postfix and MySQL? and OpenLDAP? and more) which try to take over the interfaces, and depend a lot on binding from 127.0.0.1 - it is not hard to change, but there is a couple of tricks - it is documented here - http://wiki.zimbra.com/index.php?title=Install_VServer<br />
<br />
=== xine ===<br />
won't start with no error message.<br />
<br />
"xine --verbose" shows this.<br />
<pre> <br />
ERROR: Could not determine network interfaces, you must use a interfaces config line<br />
</pre> <br />
This happens if you have the xineplug_inp_smb.so plugin. Delete it and everything is fine.<br />
<br />
=== 127.0.0.1 issues ===<br />
I had problems with an application that wanted me to access it on 127.0.0.1 and AS 127.0.0.1 to be able to do its configuration. A simple tweak solved the problem. I renamed the default interface directory "0" in /etc/vservers/server/interfaces to "1" and created interface 0 as :<br />
<pre> <br />
dev lo <br />
ip 127.0.0.1 <br />
mask 255.0.0.0 <br />
name lo <br />
</pre> <br />
now interface "1" is the default created interface by the vserver build script with a local adress like 192.168.1.2 and interface "0" is the loopback. I can now telnet on 127.0.0.1 and it sees that im connecting to 127.0.0.1 from 127.0.0.1<br />
<br />
Compiling nagios-1.4 within a vserver requires this, otherwise it hangs during the configure with "checking for ICMP ping syntax..."<br />
<div style="color: red;"><br />
note: nagios is broken, because it uses a hardcoded 127.0.0.1, and this change (which is not needed with newer kernels providing lback remapping) will affect guest security and should not be used lightly (Bertl)<br />
</div><br />
<br />
=== Hula-project ===<br />
Does not want to start. TODO: add more information.<br />
<br />
=== Postfix ===<br />
<br />
==== Postfix 2.1.5 (Debian Sarge) ====<br />
On a vserver with two interfaces (lo and eth0), and a postfix 2.1.5 listening on lo, postfix can't send emails : "Invalid argument"... Setting smtp_bind_address (http://www.postfix.org/postconf.5.html#smtp_bind_address) to the external address solves the issue. <br />
<br />
==== Postfix on Debian Etch (for local only mail) ====<br />
<br />
See [[Postfix local only problem]]<br />
<br />
==== Postfix Policy Daemon ====<br />
Running a Debian 3.1 Sarge with Backports I have several issues with the postfix-policyd because it wants to set the rlimits.<br />
<br />
Log returns: <br />
<pre> <br />
cannot set rlimit: Operation not permitted<br />
</pre> <br />
Strace tells us:<br />
<pre> <br />
setrlimit(RLIMIT_NOFILE, {rlim_cur=4097, rlim_max=4097}) = -1 EPERM (Operation not permitted)<br />
</pre> <br />
Output on the Host<br />
<pre> <br />
# ulimit -Ha<br />
...<br />
-n: file descriptors 1024<br />
...<br />
</pre><br />
Thats too little...<br />
<br />
Solution:<br />
<br />
The App has again a build in need to use CAP_SYS_RESOURCE (which is bad (tm)) so in the guest do:<br />
<pre><br />
# ulimit -HS -n 8192<br />
# ulimit -Ha<br />
.. shows us now the correct 8192 instead of 1024.<br />
<br />
# vserver $yourVserverName restart<br />
# vserver $yourVserverName enter<br />
<br />
$yourVserverName # ulimit -Ha<br />
...<br />
-n: file descriptors 8192<br />
...<br />
</pre><br />
Everything should be fine now !<br />
<br />
<br />
<br />
=== DB2 ===<br />
DB2 needs at least the following capabilities:<br />
CAP_NET_RAW<br />
CAP_NET_ADMIN<br />
CAP_SYS_ADMIN<br />
CAP_IPC_LOCK<br />
CAP_IPC_OWNER<br />
<div style="color: red;"><br />
WARNING: this configuration reduces security<br />
</div><br />
<br />
=== ejabberd ===<br />
ejabberd does not work properly in a Linux-VServer guest under Debian Etch. The server eventually stops accepting connections. Also, it's not possible to control ejabberd with ejabberdctl. The Jabber server from the jabber package works though.<br />
<br />
=== VMware Server ===<br />
VMware Server needs the following capabilities to run correctly:<br />
CAP_MKNOD<br />
CAP_SYS_MODULE<br />
CAP_SYS_ADMIN<br />
CAP_SYS_NICE<br />
CAP_NET_RAW<br />
CAP_NET_ADMIN<br />
CAP_IPC_OWNER<br />
<div style="color: red;"><br />
WARNING: this configuration reduces security<br />
</div><br />
<br />
=== ntpd ===<br />
The ntpd daemon needs to set the hardware time and can't do that from inside a vserver by default.<br />
Allow CAP_SYS_TIME and ntpd will be happy.</div>KornAndrashttp://wiki.linux-vserver.org/Running_runit-supervised_services_inside_a_vserverRunning runit-supervised services inside a vserver2007-06-28T13:11:30Z<p>KornAndras: typo fix</p>
<hr />
<div>This page describes a setup where you have a [http://smarden.org/runit runit] installation on the host and use it to directly supervise services running in vserver guests.<br />
<br />
== Motivation and goals ==<br />
<br />
This is what I wanted to achieve:<br />
<br />
* Partition a physical server with many responsibilities into vservers that can easily be upgraded individually without breaking any unrelated stuff.<br />
* Each service or small set of services should run in its own vserver.<br />
* Services should be supervised (started, stopped and managed) by [http://smarden.org/runit runit].<br />
* Service logs should accumulate on the host, not the guests.<br />
** <tt>svlogd</tt> rotates them nicely and can invoke my <tt>multilogcheck</tt> script to alert me of unusual events as a postprocessor, but<br />
** I don't want to install <tt>multilogcheck</tt> inside every vserver because it's messy.<br />
** I don't like syslog. There are many problems with it, but I won't go into that here.<br />
*** Therefore, services mostly log to stdout and thus to svlogd.<br />
*** For services that absolutely must use syslog, I provide [http://smarden.org/socklog socklog].<br />
*** Again, I don't want a separate <tt>socklog</tt> instance in every vserver.<br />
*** Alas, <tt>socklog</tt> is unable to listen on more than one Unix domain socket.<br />
**** Luckily, <tt>socat</tt> can be used to relay syslog messages from the vservers to the master <tt>socklog</tt> on the host. (<tt>syslog-ng</tt> would also have done the job nicely.)<br />
* It should be straightforward and next to transparent to manage the services running in vservers.<br />
** With <tt>runit</tt>, it's easy to delegate management rights of a service to users (chown and chmod some files in the pertinent <tt>supervise</tt> directory). This should continue to work.<br />
<br />
== Prerequisites ==<br />
<br />
# A fairly recent vserver kernel with support for persistent contexts (I used 2.6.19.2-vs2.2.0-rc8.7).<br />
# A recent version of util-vserver that supports persistent contexts correctly (I used [http://people.linux-vserver.org/~dhozac/p/uv/experimental/util-vserver-0.30.213-rc1.tar.bz2 0.30.213-rc1]).<br />
# Daniel_Hozac's [http://people.linux-vserver.org/~dhozac/t/signal-relay.c signal-relay] program.<br />
<br />
== The big picture ==<br />
<br />
Let's see how it all fits together.<br />
<br />
We'd like to achieve something like this (output of <tt>vps axfu</tt>):<br />
<br />
<pre><br />
USER PID CONTEXT %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND<br />
root 1 0 MAIN 0.0 0.0 104 16 ? Ss Jan29 0:06 runit<br />
root 4188 0 MAIN 0.0 0.0 132 32 ? Ss Jan29 0:10 runsvdir -P /var/service log: .......................................................<br />
root 4250 0 MAIN 0.0 0.0 108 28 ? Ss Jan29 0:00 \_ runsv vserver-logrelay-squid<br />
log 4256 0 MAIN 0.0 0.0 128 44 ? S Jan29 0:00 | \_ svlogd -t /var/log/sv/vserver-logrelay-squid<br />
logrelay 3106 0 MAIN 0.0 0.1 25428 1944 ? S 00:44 0:00 | \_ socat -d -d -d -D -ls -u UNIX-LISTEN:/etc/vservers/squid/vdir/dev/log,unlink-early,nonblock,mode=666,setuid=logrelay UNIX-CONNECT:/dev/log,type=2,nonblock,forever<br />
root 19272 0 MAIN 0.0 0.0 108 28 ? Ss Feb01 0:00 \_ runsv squid<br />
log 19273 0 MAIN 0.0 0.0 128 44 ? S Feb01 0:00 | \_ svlogd -t /var/log/sv/squid<br />
root 10324 0 MAIN 0.0 0.0 5728 364 ? S Feb01 0:00 | \_ signal-relay vserver squid exec squid -N -D -sYC<br />
proxy 10334 2 squid 0.0 0.5 24968 8036 ? Sl Feb01 0:01 | \_ squid -N -D -sYC<br />
root 24219 0 MAIN 0.0 0.0 108 32 ? Ss 02:02 0:00 \_ runsv nmbd<br />
root 24220 0 MAIN 0.0 0.0 5732 376 ? S 02:02 0:00 | \_ signal-relay vserver samba exec /usr/sbin/nmbd -F<br />
root 24230 3 samba 0.0 0.1 30080 2360 ? Ss 02:02 0:00 | \_ /usr/sbin/nmbd -F<br />
root 24251 3 samba 0.0 0.0 32172 1496 ? S 02:02 0:00 | \_ /usr/sbin/nmbd -F<br />
root 24253 0 MAIN 0.0 0.0 108 28 ? Ss 02:02 0:00 \_ runsv smbd<br />
root 24254 0 MAIN 0.0 0.0 5732 376 ? S 02:02 0:00 | \_ signal-relay vserver samba exec /usr/sbin/smbd -F<br />
root 24268 3 samba 0.0 0.2 41888 3404 ? Ss 02:02 0:00 | \_ /usr/sbin/smbd -F<br />
root 24289 3 samba 0.0 0.0 41888 1232 ? S 02:02 0:00 | \_ /usr/sbin/smbd -F<br />
root 29625 0 MAIN 0.0 0.0 104 28 ? Ss 02:22 0:00 \_ runsv cron-squid<br />
root 29626 0 MAIN 0.0 0.0 5732 376 ? S 02:22 0:00 \_ signal-relay vserver squid exec cron -f<br />
root 29637 2 squid 0.0 0.0 11492 1060 ? S 02:22 0:00 \_ cron -f<br />
</pre><br />
<br />
For service supervision to work, we must be able to send signals to our services. Specifically, <tt>runsv</tt> must be able to send signals to its children.<br />
Alas, it's not prepared to send signals across context boundaries, which is where <tt>signal-relay</tt> comes in.<br />
<br />
=== <tt>signal-relay</tt> ===<br />
<br />
<tt>signal-relay</tt> is a small program not unlike <tt>runit</tt>'s <tt>chpst</tt> that does the following:<br />
<br />
* it forks a child;<br />
** inside the child, it execs the program specified on its command line;<br />
* in the parent, it sets up signal handlers for every signal that relay the signal to the child, even if the child is running in a different context;<br />
* if the child exits, <tt>signal-relay</tt> exits.<br />
* (It can also put the child into its own process group; use the <tt>-P</tt> switch. Sending signals to process groups in a different context doesn't work yet, though.)<br />
<br />
=== Setting up the vservers ===<br />
<br />
When we start a service for runit, we want the command that starts the service to stay in the foreground until the moment the service dies. <tt>vserver exec</tt> looks just right, but there is a catch: it only works for vservers that have been "started". <tt>vserver start</tt>, however, doesn't fit very well into the <tt>runit</tt> way of doing things. You can set it up as a service (this is discussed in [[util-vserver:InitStyles]]), but it seems superfluous to leave some processes around just to keep a vserver "started" so that we can run services in it.<br />
<br />
What we need is a way of basically doing "start vserver <guest> if it's not started, then exec program <service> inside it". Normally, a context with no processes running inside it is destroyed by the kernel; thus, just setting <tt>/etc/vservers/guest/apps/init/cmd.start</tt> to <tt>/bin/true</tt> isn't going to work; we would need something that stays around for a while, like a script that calls <tt>sleep 1m &</tt>. This would make <tt>vserver start</tt> happy, so in our service run script, we could do something like<br />
<br />
<pre><br />
vserver guest status || vserver guest start<br />
exec signal-relay vserver guest exec /path/to/service-program<br />
</pre><br />
<br />
A more elegant solution is to make the guest context ''persistent''. This way it sticks around even if there are no processes left in it.<br />
<br />
<pre><br />
cd /etc/vservers/guest<br />
echo persistent >>flags<br />
echo persistent >>nflags<br />
echo /bin/true >apps/init/cmd.start<br />
</pre><br />
<br />
(I ''guess'' <tt>nflags</tt> is for the network context.)<br />
<br />
Now, <tt>vserver guest start</tt> should be able to "start" our vserver (set up all of its state), and exit without leaving stray processes around.<br />
<br />
== Running services ==<br />
<br />
Say you have a vserver called <tt>squid</tt>, and you want to run your <tt>squid</tt> proxy inside it to keep it insulated from the other processes on the system, and vice versa.<br />
<br />
In our current setup, the following run script will do the trick (it borrows a bit from Debian's initscript and uses the Debian defaults file):<br />
<br />
<pre><br />
#!/bin/sh<br />
exec 2>&1<br />
<br />
# Set a default for max. filedescriptors<br />
SQUID_MAXFD=4096<br />
<br />
# Figure out the name of the service we're running as<br />
SVNAME=$(basename $(pwd))<br />
<br />
# Read the configfile of this service; if it sets VSERVERNAME, we'll assume we have to run inside the specified vserver<br />
CONFIG=/etc/default/"$SVNAME"<br />
[ -r "$CONFIG" ] && . "$CONFIG"<br />
<br />
# Source Debian defaults<br />
[ -n "$VSERVERNAME" ] && VROOT="/etc/vservers/$VSERVERNAME/vdir" || VROOT=/<br />
[ -r "$VROOT/etc/default/squid" ] && . "$VROOT/etc/default/squid"<br />
<br />
[ "$SQUID_MAXFD" -gt 4096 ] && SQUID_MAXFD=4096<br />
<br />
if test -f /proc/sys/fs/file-max; then<br />
global_file_max=$(cat /proc/sys/fs/file-max)<br />
minimal_file_max=$(($SQUID_MAXFD + 4096))<br />
[ "$global_file_max" -lt "$minimal_file_max" ] && echo "$minimal_file_max" >/proc/sys/fs/file-max<br />
fi<br />
<br />
if [ ! "$VSERVERNAME" = "" ]; then<br />
VSERVERARGS="signal-relay vserver $VSERVERNAME exec"<br />
vserver "$VSERVERNAME" status || vserver "$VSERVERNAME" start # start the vserver if necessary<br />
fi<br />
<br />
exec chpst -o"$SQUID_MAXFD" $VSERVERARGS squid -N -D -sYC<br />
</pre><br />
<br />
This script is generic in the sense that it works with or without a vserver setup.<br />
<br />
You can run an <tt>svlogd</tt> for this service like you normally would; or you could have all your <tt>svlogd</tt>s run in a different vserver.<br />
<br />
A run script for <tt>cron</tt> that automatically figures out if it should run in a vserver:<br />
<br />
<pre><br />
#!/bin/sh<br />
exec 2>&1<br />
DEPENDENCIES=""<br />
RLIMIT="chpst -t 172800"<br />
SVNAME=$(basename $(pwd))<br />
CONFIG=/etc/default/"$SVNAME"<br />
<br />
# Assume part after dash is name of vserver<br />
if [ ! "${SVNAME/*-/}" = "$SVNAME" ]; then<br />
VSERVERNAME="${SVNAME/*-/}"<br />
fi<br />
<br />
# By default, we depend on the socklog service if it exists<br />
[ -e /service/socklog ] && DEPENDENCIES=socklog<br />
<br />
# And also on the logrelay service of the pertinent vserver<br />
[ -e /service/vserver-logrelay-"$VSERVERNAME" ] && DEPENDENCIES="$DEPENDENCIES vserver-logrelay-$VSERVERNAME"<br />
<br />
# Can override VSERVERNAME, RLIMIT and DEPENDENCIES here if necessary<br />
[ -r "$CONFIG" ] && . "$CONFIG"<br />
<br />
if [ ! "$VSERVERNAME" = "" ]; then<br />
VSERVERARGS="signal-relay vserver $VSERVERNAME exec"<br />
vserver "$VSERVERNAME" status || vserver "$VSERVERNAME" start<br />
fi<br />
<br />
if [ -n "$DEPENDENCIES" ]; then<br />
sv start $DEPENDENCIES || exit 1<br />
fi<br />
<br />
exec $RLIMIT $VSERVERARGS cron -f<br />
</pre><br />
<br />
Now, if you place this run script in a service directory called <tt>cron-squid</tt>, it will run a cron daemon in the <tt>squid</tt> guest. This takes care of rotating the squid logs under <tt>/var/log/squid</tt>, for example; although this could also be done on the host with a few kludges.<br />
<br />
The vserver-logrelay-template/run script looks like this:<br />
<br />
<pre><br />
#!/bin/sh<br />
exec 2>&1<br />
SVNAME=$(basename $(pwd))<br />
RUNASUSER=logrelay<br />
MODE=666<br />
VSERVERNAME=$(echo $SVNAME | sed 's/vserver-logrelay-//')<br />
[ -r "/etc/default/$SVNAME" ] && . "/etc/default/$SVNAME"<br />
<br />
exec socat -d -d -d -D -ls -u \<br />
UNIX-LISTEN:/etc/vservers/$VSERVERNAME/vdir/dev/log,unlink-early,nonblock,mode=$MODE,setuid=$RUNASUSER \<br />
UNIX-CONNECT:/dev/log,type=2,nonblock,forever<br />
</pre><br />
<br />
This will pass syslog messages from a vserver to the syslog of the host by acting as a syslog server for the <tt>/dev/log</tt> socket of the guest. Thus, you don't need to run a <tt>syslogd</tt> inside the vserver and you don't need to migrate to <tt>syslog-ng</tt> from <tt>socklog</tt> on the host.<br />
<br />
Symlink this run script into a service directory called <tt>vserver-logrelay-squid</tt>.<br />
<br />
Unfortunately, <tt>socat</tt> has a largish memory footprint; something more lightweight could, perhaps, be used.<br />
<br />
Comments and additions welcome.<br />
--[[User:KornAndras|Guy-]] 03:29, 2 February 2007 (CET)</div>KornAndrashttp://wiki.linux-vserver.org/Talk:Problematic_ProgramsTalk:Problematic Programs2007-02-04T21:13:51Z<p>KornAndras: </p>
<hr />
<div>I stronly suggest we rename this page to something else. I have become embroiled in a discussion with a customer and their development team who do not fully understand the concept of vservers, and the management team is not strong enough to discern quality of all technical arguments. The developer is using the title of this particular page as an indication that there are "problems with vservers and we shouldnt use them".<br />
<br />
The first line of the page does outline how its most often not vserver's fault, but the name of the page seems to summarize a point of view about vservers thats detrimental.<br />
<br />
Perhaps we should rename it to soemthing like "programs needing vserver-specific configuration" or the like. Hard to find a nice two word one like "problematic programs", but the name suggests more negative aspects than it should.<br />
<br />
-- [[User:Math|Math]]<br />
: The way that I see it, "Problematic Programs" means that the ''programs'' are problematic, not Linux-VServer itself ;). A new title would still be good, but "Programs needing VServer-specific configuration" is probably too long for a page title. <br /> -- [[User:Daniel15|<span style="color: darkblue; font-weight: bold; border: 1px solid #6666FF; padding: 3px;">Daniel15</span>]] <big>(</big><sup>[[User talk:Daniel15|Talk]]</sup>/<sub>[[Special:Contributions/Daniel15|Contribs]]</sub><big>)</big> 09:30, 4 February 2007 (CET)<br />
<br />
How about "Issues with 3rd party software"?<br />
--[[User:KornAndras|Guy-]] 22:13, 4 February 2007 (CET)</div>KornAndrashttp://wiki.linux-vserver.org/Running_runit-supervised_services_inside_a_vserverRunning runit-supervised services inside a vserver2007-02-02T02:29:31Z<p>KornAndras: Initial version</p>
<hr />
<div>This page describes a setup where you have a [http://smarden.org/runit runit] installation on the host and use it to directly supervies services running in vserver guests.<br />
<br />
== Motivation and goals ==<br />
<br />
This is what I wanted to achieve:<br />
<br />
* Partition a physical server with many responsibilities into vservers that can easily be upgraded individually without breaking any unrelated stuff.<br />
* Each service or small set of services should run in its own vserver.<br />
* Services should be supervised (started, stopped and managed) by [http://smarden.org/runit runit].<br />
* Service logs should accumulate on the host, not the guests.<br />
** <tt>svlogd</tt> rotates them nicely and can invoke my <tt>multilogcheck</tt> script to alert me of unusual events as a postprocessor, but<br />
** I don't want to install <tt>multilogcheck</tt> inside every vserver because it's messy.<br />
** I don't like syslog. There are many problems with it, but I won't go into that here.<br />
*** Therefore, services mostly log to stdout and thus to svlogd.<br />
*** For services that absolutely must use syslog, I provide [http://smarden.org/socklog socklog].<br />
*** Again, I don't want a separate <tt>socklog</tt> instance in every vserver.<br />
*** Alas, <tt>socklog</tt> is unable to listen on more than one Unix domain socket.<br />
**** Luckily, <tt>socat</tt> can be used to relay syslog messages from the vservers to the master <tt>socklog</tt> on the host. (<tt>syslog-ng</tt> would also have done the job nicely.)<br />
* It should be straightforward and next to transparent to manage the services running in vservers.<br />
** With <tt>runit</tt>, it's easy to delegate management rights of a service to users (chown and chmod some files in the pertinent <tt>supervise</tt> directory). This should continue to work.<br />
<br />
== Prerequisites ==<br />
<br />
# A fairly recent vserver kernel with support for persistent contexts (I used 2.6.19.2-vs2.2.0-rc8.7).<br />
# A recent version of util-vserver that supports persistent contexts correctly (I used [http://people.linux-vserver.org/~dhozac/p/uv/experimental/util-vserver-0.30.213-rc1.tar.bz2 0.30.213-rc1]).<br />
# Daniel_Hozac's [http://people.linux-vserver.org/~dhozac/t/signal-relay.c signal-relay] program.<br />
<br />
== The big picture ==<br />
<br />
Let's see how it all fits together.<br />
<br />
We'd like to achieve something like this (output of <tt>vps axfu</tt>):<br />
<br />
<pre><br />
USER PID CONTEXT %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND<br />
root 1 0 MAIN 0.0 0.0 104 16 ? Ss Jan29 0:06 runit<br />
root 4188 0 MAIN 0.0 0.0 132 32 ? Ss Jan29 0:10 runsvdir -P /var/service log: .......................................................<br />
root 4250 0 MAIN 0.0 0.0 108 28 ? Ss Jan29 0:00 \_ runsv vserver-logrelay-squid<br />
log 4256 0 MAIN 0.0 0.0 128 44 ? S Jan29 0:00 | \_ svlogd -t /var/log/sv/vserver-logrelay-squid<br />
logrelay 3106 0 MAIN 0.0 0.1 25428 1944 ? S 00:44 0:00 | \_ socat -d -d -d -D -ls -u UNIX-LISTEN:/etc/vservers/squid/vdir/dev/log,unlink-early,nonblock,mode=666,setuid=logrelay UNIX-CONNECT:/dev/log,type=2,nonblock,forever<br />
root 19272 0 MAIN 0.0 0.0 108 28 ? Ss Feb01 0:00 \_ runsv squid<br />
log 19273 0 MAIN 0.0 0.0 128 44 ? S Feb01 0:00 | \_ svlogd -t /var/log/sv/squid<br />
root 10324 0 MAIN 0.0 0.0 5728 364 ? S Feb01 0:00 | \_ signal-relay vserver squid exec squid -N -D -sYC<br />
proxy 10334 2 squid 0.0 0.5 24968 8036 ? Sl Feb01 0:01 | \_ squid -N -D -sYC<br />
root 24219 0 MAIN 0.0 0.0 108 32 ? Ss 02:02 0:00 \_ runsv nmbd<br />
root 24220 0 MAIN 0.0 0.0 5732 376 ? S 02:02 0:00 | \_ signal-relay vserver samba exec /usr/sbin/nmbd -F<br />
root 24230 3 samba 0.0 0.1 30080 2360 ? Ss 02:02 0:00 | \_ /usr/sbin/nmbd -F<br />
root 24251 3 samba 0.0 0.0 32172 1496 ? S 02:02 0:00 | \_ /usr/sbin/nmbd -F<br />
root 24253 0 MAIN 0.0 0.0 108 28 ? Ss 02:02 0:00 \_ runsv smbd<br />
root 24254 0 MAIN 0.0 0.0 5732 376 ? S 02:02 0:00 | \_ signal-relay vserver samba exec /usr/sbin/smbd -F<br />
root 24268 3 samba 0.0 0.2 41888 3404 ? Ss 02:02 0:00 | \_ /usr/sbin/smbd -F<br />
root 24289 3 samba 0.0 0.0 41888 1232 ? S 02:02 0:00 | \_ /usr/sbin/smbd -F<br />
root 29625 0 MAIN 0.0 0.0 104 28 ? Ss 02:22 0:00 \_ runsv cron-squid<br />
root 29626 0 MAIN 0.0 0.0 5732 376 ? S 02:22 0:00 \_ signal-relay vserver squid exec cron -f<br />
root 29637 2 squid 0.0 0.0 11492 1060 ? S 02:22 0:00 \_ cron -f<br />
</pre><br />
<br />
For service supervision to work, we must be able to send signals to our services. Specifically, <tt>runsv</tt> must be able to send signals to its children.<br />
Alas, it's not prepared to send signals across context boundaries, which is where <tt>signal-relay</tt> comes in.<br />
<br />
=== <tt>signal-relay</tt> ===<br />
<br />
<tt>signal-relay</tt> is a small program not unlike <tt>runit</tt>'s <tt>chpst</tt> that does the following:<br />
<br />
* it forks a child;<br />
** inside the child, it execs the program specified on its command line;<br />
* in the parent, it sets up signal handlers for every signal that relay the signal to the child, even if the child is running in a different context;<br />
* if the child exits, <tt>signal-relay</tt> exits.<br />
* (It can also put the child into its own process group; use the <tt>-P</tt> switch. Sending signals to process groups in a different context doesn't work yet, though.)<br />
<br />
=== Setting up the vservers ===<br />
<br />
When we start a service for runit, we want the command that starts the service to stay in the foreground until the moment the service dies. <tt>vserver exec</tt> looks just right, but there is a catch: it only works for vservers that have been "started". <tt>vserver start</tt>, however, doesn't fit very well into the <tt>runit</tt> way of doing things. You can set it up as a service (this is discussed in [[util-vserver:InitStyles]]), but it seems superfluous to leave some processes around just to keep a vserver "started" so that we can run services in it.<br />
<br />
What we need is a way of basically doing "start vserver <guest> if it's not started, then exec program <service> inside it". Normally, a context with no processes running inside it is destroyed by the kernel; thus, just setting <tt>/etc/vservers/guest/apps/init/cmd.start</tt> to <tt>/bin/true</tt> isn't going to work; we would need something that stays around for a while, like a script that calls <tt>sleep 1m &</tt>. This would make <tt>vserver start</tt> happy, so in our service run script, we could do something like<br />
<br />
<pre><br />
vserver guest status || vserver guest start<br />
exec signal-relay vserver guest exec /path/to/service-program<br />
</pre><br />
<br />
A more elegant solution is to make the guest context ''persistent''. This way it sticks around even if there are no processes left in it.<br />
<br />
<pre><br />
cd /etc/vservers/guest<br />
echo persistent >>flags<br />
echo persistent >>nflags<br />
echo /bin/true >apps/init/cmd.start<br />
</pre><br />
<br />
(I ''guess'' <tt>nflags</tt> is for the network context.)<br />
<br />
Now, <tt>vserver guest start</tt> should be able to "start" our vserver (set up all of its state), and exit without leaving stray processes around.<br />
<br />
== Running services ==<br />
<br />
Say you have a vserver called <tt>squid</tt>, and you want to run your <tt>squid</tt> proxy inside it to keep it insulated from the other processes on the system, and vice versa.<br />
<br />
In our current setup, the following run script will do the trick (it borrows a bit from Debian's initscript and uses the Debian defaults file):<br />
<br />
<pre><br />
#!/bin/sh<br />
exec 2>&1<br />
<br />
# Set a default for max. filedescriptors<br />
SQUID_MAXFD=4096<br />
<br />
# Figure out the name of the service we're running as<br />
SVNAME=$(basename $(pwd))<br />
<br />
# Read the configfile of this service; if it sets VSERVERNAME, we'll assume we have to run inside the specified vserver<br />
CONFIG=/etc/default/"$SVNAME"<br />
[ -r "$CONFIG" ] && . "$CONFIG"<br />
<br />
# Source Debian defaults<br />
[ -n "$VSERVERNAME" ] && VROOT="/etc/vservers/$VSERVERNAME/vdir" || VROOT=/<br />
[ -r "$VROOT/etc/default/squid" ] && . "$VROOT/etc/default/squid"<br />
<br />
[ "$SQUID_MAXFD" -gt 4096 ] && SQUID_MAXFD=4096<br />
<br />
if test -f /proc/sys/fs/file-max; then<br />
global_file_max=$(cat /proc/sys/fs/file-max)<br />
minimal_file_max=$(($SQUID_MAXFD + 4096))<br />
[ "$global_file_max" -lt "$minimal_file_max" ] && echo "$minimal_file_max" >/proc/sys/fs/file-max<br />
fi<br />
<br />
if [ ! "$VSERVERNAME" = "" ]; then<br />
VSERVERARGS="signal-relay vserver $VSERVERNAME exec"<br />
vserver "$VSERVERNAME" status || vserver "$VSERVERNAME" start # start the vserver if necessary<br />
fi<br />
<br />
exec chpst -o"$SQUID_MAXFD" $VSERVERARGS squid -N -D -sYC<br />
</pre><br />
<br />
This script is generic in the sense that it works with or without a vserver setup.<br />
<br />
You can run an <tt>svlogd</tt> for this service like you normally would; or you could have all your <tt>svlogd</tt>s run in a different vserver.<br />
<br />
A run script for <tt>cron</tt> that automatically figures out if it should run in a vserver:<br />
<br />
<pre><br />
#!/bin/sh<br />
exec 2>&1<br />
DEPENDENCIES=""<br />
RLIMIT="chpst -t 172800"<br />
SVNAME=$(basename $(pwd))<br />
CONFIG=/etc/default/"$SVNAME"<br />
<br />
# Assume part after dash is name of vserver<br />
if [ ! "${SVNAME/*-/}" = "$SVNAME" ]; then<br />
VSERVERNAME="${SVNAME/*-/}"<br />
fi<br />
<br />
# By default, we depend on the socklog service if it exists<br />
[ -e /service/socklog ] && DEPENDENCIES=socklog<br />
<br />
# And also on the logrelay service of the pertinent vserver<br />
[ -e /service/vserver-logrelay-"$VSERVERNAME" ] && DEPENDENCIES="$DEPENDENCIES vserver-logrelay-$VSERVERNAME"<br />
<br />
# Can override VSERVERNAME, RLIMIT and DEPENDENCIES here if necessary<br />
[ -r "$CONFIG" ] && . "$CONFIG"<br />
<br />
if [ ! "$VSERVERNAME" = "" ]; then<br />
VSERVERARGS="signal-relay vserver $VSERVERNAME exec"<br />
vserver "$VSERVERNAME" status || vserver "$VSERVERNAME" start<br />
fi<br />
<br />
if [ -n "$DEPENDENCIES" ]; then<br />
sv start $DEPENDENCIES || exit 1<br />
fi<br />
<br />
exec $RLIMIT $VSERVERARGS cron -f<br />
</pre><br />
<br />
Now, if you place this run script in a service directory called <tt>cron-squid</tt>, it will run a cron daemon in the <tt>squid</tt> guest. This takes care of rotating the squid logs under <tt>/var/log/squid</tt>, for example; although this could also be done on the host with a few kludges.<br />
<br />
The vserver-logrelay-template/run script looks like this:<br />
<br />
<pre><br />
#!/bin/sh<br />
exec 2>&1<br />
SVNAME=$(basename $(pwd))<br />
RUNASUSER=logrelay<br />
MODE=666<br />
VSERVERNAME=$(echo $SVNAME | sed 's/vserver-logrelay-//')<br />
[ -r "/etc/default/$SVNAME" ] && . "/etc/default/$SVNAME"<br />
<br />
exec socat -d -d -d -D -ls -u \<br />
UNIX-LISTEN:/etc/vservers/$VSERVERNAME/vdir/dev/log,unlink-early,nonblock,mode=$MODE,setuid=$RUNASUSER \<br />
UNIX-CONNECT:/dev/log,type=2,nonblock,forever<br />
</pre><br />
<br />
This will pass syslog messages from a vserver to the syslog of the host by acting as a syslog server for the <tt>/dev/log</tt> socket of the guest. Thus, you don't need to run a <tt>syslogd</tt> inside the vserver and you don't need to migrate to <tt>syslog-ng</tt> from <tt>socklog</tt> on the host.<br />
<br />
Symlink this run script into a service directory called <tt>vserver-logrelay-squid</tt>.<br />
<br />
Unfortunately, <tt>socat</tt> has a largish memory footprint; something more lightweight could, perhaps, be used.<br />
<br />
Comments and additions welcome.<br />
--[[User:KornAndras|Guy-]] 03:29, 2 February 2007 (CET)</div>KornAndrashttp://wiki.linux-vserver.org/util-vserver:InitStylesutil-vserver:InitStyles2007-02-02T01:30:33Z<p>KornAndras: /* Using runit */ updates and pointer to new to-be-written page</p>
<hr />
<div>Guests can be started using one of the following init styles:<br />
<br />
* plain<br />
** Launches a unique init process for the guest that appears to run as PID 1.<br />
** Guest's init process executes the rc scripts.<br />
** Therefore, you cannot watch the startup process.<br />
** However, any shutdown or restart command should work<br />
* sysv (default)<br />
** Executes the runlevel scripts directly.<br />
** You can watch the startup process.<br />
** Slightly lighter weight since no additional init process is needed.<br />
** The vserver sees a fake init with PID 1 that has the same properties as the real init on the host.<br />
** You must use "reboot -f" or "halt -f" to restart or shut down from within the guest.<br />
* gentoo<br />
** Like sysv but works on Gentoo-based guests.<br />
** Was deprecated but has been reinstated around util-vserver 0.30.212.<br />
* minit<br />
** Like plain init but smaller.<br />
** minit must be installed on the guest.<br />
** http://www.fefe.de/minit/<br />
<br />
=== Configuration ===<br />
<br />
The init style should go in a file containing a single word: sysv, plain, etc.<br />
<br />
/etc/vservers/<NAME>/apps/init/style<br />
<br />
If the file doesn't exist, sysv will be used. If the word isn't recognized, the guest will not be started and an error will be printed.<br />
<br />
=== Using runit ===<br />
<br />
[http://smarden.org/runit/ runit] is an init replacement that provides service monitoring. There currently are at least three ways to use it with vserver:<br />
<br />
* Set initstyle to plain; this allows you to launch your own <tt>runit</tt> inside the vserver.<br />
* Set initstyle to <tt>sysv</tt>, but <tt>cmd.start</tt> to "<tt>/etc/runit/2</tt>" and <tt>cmd.stop</tt> to "<tt>/etc/runit/3</tt>".<br />
* Use a persistent context for the guest, and just run the services inside it, not runit itself. This is discussed in [[Running runit-supervised services inside a vserver]].<br />
<br />
I haven't tried the first way; the second way has the advantage that you can run a vserver under <tt>runit</tt> running on the host.<br />
<br />
For this to work, you must customize <tt>/etc/runit/2</tt> in the vserver as follows:<br />
<br />
<pre><br />
#!/bin/sh<br />
<br />
trap ":" HUP INT QUIT ILL TRAP ABRT BUS FPE USR1 SEGV USR2 PIPE ALRM TERM CHLD CONT STOP TSTP TTIN TTOU URG XCPU XFSZ VTALRM PROF WINCH IO PWR SYS<br />
<br />
PATH=/usr/local/bin:/usr/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin<br />
<br />
runsvchdir default >/dev/null<br />
<br />
env - PATH=$PATH \<br />
runsvdir -P /var/service 'log: ...........................................................................................................................................................................................................................................................................................................................................................................................................'<br />
<br />
exec /etc/runit/3<br />
</pre><br />
<br />
Now, you can set up a <tt>runit</tt> service on the host with a <tt>run</tt> script like this one:<br />
<br />
<pre><br />
#!/bin/sh<br />
exec 2>&1<br />
exec vserver name-of-vserver start<br />
</pre><br />
<br />
This way:<br />
<br />
* <tt>vserver start</tt> doesn't exit until <tt>runsvdir</tt> terminates.<br />
* If <tt>runsvdir</tt> terminates, all services running inside the vserver are stopped.<br />
* <tt>vserver stop</tt> works as expected.<br />
** Update: with util-vserver 0.30.212 on amd64, it doesn't. The signal never reaches <tt>runsvdir</tt>.<br />
* You can control the vserver using <tt>sv</tt> like any other service, provided all processes running inside it are managed by <tt>runit</tt>.<br />
** If there are processes left inside after all the services exited, <tt>runit</tt> running on the host won't be able to restart the vserver until those stray processes are killed somehow.<br />
** You may want to add something to this effect to the <tt>finish</tt> script of the vserver service, but it may not be a good idea. Be sure you know what you are doing, as always.<br />
<br />
Still, this may not be the best way to integrate <tt>runit</tt> with vserver. I now believe the best way is [[running runit-supervised services inside a vserver]] without imitating anything like init in the guest.<br />
<br />
--[[User:KornAndras|Guy-]] 02:30, 2 February 2007 (CET)</div>KornAndrashttp://wiki.linux-vserver.org/Frequently_Asked_QuestionsFrequently Asked Questions2007-01-31T15:41:43Z<p>KornAndras: expand on hashify a bit.</p>
<hr />
<div><div style="margin: 2em auto 2em auto; padding: 10px; background-color: #F9ECCD; border: 1px solid #004433; text-align: center;"><br />
[[Image:Icon-Caution.png|left]]<br />
We currently migrate to MediaWiki from our old installation, but not all content has been migrated yet. Take a look at the [[Wiki Team]] page for instructions how to help or look at the [http://oldwiki.linux-vserver.org old wiki] to find the information not migrated yet.<br />
<br />
'''To ease migration we created a [[List of old Documentation pages]].'''<br />
</div><br />
<br />
CURRENTLY THE CONTENT OF THE OLD WIKI FAQ (AND MORE) IS BEING MIGRATED TO THIS PAGE (TASK: DERJOHN)<br />
<br />
<br />
__TOC__<br />
<br />
{{Question|Question=What is a 'Guest'?||Details=To talk about stuff, we need some naming. The physical machine is called 'Host' and the 'main' context running the Host Distro is called 'Host Context'. The virtual machine/distro is called 'Guest' and basically is a Distribution (Userspace) running inside a 'Guest Context'.|Signature=derjohn}}<br />
<br />
<br />
{{Question|Question=What kind of Operating System (OS) can I run as guest?||Details=<br />
A: With VServer you can only run Linux guests. The trick is that a guest does not run a kernel on its own (as XEN and UML do), it merely uses a virtualized host kernel-interface. VServer offers so called security contexts which make it possible to seperate one guest from each other, i.e. they cannot get data from each other. Imagine it as a chroot environment with much more security and features.|Signature=derjohn}}<br />
<br />
{{Question|Question=Which distributions did you test?||Details=<br />
A: Some. Check out the wiki for ready-made guest images. But you can easily build own guest images, e.g. with Debian's debootstrap. Checkout ((Building Guest Systems)) how to do that.|Signature=derjohn}}<br />
<br />
{{Question|Question=Is VServer comparable to XEN/UML/QEMU?||Details=<br />
A: Nope. XEN/UML/QEMU and VServer are just good friends. Because you ask, you probably know what XEN/UML/QEMU are. VServer in contrary to XEN/UML/QEMU not "emulate" any hardware you run a kernel on. You can run a VServer kernel in a XEN/UML/QEMU guest. This is confirmed to work at least with Linux 2.6/vs2.0.|Signature=derjohn}}<br />
<br />
{{Question|Question=Is VServer secure?||Details=<br />
A: We hope so. It should be as least as secure as Linux is. We consider it much much more secure though.|Signature=derjohn}}<br />
<br />
{{Question|Question=Performance?||Details=<br />
A: For a single guest, we basically have native performance. Some tests showed insignificant overhead (about 1-2%) others ran faster than on an unpatched kernel. This is IMVHO significantly less than other solutions waste, especially if you have more than a single guest (because of the resource sharing).|Signature=derjohn}}<br />
<br />
{{Question|Question=Is SMP Supported?||Details=<br />
A: Yes, on all SMP capable kernel architectures.|Signature=derjohn}}<br />
<br />
{{Question|Question=Resource sharing?||Details=<br />
A: Yes ....<br />
* memory: Dynamically.<br />
* CPU usage: Dynamically (token bucket)|Signature=derjohn}}<br />
<br />
{{Question|Question=Resource limiting?||Details=<br />
A: Yes, you can set maximum limits per guest, but you can only offer guaranteed resource availability with some ticks at the time. There is the possibility to ulimit and to rlimit. Rlimit is a new feature of kernel 2.6/vs2.0.|Signature=derjohn}}<br />
<br />
{{Question|Question=Disk I/O limiting? Is that possible?||Details=<br />
A: Well, since vs2.1.1 Linux-VServer supports a mechanism called 'I/O scheduling', which appeared in the 2.6 mainline some time ago. The mainline kernel offers several I/O schedulers:<br />
<br />
<pre><br />
# cat /sys/block/hdc/queue/scheduler<br />
noop [anticipatory] deadline cfq<br />
</pre><br />
<br />
The default is anticipatory a.k.a. "AS". When running several guests on a host you probably want the I/O performance shared in a fair way among the different guests. The kernel comes with a "completely fair queueing" scheduler, CFQ, which can do that. (More on schedulers can be found at http://lwn.net/Articles/114770/)<br />
<br />
This is how to set the scheduler to "cfq" manually:<br />
<pre><br />
root# echo "cfq" > /sys/block/hdc/queue/scheduler<br />
root# cat /sys/block/hdc/queue/scheduler<br />
noop anticipatory deadline [cfq]<br />
</pre><br />
<br />
Keep in mind that you have to do it on all physical discs. So if you run an md-softraid, do it to all physical /dev/hdXYZ discs!<br />
<br />
If you run Debian there is a predefined way to set the /sys values at boot-time:<br />
<br />
<pre><br />
# apt-get install sysfsutils<br />
[...]<br />
<br />
# cat /etc/sysfs.conf | grep cfq<br />
block/sda/queue/scheduler = cfq<br />
block/sdc/queue/scheduler = cfq<br />
<br />
# /etc/init.d/sysfsutils restart<br />
</pre><br />
<br />
For non-vserver processes and CFQ you can set by which key the kernel decides about the fairness:<br />
<br />
<pre><br />
cat /sys/block/hdc/queue/iosched/key_type<br />
pgid [tgid] uid gid<br />
</pre><br />
Hint: The 'key_type'-feature has been removed in the mainline kernel recently. Don't look for it any longer :(<br />
<br />
The default is tgid, which means to share fairly among process groups. Think every guest is treated like a own process group. It's not possible to set a scheduler strategy within a guest. All processes belonging to the same guest are treated like "noop" within the guest. So: If you run apache and some ftp-server within the _same_ guest, there is no fair scheduling between them, but there is fair scheduling between the whole guest and all other guests.<br />
<br />
And: It's possible to tune the scheduler parameters in several ways. Have a look at /sys/block/hdc/queue/....|Signature=derjohn}}<br />
<br />
{{Question|Question=Why isn't there a device /dev/xyz within a guest?||Details=<br />
A: Device nodes allow userspace to access hardware (or virtual resources). Creating a device node inside the guest's namespace will give access to that device, so for security reasons, the number of 'given' devices is small.|Signature=derjohn}}<br />
<br />
{{Question|Question=What is unification (vunify)?||Details=<br />
A: Unification is Hard Links on Steroids. Guests can 'share' common files (usually binaries and libraries) in a secure way, by creating hard links with special properties (immutable but unlinkable (removable)). The tool to identify common files and to unify them is called vunify.|Signature=derjohn}}<br />
<br />
{{Question|Question=What is vhashify?||Details=<br />
A: The successor of vunify, a tool which does unification based on hash values (which allows to find common files in arbitrary paths.)<br />
<br />
It creates hardlinks to files named after a hash of the content of the file. If you have a recent version of the vserver patch (2.2+), with CONFIG_VSERVER_COWBL enabled, you can even modify the hardlinked files inside the vservers and the links will be broken automatically.<br />
<br />
There seems to be a catch when a hashified file has multiple hardlinks inside a guest, or when another internal hardlink is added after hashification. Link breaking will remove all the internal hardlinks too, so the guest will end up with different copies of the original file. The correct solution would be to not hashify files that have multiple links prior to hashification, and to break the link to the hashified version when a new internal hardlink is created. Apparently, this is not implemented yet (?).<br />
<br />
|Signature=Guy-}}<br />
<br />
{{Question|Question=How do I manage a multi-guest setup with vhashify?||Details=<br />
A: For 'vhashify', just do these once:<br />
<br />
<pre><br />
mkdir /etc/vservers/.defaults/apps/vunify/hash /vservers/.hash<br />
ln -s /vservers/.hash /etc/vservers/.defaults/apps/vunify/hash/root<br />
</pre><br />
<br />
Then, do this one line per vserver:<br />
<br />
<pre><br />
mkdir /etc/vservers/<vservername>/apps/vunify # vhashify reuses vunify configuration<br />
</pre><br />
<br />
To hashify a running vserver, do (possibly from a cronjob):<br />
<br />
<pre><br />
vserver name-of-guest hashify<br />
</pre><br />
<br />
The guest needs to be running because vhashify tries to figure out what files not to hashify by calling the package manager of the guest via <tt>vserver enter</tt>.<br />
<br />
In order for the OS cache to benefit from the hardlinking, you'll have to restart the vservers.<br />
<br />
To clean up hashified files that are no longer referenced by any vserver, do (possibly from a cronjob):<br />
<br />
<pre><br />
find /vservers/.hash -type f -links 1 -print0 | xargs -0 rm<br />
</pre><br />
<br />
Until you do this, the files still take up place even though no vservers need them.<br />
<br />
|Signature=Guy-}}<br />
<br />
{{Question|Question=With which version should I begin?||Details=<br />
A: If you are new to VServer I recommend to try the latest stable kernel patch, and the latest util-vserver "alpha" release.|Signature=derjohn}}<br />
<br />
{{Question|Question=Is there a way to implement "user/group quota" per VServer?||Details=<br />
A: Yes, but not on a shared partition for now. You need to put the guest on a separate partition, setup a vroot device (to make the quota access secure), copy that into the guest, and adjust the mtab line inside the guest.|Signature=derjohn}}<br />
<br />
{{Question|Question=What about "Quota" for a context?||Details=<br />
A: Context quotas are now called Disk Limits (so that we can tell them apart from the user/group quotas :). They are supported out of the box (with vs2.0+) for all major filesystems (ext2/3, ReiserFS, JFS)|Signature=derjohn}}<br />
<br />
{{Question|Question=Does it support IPv6?||Details=<br />
A: Currently it requires an additional patch, but the functionality should be available in 2.3+ soon. ((IPv6)) has more information.|Signature=derjohn}}<br />
<br />
{{Question|Question=I can't do all I want with the network interfaces inside the guest?||Details=<br />
A: For now the networking is 'Host Business' -- the host is a router, and each guest is a server. You can set the capability ICMP_RAW in the context of the guest, or even the capability CAP_NET_RAW (which would even allow to sniff interfaces of other guests!). Likely to change with ngnet. |Signature=derjohn}}<br />
<br />
{{Question|Question=Is there a web-based interface for vserver that will allow creation/deletion/configuration etc. of vserver guests?||Details=<br />
A. http://OpenVPS.org which is a set of scripts with a web-interface for webhosters/ISPs. http://Openvcp.org which is a distributed system (agent!) with a web-interface, with which you can build/remove guests. http://vsmon.revolutionlinux.com/ is a distributed monitoring-only solution that allows you to search for a particular vserver in your park. |Signature=derjohn}}<br />
<br />
{{Question|Question=What is old-style and new-style config?||Details=<br />
A. Old-style config refers to a single text-file that contains all the configuration settings. With new-style config the configuration is split into several directories and files. You should probably go for new-style config if you are asking.|Signature=derjohn}}<br />
<br />
{{Question|Question=What is the "great flower page"?||Details=<br />
A. Well, [http://www.nongnu.org/util-vserver/doc/conf/configuration.html this page] contains all configuration options for util-vserver. The name of the page is derived from the stylesheet(s) it contains.|Signature=derjohn}}<br />
<br />
{{Question|Question=How do I add several IPs to a vserver? ||Details=<br />
A: First of all a single guest vserver only supports up to 16 IPs (There is a 64-IP patch available, which is in "derjohn's kernel").<br />
Here is a little helper-script that adds a list of IPs defined in a text file, one per line.<br />
<pre><br />
#!/bin/bash<br />
j=1<br />
for i in `cat myiplist`; do<br />
j=$(($j+1))<br />
mkdir $j<br />
echo $i > $j/ip<br />
echo "24" > $j/prefix<br />
done<br />
</pre>|Signature=derjohn}}<br />
<br />
{{Question|Question=If my host has only one a single public IP, can I use RFC1918 IP (e.g. 192.168.foo.bar) for the guest vservers?||Details=<br />
A: Yes, use iptables with SNAT to masquerade it. <br />
<pre><br />
iptables -t nat -I POSTROUTING -s $VSERVER_NETZ ! -d $VSERVER_NETZ -j SNAT --to $EXT_IP<br />
</pre><br />
See: [[HowtoPrivateNetworking]] and <br />
http://www.tgunkel.de/it/software/doc/linux_server.en#h3-VServer_Masquerading_SNAT (THX, [MUPPETS]Gonzo)|Signature=derjohn}}<br />
<br />
{{Question|Question=If I shut down my vserver guest, the whole Internet interface ethX on the host is shut down. What happened? ||Details=<br />
A: When you shut down a guest (''i.e. vserver foo stop''), the IP is brought down on the host also. If this IP happens to be the primary IP of the host, the kernel will not only bring down the primary IP, but also all secondary IP addresses. But in very recent kernels, there is an option ''settable'' which prevents that nasty feature. It's called "alias promotion". You may set it via sysctl by adding ''net.ipv4.conf.all.promote_secondaries=1'' in /etc/sysctl.conf or via sysctl command line.|Signature=derjohn}}<br />
<br />
<br />
{{Question|Question=I run a Debian host and want to build an Ubuntu guest. Howto?||Details=<br />
A: Simple ;) Assume you want to build a breezy guest on a sid host with IP 192.168.0.2 and hostname vubuntu, then do:<br />
<pre><br />
vserver vubuntu build --force -m debootstrap --hostname vubuntu.myvservers.net --netdev eth0 --interface 192.168.0.2/24 \<br />
--context 42 -- -d breezy -m http://de.archive.ubuntu.com/ubuntu<br />
</pre><br />
<br />
[UPDATE] Currently there are problems in building breezy under unclear circumstances, which seems to have to do with udev. If the above didnt work, try:<br />
<pre><br />
vserver vubuntu build --force -m debootstrap --hostname vubuntu.myvservers.net --netdev eth0 --interface 192.168.0.2/24 \<br />
--context 42 -- -d breezy -m http://de.archive.ubuntu.com/ubuntu -- --exclude=udev<br />
</pre><br />
In very recent versions of the utils, the problem should not occur anymore (it has to do with the 'secure-mount' if you look in the MLs)<br />
<br />
Well, sid's debootstrap knows how to bootstrap Ubuntu linux. Make sure to have a current debootstrap package: <br />
<pre><br />
apt-get update<br />
apt-get install debootstrap<br />
</pre><br />
The knowledge how to build ubuntu 'breezy badger' (which you probably want to be your guest at the time of writing) has been added recently.|Signature=derjohn}}<br />
<br />
{{Question|Question=How do I make a vserver guest start by default?||Details=<br />
A: At least on Debian, I can tell you how to do it with the new-style config. If your guest is called "derjohn" and you want it to be started somewhere at the of your bootstrap process, then do:<br />
<pre><br />
echo "default" > /etc/vservers/derjohn/apps/init/mark<br />
</pre><br />
If you want to start it earlier, please read the init script "/etc/init.d/vserver-default" to find out how to do it. In most cases you don't need to change this. On Debian the vservers are started at "90", so after most other stuff is up (networking etc.).<br />
<br />
Besides that I created a small helper script for managing the autostart foo: ((vserver-autostart))|Signature=derjohn}}<br />
<br />
{{Question|Question=My host works, but when I start a guest it says that it has a problem with chbind.||Details=<br />
A: You are probably using util-vserver <= 0.30.209, which does use dynamic network contexts internally (With 0.30.210 this fact changed). So if you compiled your kernel without dynamic contexts, you may start guests, but you can't use the network context.The solution is either to switch to .210 util (or Hollow's toolset) or compile the kernel with dynamic network contexts.<br />
SE Keyword: invalid option `nid' testme.sh|Signature=derjohn}}<br />
<br />
<br />
{{Question|Question=When I try to ssh to the guest, I log into the host, even if I installed sshd on the guest. What's wrong here?||Details=<br />
A: Look at /etc/ssh/sshd_config of the host:<br />
<br />
<pre><br />
Port 22<br />
# Use these options to restrict which interfaces/protocols sshd will bind to<br />
#ListenAddress ::<br />
</pre><br />
<br />
And now change the setting to <br />
<pre><br />
Port 22<br />
# Use these options to restrict which interfaces/protocols sshd will bind to<br />
ListenAddress your.hosts.ip.here # not the guests IP! <br />
</pre><br />
<br />
Then '/etc/init.d/ssh restart' on the host, after that on the guest (if you did apt-get install ssh on the guest already.)<br />
<br />
Do I have to explain more? If the hosts sshd binds all available IP addresses on port 22 (The hosts 'sees' even all addresses of the guests!). So if the guest starts its sshd, it can't bind to port 22 any more. You need to change that setting only on the host. <br />
(BTW: A similar approach has to be done for a lot of daemons, e.g. Apache. If the daemon does not support an explicit bind, you may use the chbind command to 'hide' IP addresses from the daemon before starting.)|Signature=derjohn}}<br />
<br />
{{Question|Question=I did everything right, but the application foo does not start. What's up there?||Details=<br />
A: Before asking on the IRC channel, please check out the 'problematic programs' page:<br />
[[Problematic Programs]]|Signature=derjohn}}<br />
<br />
{{Question|Question=Bind9 does not like to start in my guest.||Details=<br />
A: Check out the ((ProblematicPrograms)) page and/or get my [http://linux-vserver.derjohn.de/bind9-packages/bind9-capacheck_9.3.2-2_i386.deb vserver-guest-ready Debian package] for Debian Sid guests and check out the [http://linux-vserver.derjohn.de/bind9-packages/README.txt readme]. (Hint: This is fresh stuff. Please give me feedback)<br />
<br />
[UPDATE] Since VServer Devel 2.1.1-rc18 you do not need to patch the userland tools anymore. The capabilities are masked.|Signature=derjohn}}<br />
<br />
{{Question|Question=Which guest vservers are running?||Details=<br />
A: Use vserver-stat to find out. Example output:<br />
<pre><br />
CTX PROC VSZ RSS userTIME sysTIME UPTIME NAME<br />
0 77 965.1M 334.6M 14m14s18 2m28s69 1h33m46 root server<br />
49152 7 14M 5.2M 0m00s40 0m00s30 1h30m15 chiffon<br />
</pre>|Signature=derjohn}}<br />
<br />
<br />
<br />
{{Question|Question=How can I reboot/halt guests?||Details=<br />
A: It depends. <br />
For legacy Linux-VServer (i.e. 1.2.x), you have to replace /sbin/halt in the guests with vreboot and start rebootmgr in the host. You also need to have a <guest>.conf file in /etc/vservers for each guest. Please have a look at /etc/init.d/rebootmgr.<br />
For Linux-VServer 2.0+, sys_reboot has been virtualized to do the right thing. No changes are needed in guests.|Signature=derjohn}}<br />
<br />
{{Question|Question=Do I really need the legacy-interfaces? What are these legacy-interfaces?||Details=<br />
A: Since Linux-VServer is an ongoing project, new features might replace old ones, some might require a development version. Legacy-interfaces are available for backward compability (which might be removed someday) with Linux-VServer 1.2.x.|Signature=derjohn}}<br />
<br />
{{Question|Question=I have a vserver running on a Linux kernel with preemption. Is VServer "preempt" safe?||Details=<br />
A: There are no known issues about running vserver on a preemption enabled kernel. I would like to add, that the vserver kernelhackers would probably exclude that option in 'make menuconfig' if there would be an incompatibility. Just my $.02 :)|Signature=derjohn}}<br />
<br />
{{Question|Question=Is this a new project? When was it started?||Details=<br />
A: The first public occurrence of Linux-VServer was Oct 2001. The initial mail can be found here: http://www.cs.helsinki.fi/linux/linux-kernel/2001-40/1065.html<br />
So you can expect a mature software product which does its magic quite well (And hey, we have a version > 2.0!)|Signature=derjohn}}<br />
<br />
<br />
{{Question|Question=Can I run an OpenVPN Server in a guest?||Details=<br />
A: Yes. I don't want to provide an in-depth OpenVPN tutorial, but want to show how I made OpenVPN work in a guest as server.<br />
<br />
First of all you have to prepare the host with a persistent tuntap interface in tap-mode. The tools we need come from the uml-utilities.<br />
Then you need to create a device /dev/net/tun, which the OpenVPN userspace daemon reads. We'll assume 10.10.10.100 is the server IP, and 10.10.10.101 is the client IP - to be cool be choose a /31 netmask (255.255.255.254), so we have a net without broadcast and don't waste IPs :)<br />
<br />
On the host do: <br />
<pre><br />
# apt-get install uml-utilities<br />
# cd /var/lib/vserver/<myopenvpnserver>/dev/<br />
# ./MAKEDEV tun<br />
(creates the dev/net/tun device accessible by te guest - even a tap interface need /dev/net/tun !)<br />
# tunctl -t tap0<br />
(creates the network device 'tap0' persistently)<br />
</pre><br />
<br />
Then add the ip to the guest:<br />
<pre><br />
# cat /etc/vservers/<myopenvpnserver>/interfaces/1/ip<br />
10.10.10.100<br />
# cat /etc/vservers/<myopenvpnserver>/interfaces/1/prefix<br />
31<br />
# cat /etc/vservers/<myopenvpnserver>/interfaces/1/dev<br />
tap0<br />
(This kind of config brings the ip when the vserver is started - only the tap0 interface has to exist already, see above!)<br />
</pre><br />
<br />
Here is a sample config for the guest (which is acting as a server):<br />
<br />
Install OpenVPN package on server and client, in the Debian case:<br />
<pre><br />
# apt-get install openvpn<br />
</pre><br />
<br />
The server's conf looks like that:<br />
<pre><br />
# port and interface specs<br />
<br />
# behave like a ssl-webserver<br />
port 443<br />
proto tcp-server<br />
<br />
# tap device? (keep in mind you need /dev/net/tun !)<br />
dev tap0<br />
<br />
# now the ips we will use for the tunnel<br />
ifconfig 10.10.10.100 255.255.255.254<br />
ifconfig-noexec<br />
<br />
# the server part<br />
<br />
# Keep VPN connections, even if the client IP changes<br />
float<br />
<br />
# use compression (may also even obfuscate content filters)<br />
comp-lzo<br />
<br />
# use a static key - create it with 'openvpn --genkey --secret static.key'<br />
secret static.key<br />
<br />
# dont reload the key after a SIGUSR1<br />
persist-key<br />
<br />
# check alive all 10 secs<br />
keepalive 10 60<br />
<br />
# verbosity level (from 1 to 9, 9 is max log level)<br />
verb 4<br />
status openvpn-status.log<br />
</pre><br />
<br />
The client's conf may look like that (This example even makes the tunnel the clients default address):<br />
<pre><br />
# cat /etc/openvpn/client.conf<br />
# port and interface specs<br />
<br />
# the following is not necessary, if you bring up openvpn via Debian's init script:<br />
daemon ovpn-my-clients-name<br />
<br />
# behave like a ssl-webserver<br />
port 443<br />
proto tcp-client<br />
remote %%%<insert-the-guest-primary-public-ip-here>%%%%<br />
# what device tun ot tap?<br />
dev tap<br />
<br />
# now the ips we will use for the tunnel<br />
ifconfig 10.10.10.101 255.255.255.254<br />
<br />
# Keep VPN connections, even if the client IP changes<br />
float<br />
mssfix<br />
<br />
# use compression (may also even obfuscate content filters)<br />
comp-lzo<br />
<br />
# use a static key<br />
secret static.key<br />
<br />
# dont reload the key after a SIGUSR1<br />
persist-key<br />
<br />
# check alive all 10 secs<br />
keepalive 10 60<br />
<br />
# verbosity level (from 1 to 9, 9 is max log level)<br />
verb 4<br />
<br />
# set the default route<br />
route-gateway 10.10.10.100<br />
redirect-gateway def1<br />
# to add special routes you can do it wihtin the openvpn client conf:<br />
# route <dest> <mask> <gateway><br />
<br />
# if you need to connect via proxy (like squid)<br />
# http-proxy s p [up] [auth] : Connect to remote host through an HTTP proxy at<br />
# address s and port p. If proxy authentication is required,<br />
# up is a file containing username/password on 2 lines, or<br />
# 'stdin' to prompt from console. Add auth='ntlm' if<br />
# the proxy requires NTLM authentication.<br />
<br />
# http-proxy s p [up] [auth]<br />
<br />
<br />
# http-proxy-option type [parm] : Set extended HTTP proxy options.<br />
# Repeat to set multiple options.<br />
# VERSION version (default=1.0)<br />
# AGENT user-agent<br />
<br />
# http-proxy-option type [parm]<br />
</pre><br />
<br />
In the next lesson I will talk about OpenVPN's server mode, which can deal with with multiple clients connecting to one IP and one port (i.e. you only need one guest for tons of 'road warriors'), TLS connections and PKI.<br />
<br />
Contributions welcome. :)|Signature=derjohn}}<br />
<br />
{{Question|Question=32 vs 64 Bit? What should I take?||Details=<br />
A: If you have the choice make the host a 64 bit one. You can run a guest as 32 bit or as 64 bit on a 64 bit host. To run it as 32 bit, you need to compile the x86_64 (a.k.a. AMD64) with the following options:<br />
<br />
<pre><br />
[*] Kernel support for ELF binaries<br />
<M> Kernel support for MISC binaries<br />
[*] IA32 Emulation <---- without that, the entire 32bit API is not present<br />
<M> IA32 a.out support <br />
</pre><br />
<br />
You can force the guest to behave like a 32 environment like this:<br />
<pre><br />
echo linux_32bit > /etc/vservers/$NAME/personality<br />
echo i686 > /etc/vservers/$NAME/uts/machine<br />
</pre><br />
(thanks cehteh for the hint!)<br />
<br />
But you can force debootstrap to put 32 bit binaries into the guest by 'export ARCH=i386';<br />
<pre><br />
export ARCH=i386 ; vserver build .... <br />
</pre>|Signature=derjohn}}<br />
<br />
{{Question|Question=I want to (re)mount a partition in a running guest ... but the guest has no rights (capability) to (re)mount?||Details=<br />
A: I'll explain. I take as example your /tmp partition within the guest is too small, what will be likely the case if you stay with the 16MB default (vserver build mounts /tmp as 16 MB tmpfs!).<br />
<pre><br />
# vnamespace -e XID mount -t tmpfs -o remount,size=256m,mode=1777 none /var/lib/vservers/<guest>/tmp/<br />
</pre><br />
Be warned that the guest will not recognize the change, as the /etc/mtab file is not updated when you mount like this. To permanently change the mount, edit /etc/vserver/<guest>/fstab on the host.|Signature=derjohn}}<br />
<br />
<br />
{{Question|Question=How do I limit a guests RAM? I want to prevent OOM situations on the host!||Details=<br />
A: First you can read [http://linux-vserver.org/Memory+Allocation] and [[Memory Limits]].<br />
<br />
If you want a recipe, do this:<br />
1. Check the size of memory pages. On x86 and x86_64 is usually 4 KB per page.<br />
2. Create /etc/vserver/<guest>/rlimits/<br />
3. Check your physical memory size on the host, e.g. with "free -m". maxram = kilobytes/pagesize.<br />
4. Limit the guests physical RAM to value smaller then maxram:<br />
<br />
<pre><br />
echo %%insertYourPagesHereSmallerThanMaxram%% > /etc/vserver/<guest>/rlimits/rss<br />
</pre><br />
<br />
5. Check your swapspace, e.g. with 'swapon -s'. maxswap = swapkilobytes/pagesize.<br />
6. Limit the guest's maximum number of as pages to a value smaller than (maxram+maxswap):<br />
<br />
<pre><br />
echo %%desiredvalue%% > /etc/vserver/<guest>/rlimits/as<br />
</pre><br />
<br />
It should be clear this can still lead to OOM situations. Example: You have two guests and your as limit per guest is greater than 50% of (maxram+maxswap). If both guests request their maximum at the same point in time, there will be not enough mem .....|Signature=derjohn}}<br />
<br />
<br />
{{Question|Question=Were can I get newer versions of VServer as ready made packages for Debian?||Details=<br />
A: Here you go: http://linux-vserver.derjohn.de/ . There is also some stuff on backports.org, but my kernels are always 'devel' branch.|Signature=derjohn}}<br />
<br />
{{Question|Question=Can I use iptables ?||Details=<br />
Yes but right now only on the host (rootserver). Please realize that all traffic is local and will not touch the forward chain.|Signature=BeginnerFAQ}}<br />
<br />
{{Question|Question=Trying to connect to a vserver from the host or another vserver on the same host fails||Details=<br />
strace shows<br />
<pre> <br />
sin_addr=inet_addr("xx.xx.xx.xx")}, yy) = -1 EINVAL (Invalid argument)<br />
</pre><br />
A: The host/guest cannot communicate with another guest on same host.<br />
* check all netmasks on all interfaces (do they overlap) ?<br />
* check policy routing (disable it temporary) ?<br />
* check that lo is up (Networking within a host/guest always uses lo interface)<br />
|Signature=CommonProblems}}<br />
<br />
{{Question|Question=#1 ERROR: capset(): Operation not permitted||Details=capabilities are not enabled in kernel-setup<br />
please check that CONFIG_SECURITY_CAPABILITIES is loaded or included in the kernel. ( check with "cat /path_to_kernel/.config | grep -i cap ")<br />
(2.6.11.5-vs-1.9.5 + 0.30-205)|Signature=IrcQuestions}}<br />
<br />
{{Question|Question=How can I make 'vserver start' mount the root filesystem?||Details=<br />
Mount it via /etc/vservers/vserver-name/fstab, make sure to set the option 'dev' e.g.:<br />
<pre>/dev/drbd0 / xfs rw,dev 0 0</pre><br />
|Signature=AdrianReyer}}<br />
<br />
{{Question|Question=How do I tag a guest's directory with xid?||Details=<br />
Tagging the guest's files gives you serveral advantages, e.g. the accoutung will work properly.<br />
Filesystem XID tagging only works on supported filesystem. Those are currently: ext2/3, reiserfs/reiser3, xfs and jfs.<br />
To activate the XID tagging you have to mount the filesystem with "-o tagxid". Attention: It's _not_ possible to "-o remount,tagxid", you have to mount it freshly. The guests will tag their files automatiaclly. If you copy files in from the host, you have to tag them manually like this:<br />
<pre>chxid -c xid -R /var/lib/vservers/<guest></pre><br />
Note: Context 0 and 1 will see all files, guests will only be able to acess untagged files and their own XID. They can see other XID files but no information about the file, e.g. no owner, no group, no permissions.<br />
|Signature=derjohn_and_gonzo_and_are}}<br />
<br />
More FAQs to be merged;<br />
[http://www.linux-vserver.org/Frequently_Asked_Questions_scratch]<br />
<br />
{{Question|Question=My mysqld running in a guest behaves strangely and is awfully slow/locks up||Details=<br />
This can be related to /tmp being too small. mysqld stores temporary tables in /tmp and as such, if a lot of queries happen and /tmp runs full this can cause one query to lock up whilst creating the tmp table and all other queries waiting to acquire the lock. There are two possible solutions to that problem: a.) Modify /etc/vservers/vserver-name/fstab and assign more memory to the tmpfs of /tmp and b.) remove the /tmp entry from /etc/vservers/vserver-name/fstab completly. Especially on database servers with a rather high load the second one might be the preferred method.|Signature=sp}}<br />
<br />
<br />
{{Question|Question=I deleted a guest's directory without shutting it down. Now I have a "ghost" running. Is there any possibility to get it out of proc without rebooting?||Details=vkill --xid <xid> -s 15; sleep 2; vkill --xid <xid> -s 9|Signature=daniel_hozac}}<br />
<br />
== Upgrade from 2.0 to 2.2 ==<br />
<br />
{{Question|Question=I now get errors like "ncontext: vc_net_create(): Invalid argument; dynamic contexts disabled." on startup. Vservers are not started||Details=Dynamic context are disabled by default and are deprecated. For example, tagxid and network checks won't be useable with dynamic ids. Now you should manually assign a explicit context to your vservers, like<br />
echo 101 > /etc/vservers/myvserv/context<br />
|Signature=daniel_hozac&Beuc}}</div>KornAndrashttp://wiki.linux-vserver.org/util-vserver:Documentationutil-vserver:Documentation2007-01-31T15:24:17Z<p>KornAndras: /* /etc/vservers/.defaults/apps/vunify/hash */ formatting + updates based on 0.30.212</p>
<hr />
<div>=The content of the /etc/vservers directory=<br />
<br />
<br />
<br />
==/etc/vservers/.defaults==<br />
*cachebase<br />
**A link to the directory which will hold cached information about vservers.<br />
*namespace-cleanup<br />
**Enable namespace cleanup globally. It can be overridden for a single vserver by setting the nonamespace-cleanup flag there.<br />
*nonamespace<br />
**Disable namespace usage globally. It can be overridden for a single vserver by setting the namespace flag there. In this mode the /vservers directory must have the 'barrier' attribute. Else, common chroot(2) exploits are possible.<br />
*run.rev<br />
**Path of the vserver run reverse directory. This directory contains symlinks named with XID numbers which point back to the configuration directory of vservers. Under kernel 2.4 this is required for the XID to VSERVER mapping; Under kernel 2.6 it is unused. NOTE: this link exists in 0.30.202* only; in previous versions it was a vserver specific setting.<br />
*vdirbase<br />
**A link to the default vserver rootdirectory.<br />
==/etc/vservers/.defaults/apps==<br />
===/etc/vservers/.defaults/apps/debootstrap===<br />
*mirror<br />
** The Debian mirror to use with the debootstrap program<br />
*uri<br />
** When the debootstrap package is not installed; fetch it from this uri and install it at a temporary place.<br />
===/etc/vservers/.defaults/apps/init===<br />
*environment<br />
** The environment to set when starting guests. Contains one VAR=VAL pair per line.<br />
*tty<br />
** A symlink to the TTY device where input/output will be redirected from/to at startup via initscript.<br />
===/etc/vservers/.defaults/apps/pkgmgmt===<br />
*apt.conf<br />
** The default apt.conf which is going to be used. It is overridden by distribution specific configuration file.<br />
*base<br />
===/etc/vservers/.defaults/apps/vprocunhide===<br />
*files<br />
** A list of files which will be made visible by vprocunhide. Wildcards are allowed and anything ending in '/' will be processed recursively. When this file exists, it overrides the defaults in SYSDEFAULTDIR/vprocunhide-files. The entries there must be absolute filenames inclusive the leading '/proc'.<br />
===/etc/vservers/.defaults/apps/vshelper===<br />
*debug<br />
** When existing, the vshelper execution will be traced.<br />
*disabled<br />
** When existing, the vshelper functionality will be disabled for all vservers.<br />
*logfile<br />
** The file where output will be logged to when vshelper is invoked from the kernel. This should point somewhere e.g. into /var/log.<br />
*warning-disabled<br />
** When existing, sanity checks for the vshelper functionality will be skipped.<br />
===/etc/vservers/.defaults/apps/vshelper/vshelper-methods===<br />
** * handler<br />
** See vshelper/action.<br />
===/etc/vservers/.defaults/apps/vunify===<br />
*exclude<br />
** Static list of excluded files.<br />
*pgkmgmt-force<br />
** When existing, information from packagemanagement will be used to create dynamic exclude-lists. This option requires that (a known) packagemanagement is configured for the vserver; else the requested operation will fail. Most tools assume 'on' as the default value.<br />
*pkgmgmt-ignore<br />
** When existing, information from packagemanagement will not be used to create dynamic exclude-lists.<br />
===/etc/vservers/.defaults/apps/vunify/hash===<br />
* A directory which will be used as the storage place for the vhashify command. It contains:<br />
** id (? - don't have that here...)<br />
** root<br />
*** A symlink that points to the directory within the filesystems which are used for the vservers. There must be not more than one of such a directory per filesystem.<br />
*** TBD: how to specify multiple directories?<br />
** method<br />
*** The name of the hash function used. Defaults to SHA-1.<br />
** blocks<br />
*** TBD. Defaults to "all".<br />
<br />
===/etc/vservers/.defaults/init===<br />
* mtab<br />
** Default mtab file<br />
===/etc/vservers/.defaults/interfaces===<br />
* vlandev<br />
** When this file exists, the steps which setup and destroy a VLAN interface will be executed.<br />
==/etc/vservers/.distributions==<br />
===/etc/vservers/.distributions/dist===<br />
* apt.conf<br />
** The default apt.conf which is going to be used. It overrides the apt.conf from CONFDIR/.defaults/apps/pkgmgmt.<br />
* dev<br />
* execdir<br />
** Directory with all executables and libraries which are required for this distribution.<br />
* initpost<br />
** Script which will be executed after packages are installed.<br />
* initpre<br />
** Script which will be executed before packages will be installed.<br />
* rpmlib<br />
** Directory which overrides /usr/lib/rpm.<br />
===/etc/vservers/.distributions/dist/apt===<br />
** Default content of the /etc/apt/ directory.<br />
===/etc/vservers/.distributions/dist/pkgs===<br />
** Contains files with packagenames.<br />
*list<br />
** File which contains the name of packages. On top of file the special keywords '--reinstall' and '--can-fail' are possible.<br />
===/etc/vservers/.distributions/dist/pubkeys===<br />
** Directory with GPG pubkeys which are used to sign the packages of this distribution.<br />
===/etc/vservers/.distributions/dist/rpm===<br />
** Default content of the /etc/rpm directory.<br />
===/etc/vservers/.distributions/dist/yum===<br />
** The default, yum-related content of the /etc directory.<br />
*yum.conf<br />
** The master yum configuration file. It supports the @YUMETCDIR@, @YUMCACHEDIR@ and @YUMLOGDIR@ placeholder which will be replaced at vserver ... build time.<br />
===/etc/vservers/.distributions/dist/yum.repos.d===<br />
** A directory with yum repositories.<br />
==/etc/vservers/vserver-name==<br />
The configuration directory for the vserver vserver-name.<br />
*bcapabilities<br />
**[experimental; name is subject of possible change] Contains the system capabilities. See lib/bcaps-v13.c for possible values.<br />
*cache<br />
**Path of the storage area for cached information about this vserver.<br />
*capabilities<br />
**Contains per line a capability. This file is used for the 2.4 kernel only; for 2.6 use bcapabilities.<br />
*ccapabilities<br />
**[experimental; name is subject of possible change] Contains the context capabilities. See lib/ccaps-v13.c for possible values.<br />
*context<br />
**Contains the context which shall be used for the vserver.<br />
*flags<br />
**Contains per line a flag. See lib/cflags-v13.c for possible values.<br />
*fstab<br />
**The fstab file for the vserver. Entries in this file will be mounted within the network context of the host. Use the fstab.remote file when you want that the mounting happens in the network context of the vserver. In most cases the 'fstab' file should be used.<br />
*fstab.remote<br />
**The fstab file for the vserver. Entries in this file will be mounted within the network context of the host; this means that mount will be called as chbind <options> mount .... See fstab also.<br />
*name<br />
**Contains the name of the vserver. When not given, the basename of the directory will be assumed as this name.<br />
*namespace<br />
**Overrides the global nonamespace flag and enables namespace usage for the current vserver.<br />
*namespace-cleanup<br />
**Enable namespace cleanup for the current vserver.<br />
*nice<br />
**The nice-level on which the vserver will be started.<br />
*nonamespace<br />
**Disables namespace usage for the current vserver. In this mode the /vservers directory must have the 'barrier' attribute. Else, common chroot(2) exploits are possible.<br />
*nonamespace-cleanup<br />
**Overrides the global namespace-cleanup flag and disables namespace cleanup for the current vserver.<br />
*personality<br />
**Used to set the personality of the vserver. First line in the file is the personality-type followed by flags (one item per line). See /usr/include/linux/personality.h for possible values.<br />
*run<br />
**Points to a file which will contain the XID of the running vserver. When the vserver is stopped, this can be a dangling symlink.<br />
*schedule<br />
**[experimental; name is subject of possible change] Contains the scheduler parameters, one per line. The Hard CPU limit uses a mechanism called a Token Bucket. the concept is simple: you have a bucket of a certain size which is filled with a specified amount R of tokens each interval T until the maximum is reached (excess tokens are spilled). At each timer tick, a running process consumes one token from the bucket, unless the bucket is empty. If the bucket is empty the process is put in the hold queue. When the bucket has been refilled to at least M tokens, all on hold processes are rescheduled. See the Linux VServer Wiki for more information about this file.<br />
*shell<br />
**Contains the pathname of the shell which will be used by the "vserver ... enter" command.<br />
*vdir<br />
**Path of the vserver root directory.<br />
==/etc/vservers/vserver-name/apps==<br />
===/etc/vservers/vserver-name/apps/init===<br />
*cmd.prepare<br />
** The command which is used to setup the init-system (e.g. to set the runlevel in the utmp-file). Each option must be on a separate line.<br />
*cmd.start<br />
** The command which is used to start the vserver. Each option must be on a separate line.<br />
*cmd.start-sync<br />
** The command which is used to wait on the vserver after it has been started. Each option must be on a separate line. This file will be ignored when the sync flag does not exist and the '--sync' option was not used.<br />
*cmd.stop<br />
** The command which is used to stop the vserver. Each option must be on a separate line.<br />
*cmd.stop-sync<br />
** The command which is used to wait on the vserver after it has been stopped. Each option must be on a separate line. This file will be ignored when the sync flag does not exist and the '--sync' option was not used.<br />
*depends<br />
** This file is used to configure vservers which must be running before the current vserver can be started. At shutdown, the current vserver will be stopped before its dependencies. Content of this file are vserver ids (one name per line).<br />
*environment<br />
** The environment to set when starting the guest. Contains one VAR=VAL pair per line.<br />
*killseq<br />
** Contains the 'signal [wait signal]*' sequence which is used to stop the vserver.<br />
*mark<br />
** This file is used to mark group of vservers which shall be started/stopped together by the initscript. Content is a simple string like 'default'.<br />
*mtab<br />
** The initial-mtab which will be used for the vserver.<br />
*runlevel<br />
** The start runlevel.<br />
*runlevel.start<br />
** The start runlevel.<br />
*runlevel.stop<br />
** The stop runlevel.<br />
*style<br />
** Contains the init-style.<br />
*sync<br />
** If this file is not present, all 'cmd.*-sync files will be ignored.<br />
*tty<br />
** A symlink to the TTY device where input/output will be redirected from/to at startup via initscript.<br />
===/etc/vservers/vserver-name/apps/vshelper===<br />
*action<br />
** The action which is going to be executed when a vshelper event occurs. The default value is 'restart', but there can be defined own methods by placing scripts into the vshelper-methods directories. These scripts are fed with the same arguments as the vshelper script.<br />
*debug<br />
** When existing, the vshelper execution will be traced for this vserver.<br />
*disabled<br />
** When existing, the vshelper functionality will be disabled for this vserver.<br />
*event<br />
** When existing, these scripts will be executed *instead* of the default handler defined in 'action'. Their name must match the event which caused the execution of vshelper; e.g. 'restart' or 'poweroff'. See the vs_reboot() function in the kernel for more details.<br />
*sync-timeout<br />
** The timeout in seconds which is used when synchronising vserver startup/shutdown with the vshelper. When not set, 30 seconds will be assumed.<br />
*warning-disabled<br />
** When existing, sanity checks for the vshelper functionality will be skipped.<br />
===/etc/vservers/vserver-name/apps/vshelper-methods===<br />
*handler<br />
** See vshelper/action.<br />
===/etc/vservers/vserver-name/apps/vunify===<br />
** This directory contains configuration data required for vserver unification.<br />
*exclude<br />
** Static list of files which are excluded for unification. This list supports an rsync-like syntax: when a file is prefixed by '*', it is a candidate for unification; when there is no prefix or a '-' or a '~' it will be excluded. Shell-wildcards are allowed for the filenames.<br />
** When used with vcopy, the '~' prefix prevents copying of the file entirely (e.g. for keyfiles). With this tool, the file will be copied instead of hardlinked when the '-' prefix is used.<br />
*pgkmgmt-force<br />
** When existing, information from packagemanagement will be used to create dynamic exclude-lists. This option requires that (a known) packagemanagement is configured for the vserver; else the requested operation will fail. Most tools assume 'on' as the default value.<br />
*pkgmgmt-ignore<br />
** When existing, information from packagemanagement will not be used to create dynamic exclude-lists.<br />
*refserver.X<br />
** These are symlinks to the configuration directory (e.g. CONFDIR/vservers/<id>) of a refserver. There may be multiple such symlinks but they must be prefixed by 'refserver.' and will be processed in alphanumerical order.<br />
====/etc/vservers/vserver-name/apps/vunify/hash=====<br />
** A directory which will be used as the storage place for the vhashify command.<br />
** * id<br />
** Points to a directory within the filesystems which are used for the vservers. There must be not more than one of such a directory per filesystem.<br />
** * method<br />
** The used hash method.<br />
==/etc/vservers/vserver-name/cpuset==<br />
* cpu_exclusive<br />
** Is the CPU assignment exclusive?<br />
* cpus<br />
** The list of CPUs in this cpuset<br />
* mems<br />
** The list of Memory Nodes in this cpuset<br />
* mems_exclusive<br />
** Is the memory node assignment exclusive?<br />
* name<br />
** The name of the cpuset for this vserver<br />
* nocreate<br />
** When this file exists, the cpuset will be assumed to exist already<br />
==/etc/vservers/vserver-name/dlimits==<br />
===/etc/vservers/vserver-name/dlimits/dlimit===<br />
*directory<br />
** The directory to which the limit should be applied<br />
*inodes_total<br />
** The amount of inodes this vserver should be limited to<br />
*reserved<br />
** How much space (percentage-wise) should be reserved for the root user<br />
*space_total<br />
** The amount of space this vserver should be limited to (measured in blocks of 1024 bytes)<br />
==/etc/vservers/vserver-name/interfaces==<br />
* bcast<br />
** The default broadcast address.<br />
* dev<br />
** The default network device.<br />
* mask<br />
** The default network mask.<br />
* novlandev<br />
** When this file exists, the steps which setup and destroy a VLAN interface will be skipped. This overrides the global vlandev setting for this vserver.<br />
* prefix<br />
** The default network prefix-length.<br />
* scope<br />
** The default scope of the network interfaces.<br />
* vlandev<br />
** When this file exists, the steps which setup and destroy a VLAN interface will be executed for all interfaces of this vserver.<br />
===/etc/vservers/vserver-name/interfaces/iface===<br />
** 'iface' is an arbitrary name for the interface; the value itself is not important but may be interesting regarding interface-creation and usage with chbind. Both happens in alphabetical order and numbers like '00' are good names for these directories.<br />
*bcast<br />
** The broadcast address.<br />
*dev<br />
** The network device.<br />
*disabled<br />
** When this file exists, this interface will be ignored.<br />
*ip<br />
** The ip which will be assigned to this interface.<br />
*mask<br />
** The network mask.<br />
*name<br />
** When this file exists, the interface will be named with the text in this file. Without such an entry, the IP will not be shown by ifconfig but by ip addr ls only. Such a labeled interface is known as an "alias" also (e.g. 'eth0:foo').<br />
*nodev<br />
** When this file exists, the interface will be assumed to exist already. This can be used to assign primary interfaces which are created by the host or another vserver.<br />
*novlandev<br />
** When this file exists, the steps which setup and destroy a VLAN interface will be skipped. This will override the global vlandev and the per-guest vlandev.<br />
*prefix<br />
** The network prefix-length.<br />
*scope<br />
** The scope of the network interface.<br />
*vlandev<br />
** When this file exists, the steps which setup and destroy a VLAN interface will be executed.<br />
==/etc/vservers/vserver-name/rlimits==<br />
**A directory with resource limits. Possible resources are cpu, fsize, data, stack, core, rss, nproc, nofile, memlock, as and locks. This configuration will be honored for kernel 2.6 only.<br />
* resource<br />
** A file which contains the hard- and soft-limit of the given resource in the first line. The special keyword 'inf' is recognized.<br />
* resource.hard<br />
** A file which contains the hard- of the given resource in the first line. The special keyword 'inf' is recognized.<br />
* resource.min<br />
** A file which contains the guaranted minimum of the given resource in the first line. The special keyword 'inf' is recognized.<br />
* resource.soft<br />
** A file which contains the soft- of the given resource in the first line. The special keyword 'inf' is recognized.<br />
==/etc/vservers/vserver-name/scripts==<br />
**A directory for scripts. By default, when one of these scripts will be executed, the execution of defaultscripts (within .../.defaults/scripts) will be skipped. To execute them nevertheless, the $DONT_SKIP_DEFAULTS environment variable must be set by one of the in-shellcontext scripts (the non-executable ones).<br />
* initialize<br />
** The scriptlet which will be executed before the root filesystem is mounted and the configuration has been loaded. Before executing the script, the configuration directory will be made the working directory.<br />
* post-start<br />
** The scriptlet which will be executed after the vserver has been started. Before executing the script, the vserver root directory will be made the working directory.<br />
* post-stop<br />
** The scriptlet which will be executed after the vserver has been stopped, but before the directories will be umounted and the the interfaces disabled. Before executing the script, the vserver root directory will be made the working directory.<br />
* postpost-stop<br />
** The scriptlet which will be executed after the vserver has been stopped completely. Before executing the script, the vserver root directory will be made the working directory.<br />
* pre-start<br />
** The scriptlet which will be executed after network-interfaces were enabled and the directories mounted, but before the vserver itself has been started. Before executing the script, the vserver root directory will be made the working directory.<br />
* pre-stop<br />
** The scriptlet which will be executed before the vserver will be stopped. Before executing the script, the vserver root directory will be made the working directory.<br />
* prepre-start<br />
** The scriptlet which will be executed before the network-interfaces are enabled and the directories are mounted. Before executing the script, the configuration directory will be made the working directory.<br />
===/etc/vservers/vserver-name/scripts/initialize.d===<br />
** Repository of initialize like scripts. Before executing the script, the configuration directory will be made the working directory.<br />
*script<br />
** See initialize.<br />
===/etc/vservers/vserver-name/scripts/post-start.d===<br />
** Repository of post-start like scripts. Before executing these scripts, the vserver root directory will be made the working directory.<br />
*script<br />
** See post-start.<br />
===/etc/vservers/vserver-name/scripts/post-stop.d===<br />
** Repository of post-stop like scripts. Before executing the script, the vserver root directory will be made the working directory.<br />
*script<br />
** See post-stop.<br />
===/etc/vservers/vserver-name/scripts/postpost-stop.d===<br />
** Repository of postpost-stop like scripts. Before executing the script, the vserver root directory will be made the working directory.<br />
*script<br />
** See postpost-stop.<br />
===/etc/vservers/vserver-name/scripts/pre-start.d===<br />
** Repository of pre-start like scripts. Before executing these scripts, the vserver root directory will be made the working directory.<br />
*script<br />
** See pre-start.<br />
===/etc/vservers/vserver-name/scripts/pre-stop.d===<br />
** Repository of pre-stop like scripts. Before executing the script, the vserver root directory will be made the working directory.<br />
*script<br />
** See pre-stop.<br />
===/etc/vservers/vserver-name/scripts/prepre-start.d===<br />
** Repository of prepre-start like scripts. Before executing the script, the configuration directory will be made the working directory.<br />
*script<br />
** See prepre-start.<br />
===/etc/vservers/vserver-name/ulimits===<br />
**A directory with ulimits. Possible resources are cpu, data, fsize, locks, memlock, nofile, nproc, rss and/or stack. This configuration will be honored for kernel 2.4 only.<br />
* resource<br />
** A file which contains the hard- and soft-limit of the given resource in the first line. The special keyword 'inf' is recognized.<br />
* resource.hard<br />
** A file which contains the hard- of the given resource in the first line. The special keyword 'inf' is recognized.<br />
* resource.soft<br />
** A file which contains the soft- of the given resource in the first line. The special keyword 'inf' is recognized.<br />
===/etc/vservers/vserver-name/uts===<br />
* context<br />
** The context-name of the vserver. This file is listed for completeness only; the 'context' name is used and set internally by the util-vserver tools and can *not* be modified.<br />
* domainname<br />
** The NIS domainname of the vserver<br />
* machine<br />
** The machine-type of the vserver<br />
* nodename<br />
** The node-/hostname of the vserver<br />
* release<br />
** The OS-release of the vserver<br />
* sysname<br />
** The sysname of the vserver<br />
* version<br />
** The OS-version of the vserver</div>KornAndras