Linux-VServer - User contributions [en]

DRBD

2009-04-08T11:07:05Z

Jze: migrated from old wiki Vserver+DRBD

== A Vserver guest mirrored by DRBD with heartbeat failover ==

The idea is simple:
Install a vserver on a DRBD resource and let it failover to the other node of a cluster.

This configuration uses vserver, DRBD and heartbeat. This page will not describe, how these packages are installed and configured. Only the important topics are mentioned.

Steps of installation:
* compile a vserver kernel
* compile the DRBD module against this kernel
* install the kernel, the module and reboot
* install the user space utilities of DRBD, vserver and heartbeat
* install the same packages at the second node
* configure and activate a DRBD resource
* make the DRBD resource primary on one node
* create a journalled filesystem (ext3, xfs, reiser) on top of the DRBD device
* mount the DRBD device as /var/lib/vservers/<vserver-name>
* install a vserver
* finish configuration
* sync the configuration to the other node

==In detail==

===Install the necessary packages===
On Debian Sarge we can use ready packages. Your <tt>/etc/apt/sources.list</tt> should have an entry pointing to unstable.
apt-get update

Maybe some additional packages are necessary:
apt-get install libdb3-dev libncurses-dev docbook-utils
apt-get install fakeroot dpatch

Get the kernel source and unpack it:
apt-get install linux-source-2.6.12
cd /usr/src
tar xjf /usr/src/linux-source-2.6.12.tar.bz2

Maybe you want to have your old .config
cd linux-source-2.6.12
cp /boot/config-2.6.12-1-386 .config

Now it's time to install patches:
apt-get install util-vserver -t unstable
apt-get install kernel-patch-vserver -t unstable

Compile the Kernel:
make-kpkg --rootcmd fakeroot --revision custom01 --added-patches vserver--append-to-version +vserver --initrd binary-arch

Now you should find a .deb ready to install:
cd ..
dpkg -i kernel-image-2.6.12+vserver_custom01_i386.deb

The configuration of GRUB should be updated now to boot the new kernel - try a reboot.

Install the DRBD packages:
apt-get install drbd0.7-module-source -t unstable
apt-get install drbd0.7-utils -t unstable

Unpack the module source:
cd /usr/src/
tar xzf drbd0.7.tar.gz

Compile the DRBD module:
cd linux-source-2.6.12
make-kpkg --append-to-version +vserver modules_image

Install the module:
cd ..
dpkg -i /usr/src/drbd0.7-module-2.6.12+vserver_0.7.11-1+custom01_i386.deb
update-modules
modprobe drbd

===Prepare the disk space===
You will need some block device like <tt>/dev/hdaX</tt>, or a better choice is to use LVM.
lvcreate -L3000 -nlvvs03 vg0

A recommended method is, to have DRBD metadata on an extra block device for each DRBD device.

Prepare space for it:
lvcreate -L132 -nlvvs03md vg0

===Configure DRBD===
Create an entry in <tt>/etc/drbd.conf</tt> using your favorite editor:
<pre>
resource vs03 {
protocol C;
incon-degr-cmd "echo '!DRBD! pri on incon-degr' | wall ; sleep 60 ; halt -f";

startup {
wfc-timeout 100;
degr-wfc-timeout 120; # 2 minutes.
}

disk {
on-io-error pass_on;
}

net {
# sndbuf-size 512k;
# timeout 60; # 6 seconds (unit = 0.1 seconds)
# connect-int 10; # 10 seconds (unit = 1 second)
# ping-int 10; # 10 seconds (unit = 1 second)
# max-buffers 2048;
# max-epoch-size 2048;
# ko-count 4;
# on-disconnect reconnect;
}

syncer {
rate 10M;
group 1;
al-extents 257;
}

on cel600 {
device /dev/drbd1;
disk /dev/vg0/lvvs03;
address 192.168.0.22:7789;
meta-disk /dev/vg0/lvvs03md[0];
}

on xp2400 {
device /dev/drbd1;
disk /dev/vg0/lvvs03;
address 192.168.0.21:7789;
meta-disk /dev/vg0/lvvs03md[0];
}
}
</pre>

Start DRBD
/etc/init.d/drbd start

The DRBD resource is in an undefined state. It needs to be forced to be 'primary' on the current node.
drbdsetup /dev/drbd1 primary --do-what-I-say

Obviously a filesystem is needed on top of DRBD:
mke2fs -j /dev/drbd1

Also we need a mount point somewhere:
mkdir /mnt/vs03

As heartbeat is intended to manage the vserver, using the heartbeat script for mounting is a first test:
/etc/ha.d/resource.d/Filesystem /dev/drbd1 /mnt/vs03 ext3 start

=== Install the vserver guest===
There are many methods how to install a vserver. Here 'debootstrap' is used. The important option is '--rootdir' to force the installation to the DRBD device.
vserver -v vs03 build --force --rootdir /mnt/vs03 \
-m debootstrap --hostname vs03.nack.at \
--netdev eth0 --interface 192.168.0.3/24 --context 3 -- \
-d sarge -m http://ftp.at.debian.org/debian/

We could start the vserver now. But first we try to make the configuration more pretty.
cd /mnt/vs03/vs03/etc/rc0.d
rm K20makedev K25hwclock.sh S30urandom S31umountnfs.sh S35networking S36ifupdown S40umountfs S90halt K89klogd
cd ../rc6.d
rm K20makedev K25hwclock.sh S30urandom S31umountnfs.sh S35networking S36ifupdown S40umountfs S90reboot K89klogd
cd ../rcS.d
rm S05keymap.sh S48console-screen.sh S50hwclock.sh S40networking S45mountnfs.sh S10checkroot.sh S02mountvirtfs
rm S30procps.sh S35mountall.sh S36mountvirtfs S39ifupdown S30checkfs.sh S18ifupdown-clean S18hwclockfirst.sh
cd ../rc2.d
rm S20makedev S11klogd

If we want to have virtual IPs in the host context managed by heartbeat, there can be conflicts (and funny effects), if we do not 'name' the alias of the vserver IP.
echo vs03 > /etc/vservers/vs03/interfaces/0/name

sshd should only listen to the IPs of the host context:
xp2400:/# cat /etc/ssh/sshd_config | grep ListenAddress
ListenAddress 192.168.0.21:22
ListenAddress 192.168.0.20:22

We want to limit the vserver to 1 GB AS/VM (virtual address space) and 128 MB RSS (real memory). Note, that the units are pages.
xp2400:/# mkdir /etc/vservers/vs03/rlimits
xp2400:/usr/src# echo 250000 > /etc/vservers/vs03/rlimits/as
xp2400:/# echo 32000 > /etc/vservers/vs03/rlimits/rss

We want control CPU consumption:
xp2400:/# echo sched_prio > /etc/vservers/vs03/flags
xp2400:/# echo 6 > /etc/vservers/vs03/schedule
xp2400:/# echo 30 >> /etc/vservers/vs03/schedule
xp2400:/# echo 1000 >> /etc/vservers/vs03/schedule
xp2400:/# echo 200 >> /etc/vservers/vs03/schedule
xp2400:/# echo 3000 >> /etc/vservers/vs03/schedule
xp2400:/# echo dummy >> /etc/vservers/vs03/schedule
xp2400:/# cat /etc/vservers/vs03/schedule
6
30
1000
200
3000
dummy

After these checks it's time to start the vserver:
xp2400:/# vserver vs03 start

Check if the interface is nicely named and shown with ifconfig:
xp2400:/# ip addr show
[...]
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:30:bd:6b:d6:8f brd ff:ff:ff:ff:ff:ff
inet 192.168.0.21/24 brd 192.168.0.255 scope global eth0
inet 192.168.0.3/24 brd 192.168.0.255 scope global secondary eth0:vs03
inet6 fe80::230:bdff:fe6b:d68f/64 scope link
valid_lft forever preferred_lft forever

xp2400:/# ifconfig
eth0 Link encap:Ethernet [...]

eth1 [...]

eth0:vs03 Link encap:Ethernet HWaddr 00:30:BD:6B:D6:8F
inet addr:192.168.0.3 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:177 Base address:0xd000

Enter the vserver:
xp2400:/# vserver vs03 enter

In the vserver we check the base configuration and install some packages.
vs03:/# base-config
vs03:/# apt-get update
vs03:/# apt-get install locales
vs03:/# apt-get install less
vs03:/# nano /etc/resolv.conf
vs03:/# ping www.linux-vserver.org

We want to install at least one service, sshd.
vs03:/# apt-get install ssh
vs03:/# nano /etc/ssh/sshd_config
vs03:/# cat /etc/ssh/sshd_config | grep ListenAddress
ListenAddress 192.168.0.3:22
vs03:/# /etc/init.d/ssh restart
Restarting OpenBSD Secure Shell server: sshd.
vs03:/# passwd
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
vs03:/# exit
logout

Test the ssh login:
xp2400:/# ssh root@192.168.0.3
The authenticity of host '192.168.0.3 (192.168.0.3)' can't be established.
RSA key fingerprint is e2:19:d1:8d:7f:ac:0a:ce:12:f5:06:b7:ae:41:96:59.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.0.3' (RSA) to the list of known hosts.
Password: <secret>
vs03:~#

As another service Apache2 should be used:
vs03:/# apt-get install apache2
[...]
Starting web server: Apache2(98)Address already in use: make_sock: could not bind to address 0.0.0.0:80
no listening sockets available, shutting down
Unable to open logs
invoke-rc.d: initscript apache2, action "start" failed.

Setting up apache2 (2.0.54-4) ...

To avoid the above error:
vs03:/# nano /etc/apache2/ports.conf
vs03:/# cat /etc/apache2/ports.conf
Listen 192.168.0.3:80
vs03:/# /etc/init.d/apache2 start
Starting web server: Apache2(98)Address already in use: make_sock: could not bind to address 192.168.0.3:80
no listening sockets available, shutting down
Unable to open logs

Do we have an Apache listening on the vserver IP in the host context?
xp2400:/# cat /etc/apache2/ports.conf
Listen 80
xp2400:/# nano /etc/apache2/ports.conf
xp2400:/# cat /etc/apache2/ports.conf
Listen 192.168.0.21:80
Listen 127.0.0.1:80
xp2400:/# /etc/init.d/apache2 restart
Forcing reload of web server: Apache2.

vs03:/# /etc/init.d/apache2 start
Starting web server: Apache2.

xp2400:/# lynx http://192.168.0.3/
Test Page for Apache Installation

If you can see this, it means that the installation of the Apache web
server software on this system was successful. You may now add content
to this directory and replace this page.
[...]

The configuration on one node is ready.

To be continued ...

List of migrated pages

2009-04-03T08:03:18Z

Jze:

Below is a list of pages which are already migrated to the new wiki.

See also
* [[Wiki Relocation]]
* [[List of pages not migrated yet]]
* [[List of invalid old pages]]
* [[List of pages excluded from migration]]
* [[List of old Documentation pages]]

{| class="wikitablenowrap"
! Old page name
! Current URL
|-
| ArchVserver ||[[Installation on ArchLinux]]
|-
|Caps+and+Flags || [[Capabilities and Flags]]
|-
|ChangeLog26 || [[ChangeLog]]
|-
|Changelog26-Devel || [[ChangeLog]]
|-
|ChangeLog || [[ChangeLog]]
|-
|ChangeLogDevel26 || [[ChangeLog]]
|-
|ChangeLogDevelExperimental || [[ChangeLog]]
|-
|ChangeLogExperimental || [[ChangeLog]]
|-
|ChangeLogStableExperimental || [[ChangeLog]]
|-
|chroot-barrier || [[Secure chroot Barrier]]
|-
|Dates+and+Planning || [[News]]
|-
|Documentation || [[Documentation]]
|-
|Examples || [[Do I need Linux-VServer]]
|-
|FrequentlyAskedQuestions || [[Overview]]
|-
|GentooGuestHowto || [[Installation on Gentoo]]
|-
|GentooHostHowto || [[Installation on Gentoo]]
|-
|Hacker+Page || [[Sandbox]]
|-
|Hall+of+Fame || [[Hall of Fame]]
|-
|HistoryList || [[Special:Recentchanges]]
|-
|HowTo+Read+ProcFS || [[HowTo_Read_ProcFS]]
|-
|HowTo+Read+ProcFS-French || [[HowTo_Read_ProcFS/fr]]
|-
|HowtoSSHLogin || [[SSH login]]
|-
|Linux VServer Howto || [[Installation on Gentoo]]
|-
|Linux-VServer-Paper-00 || [[Paper]]
|-
|Linux-VServer-Paper-01 || [[Paper]]
|-
|Linux-VServer-Paper-02 || [[Paper]]
|-
|Linux-VServer-Paper-03 || [[Paper]]
|-
|Linux-VServer-Paper-04 || [[Paper]]
|-
|Linux-VServer-Paper-05 || [[Paper]]
|-
|Linux-VServer-Paper-06 || [[Paper]]
|-
|Linux-VServer-Paper-07 || [[Paper]]
|-
|Linux-VServer-Paper-08 || [[Paper]]
|-
|Linux-VServer-Paper-09 || [[Paper]]
|-
|Linux-VServer-Paper-10 || [[Paper]]
|-
|Linux-VServer-Paper-11 || [[Paper]]
|-
|Linux-VServer-Paper-12 || [[Paper]]
|-
|Linux-VServer-Paper-13 || [[Paper]]
|-
|Linux-VServer-Paper-14 || [[Paper]]
|-
|Linux-VServer-Paper-15 || [[Paper]]
|-
|Linux-VServer-Paper || [[Paper]]
|-
|Linux-VServer-Paper-00-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-01-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-02-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-03-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-04-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-05-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-06-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-07-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-08-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-09-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-10-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-11-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-12-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-13-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-14-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-15-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-03-espaniol || [[Paper/es]]
|-
|Linux-VServer-Paper-French||[[Paper/fr]]
|-
|Linux-VServer-self-definition || [[Overview]]
|-
|Linux-VServer || [[Welcome to Linux-VServer.org]]
|-
|MediaWiki+GIT || [[Wiki Team]]
|-
|Namespaces || [[Namespaces]]
|-
|Namespaces-French || [[Namespaces/fr]]
|-
|ProblematicPrograms || [[Problematic Programs]]
|-
|ProjectOverview || [[Overview]]
|-
|RecentChanges || [[Special:Recentchanges]]
|-
|Related+Projects || [[Related Projects]]
|-
|Release+FAQ || [[Downloads]]
|-
|Resource+Limits || [[Resource Limits]]
|-
|short+presentation || [[Overview]]
|-
|Tools+and+patches || [[Downloads]]
|-
|Tools || [[Downloads]]
|-
|VirtualServer || [[Overview]]
|-
|VServerConcept || [[Overview]]
|-
|VServerConfiguration || [[VServerConfiguration]]
|-
|VServer+Hosting || [[VServer Hosting]]
|-
|Vservers+and+X || [[Vservers and X]]
|-
|WikiStat || [[Special:Allpages]]
|-
|WorkingPrograms || [[Working programs]]
|}

List of pages not migrated yet

2009-04-03T08:02:26Z

Jze:

HowTo Read ProcFS

2009-04-03T08:02:04Z

Jze: category

==Information in /proc/virtual==
/proc/virtual
.../info

/proc/virtual/<pid>
.../info
.../status
.../sched
.../cvirt
.../cacct
.../limit

===/proc/virtual/info===
===/proc/virtual/<xid>===
This directory contains several files which can provide valuable information on the current context state and settings.
==== /proc/virtual/<xid>/info ====
ID: 1001
Info: 83c37000
Init: 0

this shows the context id, vx_info location and init pid
==== /proc/virtual/<xid>/status ====
UseCnt: 38
Tasks: 16
Flags: 0000000000000000
BCaps: 00000000d46c04ff
CCaps: 0000000000000000
Ticks: 0

this contains the usage count (references) and task count, as well as the context flags, capability boundary and context capabilities
==== /proc/virtual/<xid>/sched ====
Token: 0
FillRate: 1
Interval: 4
TokensMin: 6
TokensMax: 50
PrioBias: 0
VaVaVoom: 0
cpu 0: 0 0 0
shows the current amount of tokens, scheduler parameters (fill rate, interval, min/max), the priority bias and the calculated vavavoom (priority bonus)

==== /proc/virtual/<xid>/cacct ====
UNSPEC: 0/0 0/0 0/0
UNIX: 35/2375 35/2375 0/0
INET: 12/531 56/1937 57/1705
INET6: 0/0 0/0 0/0
OTHER: 0/0 0/0 0/0
forks: 0

this accounts socket messages for the listed protocols, as incoming messages/bytes and outgoing messages/bytes

====/proc/virtual/<xid>/cvirt ====
BiasUptime: 49.73
SysName: Linux
NodeName: XXXX.test.org
Release: 2.6.11-rc5
Version: #12 Sun Feb 27 01:07:29 CET 2005
Machine: i686
DomainName:
nr_threads: 16
nr_running: 0
nr_unintr: 0
nr_onhold: 0
load_updates: 14585
loadavg: 0.00 0.00 0.00
total_forks: 272

this contains the uptime bias, utsname settings (sys, node, rel, vers, machine, domain), the number of threads, thread stats (running, uninterruptible, on hold), the number of load updates, the load averages (1,5,15) and the number of forks

==== /proc/virtual/<xid>/limit ====
PROC: 16 17 -1 0
VM: 14440 15331 -1 0
VML: 0 0 -1 0
RSS: 5478 5847 -1 0
ANON: 1516 1516 -1 0
FILES: 140 155 -1 0
OFD: 122 122 -1 0
LOCKS: 1 3 -1 0
SOCK: 9 9 -1 0
MSGQ: 0 0 -1 0
SHM: 0 0 -1 0

limit columns are:
# current
# max observed
# limit
# number of hits

limit rows are:
*processes,
*virtual memory,
*locked memory,
*resident set size,
*anonymous memory,
*number of files,
*filedescriptors,
*locks,
*sockets,
*message queues,
*shared memory

==Debug settings in /proc/sys/vserver==
/proc/sys/vserver
.../debug_switch
.../debug_xid
.../debug_cvirt
.../debug_limit
.../debug_dlim
.../debug_nid
.../debug_net

===/proc/sys/vserver/debug_switch===
===/proc/sys/vserver/debug_xid===
===/proc/sys/vserver/debug_cvirt===
===/proc/sys/vserver/debug_limit===
===/proc/sys/vserver/debug_dlim===
===/proc/sys/vserver/debug_nid===
===/proc/sys/vserver/debug_net===

[[Category:ProcFS]]

HowTo Read ProcFS/fr

2009-04-03T08:01:46Z

Jze: migrated from old wiki HowTo+Read+ProcFS-French

==Information in /proc/virtual==
/proc/virtual
.../info

/proc/virtual/<pid>
.../info
.../status
.../sched
.../cvirt
.../cacct
.../limit

===/proc/virtual/info===
===/proc/virtual/<xid>===
Ce répertoire contient plusieurs fichiers qui donnent des informations importantes sur l'état du contexte courant et ses paramètres de fonctionnement.

==== /proc/virtual/<xid>/info ====
ID: 1001
Info: 83c37000
Init: 0

Nous avons ici le context id, l'emplacement du vx_info ainsi que le pid d'init

==== /proc/virtual/<xid>/status ====
UseCnt: 38
Tasks: 16
Flags: 0000000000000000
BCaps: 00000000d46c04ff
CCaps: 0000000000000000
Ticks: 0

this contains the usage count (references) and task count, as well as the context flags, capability boundary and context capabilities
==== /proc/virtual/<xid>/sched ====
Token: 0
FillRate: 1
Interval: 4
TokensMin: 6
TokensMax: 50
PrioBias: 0
VaVaVoom: 0
cpu 0: 0 0 0

Nombre de token en cours, parametres de l'ordonanceur (fill rate, interval, min/max), la "priority bias" ainsi que le vavavoom (bonus calcule)

==== /proc/virtual/<xid>/cacct ====
UNSPEC: 0/0 0/0 0/0
UNIX: 35/2375 35/2375 0/0
INET: 12/531 56/1937 57/1705
INET6: 0/0 0/0 0/0
OTHER: 0/0 0/0 0/0
forks: 0

this accounts socket messages for the listed protocols, as incoming messages/bytes and outgoing messages/bytes

====/proc/virtual/<xid>/cvirt ====
BiasUptime: 49.73
SysName: Linux
NodeName: XXXX.test.org
Release: 2.6.11-rc5
Version: #12 Sun Feb 27 01:07:29 CET 2005
Machine: i686
DomainName:
nr_threads: 16
nr_running: 0
nr_unintr: 0
nr_onhold: 0
load_updates: 14585
loadavg: 0.00 0.00 0.00
total_forks: 272

this contains the uptime bias, utsname settings (sys, node, rel, vers, machine, domain), the number of threads, thread stats (running, uninterruptible, on hold), the number of load updates, the load averages (1,5,15) and the number of forks

==== /proc/virtual/<xid>/limit ====
PROC: 16 17 -1 0
VM: 14440 15331 -1 0
VML: 0 0 -1 0
RSS: 5478 5847 -1 0
ANON: 1516 1516 -1 0
FILES: 140 155 -1 0
OFD: 122 122 -1 0
LOCKS: 1 3 -1 0
SOCK: 9 9 -1 0
MSGQ: 0 0 -1 0
SHM: 0 0 -1 0

limit columns are:
# current
# max observed
# limit
# number of hits

limit rows are:
*processes,
*virtual memory,
*locked memory,
*resident set size,
*anonymous memory,
*number of files,
*filedescriptors,
*locks,
*sockets,
*message queues,
*shared memory

==Debug settings in /proc/sys/vserver==
/proc/sys/vserver
.../debug_switch
.../debug_xid
.../debug_cvirt
.../debug_limit
.../debug_dlim
.../debug_nid
.../debug_net

===/proc/sys/vserver/debug_switch===
===/proc/sys/vserver/debug_xid===
===/proc/sys/vserver/debug_cvirt===
===/proc/sys/vserver/debug_limit===
===/proc/sys/vserver/debug_dlim===
===/proc/sys/vserver/debug_nid===
===/proc/sys/vserver/debug_net===

[[Category:ProcFS]]
[[Category:French]]

HowTo Read ProcFS

2009-04-03T08:00:22Z

Jze: migrated from old wiki HowTo+Read+ProcFS

List of pages not migrated yet

2009-04-01T07:39:21Z

Jze:

Openwall

2009-04-01T07:39:07Z

Jze: migrated from old wiki Openwall

Patches are available at [http://www.openwall.com/linux/ Openwall].

The nice thing of the Openwall security patches are that they apply very cleanly together with the vserver patches. No rediffing or manually applying is necesaary, making them more reliable in my eyes. Since I don't use the ACLs of grsec this works just as fine in my opinion.

I've been using them together for a few months now without any issues.

The procedure is very simple. Before you apply the vserver (ctx) patch, you apply the openwall patch. An example would be like this:
tar jxf linux-2.4.24.tar.bz2
cd linux-2.4.24
cat ../linux-2.4.24-ow1/linux-2.4.24-ow1.diff > patch -p1
bzcat ../patch-2.4.24-vs1.24.diff.bz2 | patch -p1
make menuconfig

I enabled all security options:
CONFIG_HARDEN_STACK=y
CONFIG_HARDEN_STACK_SMART=y
CONFIG_HARDEN_LINK=y
CONFIG_HARDEN_FIFO=y
CONFIG_HARDEN_PROC=y
CONFIG_HARDEN_RLIMIT_NPROC=y
CONFIG_HARDEN_SHM=y

And this hasn't given me any issues yet. After this, finish off with:
make dep && make bzImage && make modules && make modules_install
or
make-kpg --revision=131 kernel_image
or whatever you like. :)

OpenVPN

2009-04-01T07:38:17Z

Jze: migrated from old wiki OpenVPN

How to run OpenVPN inside the current version of vserver patch (tested on 2.0.2 an some earlier versions)

Note : I don't think it's The Good Way (tm) in the long term, but it works just fine.

Tested with tun mode openvpn, not in tap mode.

# Configure OpenVPN on the host computer (give it a key, config file,...)
# Configure the vservers so that they get access to bindings of the openvpn tun interface with a unique IP, i.e. : IPROOT="tunX:a.b.c.d" (among other interfaces if wanted)
# Configure the OpenVPN server to use a ccd (see client-config-dir)
# Add a configuration named after the key common name of the vserver host
# Add "iroute" entries to that file so the OpenVPN server knows where the IP resides.

Here you are. You should be able to access the VPN from inside the vserver, and access the vserver from the VPN.

Now a more tricky part : giving internet access to a vserver having only a vpn IP (SNAT)

The problem is that the routing table is shared among the host and the vserver, so you can't replace the 0.0.0.0 route by something using the OpenVPN server VPN address.

The solution is to add a second routing table with special application scope :
ip rule add from 10.0.0.112/28 lookup 2

This will make all routing for the 10.0.0.112 .. 10.0.0.127 ip range (adapt it to match the vserver vpn address, this examples can route 14 consecutives VPN address on the same host). Why do I use table 2 ? Just a random choice :). Just make sure the table numbers matches the other in the rule and that you don't use something already used. I have no ide if there is any convention in that area.

Then add the default gateway rule:
ip route add default via 10.0.0.110 dev tun0 table 2
10.0.0.110 being the IP of the host. Here is something quite strange - for me - : the packets are rerouted to the openvpn server even if the vserver host IP is given... So it's the one we will configure as a gateway (shorewall configuration extracts) :
/etc/shorewall/mask
eth0 10.0.0.0/24
/etc/shorewall/policy
vpn net ACCEPT
Last step is to configure the resolv.conf inside the vserver (but is it worth mentioning ? :) ).

Make the services reload their configurations and voila.

I think something likewise should be possible to allow DNAT (port forwarding), but I hadn't any need for that so I didn't try.

Installation on Debian

2009-03-30T10:38:11Z

Jze: versions

This guide is written against Debian Etch (4.0). This release includes kernel '''linux-image-vserver-686''', so no manual patching is needed. Hence, Installation on Debian Etch is pretty easy and straightforward.

If you need to compile your own kernel, you need to apply the vserver-version.patch. [http://www.kwu.hu/blog.php Details at 2007/Apr/25]

== Packages installation ==
The packages required by Linux-VServer are:
* '''linux-image-vserver-686''' - This is the current kernel
* '''util-vserver''' - These are the utilities used to administer the guests
* '''ssh''' - This is probably already installed, but just in case it isn't

All the packages you need can be obtained via
<pre>apt-get install linux-image-vserver-686 util-vserver ssh</pre>
so run this as ''root'' and reboot.
To check out wherever everything went fine you may run
<pre>uname -r</pre>
and check that kernel version is something like '''2.6.18-4-vserver-686'''. That's it.

Now that the host system is ready, you can proceed with [[Building Guest Systems|building guests]].

== Versions ==
Debian already contains vservers kernels, so no manual patching and compiling is needed.
{|class="wikitablenowrap"
!Debian release
!Kernel version
!VServer version
|-
| Etch
| 2.6.18+6
| 2.0.2.2-rc9
|-
| Lenny
| 2.6.26+17
| 2.3.0.35
|-
|}

== References ==
* Linux-VServer HOWTO by Daniel15: http://howtoforge.com/linux_vserver_debian_etch

List of pages not migrated yet

2009-03-30T10:31:09Z

Jze:

List of migrated pages

2009-03-30T10:31:00Z

Jze:

Below is a list of pages which are already migrated to the new wiki.

See also
* [[Wiki Relocation]]
* [[List of pages not migrated yet]]
* [[List of invalid old pages]]
* [[List of pages excluded from migration]]
* [[List of old Documentation pages]]

{| class="wikitablenowrap"
! Old page name
! Current URL
|-
| ArchVserver ||[[Installation on ArchLinux]]
|-
|Caps+and+Flags || [[Capabilities and Flags]]
|-
|ChangeLog26 || [[ChangeLog]]
|-
|Changelog26-Devel || [[ChangeLog]]
|-
|ChangeLog || [[ChangeLog]]
|-
|ChangeLogDevel26 || [[ChangeLog]]
|-
|ChangeLogDevelExperimental || [[ChangeLog]]
|-
|ChangeLogExperimental || [[ChangeLog]]
|-
|ChangeLogStableExperimental || [[ChangeLog]]
|-
|chroot-barrier || [[Secure chroot Barrier]]
|-
|Dates+and+Planning || [[News]]
|-
|Documentation || [[Documentation]]
|-
|Examples || [[Do I need Linux-VServer]]
|-
|FrequentlyAskedQuestions || [[Overview]]
|-
|GentooGuestHowto || [[Installation on Gentoo]]
|-
|GentooHostHowto || [[Installation on Gentoo]]
|-
|Hacker+Page || [[Sandbox]]
|-
|Hall+of+Fame || [[Hall of Fame]]
|-
|HistoryList || [[Special:Recentchanges]]
|-
|HowtoSSHLogin || [[SSH login]]
|-
|Linux VServer Howto || [[Installation on Gentoo]]
|-
|Linux-VServer-Paper-00 || [[Paper]]
|-
|Linux-VServer-Paper-01 || [[Paper]]
|-
|Linux-VServer-Paper-02 || [[Paper]]
|-
|Linux-VServer-Paper-03 || [[Paper]]
|-
|Linux-VServer-Paper-04 || [[Paper]]
|-
|Linux-VServer-Paper-05 || [[Paper]]
|-
|Linux-VServer-Paper-06 || [[Paper]]
|-
|Linux-VServer-Paper-07 || [[Paper]]
|-
|Linux-VServer-Paper-08 || [[Paper]]
|-
|Linux-VServer-Paper-09 || [[Paper]]
|-
|Linux-VServer-Paper-10 || [[Paper]]
|-
|Linux-VServer-Paper-11 || [[Paper]]
|-
|Linux-VServer-Paper-12 || [[Paper]]
|-
|Linux-VServer-Paper-13 || [[Paper]]
|-
|Linux-VServer-Paper-14 || [[Paper]]
|-
|Linux-VServer-Paper-15 || [[Paper]]
|-
|Linux-VServer-Paper || [[Paper]]
|-
|Linux-VServer-Paper-00-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-01-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-02-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-03-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-04-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-05-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-06-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-07-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-08-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-09-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-10-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-11-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-12-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-13-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-14-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-15-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-03-espaniol || [[Paper/es]]
|-
|Linux-VServer-Paper-French||[[Paper/fr]]
|-
|Linux-VServer-self-definition || [[Overview]]
|-
|Linux-VServer || [[Welcome to Linux-VServer.org]]
|-
|MediaWiki+GIT || [[Wiki Team]]
|-
|Namespaces || [[Namespaces]]
|-
|Namespaces-French || [[Namespaces/fr]]
|-
|ProblematicPrograms || [[Problematic Programs]]
|-
|ProjectOverview || [[Overview]]
|-
|RecentChanges || [[Special:Recentchanges]]
|-
|Related+Projects || [[Related Projects]]
|-
|Release+FAQ || [[Downloads]]
|-
|Resource+Limits || [[Resource Limits]]
|-
|short+presentation || [[Overview]]
|-
|Tools+and+patches || [[Downloads]]
|-
|Tools || [[Downloads]]
|-
|VirtualServer || [[Overview]]
|-
|VServerConcept || [[Overview]]
|-
|VServerConfiguration || [[VServerConfiguration]]
|-
|VServer+Hosting || [[VServer Hosting]]
|-
|Vservers+and+X || [[Vservers and X]]
|-
|WikiStat || [[Special:Allpages]]
|-
|WorkingPrograms || [[Working programs]]
|}

Working programs

2009-03-30T10:30:50Z

Jze: migrated from old wiki WorkingPrograms

This is a list of known working programs (mostly daemons), if any of those need a special configuration or setup it will contain a link with details. It is important is to document which versions worked together (kernel + vserver + program version).

''(If you add entries, please keep this in alphabetical order.)''

{| class="wikitablenowrap"
!Program
!Kernel
!V-Server
|-
|Amavisd-new (20030616p10)
|2.4.28
|1.29
|-
|Apache (1.3.26)
|2.4.28
|1.29
|-
|Apache (2.0.55)
|2.4.27
|1.29
|-
|[[Problematic Programs|Asterisk (1.0.3)]]
|2.4.28
|1.29
|-
|Bind (8.3.3)
|2.4.28
|1.29
|-
|Courier (0.37.3)
|2.4.28
|1.29
|-
|Courier IMAP (1.4.3)
|2.4.28
|1.29
|-
|Cupsys (1.1.20)
|2.4.28
|1.29
|-
|[[Problematic Programs|Cups (1.1.21-0.rc1.7mdk)]]
|2.6.9
|1.9.3
|-
|CVS (1.11.1p1)
|2.4.28
|1.29
|-
|CVS (1.11.17)
|2.6.9
|1.9.3
|-
|Cyrus IMAPd
|2.1.17
|1.9.3
|-
|Cyrus IMAPd 2.3.1
|2.6.14
|2.0.1
|-
|djbdns 1.0.5
|2.4.17ctx-5
|0.9-1
|-
|F-Secure Policy Manager Server (5.60.4111)
|2.4.28
|1.29
|-
|[[Problematic Programs|Hylafax (4.1.8)]]
|2.4.28
|1.29
|-
|Mailman (2.1.5)
|2.6.9
|1.9.3
|-
|MIT Kerberos (kadmind+krb5kdc v1.3.5)
|2.6.9
|1.9.3
|-
|MySQL? (3.23.49)
|2.4.28
|1.29
|-
|[[Problematic Programs|OpenGroupware (1.0)]]
|2.4.28
|1.29
|-
|[[Problematic Programs|OpenLDAP (2.1.30)]]
|2.4.28
|1.29
|-
|[[Problematic Programs|OpenLDAP (2.1.30)]]
|2.6.9
|1.9.3
|-
|[[Problematic Programs|OpenSwan (2.2.0)]]
|2.4.28
|1.29+patch
|-
|Postfix (2.1.4)
|2.4.28
|1.29
|-
|PostgreSQL? (7.4.6)
|2.4.28
|1.29
|-
|qmail 1.03
|2.6.9
|1.9.3
|-
|SNMPd (5.1.2)
|2.4.28
|1.29
|-
|Samba (3.0.10)
|2.6.10
|1.9.3.16
|-
|[[Problematic Programs|Samba print and file server with Cups]]
|2.6.9
|1.9.3
|-
|Squid (2.4.6)
|2.4.28
|1.29
|-
|Subversion (1.0.9)
|2.4.28
|1.29
|}

Scheduler

2009-03-30T10:24:28Z

Jze: migrated from old wiki Scheduler

The Scheduler in the 2.6 kernel is radically different from the 2.4.x series. It is an O(1) scheduler. This means that the job of scheduling does not get more and more complex as the number of running or inactive processes on the machine increases. This is important for SMP scalablity, and the case where there are lots of processes running. In addition, the newer scheduler has better real-time and interactive performance.

Basically, the way it works is this (based on my analysis of the code, read a kernel book and it might say something different :-): each CPU has two linked list run-queues, which hold a list of runnable processes (those waiting for CPU time). Slices are taken from the front of one of the queues, and when the process has finished its cycle, it is either inserted back on the one actively being processed, or moved to the second one - depending on factors such as the priority of the process, and how long it actually ran. What this means is that processes that have not been using much CPU time (ie, interactive processes) get an increased priority, because they are inserted on the end of the running list. When the first process on the second list start to become "starved" of CPU time, this action is canceled so that the first list can deplete. Once it is depleted, the lists are swapped around and the waiting list becomes the running list.

There have been two implementations of implementing the optional per-s_context scheduling for the O(1) scheduler. The approach taken by SamV is to use a "token bucket" for each s_context that assigns a number (N) of CPU "tokens" to each vserver every M cycles. If the process is caught running when the timer tick (which happens 100 times a second on the i386 port) happens, then a token is taken from the bucket. The process is then given a priority penalty or advantage based on the number of tokens left in the bucket. The penalty seems to work best when it is roughly quadratic - ie, giving more (3-4 times) of a maximum penalty for exceeding your quota of tokens than a boost for using nothing. This gives the following characteristics:
* s_contexts that have been hogging the CPU get a very low priority - but still, they are not starved of CPU time, and if there are no other running processes on the system the only disadvantage is more frequent context switches.
* s_contexts that do not use their quota up get very good interactive and general performance
* It is still possible for a vserver assigned to a context to use more tokens than they should, if they start a very large number of processes - as each process is always assigned at least one CPU slice.
However, it is perfectly suitable for most use cases.

The approach taken by Alex Lyashkov when I last looked took a more thorough, but not O(1) approach, but I won't comment on its exact workings as I haven't analysed it thoroughly.

Another approach that would work and still be O(1) would be to assign each s_context its own pair of run-queues, and schedule the entire s_context as if it were a single process to the outside server. This would satisfy "hard" scheduling requirements, while increasing the complexity of the code marginally.

List of pages not migrated yet

2009-03-30T10:11:54Z

Jze:

List of migrated pages

2009-03-30T10:11:48Z

Jze: Linux-VServer-Paper-03-espaniol

Below is a list of pages which are already migrated to the new wiki.

See also
* [[Wiki Relocation]]
* [[List of pages not migrated yet]]
* [[List of invalid old pages]]
* [[List of pages excluded from migration]]
* [[List of old Documentation pages]]

{| class="wikitablenowrap"
! Old page name
! Current URL
|-
| ArchVserver ||[[Installation on ArchLinux]]
|-
|Caps+and+Flags || [[Capabilities and Flags]]
|-
|ChangeLog26 || [[ChangeLog]]
|-
|Changelog26-Devel || [[ChangeLog]]
|-
|ChangeLog || [[ChangeLog]]
|-
|ChangeLogDevel26 || [[ChangeLog]]
|-
|ChangeLogDevelExperimental || [[ChangeLog]]
|-
|ChangeLogExperimental || [[ChangeLog]]
|-
|ChangeLogStableExperimental || [[ChangeLog]]
|-
|chroot-barrier || [[Secure chroot Barrier]]
|-
|Dates+and+Planning || [[News]]
|-
|Documentation || [[Documentation]]
|-
|Examples || [[Do I need Linux-VServer]]
|-
|FrequentlyAskedQuestions || [[Overview]]
|-
|GentooGuestHowto || [[Installation on Gentoo]]
|-
|GentooHostHowto || [[Installation on Gentoo]]
|-
|Hacker+Page || [[Sandbox]]
|-
|Hall+of+Fame || [[Hall of Fame]]
|-
|HistoryList || [[Special:Recentchanges]]
|-
|HowtoSSHLogin || [[SSH login]]
|-
|Linux VServer Howto || [[Installation on Gentoo]]
|-
|Linux-VServer-Paper-00 || [[Paper]]
|-
|Linux-VServer-Paper-01 || [[Paper]]
|-
|Linux-VServer-Paper-02 || [[Paper]]
|-
|Linux-VServer-Paper-03 || [[Paper]]
|-
|Linux-VServer-Paper-04 || [[Paper]]
|-
|Linux-VServer-Paper-05 || [[Paper]]
|-
|Linux-VServer-Paper-06 || [[Paper]]
|-
|Linux-VServer-Paper-07 || [[Paper]]
|-
|Linux-VServer-Paper-08 || [[Paper]]
|-
|Linux-VServer-Paper-09 || [[Paper]]
|-
|Linux-VServer-Paper-10 || [[Paper]]
|-
|Linux-VServer-Paper-11 || [[Paper]]
|-
|Linux-VServer-Paper-12 || [[Paper]]
|-
|Linux-VServer-Paper-13 || [[Paper]]
|-
|Linux-VServer-Paper-14 || [[Paper]]
|-
|Linux-VServer-Paper-15 || [[Paper]]
|-
|Linux-VServer-Paper || [[Paper]]
|-
|Linux-VServer-Paper-00-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-01-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-02-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-03-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-04-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-05-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-06-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-07-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-08-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-09-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-10-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-11-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-12-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-13-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-14-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-15-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-03-espaniol || [[Paper/es]]
|-
|Linux-VServer-Paper-French||[[Paper/fr]]
|-
|Linux-VServer-self-definition || [[Overview]]
|-
|Linux-VServer || [[Welcome to Linux-VServer.org]]
|-
|MediaWiki+GIT || [[Wiki Team]]
|-
|Namespaces || [[Namespaces]]
|-
|Namespaces-French || [[Namespaces/fr]]
|-
|ProblematicPrograms || [[Problematic Programs]]
|-
|ProjectOverview || [[Overview]]
|-
|RecentChanges || [[Special:Recentchanges]]
|-
|Related+Projects || [[Related Projects]]
|-
|Release+FAQ || [[Downloads]]
|-
|Resource+Limits || [[Resource Limits]]
|-
|short+presentation || [[Overview]]
|-
|Tools+and+patches || [[Downloads]]
|-
|Tools || [[Downloads]]
|-
|VirtualServer || [[Overview]]
|-
|VServerConcept || [[Overview]]
|-
|VServerConfiguration || [[VServerConfiguration]]
|-
|VServer+Hosting || [[VServer Hosting]]
|-
|Vservers+and+X || [[Vservers and X]]
|-
|WikiStat || [[Special:Allpages]]
|}

Paper/es

2009-03-30T10:11:05Z

Jze: migrated from old wiki Linux-VServer-Paper-03-espaniol

== Infraestructura Existente==
Los recientes núcleos de Linux ya proveen muchas prestaciones de seguridad que son utilizadas por Linux-Vserver para hacer su trabajo. Especialmente características tales como el Sistema de Capacidades de Linux, Límite de Recursos, Atributos de archivos y el Cambio del Entorno Raíz. Las siguientes secciones darán una breve reseña acerca de cada una de estas.

=== Sistema de Capacidades de Linux===
En ciencias de la computación, una capacidad es un signo usado por un proceso para probar que tiene permitido realizar una operación sobre un objeto. El Sistema de Capacidades de Linux se basa en las "Capacidades Posix", un concepto ligeramente, diseñado para fraccionar el privilegio todo poderoso de root en un conjunto de de distintos privilegios.

==== Capacidades de Linux ====
Un proceso tiene tres conjuntos de mapas de bits llamadas capacidades hereditarios(I), permitidos(P), y efectivos(E). Cada capacidad se implementa como un bit de estos mapas de bits que están activado o desactivados.

Cuando un proceso intenta hacer una operación privilegiada, el sistema operativo comprobará el bit apropiado en el conjunto efectivo de los procesos (en lugar de comprobar si el uid efectivo del proceso es 0 como se hace normalmente).

Por ejemplo, cuando un proceso intenta configurar el reloj, el núcleo Linux comprobará que el proceso tiene el bit CAP_SYS_TIME (que es actualmente el bit 25) habilitado en su conjunto efectivo.

El conjunto pemitido de los procesos indica las capacidades que el proceso puede usar. El proceso puede tener capacidades habilitadas en el conjunto permitido que no están en el conjunto efectivo.

Esto indica que el proceso tiene temporalmente deshabilitado esta capacidad. Un proceso tiene permitido habilitar un bit en su conjunto permitido solamente si está disponible en el conjunto permitido. La distinción entre efectivo y permitido existe de manera que el proceso puede agrupar operaciones que necesitan privilegios.

La implementación de en Linux detenida a este punto, mientras que las Capacidades de POSIX requier la adición de conjuntos de capacidades para archivos también para reemplazar la marca SUID (al menos para ejecutables)

=== Capability Overview ===
Las lista de Capacidades de POSIX que se usan es larga, y se usan casi todos de los 32 bits disponibles. Si bien la lista detalla da de todas las capacidades se puede encontrar en <tt>/usr/include/linux/capability.h</tt> en la matoría de los sistemas Linux, se da aquí un resumen general de las capacidades importantes que se pueden encontrar.

{|class="wikitablenowrap"
|0 || CAP_CHOWN|| cambia el dueño y grupo del archivo.
|-
|5 || CAP_KILL|| envía una señal a un proceso con un identificador de usuario diferente existente o efectivo
|-
|6 || CAP_SETGID|| permite setgid(2), setgroups(2), y falsos gids en pase de credenciales de socket
|-
|7 || CAP_SETUID|| permite set*uid(2), y falsos uids en pase de credenciales
|-
|8 || CAP_SETPCAP|| transfiere/elimina cualquier capacidad en el conjunto permitido hacia/desde cualquier pid
|-
|9 || CAP_LINUX_IMMUTABLE|| permite la modificación de los atributos de archivo S_IMMUTABLE y S_APPEND
|-
|11 || CAP_NET_BROADCAST|| permite hacer broadcast y escuchar a múltiples direcciones
|-
|12 || CAP_NET_ADMIN|| permite la configuración de una interfaz, firewall de IP, enmascaramiento, cuantificación, depuración de socket, tablas de ruteo, conexión a cualquier dirección, entrar en modo promiscuo, multicasting,...
|-
|13 || CAP_NET_RAW|| permite el uso de sockets crudos y de paquetes
|-
|16 || CAP_SYS_MODULE|| inserta y saca módulos del kernel
|-
|18 || CAP_SYS_CHROOT|| permite chroot(2)
|-
|19 || CAP_SYS_PTRACE|| permite ptrace() de cualquier proceso
|-
|21 || CAP_SYS_ADMIN|| esta lista sería demasiado larga, basicamente permite hacer cualquier otra cosa, no mencionada en otra capacidad.
|-
|22 || CAP_SYS_BOOT|| permite reboot(2)
|-
|23 || CAP_SYS_NICE|| permite aumentar la prioridad
|}

Paper/fr

2009-03-30T10:10:37Z

Jze: category

==Abstract ==
Concept logiciel basé sur les ''Security Contextes'' permet la création d'une multitude de serveurs virtuels Privés (VPS) tournant simultanément sur un même serveur physique à pleine vitesse, en partageant efficacement les ressources matérielles.
Un VPS offre un environnement quasiment identique à celui d'un serveur Linux conventionnel. Tous les services, comme ssh, mail, Web, bases de données, peuvent être lancés dans un tel VPS, sans aucune modification (ou, dans certains cas, des modifications mineures), exactement comme avec n'importe quel autre serveur réel.

Chaque serveur virtuel possède sa propre base utilisateurs et son mot de passe root. Il est isolé de tous les autres serveurs virtuels, sauf en ce qui concerne les ressources matérielles, qui sont partagées par tous les serveurs virtuels.

== Introduction ==
Au fur et à mesure des années, les micro ordinateurs sont devenus suffisemment puissant pour utiliser la virtualisation comme méthode pour donner l'illusion d'avoir une multitude de petites machines virtuelles, chacune d'elle tournant avec une instance différente de n'importe quel système d'exploitation.

Il existe plusieurs types de Machines Virtuelles (VMs) dont les fonctionnalités sont similaires, mais qui diffèrent dans le degré d'abstraction et les méthodes utilisées pour la virtualisation.

La plupart d'entre elles "émulent" une ressource matérielle réelle ou fictive, qui, à son tour, fait usage de "vraies" ressources du système Hote (la machine qui fait tourner les VMs). Cette approche, utilisée par la plupart des émulations système (comme QEMU[U1], Bochs[U2], ... permet à l'émulateur d'éxécuter n'importe quel système d'exploitation, même pour une architecture différente (CPU et matérielle). Pas besoin de modifier le système d'exploitation Invité, puisqu'il n'est pas conscient de s'éxécuter sur autre chose qu'un vrai matériel.

Quelques émulations systèmes ont besoin d'un petit nombre de modifications ou de pilotes de périphériques spécifiques sur le système Hote ou le système Invité pour améliorer les performances, et minimiser le grignotage superflu de ressources système qui passe dans les systèmes de cache et de médiation entre le système Hote et le système Invité. Bien que cela améliore sensiblement l'efficacité de ces solutions, les ressources perdues sont toujours notables (par exemple dans UML[U3] et Xen[U4]).

Supposez par contre que les systèmes d'exploitation à lancer ne sont pas différents ... La plupart des applications qui tournent sur un serveur n'ont pas besoin d'acceder au matériel ou à du code au niveau noyau, et pourraient donc partager une machine avec les autres, si l'on pouvait les séparer et les isoler ...

== Le Concept ==
A la base, un serveur Linux est constitué de trois blocs constitutifs: Le matériel, le Noyau, et les Applications. Le Matériel dépend habituellement du fournisseur ou de l'administrateur système, et, bien qu'ayant une grande influence sur les performances globales, ne peut pas être changé facilement, et diffère sensiblement d'une configuration à l'autre.

Un role de base du noyau consiste à créer une couche d'abstraction au dessus du matériel pour permettre aux processus (Applications) de travailler avec des ressources (Données) sans connaitre les détails du matériel qui se trouve en dessous. Idéalement, ces processus sont complètement agnostiques vis-à-vis du matériel, écrit dans un langage interprété, et ne nécessitant par conséquent aucun savoir faire spécifique au matériel.

Puisqu'un système possède assez de ressources pour faire tourner environ dix fois plus d'applications que nécessaire sur un serveur Linux traditionnel, pourquoi ne pas placer sur celui-ci une dizaine de serveurs, qui vont partager les ressources d'une manière efficace ?

La plupart des serveurs d'application (par exemple httpd) considère qu'il est la seule application à fournir un service particulier, et d'habitude, va donc supposer une organisation particulière au niveau du système de fichiers, et de l'environnement. Cela implique que deux services identiques tournant sur un même serveur physique, mais différent simplement au niveau de leur adresse IP, par exemple, doivent être coordonnées. Cela demande typiquement pas mal de boulot pour l'administrateur système, et cela peut conduire à un stabilité réduite du système et de la sécurité.

Le concept de base de la solution Linux-VServer est de séparer l'environnement en user space (espace utilisateur) en trois unités distinctes (appellées parfois VPS, ou Virtual Private Server), de telle manière que chaque VPS ressemblera à un vrai serveur vis-à-vis des processus qu'il contient.

Bien que différentes Distributions Linux utilisent des noyaux modifiées (parfois lourdement) pour assurer le support de telle ou telle fonctionnalité, ou matériel, la plupart des distributions Linux ne sont pas liées irrévocablement à un noyau linux particulier.

Linux-VServer utilise cela pour donner à plusieurs distributions, la possibilité de se lancer au dessus d'un seul noyau, partagé, sans accès direct au matériel, et partager les ressources d'une manière très efficace.

== Infrastructure Existante ==
Les noyaux Linux récents fournissent déjà de nombreuses fonctions de sécurité qui sont utilisées par Linux-Vserver pour fonctionner, telles que le Système de Privileges Linux, les limites de ressource, les attributs de fichier et l'environnement chroot. Les sections suivantes vous donneront un court aperçu de chacune d'entre elles.
=== Le système de Privileges (Capabilities) Linux ===
En science informatique, un privilege est un jeton utilisé par un processus pour prouver qu'il est autorisé à faire une opération sur un objet. Le Système de privileges Linux est basé sur les "Privileges POSIX", un concept légèrement similaire, conçu pour diviser les privilèges root puissants en un ensemble de privilèges distincts.

==== Privileges POSIX ====
Un processus possède trois champs de bits appelés les privileges héritables (I - "Inheritable"), permises (P), et effectives (E). Chaque privilege est implémenté dans un bit de chacun de ces champs, bit qui est soit défini soit non-défini.

Quand un processus essaie de faire une opération privilégiée, le système d'exploitation va vérifier les bits appropriés dans l'ensemble effectif des processus (au lieu de vérifier si l'uid respectif du processus est 0 comme il le fait habituellement).

Par exemple, quand un processus essaie de modifier l'horloge, le noyau Linux va vérifier que ce processus a le bit CAP_SYS_TIME (actuellement le bit 25) parmi ses privileges effectives.

L'ensemble permis d'un processus indique les privileges que celui-ci peut utiliser. Le processus peut avoir des privileges définies dans l'ensemble permis qui ne sont pas dans l'ensemble effectif.

Ceci indique que le processus a temporairement désactivé ce privilege. Un processus n'est autorisé à définir un bit dans son ensemble effectif que si ce bit est disponible dans son ensemble permis.

La distinction entre privileges effectif et permis existe pour que les processus puissent réaliser des opérations qui nécessitent des privilèges.

Les privileges héritables sont les privileges du processus courant qui peuvent être hérités par un programme exécuté par ce dernier. L'ensemble permis d'un processus est masqué contre l'ensemble héritable pendant exec().

Rien de spécial ne se produit durant fork() ou clone().

Les processus fils ou les threads obtiennent une copie exacte des privileges du processus parent.

L'implémentation dans Linux s'arrête là, alors que les privileges POSIX[U5] requièrent l'ajout d'un ensemble de privileges aux fichiers, pour remplacer le flag SUID (au moins pour les exécutables).

==== Vue d'ensemble des privileges ====
La liste des privileges POSIX utilisées avec Linux est longue, et les 32 bits disponibles sont presques tous utilisés. Bien que la liste détaillée de ces privileges puisse être trouvée dans /usr/include/linux/capability.h sur la plupart des systèmes Linux, une vue d'ensemble des privileges importantes est donnée ici.
{|class="wikitablenowrap"
| 0|| CAP_CHOWN || change le propriétaire et le groupe du fichier
|-
| 5|| CAP_KILL|| envoie un signal au processus avec un ID utilisateur différent, réel ou effectif
|-
| 6|| CAP_SETGID|| permet le passage de setgid(2), setgroups(2), et de gids forgés sur les sockets
|-
| 7|| CAP_SETUID|| permet le passage de set*uid(2) et d'uids forgés sur les sockets
|-
| 8|| CAP_SETPCAP|| transfert/déplace tout privilege de l'ensemble permis vers/depuis n'importe quel pid
|-
| 9|| CAP_LINUX_IMMUTABLE|| permet la modification des attributs de fichier S_IMMUTABLE et S_APPEND
|-
| 11|| CAP_NET_BROADCAST|| permet la diffusion et l'écoute en multicast
|-
| 12|| CAP_NET_ADMIN|| permet la configuration de l'interface, le pare-feux IP, le masquerading, l'accounting, le débugage de sockets, les tables de routage, la liaison sur n'importe quelle adresse, l'entrée dans le mode de promiscuité, le multicasting...
|-
| 13|| CAP_NET_RAW|| permet l'utilisation des sockets RAW et PACKET
|-
| 16|| CAP_SYS_MODULE|| ajoute et retire des modules noyau
|-
| 18|| CAP_SYS_CHROOT|| permet chroot(2)
|-
| 19|| CAP_SYS_PTRACE|| permet ptrace() sur n'importe quel processus
|-
| 21|| CAP_SYS_ADMIN|| la liste serait trop longue, ceci permet en gros de faire tout ce qui n'est pas mentionné dans les autres privileges
|-
| 22|| CAP_SYS_BOOT|| permet reboot(2)
|-
| 23|| CAP_SYS_NICE|| permet l'élévation des privilèges et la modification de la priorité des autres processus, en modifiant l'ordonnanceur
|-
| 24|| CAP_SYS_RESOURCE|| passe outre les limites de ressource, de quota, l'espace réservé sur un système de fichier...
|-
| 27|| CAP_MKNOD|| permet les aspects privilégiés de mknod(2)
|}

Voir également les Exemples [E01],[E02], et [E03].

=== Limite des Ressources ===
Vous pouvez limiter les ressources de chaque processus en spécifiant une limite pour chaque ressource. A la manière des privileges Linux, il existe deux types de limites, l'une Douce, l'autre Dure.

La limite Douce est la valeur que le noyau imposera pour cette ressource à un processus. Un utilisateur non privilégié pourra régler la limite Douce n'importe où en dessous de la valeur Dure. Seul l'utilisateur root pourra re-hausser la limite Dure.

==== Apercu des Ressources Limit-ables ====
La liste des ressources qui peuvent être limitées se trouve dans le fichier /usr/include/asm/resource.h sur la plupart des systèmes Linux.
{|class="wikitablenowrap"
| 0|| RLIMIT_CPU || Temps CPU en secondes. un signal SIGXCPU est envoyé au processus qui a atteind la limite Douce, et un SIGKILL pour la limite Dure.
|-
| 4|| RLIMIT_CORE || Taille maximale d'un fichier core.
|-
| 5|| RLIMIT_RSS || Nombre de pages maximum qu'un processus peut utiliser (en RAM)
|-
| 6|| RLIMIT_NPROC || Nombre maximum de processus autorisés à l'utilisateur réel du processus appelant.
|-
| 7|| RLIMIT_NOFILE || Spécifie la valeur +1 pour le nombre maximum de descripteurs de fichiers ouvert par un processus.
|-
| 8|| RLIMIT_MEMLOCK || Nombre maximum de pages mémoire virtuelle autorisées à être vérouillées en RAM à l'aide des appels mlock() ou mlockall().
|-
| 9|| RLIMIT_AS || Nombre maximum de pages de mémoire virtuelle disponible pour un processus.
|}

(Limite de l'espace d'adressage)

Voir aussi les Exemples [E11], et [E12].

=== Attributs de Fichiers ===
Auparavant, cette fonctionnalité n'était disponible qu'avec ext2, mais maintenant tous les systèmes de fichiers majeurs implémentent un ensemble d'Attributs de fichiers de base, qui permettent le paramétrage de certaines propriétés. Voici de nouveau un bref aperçu des possibilités des attributs, et leur signification.

{|class="wikitablenowrap"
| s SECRM || Lorsqu'un fichier avec cet attribut est détruit, les blocs qui le composent sont mis à zéro et re-écrit sur le disque.
|-
| u UNRM || Lorsqu'un fichier avec cet attribut est détruit, son contenu est sauvegardé.
|-
| c COMPR || Un fichier marqué avec cet attribut est automatiquement compressé à l'écriture et décompressé à la lecture. (pas encore implémenté)
|-
| i IMMUTABLE || Un fichier avec cet attribut ne pourra pas être modifié: Impossible de le renommer ou de le détruire, impossible de créer un lien vers ce fichier, ni d'écrire une donnée de plus vers ce fichier.
|-
| a APPEND || Un fichier avec cet attribut ne pourra être ouvert qu'en mode ajout.
|-
| d NODUMP || Si cet attribut de fichier est mis, le fichier n'est pas candidat à un backup via l'utilitaire "dump".
|-
| S SYNC || Les mises à jour vers ce fichier se feront de manière synchrone.
|-
| A NOATIME || Empêche la mise à jour de l'enregistrement atime lors d'un accès ou d'une modification de fichier.
|-
| t NOTAIL || Un fichier avec l'attribut t n'aura pas de fragment bloc en fin de fichier fusionné avec un autre fichier.
|-
| D DIRSYNC || Les modifications apportés à ce répertoire seront écrites de manière synchrones.
|}

Voir aussi les Exemples [E13] et [E14].

=== La Commande chroot(1) ===
chroot permet de lancer une commande en changeant le répertoire racine dans lequel il va s'éxécuter. Cela signifie que tout parcours du système de fichiers à partir de la racine '/' se fera à partir de la racine substituée et non pas à partir de la racine originelle.

Bien que le chroot Linux n'est pas très sécurisé, son utilisation augmente l'isolation des processus par rapport au système de fichier, et, à condition de l'utiliser correctement, peut être utilisé pour "emprisonner" un processus, un utilisateur unique, ou un démon (service).

Voir l'Exemple [E15]

== Modifications Requises ==
Ce chapitre décrit les modifications à apporter au noyau pour implémenter un mécanisme comme Linux-VServer.

=== Séparation de Contextes ===
La séparation telle que décrite dans la partie 'Concepts' nécessite quelques modifications au noyau pour permettre la notion de Contexte.

Le but d'un tel "Contexte" est de cacher à un processus tout ce qui ne doit pas etre à sa portée, et empécher les interractions indésirables entre un processus appartenant à un contexte et un processus appartenant à un autre contexte.

Cette séparation nécessite l'extension d'un certain nombre de structures de données pour qu'elles prennent en compte les contextes et fassent la différentiation entre deux uids identiques mais utilisés dans deux serveurs virtuels différents.

De plus, nous avons besoin d'un contexte par defaut qui sera utilisé par le serveur hôte au démarrage, et pour éviter les problèmes liés à des suppositions érronées de certains outils en espace utilisateur (comme pstree) par exemple, l'idée comme quoi init existe toujours et a toujours l'uid 1.

Pour simplifier l'administration, le Contexte de l'Hôte n'est pas traité différemment d'un autre contexte, en tout cas du point de vue de l'isolation des processus.

Pour avoir un apercu global de tous les processus, un Spectateur spécial a été mis en place, qui est capable de capturer tous les processus d'un coup.
Voir les Examples [E21],[E22] et [E23]

=== Séparation Réseau ===
Bien que les Contextes soient suffisant pour isoler un groupe de processus, un autre type d'isolation, ou plutot une limitation, est nécessaire pour confiner les processus dans un sous ensemble d'adresses réseau disponibles.

Plusieurs problèmes doivent être pris en compte dans ce sens: par exemple, les appels système bind sur IPADDR_ANY doivent être traités d'une manière bien particulière.

Actuellement, Linux-Vserver n'utilise pas les interfaces virtuelles (et ne les utilisera peut-être jamais), pour minimiser le cout supplémentaire qu'elles engendrent. De ce fait, l'attachement d'une socket et la transmission des packets ont été adaptés.

Voir Example [E24]

=== La Barrière Chroot ===
Un problème majeur avec le chroot() de Linux aujourd'hui tient au fait que cette information est volatile, et changera au prochain appel système de chroot().

Voici une façon simple pour sortir d'un environnement chrooté Créez tout d'abord un fichier, et retenez son descripteur. Puis chrootez dans un répertoire au même niveau ou un niveau au dessous de celui-ci. Cela a pour effet de faire descendre la racine' dans le système de fichiers. Ensuite, faites un appel à fchdir() sur le descripteur de fichiers pour sortir de cette nouvelle racine. Vous sortirez en même temps de l'ancienne racine, qui a été perdue suite au dernier appel système chroot().

Alors que des méthodes exotiques étaient utilisées dans les anciennes versions de Linux-Vserver pour fixer ce problème, les versions récentes utilisent un marquage spécial, connu sous le nom de Barrière Chroot, placé sur le parent de tous les VPS pour prévenir toute modification non autorisée et sortie du confinement.

=== Un plafond pour les Privileges ===
L'implémentation actuelle des privileges Linux ne prend pas en compte les privileges POSIX sur les systèmes de fichiers. Si cela était le cas, les executables setuid et setgid seraient sécurisés. Pour conserver donc une bonne sécurité malgré cette contrainte, nous avons défini un plafond pour tous les processus d'un même contexte, et un masque de privileges additionnel pour chaque contexte a été aussi ajouté pour limiter à ce seul masque les processus qui appartiennent à ce contexte.

La signification des privileges individuels (bits) pour ce masque est exactement identique à celui que permet l'ensemble des privileges.=== Isolation de Ressources ===

=== Isolation de Ressources ===
La plupart des ressources sont d'une certaine manière partagées à travers les différents contextes; certaines requièrent une isolation plus importante que les autres, soit pour éviter les problèmes de sécurité, ou pour permettre une meilleure comptabilité de l'usage des ressources;

Ces ressources sont:
* mémoire partagée, IPC
* PID et User ID
* Drapeau xid sur les fichiers
* ptys Unix
* sockets

=== Drapeau XID pour les Filesystem XID ===
Bien qu'elle puisse être totalement desactivée, cette modification est requise pour une meilleure robustesse au niveau du système de fichiers, et pour isoler les contextes. Le drapeau XID est aussi totalement indispensable pour implémenter le support pour les Limites Disques par Contexte et les Quotas par Contexte sur une partition partagée.

Ce concept d'ajouter un identifiant de contexte (xid) à chaque fichier pour créer une notion d'appartenance d'un fichier à un contexte parait simple ... Il n'en est rien, car l'implémentation actuelle n'est pas triviale. Elle nécessite soit une modification des représentations du système de fichier, soit des astuces au niveau applicatif.

Une approche non intrusive pour éviter toute modification du système de fichiers sous-jacent est d'utiliser les bits de poids forts de champs existants, comme ceux des UID ou GID pour stocker le XID additionnel.

Une fois que les informations de contexte sont disponibles au niveau de chaque inode, l'étape logique suivante est d'étendre la vérification d'accès au contexte en plus du reste.

Actuellement, tous les acces aux inodes sont vérifiés par rapport à leur contexte ID, à l'exception des contextes "Hôte" et "Spectateur".

Les fichiers non étiquettés dans le contexte hôte sont simplement traités comme appartenant au contexte courant, et cela est requis pour que l'Unification soit possible. Si un tel fichier est modifié à l'intérieur d'un contexte, elle changera en silence vers son noveau contexte, en changeant son XID.

Les méthodes suivantes de marquage sont utilisées:

;UID32/GID32 or EXTERNAL: Ce format utilise l'espace inutilisé dans l'inode disque pour stocker les informations de contexte. Pour l'instant, c'est uniquement défini pour ext3/ext3, mais sera dans le futur aussi défini pour xfs, reiserfs, et jfs, dès que possible.

Avantage: Valeurs 32bit uid/gid complètes.

;UID32/GID16: Ce format utilise la moitié haute du GID pour stocker les informations de contexte. Cela est fait de manière transparente, sauf si le format est changé sans conversion préalable.

Avantage: fonctionne avec tout système de fichiers équipé de UID / GID 32bits

Désavantage: le GID est réduit a 16 bits.

;UID24/GID24: Ce format utilise le premier quart haut de l'UID et du GID pour stocker les informations de contexte, une fois encore, d'une manière transparente. Cela permet 16 millions de groupes et utilisateurs, ce qui devrait suffire pour la majorité des applications.

Avantage: fonctionne sur tout système de fichiers avec des UID/GID 32bits

Desavantage: les UID et GID sont réduits a 24 bits.

Voir Examples [E31] et [E32]

== Modifications Supplémentaires ==
En plus du strict minimum, voici un certain nombre de modifications, non indispensables, mais qui se sont révélées très utiles au fil du temps.

=== Drapeaux par Contexte ===
Très tôt, le besoin d'activer ou désactiver une fonctionnalité séparement pour l'un ou l'autre des Vserver est apparue. Un champ de bits a donc été ajouté (taille=word).

Ce champ de bits comprend un bon nombre de drapeaux, un champ masque, qui indique les drapeaux disponibles, et un mécanisme de déclanchement spécial, pour activer un drapeau au démarrage, puis le désactiver en causant un évennement ou une action associée.

Voici la liste des drapeaux prévus et pour la plupart déjà implémentés. Ils sont disponibles dans la branche de développement de Linux-VServer:

{|class="wikitablenowrap"
| 0|| VXF_INFO_LOCK (historique, obsolète)
|-
| 1|| VXF_INFO_SCHED (historique, obsolète)|| schedule all processes in a context as if they where one.
|-
| 2|| VXF_INFO_NPROC (historique, obsolète)|| limite le nombre de processus autorisés dans un contexte à la valeur NPROC.
|-
| 3|| VXF_INFO_PRIVATE (historique)|| interdiction d'entrer dans ce contexte depuis l'extérieur.
|-
| 4|| VXF_INFO_INIT (historique) || show the init process with pid '1'
|-
| 5|| VXF_INFO_HIDE (historique, obsolète)||
|-
| 6|| VXF_INFO_ULIMIT (historique, obsolète)||
|-
| 7|| VXF_INFO_NSPACE (historique, obsolète)||
|-
| 8|| VXF_SCHED_HARD || activer l'ordonnancement "Hard CPU"
|-
| 9|| VXF_SCHED_PRIO || calculer les priorités de chaque processus à l'aide du "contexte token bucket".
|-
| 10|| VXF_SCHED_PAUSE || mettre tous les processus de ce contexte dans la file "hold", les empéchant d'être ordonnancés à nouveau.
|-
| 16|| VXF_VIRT_MEM || virtualize the memory information so that the VM and RSS limits are used for meminfo and friends
|-
| 17|| VXF_VIRT_UPTIME || virtualiser l'uptime, en commançant à la date de création du contexte.
|-
| 18|| VXF_VIRT_CPU ||
|-
| 24|| VXF_HIDE_MOUNT || afficher les /proc/{pid}/mounts comme vides.
|-
| 25|| VXF_HIDE_NETIF || cache les interfaces réseau et addresses non autorisées dans ce contexte.
|}

Voir Exemple [XX]

=== Privileges par Contexte ===
Lorsque nous sommes arrivé au nombre maximum de privileges envisageables sans trop modifier le noyau, l'étape suivante a été, naturellement, d'ajouter un système de privileges par contexte.

Le mécanisme des privileges par contexte implémenté dans Linux-VServer permet un réglage fin des privileges Linux. Ils ne sont pas visibles aux processus d'un contexte donné, puisque de toute facon le processus n'aurait pas le droit de les vérifier ou de les modifier.

Généralement, il y a deux facons d'utiliser ces privileges : * Require one or a number of context capabilities to be set in addition to a given Linux capability, each one controlling a distinct part of the functionality. For example the CAP_NET_ADMIN could be split into RAW and PACKET sockets, so you could take away each of them separately by not providing the required context capability.

Consider the context capability sufficient for a specified functionality, even if the Linux Capability says something different. For example mount() requires CAP_SYS_ADMIN which adds a dozen other things we do not want, so we define a CCAP_MOUNT to allow mounts for certain contexts.

The difference between the Context Flags and the Context Caps is more an abstract logical separation than a functional one, because they are handled very similar.
Again, a list of the Context Capabilities and their purpose:

{|class="wikitablenowrap"
|0|| VXC_SET_UTSNAME|| autoriser le contexte à changer le nom de serveur et le nom de domaine en utilisant l'appel système noyau approprié
|-
|1|| VXC_SET_RLIMIT|| allow the context to modify the resource limits (within the vserver limits).
|-
|8|| VXC_RAW_ICMP|| allow raw icmp packets in a secure way (this makes ping work from inside)
|-
|16|| VXC_SECURE_MOUNT|| permit secure mounts, which at the moment means that the nodev mount option is added.
|}

=== Comptabilité par Contexte ===
Plusieurs propriétés des contextes sont très utiles pour l'administrateur système, que ce soit pour garder un oeil sur les ressources, pour avoir une idée de ce que peut supporter le serveur, ou pour pouvoir facturer d'une manière ou d'une autre au client.

Deux types de propriétés peuvent être comptabilisées, celles dont la valeur courante représente l'état du système (par analogie, prenez la vitesse d'un véhicule), et celles dont la valeur augmente régulièrement avec le temps (comme le kilométrage).

La plupart des valeurs d'état sont limitables, et sont donc traitées d'une façon spécifique, comme cela est décrit dans la section qui suit.

Good candidates for Context Accounting are:
* Temps CPU utilisé
* Nombre de fork() effectués
* Nombre de messages Socket par Type
* Nombre de paquets Transmis et Recus

Voir Exemple [E41]

=== Limites par Contexte ===
La plupart des ressources système, que ce soit la consommation mémoire, le nombre de processus utilisés, le nombre de descripteurs de fichiers, la bande passante réseau, doivent pouvoir être limitées.

Les limites par contexte permettent, pour chaque valeur limitable, de définir trois types de limites: minimum, soft, et hard(maximum).

A l'heure actuelle, seule les limites hard sont supportées, et seulement une partie d'entre elles sont réellement activées. Voici une liste des limites par contexte actuelles et prévues:
* limites sur les processus
* limites sur l'ordonnanceur
* limites mémoire
* limites disques par contexte
* quotas user/groupe par contexte

De plus, les limites par contexte gardent trace des valeur maxima atteintes et du nombre de fois ou la limite a été atteinte (hit), pour donner un feedback utile a l'administrateur.

Voir Exemple [E42]

=== Virtualisation ===
One major difference between the Linux-VServer approach and Virtual Machines is that you do not have the virtualization part as a side-effect, so you have to do that by hand where it makes sense.

For example, a Virtual Machine does not need to think about uptime, because naturally the running OS was started somewhere in the past and will not have any problem to tell the time it thinks it began running.

A context can also store the time when it was created, but that will be different from the systems uptime, so in addition, there has to be some function, which adjusts the values passed from kernel to user-space depending on the context the process belongs to.

This is what for Linux-VServer is known as Virtualization (actually it's more faking some values passed to and from the kernel to make the processes think that they are on a different machine).

Currently modified for the purpose of Virtualization are:
* System Uptime
* Host and Domain Name
* Machine Type and Kernel Version
* Context Memory Availability
* Context Disk Space

Voir Exemple [E43]

=== Sécurité Renforcée ===
Le mécanisme de sécurité Proc-FS protège les entrées dynamiques du système de fichiers proc, de façon à ce que toutes les entrées ne soient pas vues dans tous les contextes.

Le système est constitué de trois drapeaux pour chaque entrée du Proc-FS: Admin, Watch, et Hide.

Le Drapeau Hide active ou désactive entierement une fonctionnalité, donc toute combinaison associée avec un drapeau Hide à 0 aura donc la signification visible.

Les drapeaux Admin et Watch déterminent ou l'entrée hidden (cachée) reste visible; par exemple, si les drapeaux Admin et Hidden sont mis, seul le Host Contexte (0) sera en mesure de voir cette entrée spécifique.

Voir Exemple [E44] et Voir Exemple [E45]

=== Kernel Helper ===
Dans certains cas, il peut être nécessaire de mettre en place un outil en espace utilisateur qui va agir en lieu et place du noyau, lorsque par exemple un processus demande une fonctionnalité disponible sur un serveur réel, mais non disponible dans un contexte.

Le meilleur exemple d'un tel cas est le "Reboot Helper", qui implémente l'appel système reboot(), invoqué depuis l'intérieur d'un contexte en lieu et place du noyau. L'appel sera éxécuté depuis le contexte hôte, qui lancera l'action adéquate, reboot ou un simple halt du contexte en question.

Bien que ce "helper" soit concu pour être flexible et gérer un certain nombre de choses de la même facon, il n'est pas utilisé pour l'instant à autre chose, et pourrait être remplacé dans le futur par une interface par evènement.

Voir Exemple [XX]

== Fonctionnalités et documentation additionnelle ==
=== Unification ===
L'un des objectifs centraux de Linux-VServer est de réduire l'utilisation des ressources partout ou cela est possible. Une excellente idée a donc germé, celle de partager des fichiers à travers les différents contextes sans interférer avec les taches administratives classiques ou diminuer le niveau de sécurité.

Les fichiers communs à plusieurs contextes, peu sujet à être modifiés, comme les bibliothèques ou les binaires, peuvent être soudés via un lien dur sur un système de fichier partagé, réduisant d'autant le besoin en espace disque, cache d'inodes, et surtout, l'occupation mémoire, via l'utilisation des bibliothèques partagées.

Seul inconvénient, si nous ne prenons pas quelques mesures supplémentaires, un contexte malicieux sera en mesure, par accident ou volontairement, de détruire ou modifier un tel fichier partagé, ce qui aurait des conséquences directes sur les autres contextes.
La première étape consiste à placer sur les fichiers partagés un drapeau Immutable (et enlever la caps qui permet de modifier un tel fichier). Il faut toutefois ajouter un attribut supplémentaire à ces fichiers partagés, pour permettre leur suppréssion, lors, par exemple, d'une mise à jour des bibliothèques dans un l'un des contextes.

Ces fichiers liés, immutables, que l'ont peut toutefois détruire, et appartenant à plus d'un contexte sont appelés unifiés, et l'action qui consiste à les rechercher et les préparer s'appelle Unification.

Choississez l'unification si vous souhaitez réduire votre usage de ressources. L'inconvénient évident est une administration moins facile. Un Serveur Linux s'installe typiquement sur 500Mo de disque, et 10 serveurs unifiés en consommeront donc seulement 700Mo, et moins de mémoire pour les caches.

Voir Exemple [XX]

=== Espaces de nom privés ===
Ajoutés récemment dans Linux-VServer, les espaces de noms privés utilisent la couche VFS du noyau linux et offrent une vue différente du système de fichier pour chaque contexte.
Par rapport au schéma traditionnel, l'avantage principal apparait lorsqu'on modifie quelquechose dans un espace de nommage (par exemple, les points de montage); à cet instant, les autres contextes resteront intact, y compris biensur le contexte Hôte.
Désavantage évident d'une telle approche; entrer dans un tel espace de noms privé n'est pas aussi simple que d'entrer dans un chroot. Toutefois, les choses pourraient changer dans les noyaux futurs, si cette fonctionnalité est par exemple intégrée directement à la fonction chroot().

=== Le système de fichier Proc-FS de Linux-VServer ===
A structured, dynamically generated subtree of the well-known Proc-FS - actually two of them - has been created to allow for inspecting the different values of Security and Network Contexts.
/proc/virtual
.../info

/proc/virtual/<pid>
.../info
.../status
.../sched
.../cvirt
.../cacct
.../limit

=== Extensions Token Bucket ===
While the basic idea of Linux-VServer is a peaceful coexistence of all contexts, sharing the common resources in a respectful way, it is sometimes useful to control the resource distribution for resource hungry processes.

The basic principle of a Token Bucket is not very new. It is given here as an example for the Hard CPU Limit. The same principle also applies to scheduler priorities, network bandwidth limitation and resource control in general.

The Hard CPU Limit uses this mechanism in the following way: consider a bucket of a certain size S which is filled with a specified amount of tokens R every interval T, until the bucket is "full" - excess tokens are spilled. At each timer tick, a running process consumes exactly one token from the bucket, unless the bucket is empty, in which case the process is put on a hold queue until the bucket has been refilled with a minimum M of tokens. The process is then rescheduled.

A major advantage of a Token Bucket is that a certain amount of tokens can be accumulated in times of quiescence, which later can be used to burst when resources are required.

Where a per-process Token Bucket would allow for a CPU resource limitation of a single process, a Context Token Bucket allows to control the CPU usage of all confined processes.

Another approach, which is also implemented, is to use the current fill level of the bucket to adjust the process priority, thus reducing the priority of processes belonging to excessive contexts.

Voir Exemple [XX]

=== Limites Disque par Contexte ===
Pour faire usage de cette fonctionnalité, le support pour les fichiers étiquetés XID doit être présent. Grace aux limites par contexte, vous pouvez alors régler une limite différente pour chaque contexte d'une partition partagée.

Chaque block et inode d'un système de fichier est comptabilisé, dès lors qu'un hachage XID a été ajouté à ce système de fichier dans ce contexte donné.
Those values, including current usage, maximum and reserved space, will be shown for filesystem queries, creating the illusion that the shared filesystem has a different usage and size, for each context.

=== Quota par Contexte ===
Similar to the Context Disk Limits, Per-Context Quota uses separate quota hashes for different Contexts on a shared filesystem. This is not required to allow for Linux-VServer quota on separate partitions.

=== Le périphérique "proxy" VRoot ===
Les opérations sur les Quotas (ioctls) nécessitent un accès aux périphériques de bloc. Ils ne sont donc pas disponible dans un VPS.

=== Stealth ===
Pour certaines applications, par exemple la préparation d'un "pot de miel" (honey-pot), ou d'une imitation particulièrement réaliste d'un vrai serveur à des fins éducatives, vous aurez peut-être besoin de confondre le contexte du serveur hôte (réel) et celui de votre pot de miel.
Toutefois, certaines alternatives libres comme QEMU ou UML vous permettent de faire la même chose beaucoup mieux et avec moins d'efforts. Ce n'est donc pas une question centrale dans le développement de Linux-VServer.

== Sécurité Linux-VServer ==
Nous savons maintenant que Linux-VServer implémente quelques principes de sécurité, et comment ils fonctionnent. Il faut tout de même dire quelques mots la dessus, puisqu'il ne suffit pas, bien évidemment, de considérer que Linux-VServer étant une architecture sécurisée, votre système sera sur automatiquement. Comme d'habitude, mieux vaut savoir *exactement* ce que vous faites.

=== Privileges Sécurisées ===
Actuellement, seules les privileges Linux suivantes sont considérés d'un usage sans risque dans un VPS. Si d'autres privileges sont nécessaires, ils ouvrent probablement des trous de sécurité.
* CAP_CHOWN
* CAP_DAC_OVERRIDE
* CAP_DAC_READ_SEARCH
* CAP_FOWNER
* CAP_FSETID
* CAP_KILL
* CAP_SETGID
* CAP_SETUID
* CAP_NET_BIND_SERVICE
* CAP_SYS_CHROOT
* CAP_SYS_PTRACE
* CAP_SYS_BOOT
* CAP_SYS_TTY_CONFIG
* CAP_LEASE
CAP_NET_RAW par exemple n'est pas considéré comme sur. Bien qu'il soit souvent utilisé pour donner le droit à la commande "ping" (dont le fonctionnement est cassé), il existe de bien meilleures alternatives comme la commande ping "poink[U7]", ou la cap VXC_RAW_ICMP.

=== La Barrière Chroot ===
Il faut vous assurer que le drapeau barrière est bien mis sur tout répertoire parent de chacun de vos VPS. Cela est indispensable pour prévenir quiconque de sortir du chroot et aller se balader dans le système de fichier de votre vserver hôte.

=== Fichiers de périphériques Sécurisés ===
Le répertoire /dev d'un VPS ne doit pas contenir plus de fichiers qu'indiqué ci-dessous, plus le répertoire pour les pts unix.
* c 1 7 full
* c 1 3 null
* c 5 2 ptmx
* c 1 8 random
* c 5 0 tty
* c 1 9 urandom
* c 1 5 zero
* d pts
Bien entendu, d'autres périphériques comme console, mem, kmem, et même des périphériques en mode block et/ou caractère peuvent être ajoutés, mais une certaine expertise sera nécessaire pour s'assurer que cela n'entraine aucun trou de sécurité.

=== Entrées Proc-FS Sécurisées ===
Aucun test n'a été fait sur la fiabilité et la sécurité des entrées dans le système de fichiers proc, mais quelques incidents ont été notés lorsqu'on utilise par exemple des entrées proc avec permission d'écriture, et non protégées par une CAP linux.
Par exemple, <tt>/proc/sysrq-trigger</tt> est un fichier qui ne doit en aucun cas être accessible dans un VPS sans une excellente raison.

== Champ d'Applications ==
Le but premier de ce projet est de permettre la création de serveurs virtuels partageant les ressources d'une même machine physique. Un Serveur Virtuel fonctionne comme un serveur Linux normal, et peut lancer des services traditionnels comme telnet, service de mail, service web, service SQL.

=== Séparation Administrative ===
Un provider intelligent peut donc vendre un serveur virtuel, qui, en utilisant moins de ressources que d'autres techniques de virtualisation, permet de lancer plus d'instances sur une même machine.

La liste des providers qui fournissent un tel service est assez longue, et on peut donc considérer que c'est l'application principale de vserver.

=== Séparation de Services ===
Pour séparer plusieurs services identiques ou de nature différente, qui auraient autrement des interférences entre eux, est une chose facile à mettre en oeuvre avec Vserver. Plusieurs raisons peuvent vous pousser à faire cela; un service mal écrit, ou simplement deux services qui ne savent pas co-exister pour de multiples raisons.

Même sur une machine à l'ancienne mode, placer un service très exposé ou non sécurisé car inconnu ou propriétaire dans une prison chroot peut améliorer grandement la sécurité et la maintenabilité.

=== Améliorer la Sécurité ===
Bien que l'idée de lancer plusieurs serveurs sur une seule machine soit en elle même très interessante, d'autres concepts sont encore plus interessants. Imaginez un serveur physique sur lequel tourne un seul vserver. Le but est d'isoler l'environnement principal de n'importe quel service, n'importe quel réseau. Vous démarrerez dans l'environnement principal, lancez très très peu de services, puis continuez dans le serveur virtuel.

Le service de l'environnement principal sera:
* Injoignable depuis le reseau.
* En mesure de logger tous les messages du virtual serveur, d'une manière sécurisée. Rien dans le serveur virtuel ne permet d'effacer les logs, ou de les modifier. Même un serveur virtuel cracké ne permet pas de changer les logs.
* En mesure de faire tourner un système de détection d'intrusion, qui espionnera l'état du serveur virtuel sans être accessible ou même détecté. Par exemple, vous pouvez installer et faire tourner tripwire depuis l'environnement principal, et impossible de modifier son fonctionnement ou de le tromper.
Une autre option consiste à mettre le firewall dans un serveur virtuel, puis étirer la DMZ sur un ensemble de VPS séparés. Moyennant une configuration bien faite, ce genre d'installation peut réduire substantiellement le nombre de machines requises, sans pour autant impacter les performances.

=== Maintenance Facilitée ===
Une fonctionnalité clef d'un serveur virtuel est son indépendance vis à vis du matériel. La plupart des problèmes matériels sont inconnus au fonctionnement d'un serveur virtuel.

Le serveur principal agit comme un système hôte, et s'occupe de tous les détails. Le serveur virtuel est simplement un client, et ignore tous les détails. De cette manière, le client peut être déplacé vers un autre serveur physique avec très peu de manipulations.

Par exemple, pour déplacer un serveur virtuel depuis un ordinateur physique vers un autre, il suffit de procéder aux étapes suivantes:
* stopper le serveur virtuel
* le copier sur l'autre machine
* copier sa configuration
* lancer le serveur virtuel sur la nouvelle machine
Pas de mise à jour des utilisateurs, pas de configuration matérielle, tant que les machines sont compatibles au niveau de leurs binaires.

=== Scenarios de Fail-Over ===
En repoussant les limites un peu plus loin, on peut utiliser des technologies de réplication pour conserver une copie identique à la minute près du système de fichier d'un serveur virtuel en fonctionnement. Cela peut servir à un basculement très rapide si le serveur en fonction tombe pour n'importe quelle raison.

Toutes les methodes connues sont utilisables dans ce but, en commancant par la réplication réseau comme rsync, ou drdb, en passant par NBD (les Network Devices), les disques partagés, ou un système de fichier distribué. Toutes ces méthodes sont utilisables pour réduire le temps d'indisponibilité d'un système et améliorer l'efficacité globale.

=== Pour test ===
Vous avez besoin de construire un logiciel pour plusieurs versions d'une distribution particulière. (Mandrake 8.2, 9.0, 9.1, 9.2, 10.0), ou bien même pour plusieurs distributions différentes.

Ce problème est résolu d'une manière très simple par Vserver. Avec pas mal d'espace disque, ces différentes distributions peuvent être installées et lancées en parallèle, simplifiant la tache de passer de l'une à l'autre.

Biensur, vous pouvez faire cela simplement avec chroot() et rien d'autre, mais Vserver offre une simulation bien plus réaliste.

== Performance et Stabilité ==
=== Impact de Linux-VServer sur l'hôte ===
=== Overhead dans un Contexte ===
=== Taille du patch noyau ===

== Matériels Non Intel i386 ==
Linux-VServer est concu pour être indépendant de l'architecture au maximum du coup, seule une toute petite partie, la définition de l'appel système lui-même est spécifique à une architecture. Malgré cela, quelques architectures renfermen des copies de certains codes 'architecture independant', pour une raison ou pou une autre, et nécessitent par conséquent de légères modifications.

Les architectures suivantes sont supportées, et certaines d'entre elles ont même été testées:
* alpha
* ia32 / ia64 / xbox
* x86_64 (AMD64)
* mips / mips64
* hppa / hppa64
* ppc / ppc64
* sparc / sparc64
* s390
* uml
L'ajout d'une nouvelle architecture est relativement simple, même si de tests extensifs sont nécessaires pour valider le bon fonctionnement d toutes les fonctionnalités telle qu'attendu. (et biensur, du matériel ;).

== Intro Noyau Linux ==
Bien que les fonctionnalités décrites plus haut sont codées dans le noyau, quelques outils sont nécessaires en espace utilisateur (userspace) pour les activer et les controler.

Ces outils en userspace communiquent généralement avec le noyau via des appels système (syscalls).

Le chapitre qui suit décrit les liens entre espace kernel et espace utilisateur, comment les appels système, méthode simple pour communiquer entre les processus et le noyau, fonctionnent.

=== Espace Noyau et Espace Utilisateur ===
Sous Linux et les systèmes d'exploitation similaires, l'espace noyau et l'espace utilisateur sont séparés, et l'espace d'adressage est divisé en deux parties. Dans L'espace noyau réside le code noyau, alors que les programmes utilisateur vivent dans l'espace utilisateur. Bien entendu, un programme ne peut écrire dans la mémoire noyau, ni dans la mémoire d'un autre processus.

Malheureusement, c'est aussi le cas pour le code du noyau. Le code kernel n'a pas le droit d'écrire dans l'espace utilisateur. Qu'est-ce que cela signifie ? Lorsqu'un driver de périphérique a besoin d'écrire ses octets destinés à un programme dans l'espace utilisateur, il ne peut pas le faire directement, mais doit passer par des fonctions noyau spécifiques à la place. De même, lorsque des paramètres sont passés au noyau par référence à une fonction kernel, la fonction kernel ne peut pas lire les paramètres directement. Elle doit utiliser d'autres fonctions noyau pour lire chaque octet des paramètres.

Bien entendu, il existe des fonctions écrites tout spécialement pour les transfer depuis et vers l'espace utilisateur.
copy_to_user(void *to, const void *from, long n);
copy_from_user(void *to, const void *from, long n);

get_user() and put_user() Prendre ou placer l'octet, le mot, ou l'entier long depuis l'espace utilisateur ou vers celui-ci. C'est une macro, et elle se fie au type de ses arguments pour évaluer le nombre d'octets à transférer.

=== Appels système Linux ===
La plupart des appels libc s'appuient sur les appels système, la plus petite forme de fonction qu'un programme peut appeler.

Ces appels système sont implémentés dans le noyau lui-même, ou dans des modules, parties de code noyau chargeables dynamiquement.

Ils sont implémentés via un multiplexeur appelé avec un masque d'interruption précis. Sous Linux, ce masque d'interruption est int 0x80. Lorsque l'instruction 'int 0x80' est exécutée, le contrôle est donné au noyau (ou, plus précisément, à la fonction _system_call() ), et le démultipléxage proprement dit prend place.

Comment fonctionne la fonction _system_call() ?

Tout d'abord, tous les registres sont sauvegardés, et le contenu du registre %eax est comparé à la table des appels systèmes, qui recense tous les appels systèmes et leur adresse respective.

On peut acceder à cette table via la variable extern void *sys_call_table[] Il existe un nombre et une adresse mémoire données dans cette table pour chacun des appels système.

Ceux-ci sont référencés dans le fichier /usr/include/sys/syscall.h.

Ils sont de la forme SYS_nomappelsysteme. si l'appel système n'est pas implémenté, la cellule correspondante dans la table sys_call_table est à 0, et une erreur est retournée.

Sinon, l'appel système sort, et l'entrée correspondante dans la table donne l'adresse du code ou se trouve l'appel système.

== Implémentation ==
Ce chapitre est plus particulierement reserve aux developpeurs noyau. Toutefois, les curieux trouveront avantage a tirer le rideau pour decouvrir les entrailles du systeme.

=== Appel systeme===
Pendant un certain temps, Linux-VServer a utilise different appels systeme pour accomplir les differents aspects de son travail. Tres vite, le nombre des commandes necessaires est devenu important, nous avons donc commence a donner des valeurs magiques aux appels pour choisir le comportement desire.

Enfin, il y a peu de temps, nous avons obtenu un numero reserve pour les appels systemes Linux-VServer, et malgre l'opinion de certains developpeurs, c'est globalement une bonne decision de garder un seul appel systeme.

Avoir plusieurs appels systeme peut faciliter les choses pour travailler avec les appels systemes sur plusieurs architectures; toutefois, cela n'a pas constitue un probleme majeur jusqu'ici, les donnees transitant depuis et vers le noyau etant, conformement au standard C99, fortement typees.

Quoi qu'il en soit, la mise en place d'un appel systeme passe par la creation d'un multiplexeur, qui va decider quelle commande doit etre executee, et quels arguments lui passer. A elle par la suite d'executer effectivement le travail demande.
extern asmlinkage long
sys_vserver(uint32_t cmd, uint32_t id, void __user *data)
L'appel systeme Linux-VServer prend trois arguments dans tous les cas: la commande (cmd), un nombre (id), et une structure de donnee en espace utilisateur d'une taille encore inconnue.

Pour faciliter le deboggage et la tenue a jour des informations de versionning, la chaine cmd est decomposee en trois parties: les 12 bits de poids faible contiennent le numero de version, puis 4 bits sont reserves. Les 16 bits de poids fort sont divises en 8 bits de commande et 6 pour la categorie, puis les 2 bits restant, reserves pour usage ulterieur.

Nous avons donc 64 Categories avec chacune 256 commandes, et 4096 revisions possible pour chaque commande, ce qui surpasse largement nos besoins presents et futurs.

Voici un apercu des categories deja definies, et leur valeur numerique associee:

Matrice des appels systeme V2.6

|VERSION|CREATE |MODIFY |MIGRATE|CONTROL|EXPERIM| |SPECIAL|SPECIAL|
|STATS |DESTROY|ALTER |CHANGE |LIMIT |TEST | | | |
|INFO |SETUP | |MOVE | | | | | |
-------+-------+-------+-------+-------+-------+-------+ +-------+-------+
SYSTEM |VERSION|VSETUP |VHOST | | | | |DEVICES| |
HOST | 00| 01| 02| 03| 04| 05| | 06| 07|
-------+-------+-------+-------+-------+-------+-------+ +-------+-------+
CPU | |VPROC |PROCALT|PROCMIG|PROCTRL| | |SCHED. | |
PROCESS| 08| 09| 10| 11| 12| 13| | 14| 15|
-------+-------+-------+-------+-------+-------+-------+ +-------+-------+
MEMORY | | | | | | | |SWAP | |
| 16| 17| 18| 19| 20| 21| | 22| 23|
-------+-------+-------+-------+-------+-------+-------+ +-------+-------+
NETWORK| |VNET |NETALT |NETMIG |NETCTL | | |SERIAL | |
| 24| 25| 26| 27| 28| 29| | 30| 31|
-------+-------+-------+-------+-------+-------+-------+ +-------+-------+
DISK | | | | | | | |INODE | |
VFS | 32| 33| 34| 35| 36| 37| | 38| 39|
-------+-------+-------+-------+-------+-------+-------+ +-------+-------+
OTHER | | | | | | | |VINFO | |
| 40| 41| 42| 43| 44| 45| | 46| 47|
=======+=======+=======+=======+=======+=======+=======+ +=======+=======+
SPECIAL| | | | |FLAGS | | | | |
| 48| 49| 50| 51| 52| 53| | 54| 55|
-------+-------+-------+-------+-------+-------+-------+ +-------+-------+
SPECIAL| | | | |RLIMIT |SYSCALL| | |COMPAT |
| 56| 57| 58| 59| 60|TEST 61| | 62| 63|
-------+-------+-------+-------+-------+-------+-------+ +-------+-------+

La definition de ces commandes est simplifiee grace a certaines macros, comme par exemple interroger un drapeau ou lui attribuer une valeur:
#define VCMD_get_cflags VC_CMD(FLAGS, 1, 0)
#define VCMD_set_cflags VC_CMD(FLAGS, 2, 0)

extern int vc_get_cflags(uint32_t, void __user *);
extern int vc_set_cflags(uint32_t, void __user *);

Notez bien, ce n'est pas la commande elle meme qui est passee en parametre, mais un id et un pointeur vers une structure de donnee en espace utilisateur.

=== Structures de Donnees Utilisees===
Plusieurs types de structures sont utilisees par les differentes parties de l'implementation; seuls quelques exemples sont donnes ici, l'ensemble complet des structures utilisees se trouve dans le source.
==== La Structure Data Context====
La structure Data Context permet de gerer les contextes, leur destruction, ainsi que les futurs contextes hierarchiques.

Les sections reservees pour l'ordonanceur ou les limites sont definies dans des structures separees, comme le veut la logique, puis incorporees dans la structure principale.
struct vx_info {
struct list_head vx_list; /* linked list of contexts */
xid_t vx_id; /* context id */
atomic_t vx_refcount; /* refcount */
struct vx_info *vx_parent; /* parent context */

struct namespace *vx_namespace; /* private namespace */
struct fs_struct *vx_fs; /* private namespace fs */
uint64_t vx_flags; /* context flags */
uint64_t vx_bcaps; /* bounding caps (system) */
uint64_t vx_ccaps; /* context caps (vserver) */

pid_t vx_initpid; /* PID of fake init process */

struct _vx_limit limit; /* vserver limits */
struct _vx_sched sched; /* vserver scheduler */
struct _vx_cvirt cvirt; /* virtual/bias stuff */
struct _vx_cacct cacct; /* context accounting */

char vx_name[65]; /* vserver name */
};

Voici un exemple de la sous-structure Ordonanceur:
struct _vx_sched {
spinlock_t tokens_lock; /* lock for this structure */

int fill_rate; /* Fill rate: add X tokens ... */
int interval; /* Divisor: ... each Y jiffies */
atomic_t tokens; /* current number of tokens */
int tokens_min; /* Limit: minimum for unhold */
int tokens_max; /* Limit: no more than N tokens */
uint32_t jiffies; /* bias: integral multiple of Y */

uint64_t ticks; /* token tick events */
cpumask_t cpus_allowed; /* cpu mask for context */
};

L'idee principale derriere ces sous-structures est de faciliter leur maintenabilite, a l'aide, pour chacune d'elles, d'une fonction init et cleanup, d'ou une lecture facilitee et une maintenabilite accrue.

==== The Scheduler Command Data====
As an example for the data structure used to control a specific part of the context from user-space, here is a scheduler command and the utilized data structure to set the properties:
#define VCMD_set_sched VC_CMD(SCHED, 1, 2)

struct vcmd_set_sched_v2 {
int32_t fill_rate; /* Fill rate: add X tokens ... */
int32_t interval; /* Divisor: ... each Y jiffies */
int32_t tokens; /* current number of tokens */
int32_t tokens_min; /* Limit: minimum for unhold */
int32_t tokens_max; /* Limit: no more than N tokens */
uint64_t cpu_mask; /* Mask: allowed cpus */
};

==== Example Accounting: Sockets====
Basically all the accounting and limit stuff are defined as macros or inline functions capable of handling the different resources, hiding the underlying implementation wherever possible.
#define vx_acc_sock(v,f,p,s) \
__vx_acc_sock((v), (f), (p), (s), __FILE__, __LINE__)

static inline void __vx_acc_sock(struct vx_info *vxi,
int family, int pos, int size, char *file, int line)
{
if (vxi) {
int type = vx_sock_type(family);

atomic_inc(&vxi->cacct.sock[type][pos].count);
atomic_add(size, &vxi->cacct.sock[type][pos].total);
}
}

#define vx_sock_recv(sk,s) \
vx_acc_sock((sk)->sk_vx_info, (sk)->sk_family, 0, (s))
#define vx_sock_send(sk,s) \
vx_acc_sock((sk)->sk_vx_info, (sk)->sk_family, 1, (s))
#define vx_sock_fail(sk,s) \
vx_acc_sock((sk)->sk_vx_info, (sk)->sk_family, 2, (s))

And this general definition is then used where appropriate, for example in the __sock_sendmsg() function like this:

len = sock->ops->sendmsg(iocb, sock, msg, size);
if (sock->sk) {
if (len == size)
vx_sock_send(sock->sk, size);
else
vx_sock_fail(sock->sk, size);
}

==== Example Limits: Virtual Memory====
#define vx_pages_avail(m, p, r) \
__vx_pages_avail((m)->mm_vx_info, (r), (p), __FILE__, __LINE__)

static inline int __vx_pages_avail(struct vx_info *vxi,
int res, int pages, char *file, int line)
{
if (!vxi)
return 1;
if (vxi->limit.rlim[res] == RLIM_INFINITY)
return 1;
if (atomic_read(&vxi->limit.res[res]) +
pages < vxi->limit.rlim[res])
return 1;
return 0;
}

#define vx_vmpages_avail(m,p) vx_pages_avail(m, p, RLIMIT_AS)
#define vx_vmlocked_avail(m,p) vx_pages_avail(m, p, RLIMIT_MEMLOCK)
#define vx_rsspages_avail(m,p) vx_pages_avail(m, p, RLIMIT_RSS)

And again the test against those limits at certain places, for example here in copy_process()
/* check vserver memory */
if (p->mm && !(clone_flags & CLONE_VM)) {
if (vx_vmpages_avail(p->mm, p->mm->total_vm))
vx_pages_add(p->mm->mm_vx_info,
RLIMIT_AS, p->mm->total_vm);
else
goto bad_fork_free;
}

==== Example Virtualization: Uptime====
void vx_vsi_uptime(struct timespec *uptime)
{
struct vx_info *vxi = current->vx_info;

set_normalized_timespec(uptime,
uptime->tv_sec - vxi->cvirt.bias_tp.tv_sec,
uptime->tv_nsec - vxi->cvirt.bias_tp.tv_nsec);
return;
}

if (vx_flags(VXF_VIRT_UPTIME, 0))
vx_vsi_uptime(&uptime, &idle);

[[Category:French]]

List of migrated pages

2009-03-30T10:07:25Z

Jze: Linux-VServer-Paper-French

Below is a list of pages which are already migrated to the new wiki.

See also
* [[Wiki Relocation]]
* [[List of pages not migrated yet]]
* [[List of invalid old pages]]
* [[List of pages excluded from migration]]
* [[List of old Documentation pages]]

{| class="wikitablenowrap"
! Old page name
! Current URL
|-
| ArchVserver ||[[Installation on ArchLinux]]
|-
|Caps+and+Flags || [[Capabilities and Flags]]
|-
|ChangeLog26 || [[ChangeLog]]
|-
|Changelog26-Devel || [[ChangeLog]]
|-
|ChangeLog || [[ChangeLog]]
|-
|ChangeLogDevel26 || [[ChangeLog]]
|-
|ChangeLogDevelExperimental || [[ChangeLog]]
|-
|ChangeLogExperimental || [[ChangeLog]]
|-
|ChangeLogStableExperimental || [[ChangeLog]]
|-
|chroot-barrier || [[Secure chroot Barrier]]
|-
|Dates+and+Planning || [[News]]
|-
|Documentation || [[Documentation]]
|-
|Examples || [[Do I need Linux-VServer]]
|-
|FrequentlyAskedQuestions || [[Overview]]
|-
|GentooGuestHowto || [[Installation on Gentoo]]
|-
|GentooHostHowto || [[Installation on Gentoo]]
|-
|Hacker+Page || [[Sandbox]]
|-
|Hall+of+Fame || [[Hall of Fame]]
|-
|HistoryList || [[Special:Recentchanges]]
|-
|HowtoSSHLogin || [[SSH login]]
|-
|Linux VServer Howto || [[Installation on Gentoo]]
|-
|Linux-VServer-Paper-00 || [[Paper]]
|-
|Linux-VServer-Paper-01 || [[Paper]]
|-
|Linux-VServer-Paper-02 || [[Paper]]
|-
|Linux-VServer-Paper-03 || [[Paper]]
|-
|Linux-VServer-Paper-04 || [[Paper]]
|-
|Linux-VServer-Paper-05 || [[Paper]]
|-
|Linux-VServer-Paper-06 || [[Paper]]
|-
|Linux-VServer-Paper-07 || [[Paper]]
|-
|Linux-VServer-Paper-08 || [[Paper]]
|-
|Linux-VServer-Paper-09 || [[Paper]]
|-
|Linux-VServer-Paper-10 || [[Paper]]
|-
|Linux-VServer-Paper-11 || [[Paper]]
|-
|Linux-VServer-Paper-12 || [[Paper]]
|-
|Linux-VServer-Paper-13 || [[Paper]]
|-
|Linux-VServer-Paper-14 || [[Paper]]
|-
|Linux-VServer-Paper-15 || [[Paper]]
|-
|Linux-VServer-Paper || [[Paper]]
|-
|Linux-VServer-Paper-00-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-01-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-02-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-03-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-04-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-05-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-06-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-07-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-08-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-09-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-10-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-11-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-12-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-13-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-14-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-15-French||[[Paper/fr]]
|-
|Linux-VServer-Paper-French||[[Paper/fr]]
|-
|Linux-VServer-self-definition || [[Overview]]
|-
|Linux-VServer || [[Welcome to Linux-VServer.org]]
|-
|MediaWiki+GIT || [[Wiki Team]]
|-
|Namespaces || [[Namespaces]]
|-
|Namespaces-French || [[Namespaces/fr]]
|-
|ProblematicPrograms || [[Problematic Programs]]
|-
|ProjectOverview || [[Overview]]
|-
|RecentChanges || [[Special:Recentchanges]]
|-
|Related+Projects || [[Related Projects]]
|-
|Release+FAQ || [[Downloads]]
|-
|Resource+Limits || [[Resource Limits]]
|-
|short+presentation || [[Overview]]
|-
|Tools+and+patches || [[Downloads]]
|-
|Tools || [[Downloads]]
|-
|VirtualServer || [[Overview]]
|-
|VServerConcept || [[Overview]]
|-
|VServerConfiguration || [[VServerConfiguration]]
|-
|VServer+Hosting || [[VServer Hosting]]
|-
|Vservers+and+X || [[Vservers and X]]
|-
|WikiStat || [[Special:Allpages]]
|}

List of pages not migrated yet

2009-03-30T10:06:16Z

Jze:

Paper/fr

2009-03-30T10:05:26Z

Jze:

Paper/fr

2009-03-30T10:00:29Z

Jze: interim saving

Paper/fr

2009-03-30T09:11:26Z

Jze: migrated from old wiki Linux-VServer-Paper-xx-French (up to 05)

List of pages not migrated yet

2009-03-30T06:56:47Z

Jze: HowtoSSHLogin

List of migrated pages

2009-03-30T06:56:46Z

Jze: HowtoSSHLogin

Below is a list of pages which are already migrated to the new wiki.

See also
* [[Wiki Relocation]]
* [[List of pages not migrated yet]]
* [[List of invalid old pages]]
* [[List of pages excluded from migration]]
* [[List of old Documentation pages]]

{| class="wikitablenowrap"
! Old page name
! Current URL
|-
| ArchVserver ||[[Installation on ArchLinux]]
|-
|Caps+and+Flags || [[Capabilities and Flags]]
|-
|ChangeLog26 || [[ChangeLog]]
|-
|Changelog26-Devel || [[ChangeLog]]
|-
|ChangeLog || [[ChangeLog]]
|-
|ChangeLogDevel26 || [[ChangeLog]]
|-
|ChangeLogDevelExperimental || [[ChangeLog]]
|-
|ChangeLogExperimental || [[ChangeLog]]
|-
|ChangeLogStableExperimental || [[ChangeLog]]
|-
|chroot-barrier || [[Secure chroot Barrier]]
|-
|Dates+and+Planning || [[News]]
|-
|Documentation || [[Documentation]]
|-
|Examples || [[Do I need Linux-VServer]]
|-
|FrequentlyAskedQuestions || [[Overview]]
|-
|GentooGuestHowto || [[Installation on Gentoo]]
|-
|GentooHostHowto || [[Installation on Gentoo]]
|-
|Hacker+Page || [[Sandbox]]
|-
|Hall+of+Fame || [[Hall of Fame]]
|-
|HistoryList || [[Special:Recentchanges]]
|-
|HowtoSSHLogin || [[SSH login]]
|-
|Linux VServer Howto || [[Installation on Gentoo]]
|-
|Linux-VServer-Paper-00 || [[Paper]]
|-
|Linux-VServer-Paper-01 || [[Paper]]
|-
|Linux-VServer-Paper-02 || [[Paper]]
|-
|Linux-VServer-Paper-03 || [[Paper]]
|-
|Linux-VServer-Paper-04 || [[Paper]]
|-
|Linux-VServer-Paper-05 || [[Paper]]
|-
|Linux-VServer-Paper-06 || [[Paper]]
|-
|Linux-VServer-Paper-07 || [[Paper]]
|-
|Linux-VServer-Paper-08 || [[Paper]]
|-
|Linux-VServer-Paper-09 || [[Paper]]
|-
|Linux-VServer-Paper-10 || [[Paper]]
|-
|Linux-VServer-Paper-11 || [[Paper]]
|-
|Linux-VServer-Paper-12 || [[Paper]]
|-
|Linux-VServer-Paper-13 || [[Paper]]
|-
|Linux-VServer-Paper-14 || [[Paper]]
|-
|Linux-VServer-Paper-15 || [[Paper]]
|-
|Linux-VServer-Paper || [[Paper]]
|-
|Linux-VServer-self-definition || [[Overview]]
|-
|Linux-VServer || [[Welcome to Linux-VServer.org]]
|-
|MediaWiki+GIT || [[Wiki Team]]
|-
|Namespaces || [[Namespaces]]
|-
|Namespaces-French || [[Namespaces/fr]]
|-
|ProblematicPrograms || [[Problematic Programs]]
|-
|ProjectOverview || [[Overview]]
|-
|RecentChanges || [[Special:Recentchanges]]
|-
|Related+Projects || [[Related Projects]]
|-
|Release+FAQ || [[Downloads]]
|-
|Resource+Limits || [[Resource Limits]]
|-
|short+presentation || [[Overview]]
|-
|Tools+and+patches || [[Downloads]]
|-
|Tools || [[Downloads]]
|-
|VirtualServer || [[Overview]]
|-
|VServerConcept || [[Overview]]
|-
|VServerConfiguration || [[VServerConfiguration]]
|-
|VServer+Hosting || [[VServer Hosting]]
|-
|Vservers+and+X || [[Vservers and X]]
|-
|WikiStat || [[Special:Allpages]]
|}

SSH login

2009-03-30T06:55:52Z

Jze: migrated from old wiki HowtoSSHLogin

==Via [[GECOS]]==
===Manual===
Virtuozzo(tm) have one very intresting feature: you can log into namebased site by SSH with only one SSH instance, runned on host.

So you have not need to have several ports for SSH access.

For VServer I have found tool, created by Alec Thomas (you can find it here: http://swapoff.org/LinuxVServer.html) that allow to do that (or close to that) on linux-vserver.

I have made small change in vslogin: it get gecos field of user, that named in environment variable LOGNAME, not via userid, so all vserver users are now have one uid - 9999 on vserver host.

There also created passwd and shadow sync daemon in perl, that update host /etc/passwd and /etc/shadow with contents of vservers' passwd and shadow.

But, better to use nss_vserver module, get info on it at [[HowtoHostAuth]]

So, to get one auth point for all users - host ssh (in general - anything, that can auth, can be authorized via PAM on host), you need to:
# install SGI::FAM and Proc::Daemon from CPAN.
# copy syncshadows daemon to /usr/local/sbin
# copy syncshadows init.d script ot /etc/init.d/ (or /etc/rc.d/init.d)
# create links to it from rcX.d directiories (/etc/rcX.d or /etc/rc.d/rcX.d/)
# Run <tt>/etc/init.d/syncshadows start</tt>
# run "make" at vslogin directory and copy vslogin binary to /sbin/
# <tt>chmod u+s /sbin/vslogin</tt>
## <tt>chmod o-rwx /sbin/vslogin; chgrp vslogin /sbin/vslogin</tt> to allow /sbin/vslogin execution only by users in group vserver. needs vslogin group, but you'll have it "automatically" if nss_vserver is configured!
# <tt>echo /sbin/vslogin >> /etc/shells</tt>
That's all! Now you can log into your vserver by run
ssh vserver-user@host
;Note: on host created stubs in form user@vserver and vserver-user for allowing to use domain form where available, and just dash form where not available.

===Download===
Download vslogin and syncshadows daemon at http://dev.call2ru.com/vserverauth.tar.gz

==Via IP==
When you SSH to a server you get an IP number. This IP number can be used to select which of the VServers you want to connect to. Of course this only works if each of the VServers have an individual IP number.

The process is as follows:
# Setup SSHD to bind to 0.0.0.0 - any IP (or rather ALL IPs)
# Replace LOGIN Script of users you want to support the above
# SSH as any user @ any host
# The login script picks up the IP number, checks for each IP in the list of running servers
# Login script then runs "enter" on the server and "su" to the valid user.
And it is logged in with a single SSH.

I am just perfecting the login script (currently about a 20 line perl script, reviewing the possible C script for better SUID support) - Scott Penrose - scottp@dd.com.au

==Security note==
Warning! Do not give user accounts on host to other users! Any user can change its own gecos field and log into any vserver by any user!

==Further information==

If you find that trying to ssh to the guest keeps logging you into the host, check the note on ssh on this page: http://linux-vserver.org/some_hints_from_john.

[[Category:HowTo]]

List of migrated pages

2009-03-30T06:48:20Z

Jze: simpler list, easier to maintain

Below is a list of pages which are already migrated to the new wiki.

See also
* [[Wiki Relocation]]
* [[List of pages not migrated yet]]
* [[List of invalid old pages]]
* [[List of pages excluded from migration]]
* [[List of old Documentation pages]]

{| class="wikitablenowrap"
! Old page name
! Current URL
|-
| ArchVserver ||[[Installation on ArchLinux]]
|-
|Caps+and+Flags || [[Capabilities and Flags]]
|-
|ChangeLog26 || [[ChangeLog]]
|-
|Changelog26-Devel || [[ChangeLog]]
|-
|ChangeLog || [[ChangeLog]]
|-
|ChangeLogDevel26 || [[ChangeLog]]
|-
|ChangeLogDevelExperimental || [[ChangeLog]]
|-
|ChangeLogExperimental || [[ChangeLog]]
|-
|ChangeLogStableExperimental || [[ChangeLog]]
|-
|chroot-barrier || [[Secure chroot Barrier]]
|-
|Dates+and+Planning || [[News]]
|-
|Documentation || [[Documentation]]
|-
|Examples || [[Do I need Linux-VServer]]
|-
|FrequentlyAskedQuestions || [[Overview]]
|-
|GentooGuestHowto || [[Installation on Gentoo]]
|-
|GentooHostHowto || [[Installation on Gentoo]]
|-
|Hacker+Page || [[Sandbox]]
|-
|Hall+of+Fame || [[Hall of Fame]]
|-
|HistoryList || [[Special:Recentchanges]]
|-
|Linux VServer Howto || [[Installation on Gentoo]]
|-
|Linux-VServer-Paper-00 || [[Paper]]
|-
|Linux-VServer-Paper-01 || [[Paper]]
|-
|Linux-VServer-Paper-02 || [[Paper]]
|-
|Linux-VServer-Paper-03 || [[Paper]]
|-
|Linux-VServer-Paper-04 || [[Paper]]
|-
|Linux-VServer-Paper-05 || [[Paper]]
|-
|Linux-VServer-Paper-06 || [[Paper]]
|-
|Linux-VServer-Paper-07 || [[Paper]]
|-
|Linux-VServer-Paper-08 || [[Paper]]
|-
|Linux-VServer-Paper-09 || [[Paper]]
|-
|Linux-VServer-Paper-10 || [[Paper]]
|-
|Linux-VServer-Paper-11 || [[Paper]]
|-
|Linux-VServer-Paper-12 || [[Paper]]
|-
|Linux-VServer-Paper-13 || [[Paper]]
|-
|Linux-VServer-Paper-14 || [[Paper]]
|-
|Linux-VServer-Paper-15 || [[Paper]]
|-
|Linux-VServer-Paper || [[Paper]]
|-
|Linux-VServer-self-definition || [[Overview]]
|-
|Linux-VServer || [[Welcome to Linux-VServer.org]]
|-
|MediaWiki+GIT || [[Wiki Team]]
|-
|Namespaces || [[Namespaces]]
|-
|Namespaces-French || [[Namespaces/fr]]
|-
|ProblematicPrograms || [[Problematic Programs]]
|-
|ProjectOverview || [[Overview]]
|-
|RecentChanges || [[Special:Recentchanges]]
|-
|Related+Projects || [[Related Projects]]
|-
|Release+FAQ || [[Downloads]]
|-
|Resource+Limits || [[Resource Limits]]
|-
|short+presentation || [[Overview]]
|-
|Tools+and+patches || [[Downloads]]
|-
|Tools || [[Downloads]]
|-
|VirtualServer || [[Overview]]
|-
|VServerConcept || [[Overview]]
|-
|VServerConfiguration || [[VServerConfiguration]]
|-
|VServer+Hosting || [[VServer Hosting]]
|-
|Vservers+and+X || [[Vservers and X]]
|-
|WikiStat || [[Special:Allpages]]
|}

List of pages not migrated yet

2009-03-30T06:41:44Z

Jze: much simpler list (easier to edit)

Installation on ArchLinux

2009-03-30T06:41:18Z

Jze: migrated from old wiki ArchVserver

WARNING: You will need knowledge of Arch Linux's pacman, abs and init system. This is not an Arch tutorial

== Overview ==

[http://archlinux.org Arch Linux] is ideal for running as the host and for VServers. What makes it ideal for the host server is its low foot print and simplicity. On the downside, Arch Linux does not include a VServer kernel or utilities. However, if you are confident building your own kernel and using ABS (the Arch Build System), it is excellent.

Arch is ideal for VServers because it is trivial to install an instance of Arch Linux into a target directory and does not require Arch on the host system.

== Building dietlibc==

First for more secure chroots and compatibility you need dietlibc
<pre>
pkgname=dietlibc
pkgver=0.29
pkgrel=1
pkgdesc="A libc that is optimized for small size"
url="http://www.fefe.de/dietlibc/"
depends=()
makedepends=()
conflicts=()
replaces=()
install=
source=(http://www.kernel.org/pub/linux/libs/dietlibc/$pkgname-$pkgver.tar.gz)
md5sums=('84059c71d6f559f8c4ca4df03a7a541f')

build()
{
mkdir -p $startdir/pkg/usr/{lib,diet,bin,man} $startdir/pkg/usr/man/man1 $startdir/pkg/opt
cd $startdir/src/$pkgname-$pkgver
make || return 1
make prefix=$startdir/pkg/usr/lib/diet install || return 1
mv $startdir/pkg/usr/lib/diet/bin/* $startdir/pkg/usr/bin
rm -r $startdir/pkg/usr/lib/diet/{man,bin}
cp diet.1 $startdir/pkg/usr/man/man1
ln -s /usr/lib/diet/ $startdir/pkg/opt/diet
find $startdir/pkg -name '*.la' -exec rm {} \;
}
</pre>

==Building beecrypt==
<pre>
pkgname=beecrypt
pkgver=4.1.2
pkgrel=1
pkgdesc="A general purpose cryptography library"
url="http://beecrypt.sourceforge.net/"
depends=('gcc')
makedepends=()
source=(http://puzzle.dl.sourceforge.net/sourceforge/beecrypt/$pkgname-$pkgver.tar.gz)
md5sums=('820d26437843ab0a6a8a5151a73a657c')

build() {
cd $startdir/src/$pkgname-$pkgver
./configure --prefix=/usr
make || return 1
make DESTDIR=$startdir/pkg install
find $startdir/pkg -name '*.la' -exec rm {} \;
}
</pre>

==Building util-vserver on the Host==
The following PKGBUILD will download, package and install util-vserver version 0.30.209. It should be only a matter of changing the version number to make it work with later versions, assuming nothing major changes in the build process. Before starting to build, make a soft link: ln -s /usr/lib/dietlibc /opt/diet - otherwise the build fails because dietlibc cannot be found.
<pre>
pkgname=util-vserver
pkgver=0.30.209
pkgrel=1
pkgdesc="The util-vserver project provides tools for kernels with the security context patch."
url="http://savannah.nongnu.org/projects/util-vserver/"
source=(http://www.13thfloor.at/~ensc/util-vserver/files/alpha/${pkgname}-${pkgver}.tar.bz2)
depends=(beecrypt perl dietlibc)
makedepends=(vconfig iproute dietlibc beecrypt iptables)
md5sums=('674b122824292c20d3c53245b91f6088')

build()
{
cd $startdir/src/$pkgname-$pkgver
./configure --prefix=/usr --sysconfdir=/etc --with-initrddir=/etc/rc.d --localstatedir=/var --enable-beecrypt --enable-dietlibc
make || return 1
make DESTDIR=$startdir/pkg install || return 1
# Move the v_* scripts out of the init dir, as Arch does not support SYSV style init scripts
install -m755 -d $startdir/pkg/usr/libexec/vserver
mv $startdir/pkg/etc/rc.d/v_* $startdir/pkg/usr/libexec/vserver
find $startdir/pkg -name '*.la' -exec rm {} \;
}
</pre>
VERY IMPORTANT! After you have installed the util-vserver package it is imperative to copy the /usr/lib/libvserver.so.0.0.0 to /lib and then create soft link, libvserver.so.0 to it, also to /lib. Otherwise you might have serious trouble with booting the system up, especially when you use drives with raid driver. (31.03.2006, current Arch with Udev). The util-vserver package must be updated to do this automatically.

Once built and installed, add vprocunhide and vservers-default to DAEMONS in <tt>/etc/rc.conf</tt>.

==Creating an Arch Linux VServer==
Download [http://www.linux-stats.org/download/archbootstrap archbootstrap] (this script will run on any GNU/Linux host system with wget), choose appropriate values for name, interface and {{context}, pick some vserver flags (or just use the ones below) then use the following shell commands to create your vserver:

''(choose a mirror close to you, as archbootstrap will download all base packages)''
<pre>
# name=test
# interface=eth0:72.36.180.187/29
# context=5
# vserver ${name} build -m skeleton --context ${context} --interface ${interface} \
--flags lock,virt_mem,virt_uptime,virt_cpu,virt_load,sched_hard,hide_netif --initstyle plain
# echo default > /etc/vservers/${name}/apps/init/mark
# archbootstrap /vservers/${name} ftp://ftp.archlinux.de/pub/archlinux
...
</pre>

If you don't have a public ip to spare for your vserver guest, then you must create guest with private ip, like 192.168.0.103 for example. Then in order to allow guest to access the Internet, you will have to set up proper NAT rule for your host's iptables. Assuming that you are using addresses like in previous example, a working NAT rule is this:
iptables -t nat -I POSTROUTING -s 192.168.0.0/24 -j SNAT --to x.x.x.x

where the last one is your host's public ip, assuming that it can access the Internet directly. You can now test if NAT rule succeeded by using this command:
iptables -t nat -L

It should display an output like this:
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
SNAT all -- 192.168.0.0/24 anywhere to:x.x.x.x

Remeber to copy /etc/resolv.conf to /vservers/${name}/etc to be able to use domain names instead of just ip addresses.

If you plan to set up servers to your guest, it would also be useful to have localhost in there. This can be achieved by creating a new folder in /etc/vservers/name/interfaces/ - name the folder 1, for example, if the previous one that exists there is 0. Then create there files named ip, dev and prefix.

To ip write 127.0.0.1, to dev write lo and to prefix write 32.

Start your vserver:
# vserver ${name} start

Check it has started
# vserver-stat

Then enter the guest (vserver name enter) and at first create iproute package (it is at <tt>/var/abs/network/iproute</tt>) - you will need it to see ip addresses and other needful information. Add the package and now to see how networking is working use this command ip addr show and try to ping the world.

That is pretty much it. You will probably want to edit <tt>/vservers/test/etc/rc.conf </tt>to remove interface configuration and set your hostname.

All the usual vserver commands should work as you would expect, but don't forget to modify host service config files so they don't bind to INADDR_ANY.

;Note: the value in <tt>/etc/vservers/${name}/apps/init/mark</tt> must be default if you wish your vservers to start at boot using the vservers-default init script.

;Note2: if on starting up a vserver the keyboard control is lost on host, remove console from /dev of vserver

Scheduler Parameters

2009-03-27T16:18:19Z

Jze: migrated from old wiki Scheduler+Parameters

Scheduler parameters <tt>/etc/vservers/<server name>/schedule</tt> should contain 6 lines:
# fill rate
# fill interval
# amount of "tokens" on start
# minimum number of tokens in token bucket
# maximum number of tokens
# dummy line

Each <fill interval> jiffies <fill rate> tokens will be put into bucket. Any tokens more than <maximum number of tokens> are spilled.

Processes will be back from "on hold" when in bucket is more than <minimum number of tokens>.
You should aim that the sum of (<fill rate> / <fill interval>) adds up to roughly the number of processors in your system. If the fill interval is too long, it might make performance erratic. Setting it as small as 1 or 2 is fine. It only actually recalculates the amount when it has to. Of course, with a fill interval of such a small value you're dishing out large chunks of the system :)

----
<romke> mugwump: so, wouldn't be better if fill interval be more like 10-20 ? and fill rate proportionally greater?

<mugwump> it makes little difference. Just don't go expecting smooth scheduling behaviour when it gets near HZ (100 or 1000)

(thx to mugwump)
----

For example:
7
32
500
200
1000
dummy

Will aim to give the context 7/32 (21.9%) of one processor. If you turned on "hard" scheduling, then if the context ran out of tokens, it would be put on hold for (200 / 7) * 32 = 928 jiffies (~1 second if HZ = 1000, ~10 seconds if HZ = 100). If you didn't turn on 'hard' scheduling, it would be run a very low priority - meaning it gets much shorter timeslices.

(Don't forget to put sched_prio or/and sched_hard flags in /etc/vservers/<vserver>/flags)

If you have set sched_prio and/or sched_hard but there is no schedule file, the following default values are used:
FillRate: 1
Interval: 4
TokensMin: 15
TokensMax: 125

(note, the default is to use pure system scheduling)

CPU and 'vsched'

2009-03-27T16:16:18Z

Jze: migrated from old wiki vsched+explained

note: all information is taken from the linux-vserver mailing list or other pages in this wiki.

The token-bucket scheduler principle is pretty well explained here: http://www.linux-vserver.org/index.php?page=Linux-VServer-Paper-06

== vscheduling a vserver==

vsched takes the following arguments:
--fill-rate
The number of tokens that will be placed in the bucket.

--interval
How often (the above specified) number of tokens will be placed.
This is in jiffies.

note:
The important factor is the ratio:
fill-rate
--------- * 100 = % CPU allocation
interval

Note that that this is the proportion of a *single* CPU in the system. So, if you have four CPUs and you want one context to get an average of one whole CPU to itself, then you'd set fill-rate to 1 and interval to 4.
It is advantageous to smooth operation of the algorithm to make the interval as small as possible (or much smaller than the bucket size). You can in most cases simplify the fraction, such as changing --fill-rate=30 and interval=100 to fill-rate=3 and --interval=10.

For simple cases, like evenly distributing cpu time between vservers, you probably just want to set the ratio to somewhere between 1/N (where N is the number of servers) and 1/P (where P is the maximum expected peak load per CPU), and not bother with hard scheduling. Process count ulimits will put an upper bound on possible abuse by a context.

--tokens
The bucket starts out with this many tokens. Tokens_max takes
precedence here, so it cannot be higher than tokens_max.

--tokens_min
When a bucket is empty, the context is on hold _until_ at least
this many tokens are in the bucket.

--tokens_max
The size of the bucket. When tokens aren't being used, the bucket
will be getting fuller and fuller, but up to this value. So in effect
this is your CPU burst parameter.

--cpu_mask
This is obsolete, but I've found the current vsched is a little
picky and will segfault if you omit parameters, so I always
specified 0 here.

According to the VServer paper, "At each timer tick, a running process consumes exactly one token from the bucket". Here running means actually needing the CPU as opposed to "running" as in "existing". Most processes are not running most of the time, e.g. an httpd waiting on a socket isn't running, even though ps would list it.

To put it another way, processes can have various states:
* R (runnable),
* S (sleeping)
* T,Z,D ... (see man ps(1))
and processes in 'R' state can be scheduled (running) or not scheduled (waiting to be run) those which are scheduled (i.e. running on a cpu) will consume one token for every tick ...

A token is quite a bit of CPU time - the ticks (or jiffies for now) are generated at a (usually) constant intervall called HZ which was 100 for 2.4 and typically is 1000 for 2.6 so you can assume to get a tick every 1ms (or 1000 ticks each second)

Here are some guidelines. All this is very much unscientific and without a lot of testing and theory behind, so if someone has better guidelines, please pitch in. [(again, not sure if this is CPU speed dependent - tests were on a 2.8GHz Xeon). Typing "python" on the command line (which is a huge operation IMHO) consumes 17 tokens in my tests. Having 100000 tokens in your bucket is probably sufficient for a medium size compile job.]
When trying to come up with a good setting in my environment (basically hosting), I was looking for values that would not cripple the snappiness of the server, but prevent people from being stupid (e.g. cat /dev/zero | bzip2 | bzip2 | bzip2 > /dev/null).

To achieve this, it is important that contexts that are being CPU hogs are penalised fairly quickly...
As the tokens in the bucket deplete, the "nice" value of the contexts is adjusted - they lose their vavavoom. As this happens, the processes get shorter and shorter timeslices. Other, more deserving processes will get longer timeslices and hence more CPU time.

Additionally, bear in mind that individual processes also get a minor nice boost or penalty, depending on whether those processes have been CPU hogs recently or not. This is diminished in vserver kernels compared to standard kernels, but should still have sufficient effect to counter extreme conditions.

The fill interval should be short enough to not be noticeable, so something like 100 jiffies. The fill rate should be relatively small, something like 30 tokens. Tokens_min seems like it should simply equal to the fill rate. The tokens_max should be generous so that people can do short cpu-intensive things when the need them, so something like 10000 tokens.

From the experimentation I did, I'd say 10,000 tokens is quite large - 10 seconds of real CPU time. Compare this with the default value of 500. If you've given a context 30% of the CPU as described above, then that actually means about 10-15 wall clock seconds of CPU hogging before the context gets appreciably penalised. For the algorithm to work best, I think you would want to reduce this to about 1-2 seconds' worth of jiffies.
You are right in saying that tokens_max is the "burst" CPU rate, so setting it to a large value like 10000, while setting the interval to a large value like 100, would indicate that you are optimising your system for batch scheduling (long time slices, higher overall throughput), not interactive use (short time slices, reduced throughput). My guess is that min_tokens (not in my original implementation) is a batch optimisation as well, but perhaps small values (~10) are useful to avoid excessive context switching.

But then, I didn't really experiment with the hard scheduling side of things, so maybe if you are hard scheduling it is more important to make sure that the buckets don't normally run out.

Of course just because I wrote the original algorithm does not by any means lend much extra weight to my opinion on how to use it, and I invite others to respond with their experience.

You can see current token stats by looking at <tt>/proc/virtual/<xid>/sched</tt> on the mother server.

==vscheduling an application inside a vserver==
You can also use vsched to pace any cpu intensive command, e.g.:
vcontext --create -- \
vsched --fill-rate 30 \
--interval 100 \
--tokens 100 \
--tokens_min 30 \
--tokens_max 200 \
--cpu_mask 0 -- /bin/my_cpu_hog

however, this is dependent upon the hard scheduler actually being enabled. If either the minimum is not reached yet, or the context is paused (a special flag) then the process will enter the new 'H' (on hold) state which doesn't allow it to do anything until the minfill has been reached again ...

While playing with this stuff I've run into situations where a context has no tokens left, at which point you cannot even kill the processes in it. Don't panic - you can always reenter the context and call vsched with new parameters.

So the pacing example should really be:
vcontext --create -- \
vsched --fill-rate 30 \
--interval 100 \
--tokens 100 \
--tokens_min 30 \
--tokens_max 200 \
--cpu_mask 0 -- \
vattribute --flag sched_hard -- /bin/my_cpu_hog
A load of 30 is not a real problem (in terms of CPU, anyway), if those processes have such a low priority that everything else on the system is pretty much real time. What you are seeing is probably just due to the context not getting enough penalisation by the time the load hits 30, or some secondary effect like disk load or memory exhaustion. Try it with a smaller bucket size.

When a context goes on hold with runnable processes, those processes might not contribute to the visible load factor, but they could be said to still be runnable. So all you're doing is hiding the problem and underutilising your CPUs.

Having said that, because the cpu scheduler tries to avoid process starvation (where a process gets no CPU at all), then if a context has a *lot* of processes then it will `exploit' the anti-starvation code into getting more CPU than allocated, without hard scheduling. To give you an indication, this is around the number of minimum time slices (MIN_TIMESLICE, 5ms) than fit into the starvation limit (MAX_SLEEP_AVG, 2.5s) - ie, a per-second CPU load of 500.

Turning on the hard scheduling means letting processes starve. If you're happy to let processes starve then you can make the scheduler perform better in other ways - that is a classic trade-off in CPU scheduling.

----
Heh. I don't know if this is current behaviour or not, but I think the signals should really queue and the context will close as soon as the processes wake up and receive enough cycles to process them and exit. Sending -KILL signals would clean it up pretty quickly (as soon as enough tokens are allocated for the processes to run), as chances are they won't consume any tokens to receive a KILL signal. Though, it would be nice if they didn't need tokens allocated to be stopped via KILL.
----

== Links ==
* http://list.linux-vserver.org/archive/vserver/msg08134.html - and the rest of the thread
* [[Scheduler Parameters]]
* [[Paper]]

Linux-VServer:Visual Aids

2009-03-27T16:09:58Z

Jze: migrated from old wiki VisualAids

No this is not about yet another anti-AIDS campaign, this is about creating things that are nice too look at and that can help explain to somebody what VServer does.

I (Milf) made one slide at Linuxtag 2006 (actually I wanted to make more, but so much to do at a tradeshow: drink Jolt cola, talk to people, grab agoogle-pen each hour ...)

So here it is: [http://www.ipsi.fraunhofer.de/~mikeschneider/Vserver/VergleichEmulation.pdf Comparison of emulation techniques (pdf)] [http://www.ipsi.fraunhofer.de/~mikeschneider/Vserver/VergleichEmulation.fig xfig-source].

What else do we need to explain in pictures or graphs?
* the different jails that make up a VServer: chroot, chbind, chcontext
* how these jails combine to create an impenetrable capsule
* benchmarks that show the little overhead compared to unpatched kernel and compared to VMware et al.
* feature-comparison between, for example, vServer versions, different virtualisation-solutions and so on (BenBen?)
* Roadmap (BenBen?)
* handy handout which can be printed as dinA0 or something (has anyone connections to get some cheap print-stuff?) (BenBen?)
* that we are not a subset of anything :)

Loop Device

2009-03-27T16:04:53Z

Jze: migrated from old wiki HowtoGuestLoopDevice

This mini HOWTO explains how to set up loopback devices inside a virtual server. With some work you will be able to mount loop-AES based cryptoloops too. To repeat the steps described here, you're going to fulfill some prerequisites.

==Prerequisites==
* root-access on the host-machine
* The kernel 2.6.16 (or newer) kernel source
* The 2.1.1-rc14 (or newer) vserver-patch
* If you intend to use loop-AES: loop-AES-v3.1c or newer
* some patches, see below

'''Note:''' Please keep in mind that you will need, as of the time I write this, some patches to get this working. If you are using newer vserver-patches than 2.1.1-rc14 and/or a newer kernel than 2.6.16 chances are, you don't need some of them.

== Security ==
Keep in mind that doing the changes described later weaken the security of your server. Don't use it on guest hosts you don't trust. If you intend to use loop-AES note that root on the host-machine will still be able to read your crypted filesystem if its mounted.

== Setting up the host environment ==
I expect here, you know how to set up a running linux vserver environment. If not, consult other manuals and HOWTO's. Just patch and configure your vserver kernel as usual. Ensure that you chose to activate loopback devices (CONFIG_BLK_DEV_LOOP). If you plan to use loop-AES deactivate CONFIG_BLK_DEV_LOOP, or build it as module. Therefore you'll need some additional patches to get this feature running inside vserver guests. Depending on your configuration you have to use more or less additional patches. Just answer the following questions:

=== Do you use kernel 2.6.16 or older ===
Yes: Apply this patch: http://lkml.org/lkml/2006/3/24/370

=== Do you use vserver 2.1.1-rc14 or older? ===
Yes: Apply this patches:
<pre>
diff -NurpP linux-2.6.16-vs2.1.1-rc14.3/kernel/fork.c linux-2.6.16-vs2.1.1-rc14.4/kernel/fork.c
--- linux-2.6.16-vs2.1.1-rc14.3/kernel/fork.c 2006-03-20 18:09:05 +0100
+++ linux-2.6.16-vs2.1.1-rc14.4/kernel/fork.c 2006-03-25 02:22:55 +0100
@@ -1348,6 +1348,7 @@ long do_fork(unsigned long clone_flags,
if ((clone_flags & CLONE_KTHREAD) && !vx_check(0, VX_ADMIN)) {
vxwprintk(1, "xid=%d tried to spawn a kernel thread.",
vx_current_xid());
+ free_pidmap(pid);
return -EPERM;
}
</pre>
and
<pre>
diff -NurpP --minimal linux-2.6.16-vs2.1.1-rc14.1/drivers/block/loop.c linux-2.6.16-vs2.1.1-rc14.2/drivers/block/loop.c
--- linux-2.6.16-vs2.1.1-rc14.1/drivers/block/loop.c 2006-03-20 17:32:31 +0100
+++ linux-2.6.16-vs2.1.1-rc14.2/drivers/block/loop.c 2006-03-24 03:37:07 +0100
@@ -943,7 +943,7 @@ loop_set_status(struct loop_device *lo,
struct loop_func_table *xfer;

if (lo->lo_encrypt_key_size && lo->lo_key_owner != current->uid &&
- !capable(CAP_SYS_ADMIN))
+ !capable(CAP_SYS_ADMIN) && !vx_ccaps(VXC_CRYPTO_LOOP))
return -EPERM;
if (lo->lo_state != Lo_bound)
return -ENXIO;
@@ -1023,7 +1023,8 @@ loop_get_status(struct loop_device *lo,
memcpy(info->lo_crypt_name, lo->lo_crypt_name, LO_NAME_SIZE);
info->lo_encrypt_type =
lo->lo_encryption ? lo->lo_encryption->number : 0;
- if (lo->lo_encrypt_key_size && capable(CAP_SYS_ADMIN)) {
+ if (lo->lo_encrypt_key_size &&
+ (capable(CAP_SYS_ADMIN) || vx_ccaps(VXC_CRYPTO_LOOP))) {
info->lo_encrypt_key_size = lo->lo_encrypt_key_size;
memcpy(info->lo_encrypt_key, lo->lo_encrypt_key,
lo->lo_encrypt_key_size);
diff -NurpP --minimal linux-2.6.16-vs2.1.1-rc14.1/include/linux/vserver/context.h linux-2.6.16-vs2.1.1-rc14.2/include/linux/vserver/context.h
--- linux-2.6.16-vs2.1.1-rc14.1/include/linux/vserver/context.h 2006-03-20 18:09:05 +0100
+++ linux-2.6.16-vs2.1.1-rc14.2/include/linux/vserver/context.h 2006-03-24 03:35:26 +0100
@@ -76,6 +76,7 @@
#define VXC_BINARY_MOUNT 0x00040000

#define VXC_QUOTA_CTL 0x00100000
+#define VXC_CRYPTO_LOOP 0x00200000

/* context state changes */
</pre>
Once this patches are commited to your kernel source, (re)compile and boot it.

=== change capabilities files ===
You have to make some changes in the capabilities files too. If they don't exist already, just create them. Usually they can be found under <tt>/etc/vservers/<guest name>/bcapabilities</tt> and <tt>/etc/vservers/<guest name>/ccapabilities. </tt>
==== ccapabilities ====
^21
secure_mount
secure_remount

^21 is VXC_CRYPTO_LOOP, but as of version 0.30.210 the util-vserver don't recognize this flag (yet).

==== bcapabilities ====
CAP_IPC_LOCK

== Building loop-AES ==
If you plan to use loop-AES you have to apply an additional patch. Since loop-AES replaces the kernels loopback device you have to tell loop-AES about the changes in your vserver kernel. It's a quite simple patch, apply it to your loop-AES source.

<pre>
diff -ruN loop-AES-v3.1c-orig/loop.c-2.6.patched loop-AES-v3.1c/loop.c-2.6.patched
--- loop-AES-v3.1c-orig/loop.c-2.6.patched 2006-01-12 19:22:48.000000000 +0100
+++ loop-AES-v3.1c/loop.c-2.6.patched 2006-03-25 03:09:59.000000000 +0100
@@ -102,6 +102,8 @@
#endif

#include <asm/uaccess.h>
+#include <linux/vserver/context.h>
+#include <linux/vs_context.h>

#if !defined(LO_FLAGS_DO_BMAP)
# define LO_FLAGS_DO_BMAP 0x20000
@@ -1267,6 +1269,7 @@
struct file *file;
struct inode *inode;
struct block_device *lo_device = NULL;
+ struct vx_info_save vxis;
int lo_flags = 0;
int error;

@@ -1412,7 +1415,9 @@

loop_set_softblksz(lo, bdev);

+ __enter_vx_admin(&vxis);
error = kernel_thread(loop_thread, lo, CLONE_KERNEL);
+ __leave_vx_admin(&vxis);
if(error < 0)
goto out_mapping;
wait_for_completion(&LDE_lo_done);
@@ -1527,7 +1532,7 @@
struct loop_func_table *xfer = NULL;

if (lo->lo_encrypt_key_size && lo->lo_key_owner != current->uid &&
- !capable(CAP_SYS_ADMIN))
+ !capable(CAP_SYS_ADMIN) && !vx_ccaps(VXC_CRYPTO_LOOP))
return -EPERM;
if ((unsigned int) info->lo_encrypt_key_size > LO_KEY_SIZE)
return -EINVAL;
@@ -1607,7 +1612,8 @@
memcpy(info->lo_file_name, lo->lo_file_name, LO_NAME_SIZE);
memcpy(info->lo_crypt_name, lo->lo_crypt_name, LO_NAME_SIZE);
info->lo_encrypt_type = lo->lo_encryption ? lo->lo_encryption->number : 0;
- if (lo->lo_encrypt_key_size && capable(CAP_SYS_ADMIN)) {
+ if (lo->lo_encrypt_key_size &&
+ (capable(CAP_SYS_ADMIN) || vx_ccaps(VXC_CRYPTO_LOOP))) {
info->lo_encrypt_key_size = lo->lo_encrypt_key_size;
memcpy(info->lo_encrypt_key, lo->lo_encrypt_key,
lo->lo_encrypt_key_size);
</pre>

Once done, just (re)compile loop-AES with <tt>make clean && make</tt>. You should now be able to load the loop-AES module. Simply type modprobe loop. If you want to do make tests ensure, you have installed the patched aes utils on your host system.

==Setting up the guest environment==
You have to create some devices on your guest host, namely /dev/loop* and, if you set-up loop-AES even /dev/zero} and {{/dev/null. If /dev/loop0 to /dev/loop7 does not already exist on your host, just create them with
mknod -m 600 /dev/loop0 b 7 0
mknod -m 600 /dev/loop0 b 7 0
mknod -m 600 /dev/loop1 b 7 1
mknod -m 600 /dev/loop2 b 7 2
mknod -m 600 /dev/loop3 b 7 3
mknod -m 600 /dev/loop4 b 7 4
mknod -m 600 /dev/loop5 b 7 5
mknod -m 600 /dev/loop5 b 7 6
mknod -m 600 /dev/loop6 b 7 6
mknod -m 600 /dev/loop7 b 7 7

then copy all the necessary devices to your guest system:
cp -a /dev/null /dev/zero /dev/loop* /path/to/your/vhost/images/dev

You're now done in the host system. Change to your guest image, e.g. with vserver imagename enter.

Using loop-AES you'll now need to install the loop-aes-utils on your guest system. Check your distributions packages for prebuilt images. On Debian use
apt-get install loop-aes-utils

== Setting up a simple loopback ==
Follow the usual steps. Note, that you have to be logged in as root user (the example will create a 5M loopback):
dd if=/dev/zero of=/container bs=1024 count=5120
mkfs.ext2 /container
mount -t ext2 -o ro,loop=/dev/loop0 container /mnt/

== Setting up a loop-AES loopback ==
Even loop-AES is not different from a generic set up. Ensure, you are logged in as root
dd if=/dev/zero of=/container bs=1024 count=5120
losetup -e AES128 /dev/loop0 /container
mkfs -t ext2 /dev/loop0
losetup -d /dev/loop0
mount -t ext2 -o loop=/dev/loop0,encryption=AES128 /container /mnt/

== Using loopback devices on multiple guests ==
Keep in mind, that you can't use the same loopback device twice or more. Therefore your guests will be unable to mount any content to /dev/loopX if this device is already mounted in any other context, including the host filesystem. If you have multiple guests it might be a good idea assigning them just one device, not all, so guests can block only one. Without any furhter work you can use up to 8 devices, the driver supports up to 255 though.

[[Category:HowTo]]

Networking vserver guests

2009-03-27T15:59:04Z

Jze: category

Setting up network access to and from your vserver guests.
__TOC__
==Introduction==

Lets imagine, you have only one external IP -- <code>$EXTIP</code>.

You want to have several vservers running without worrying about port overlapping.

Example:

Two vservers run a default webserver, running on port 80. If each "guest" vserver shares an IP with the host, then the two webservers will conflict.

One solution is:

* All vservers are contained in a "virtual lan", say 192.168.1.x
* Each vserver has its own IP
* Control port forwarding on "parent" host. That is, run a router.

==Configuration==
===Host===
Set up <code>dummy0</code> interface on the parent host
# /etc/network/interfaces on a Debian box,
# configure on other distros with your preferred way
auto dummy0
iface dummy0 inet static
address 192.168.1.250
netmask 255.255.255.0

===Guests===
Set up each guest vserver:
cd /etc/vservers/$VSERVER/interfaces/0
echo dummy0 > dev
echo 192.168.1.1 > ip
echo 1 > name
echo 24 > prefix
Consider using a value of <code>name</code> equal to the last digit of the IP for easy separation.

===Host as router===
Configure the host to act as a router.

For internal packets going outside, pretend each packet came from our external IP (put it in one line without backslash):
# iptables -t nat -A POSTROUTING -s 192.168.1.0/24 \
-d ! 192.168.1.0/24 -j SNAT --to-source $EXTIP
For each service that runs on a vserver, map it to an external port. Vserver local address <code>$VHOST</code> and port <code>$INTPORT</code> you select one external port <code>$EXTPORT</code> and run the following (put it in one line without backslash):
# iptables -t nat -A PREROUTING -s ! 192.168.1.0/24 \
-m tcp -p tcp --dport $EXTPORT
-j DNAT --to-destination $VHOST:$INTPORT
That's all!

==Verifying==
Try <code>ping pool.ntp.org</code> from your vserver -- it should ping fine.

Try to connect to your <code>$EXTIP:$EXTPORT</code> (from another external host) -- you will successfully connect to service running on a guest vserver.
==See also==
* [[Frequently_Asked_Questions#If_my_host_has_only_one_a_single_public_IP.2C_can_I_use_RFC1918_IP_.28e.g._192.168.foo.bar.29_for_the_guest_vservers.3F |FAQ on private networking]]
* [[Frequently_Asked_Questions#When_I_try_to_ssh_to_the_guest.2C_I_log_into_the_host.2C_even_if_I_installed_sshd_on_the_guest._What.27s_wrong_here.3F |Permit guest sshd to bind to its IP address's port 22]]
* [[Networking_vserver_guests_RHEL|Networking_vserver_guests_RHEL]]

[[Category:HowTo]]
[[Category:Network]]

Howto HostAuth

2009-03-27T15:58:42Z

Jze: category

== What is this? ==

nss_vserver is a nss authentication module for linux-vserver powered systems which allows processes running on the host (sshd, getty) to authenticate users that exist on guests.

The module should almost transparently drop in to a modern Linux system: PAM would call its pam_unix module, which would in turn look through the nss modules to complete the process.

If you want to complete the guest login process, you should also get a modified version of vslogin linked to below. vslogin will pick up after authentication and deliver the user to a shell on his guest.

Note that with nss_vserver you don't need the syncshadows included in the vserverauth tarball.

== Why would I use it? ==

Using nss_vserver and vslogin you could run a single instance of sshd on the host. This host-based server would verify the credentials of a user on a guest and then vslogin would take care of presenting the user a guest-based shell.

== Installation Instructions ==

1. Get the appropriate version. On x86 versions you need to use the pthread version, on amd64 (and possible x86_64) you need the cthreads version (listed as nss_vserver_64). Also, on amd64 it's in /lib/, not in /lib/tls/.

2. On linux, just run
make install

3. After, try to run
make test
To see if it works.

== How to remove it from system? ==

Just run

make uninstall

== Use with vslogin ==

After you have installed module, (and have vslogin copied to /sbin/ and suid-root) you are ready: try to login into a guest, say one named "test" with user "user", by loggin in into the host with username "test-user" or "user@test." You should find yourself logged into the guest.

Note: vslogin requires vservers root too be at /vservers, so make it as symlink to your location. For example, for debian systems need to do
ln -s var/lib/vservers /vservers

== Caveats ==

=== Security ===
WARNING! If you have installed vslogin, NEVER give shell access to your host to users -- any user on host, who able to execute programs and modify environment will be able to log into guests as anybody he wants!

=== Usernames and guest names with dashes ===

Avoid using usernames or guest names with dashes.

The current version only tries one configuration while searching for the user in guest databases, which can cause problems:

* User "user" on guest "ser-ver" when written as "user@ser-ver" will work fine, while "ser-ver-user" will be threated as user "ver-user" on vserver "ser".
* User "us-er" on guest "server" when written as "guest-us-er" will work fine, while "us-er@guest" will be threated as user "er@guest" on vserver "us".

If you must have dashes, use the syncshadows method instead.

== Download links ==

nss_vserver: http://dev.call2ru.com/vs/nss_vserver.tar.bz2

nss_vserver_64 (for use on 64bit systems): http://dev.call2ru.com/vs/nss_vserver_64.tar.bz2

modified vslogin: http://dev.call2ru.com/vs/vserverauth.tar.gz

== Authors and copyright ==

nss_vserver was written by Anton Fedorov <datacompboy@call2ru.com> 19 march 2006 and is public domain; feel free to use it as you want.

vslogin was written by Alec Thomas (http://swapoff.org/LinuxVServer)

== Troubleshooting ==

vslogin:chroot: No such file or directory
indicates that vslogin can't access the vserver set in the GECOS field (i.e. you possibly have a typo in the GECOS field).

[[Category:HowTo]]

List of pages not migrated yet

2009-03-27T13:48:25Z

Jze:

Below is a list of pages which are either not yet migrated or have not yet been invalidated or excluded from migration.

If you think a page listed in here has already been migrated or should be excluded please contact our [[Wiki Team]].

See also
* [[Wiki Relocation]]
* [[List of migrated pages]]
* [[List of invalid old pages]]
* [[List of pages excluded from migration]]
* [[List of old Documentation pages]]

{| class="wikitablenowrap"
! Old page name
! Current URL
|-
! advanced+DRBD+mount+issues
| http://oldwiki.linux-vserver.org/advanced+DRBD+mount+issues
|-
! alpha+util-vserver
| http://oldwiki.linux-vserver.org/alpha+util-vserver
|-
! ArchVserver
| http://oldwiki.linux-vserver.org/ArchVserver
|-
! BeginnerFAQ
| http://oldwiki.linux-vserver.org/BeginnerFAQ
|-
! BeginnerHowTo
| http://oldwiki.linux-vserver.org/BeginnerHowTo
|-
! breve-presentacion
| http://oldwiki.linux-vserver.org/breve-presentacion
|-
! Cacti+configuration
| http://oldwiki.linux-vserver.org/Cacti+configuration
|-
! CentOS_HowTo
| http://oldwiki.linux-vserver.org/CentOS_HowTo
|-
! CentOS_min_install
| http://oldwiki.linux-vserver.org/CentOS_min_install
|-
! chroot-barrier-French
| http://oldwiki.linux-vserver.org/chroot-barrier-French
|-
! CommonProblems
| http://oldwiki.linux-vserver.org/CommonProblems
|-
! ConfigConverters
| http://oldwiki.linux-vserver.org/ConfigConverters
|-
! DebianVserver
| http://oldwiki.linux-vserver.org/DebianVserver
|-
! DebianVserverVirtualHosting
| http://oldwiki.linux-vserver.org/DebianVserverVirtualHosting
|-
! DemoBrainStorming
| http://oldwiki.linux-vserver.org/DemoBrainStorming
|-
! Disk+Limits
| http://oldwiki.linux-vserver.org/Disk+Limits
|-
! Distribution+specific+stuff
| http://oldwiki.linux-vserver.org/Distribution+specific+stuff
|-
! distro_hints
| http://oldwiki.linux-vserver.org/distro_hints
|-
! FC3_min_install
| http://oldwiki.linux-vserver.org/FC3_min_install
|-
! FC4+patched+rpm%27s
| http://oldwiki.linux-vserver.org/FC4+patched+rpm%27s
|-
! Fedora2Vserver
| http://oldwiki.linux-vserver.org/Fedora2Vserver
|-
! FedoraCore3_HowTo
| http://oldwiki.linux-vserver.org/FedoraCore3_HowTo
|-
! FedoraHowTo
| http://oldwiki.linux-vserver.org/FedoraHowTo
|-
! FedoraHowToFrench
| http://oldwiki.linux-vserver.org/FedoraHowToFrench
|-
! Gathered+Ideas
| http://oldwiki.linux-vserver.org/Gathered+Ideas
|-
! GettingStarted
| http://oldwiki.linux-vserver.org/GettingStarted
|-
! grsecurityHowto
| http://oldwiki.linux-vserver.org/grsecurityHowto
|-
! HowTo+Read+ProcFS
| http://oldwiki.linux-vserver.org/HowTo+Read+ProcFS
|-
! HowTo+Read+ProcFS-French
| http://oldwiki.linux-vserver.org/HowTo+Read+ProcFS-French
|-
! HowtoCloneVserver
| http://oldwiki.linux-vserver.org/HowtoCloneVserver
|-
! HowtoGuestLoopDevice
| http://oldwiki.linux-vserver.org/HowtoGuestLoopDevice
|-
! HowtoHostAuth
| http://oldwiki.linux-vserver.org/HowtoHostAuth
|-
! HowtoPrivateNetworking
| http://oldwiki.linux-vserver.org/HowtoPrivateNetworking
|-
! HowToRegisterNewDistributions
| http://oldwiki.linux-vserver.org/HowToRegisterNewDistributions
|-
! HowtoSSHLogin
| http://oldwiki.linux-vserver.org/HowtoSSHLogin
|-
! initscript-default-debian
| http://oldwiki.linux-vserver.org/initscript-default-debian
|-
! InitStyles
| http://oldwiki.linux-vserver.org/InitStyles
|-
! IpCopInAvserver
| http://oldwiki.linux-vserver.org/IpCopInAvserver
|-
! IPv6
| http://oldwiki.linux-vserver.org/IPv6
|-
! IrcQuestions
| http://oldwiki.linux-vserver.org/IrcQuestions
|-
! Kernel-Knowledge
| http://oldwiki.linux-vserver.org/Kernel-Knowledge
|-
! KernelHowto
| http://oldwiki.linux-vserver.org/KernelHowto
|-
! KernelHowto-French
| http://oldwiki.linux-vserver.org/KernelHowto-French
|-
! Legacy-To-Newstyle-Config
| http://oldwiki.linux-vserver.org/Legacy-To-Newstyle-Config
|-
! Linux-Vserver+FAQ
| http://oldwiki.linux-vserver.org/Linux-Vserver+FAQ
|-
! Linux-Vserver+FAQ-French
| http://oldwiki.linux-vserver.org/Linux-Vserver+FAQ-French
|-
! Linux-VServer-Paper-00-French
| http://oldwiki.linux-vserver.org/Linux-VServer-Paper-00-French
|-
! Linux-VServer-Paper-01-French
| http://oldwiki.linux-vserver.org/Linux-VServer-Paper-01-French
|-
! Linux-VServer-Paper-02-French
| http://oldwiki.linux-vserver.org/Linux-VServer-Paper-02-French
|-
! Linux-VServer-Paper-03-espaniol
| http://oldwiki.linux-vserver.org/Linux-VServer-Paper-03-espaniol
|-
! Linux-VServer-Paper-03-French
| http://oldwiki.linux-vserver.org/Linux-VServer-Paper-03-French
|-
! Linux-VServer-Paper-04-French
| http://oldwiki.linux-vserver.org/Linux-VServer-Paper-04-French
|-
! Linux-VServer-Paper-05-French
| http://oldwiki.linux-vserver.org/Linux-VServer-Paper-05-French
|-
! Linux-VServer-Paper-06-French
| http://oldwiki.linux-vserver.org/Linux-VServer-Paper-06-French
|-
! Linux-VServer-Paper-07-French
| http://oldwiki.linux-vserver.org/Linux-VServer-Paper-07-French
|-
! Linux-VServer-Paper-08-French
| http://oldwiki.linux-vserver.org/Linux-VServer-Paper-08-French
|-
! Linux-VServer-Paper-09-French
| http://oldwiki.linux-vserver.org/Linux-VServer-Paper-09-French
|-
! Linux-VServer-Paper-10-French
| http://oldwiki.linux-vserver.org/Linux-VServer-Paper-10-French
|-
! Linux-VServer-Paper-11-French
| http://oldwiki.linux-vserver.org/Linux-VServer-Paper-11-French
|-
! Linux-VServer-Paper-12-French
| http://oldwiki.linux-vserver.org/Linux-VServer-Paper-12-French
|-
! Linux-VServer-Paper-13-French
| http://oldwiki.linux-vserver.org/Linux-VServer-Paper-13-French
|-
! Linux-VServer-Paper-14-French
| http://oldwiki.linux-vserver.org/Linux-VServer-Paper-14-French
|-
! Linux-VServer-Paper-15-French
| http://oldwiki.linux-vserver.org/Linux-VServer-Paper-15-French
|-
! Linux-VServer-Paper-French
| http://oldwiki.linux-vserver.org/Linux-VServer-Paper-French
|-
! linux-vserver_administrators_gide
| http://oldwiki.linux-vserver.org/linux-vserver_administrators_gide
|-
! linux-vserver_administrators_guide
| http://oldwiki.linux-vserver.org/linux-vserver_administrators_guide
|-
! Memory+Allocation
| http://oldwiki.linux-vserver.org/Memory+Allocation
|-
! Memory+Management
| http://oldwiki.linux-vserver.org/Memory+Management
|-
! MoreUbuntu
| http://oldwiki.linux-vserver.org/MoreUbuntu
|-
! New-Howto
| http://oldwiki.linux-vserver.org/New-Howto
|-
! NFS+and+portmap
| http://oldwiki.linux-vserver.org/NFS+and+portmap
|-
! OpenVPN
| http://oldwiki.linux-vserver.org/OpenVPN
|-
! OpenwallHowto
| http://oldwiki.linux-vserver.org/OpenwallHowto
|-
! PartsList
| http://oldwiki.linux-vserver.org/PartsList
|-
! Per+Context+Quota
| http://oldwiki.linux-vserver.org/Per+Context+Quota
|-
! ProblematicPrograms-French
| http://oldwiki.linux-vserver.org/ProblematicPrograms-French
|-
! Quota+and+Disk+Limits
| http://oldwiki.linux-vserver.org/Quota+and+Disk+Limits
|-
! Recipes
| http://oldwiki.linux-vserver.org/Recipes
|-
! Release+FAQ-French
| http://oldwiki.linux-vserver.org/Release+FAQ-French
|-
! Remote+Server+Repartitioning
| http://oldwiki.linux-vserver.org/Remote+Server+Repartitioning
|-
! Scheduler
| http://oldwiki.linux-vserver.org/Scheduler
|-
! Scheduler+Parameters
| http://oldwiki.linux-vserver.org/Scheduler+Parameters
|-
! Security
| http://oldwiki.linux-vserver.org/Security
|-
! short+presentation-French
| http://oldwiki.linux-vserver.org/short+presentation-French
|-
! SlackwareVserverHowto
| http://oldwiki.linux-vserver.org/SlackwareVserverHowto
|-
! Snapshots
| http://oldwiki.linux-vserver.org/Snapshots
|-
! some_hints_from_john
| http://oldwiki.linux-vserver.org/some_hints_from_john
|-
! sparc64
| http://oldwiki.linux-vserver.org/sparc64
|-
! Standard+non-shared+quota
| http://oldwiki.linux-vserver.org/Standard+non-shared+quota
|-
! Step-by-Step+Guide
| http://oldwiki.linux-vserver.org/Step-by-Step+Guide
|-
! Step-by-Step+Guide+2.6
| http://oldwiki.linux-vserver.org/Step-by-Step+Guide+2.6
|-
! SuseVserverHowTo
| http://oldwiki.linux-vserver.org/SuseVserverHowTo
|-
! Syscall+Switch+Info
| http://oldwiki.linux-vserver.org/Syscall+Switch+Info
|-
! TestScripts
| http://oldwiki.linux-vserver.org/TestScripts
|-
! TestWorkingPrograms
| http://oldwiki.linux-vserver.org/TestWorkingPrograms
|-
! ttyHowto
| http://oldwiki.linux-vserver.org/ttyHowto
|-
! UbuntuVserverHowTo
| http://oldwiki.linux-vserver.org/UbuntuVserverHowTo
|-
! Util-VServer+for+RH9
| http://oldwiki.linux-vserver.org/Util-VServer+for+RH9
|-
! util-vserver+on+sarge
| http://oldwiki.linux-vserver.org/util-vserver+on+sarge
|-
! Virtual+Context+Separation
| http://oldwiki.linux-vserver.org/Virtual+Context+Separation
|-
! Virtual+Init+Task
| http://oldwiki.linux-vserver.org/Virtual+Init+Task
|-
! VirtualiseNTP
| http://oldwiki.linux-vserver.org/VirtualiseNTP
|-
! VirtualizeHowto
| http://oldwiki.linux-vserver.org/VirtualizeHowto
|-
! VisualAids
| http://oldwiki.linux-vserver.org/VisualAids
|-
! vsched+explained
| http://oldwiki.linux-vserver.org/vsched+explained
|-
! Vserver+Completion
| http://oldwiki.linux-vserver.org/Vserver+Completion
|-
! Vserver+DRBD
| http://oldwiki.linux-vserver.org/Vserver+DRBD
|-
! VServer+installation+Fedora+Core+4
| http://oldwiki.linux-vserver.org/VServer+installation+Fedora+Core+4
|-
! VServer+installation+Fedora+Core+5
| http://oldwiki.linux-vserver.org/VServer+installation+Fedora+Core+5
|-
! vserver-autostart
| http://oldwiki.linux-vserver.org/vserver-autostart
|-
! VServerBook
| http://oldwiki.linux-vserver.org/VServerBook
|-
! VserverDocumentationProject
| http://oldwiki.linux-vserver.org/VserverDocumentationProject
|-
! VServerKernelInstall
| http://oldwiki.linux-vserver.org/VServerKernelInstall
|-
! VServerManual
| http://oldwiki.linux-vserver.org/VServerManual
|-
! VServerUtilitiesInstall
| http://oldwiki.linux-vserver.org/VServerUtilitiesInstall
|-
! VSkel
| http://oldwiki.linux-vserver.org/VSkel
|-
! VSkel-French
| http://oldwiki.linux-vserver.org/VSkel-French
|-
! WorkingPrograms
| http://oldwiki.linux-vserver.org/WorkingPrograms
|}

Network Bandwidth Management

2009-03-27T13:47:53Z

Jze: migrated from old wiki

Network Bandwidth Management for Guests is most easily achieved via iptables and tc -- see the [http://www.lartc.org/howto Linux Advanced Routing & Traffic Control HOWTO] for details ...

Future network implementations (ngnet) will aid with the context tagging of network packets but will not duplicate features already present in the mainline kernels (like traffic shaping and such)

==Accounting==
The amount of sent/received data at the socket level is already accounted, the actual network traffic has to be accounted by utilizing iptable accounting rules (this will change with ngnet)

Documentation

2009-03-27T13:47:22Z

Jze: /* Lists & Theory */ Network Bandwidth Management

<div style="margin: 2em auto 2em auto; padding: 10px; background-color: #F9ECCD; border: 1px solid #004433; text-align: center;">
[[Image:Icon-Caution.png|left]]
We are currently migrating to MediaWiki from our old system, 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.

'''To ease migration we created a [[List of old Documentation pages]].'''
</div>

== Introduction ==

* [[Overview|Virtualization Overview]]
* [[Usage Scenarios]]
* [[Feature Matrix]]

== Installation ==

* [[Installation Considerations]]
* [[Installation on Linux 2.6]]: from source, both the kernel and util-vserver
* [[Installation on ArchLinux]]
* [[Installation on CentOS]]
* [[Installation on Debian]]
* [[Installation on Fedora]]
* [[Installation on Gentoo]]
* [[Installation on Mandrake]]
* [http://pld-linux.org/Vserver Installation on PLD-Linux]
* [[Installation on Redhat]]
* [[Installation on Slackware]]
* [[Installation on SuSE/OpenSUSE]]
* [[Installation on Ubuntu]]

== Configuration ==

* [[Util-vserver:Documentation|util-vserver Documentation]]
* [[vcd:Documentation|VServer Control Daemon Documentation]]
* [[Share a directory among multiple guests]]

== Guides and Howtos ==

* [[Building Guest Systems]]
* [[util-vserver:Howto virtualize an exisiting Linux server|Howto virtualize an existing Linux server]]
* [[VCMD HowTo]]
* [[Howto make bsd-style init sysv-compatible|Howto make Bsd-style init sysv-compatible (archlinux guest system)]]
* [[Installing 32-bit Fedora on 64-bit Debian]]
* [[Installing Ubuntu on Debian]]
* [[Installing an openSUSE vserver guest]]
* [[Networking vserver guests]]
* [[Howto HostAuth]]
* [[Fuse_GlusterFS| Fuse and GlusterFS]]
* [[yum-patch|How to patch vyum]]
* [[yum-upgrade-3.2.4|Upgrading existing installations to yum-3.2.4]]
* [[Migrating from OpenVZ to Linux-Vserver]]
* [[Getting_high_with_lenny]]
* [[Installing_Ubuntu_Hoary_as_guest| Installing Ubuntu Hoary as guest]]
* [[Applying CPU Limits]]

== Lists & Theory ==

* Basic configuration
** [[Capabilities and Flags]]
** [[CPU Scheduler]]
** [[Disk Limits and Quota]]
** [[Resource Limits]]
*** [[Memory Limits]]
*** [[Network Bandwidth Management]]
** [[Virtual System Information]]
** [[Unification]]

* Security Considerations
** [[Secure Capabilities]]
** [[Secure chroot Barrier]]
** [[Secure Device Nodes]]
** [[Secure ProcFS Entries]]

* Performance and Stability
** [[Virtualization Overhead]]

* Implementation Details
** [[Context Accounting]]
** [[Filesystem Attributes]]
** [[Filesystem Tagging]]
** [[Filesystem Namespaces]]
** [[Kernel Userspace Helper]]
** [[Mainline Kernel Virtualization]]
** [[ProcFS]]
** [[Syscall Command Switch]]

== External Resources ==

Category:French

2009-03-27T13:46:29Z

Jze: category

[[Category:Translation]]

Secure ProcFS Entries/fr

2009-03-27T13:46:12Z

Jze: New page: Depuis les versions stable 1.23 et développement 1.3.5, vous pouvez protéger les entrées du système de fichier /proc, de manière à ce qu'elles ne soient pas visibles dans tous les co...

Depuis les versions stable 1.23 et développement 1.3.5, vous pouvez protéger les entrées du système de fichier /proc, de manière à ce qu'elles ne soient pas visibles dans tous les contextes. Le système est constitué de trois drapeaux: admin, watch et hide (caché). Pour les activer ou les consulter, vous devez utiliser une version récente du paquet util-vserver, qui contient setattr et showattr. (Un autre outil existe, vproc, mais ne sera pas détaillé ici). La logique derrière ces drapeaux a été modifiée dans la release expérimentale 0.09, et les nouvelles releases stable et devel utilisent aussi cette logique. Nous ne parlerons pas de l'ancienne logique.

'''Note:''' Pour faire allusion aux drapeaux, j'utiliserai la syntaxe de l'outil showattr du paquet util-vserver, ou '''a''' est mis pour admin, '''w''' pour watch et '''h''' pour hide (caché). De plus, une minuscule signifie désactivé alors qu'une majuscule signifie activé.

== Flag logic (Linux-VServer 2.4 branch > 1.3.7 / 2.6 branch > 0.08) ==
Les drapeaThe flags have the following meanings:
{|class="wikitablenowrap"
!Drapeau
! Signification
|-
|admin
| toujours visible dans le contexte 0
|-
|watch
| toujours visible dans le contexte 1
|-
|hide
| caché
|}

La correspondance entre drapeaux et visibilité est donnée par la table suivante:
{|class="wikitablenowrap"
!Drapeau
!Signification
|-
|<tt>* * h</tt>
|Visible partout (les drapeaux admin et watch n'ont pas d'effet)
|-
|<tt>A w H</tt>
|Visible seulement dans le contexte 0
|-
|<tt>a W H </tt>
|Visible seulement dans le contexte 1
|-
|<tt>A W H </tt>
|Visible dans les contextes 0 et 1
|-
|<tt>a w H</tt>
|Totalement invisible (irreversible sans reboot!)
|}

== Drapeaux par Default ==
Les drapeaux sont mis par défaut à:
*toutes les entrées de /proc sont visibles partout (branche stable)
*toutes les entrées de /proc sont visibles seulement dans le contexte 0 (branches devel et expérimentale)

==Activation des drapeaux==
Pour activer ces drapeaux vous devez utiliser l'outil setattr (à partir de util-vserver >= 0.30.193), dont l'usage est assez clair d'après l'aide en ligne de commande. Pour faire en sorte que l'entrée /proc/loadavg soit visible partout, désactivez par exemple le drapeau hide (caché):
setattr --~hide /proc/loadavg

Peu importe la position des drapeaux admin et watch, puisque hide n'est controlé que par le drapeau hide.
Pour éviter aux vservers d'avoir accès aux informations à propos des interruptions, vous devez cacher l'entrée /proc/interrupts. Si vous voulez pouvoir y accéder depuis le context admin uniquement (contexte 0), utilisez simplement:
setattr --hide --admin --~watch /proc/interrupts

==vprocunhide==
Les outils alpha util-vserver sont livrés avec un outil appelé vprocunhide qui attribue des drapeaux raisonnables pour un certain nombre d'entrées proc, dont on a généralement besoin. Un script d'init est aussi fourni, situé en principe dans <tt>/usr/local/etc/init.d/vprocunhide</tt>, et que vous pouvez include dans votre séquence de démarrage.

[[Category:French]]

List of pages not migrated yet

2009-03-27T13:42:58Z

Jze:

Below is a list of pages which are either not yet migrated or have not yet been invalidated or excluded from migration.

If you think a page listed in here has already been migrated or should be excluded please contact our [[Wiki Team]].

See also
* [[Wiki Relocation]]
* [[List of migrated pages]]
* [[List of invalid old pages]]
* [[List of pages excluded from migration]]
* [[List of old Documentation pages]]

{| class="wikitablenowrap"
! Old page name
! Current URL
|-
! advanced+DRBD+mount+issues
| http://oldwiki.linux-vserver.org/advanced+DRBD+mount+issues
|-
! alpha+util-vserver
| http://oldwiki.linux-vserver.org/alpha+util-vserver
|-
! ArchVserver
| http://oldwiki.linux-vserver.org/ArchVserver
|-
! BeginnerFAQ
| http://oldwiki.linux-vserver.org/BeginnerFAQ
|-
! BeginnerHowTo
| http://oldwiki.linux-vserver.org/BeginnerHowTo
|-
! breve-presentacion
| http://oldwiki.linux-vserver.org/breve-presentacion
|-
! Cacti+configuration
| http://oldwiki.linux-vserver.org/Cacti+configuration
|-
! CentOS_HowTo
| http://oldwiki.linux-vserver.org/CentOS_HowTo
|-
! CentOS_min_install
| http://oldwiki.linux-vserver.org/CentOS_min_install
|-
! chroot-barrier-French
| http://oldwiki.linux-vserver.org/chroot-barrier-French
|-
! CommonProblems
| http://oldwiki.linux-vserver.org/CommonProblems
|-
! ConfigConverters
| http://oldwiki.linux-vserver.org/ConfigConverters
|-
! DebianVserver
| http://oldwiki.linux-vserver.org/DebianVserver
|-
! DebianVserverVirtualHosting
| http://oldwiki.linux-vserver.org/DebianVserverVirtualHosting
|-
! DemoBrainStorming
| http://oldwiki.linux-vserver.org/DemoBrainStorming
|-
! Disk+Limits
| http://oldwiki.linux-vserver.org/Disk+Limits
|-
! Distribution+specific+stuff
| http://oldwiki.linux-vserver.org/Distribution+specific+stuff
|-
! distro_hints
| http://oldwiki.linux-vserver.org/distro_hints
|-
! FC3_min_install
| http://oldwiki.linux-vserver.org/FC3_min_install
|-
! FC4+patched+rpm%27s
| http://oldwiki.linux-vserver.org/FC4+patched+rpm%27s
|-
! Fedora2Vserver
| http://oldwiki.linux-vserver.org/Fedora2Vserver
|-
! FedoraCore3_HowTo
| http://oldwiki.linux-vserver.org/FedoraCore3_HowTo
|-
! FedoraHowTo
| http://oldwiki.linux-vserver.org/FedoraHowTo
|-
! FedoraHowToFrench
| http://oldwiki.linux-vserver.org/FedoraHowToFrench
|-
! Gathered+Ideas
| http://oldwiki.linux-vserver.org/Gathered+Ideas
|-
! GettingStarted
| http://oldwiki.linux-vserver.org/GettingStarted
|-
! grsecurityHowto
| http://oldwiki.linux-vserver.org/grsecurityHowto
|-
! HowTo+Read+ProcFS
| http://oldwiki.linux-vserver.org/HowTo+Read+ProcFS
|-
! HowTo+Read+ProcFS-French
| http://oldwiki.linux-vserver.org/HowTo+Read+ProcFS-French
|-
! HowtoCloneVserver
| http://oldwiki.linux-vserver.org/HowtoCloneVserver
|-
! HowtoGuestLoopDevice
| http://oldwiki.linux-vserver.org/HowtoGuestLoopDevice
|-
! HowtoHostAuth
| http://oldwiki.linux-vserver.org/HowtoHostAuth
|-
! HowtoPrivateNetworking
| http://oldwiki.linux-vserver.org/HowtoPrivateNetworking
|-
! HowToRegisterNewDistributions
| http://oldwiki.linux-vserver.org/HowToRegisterNewDistributions
|-
! HowtoSSHLogin
| http://oldwiki.linux-vserver.org/HowtoSSHLogin
|-
! initscript-default-debian
| http://oldwiki.linux-vserver.org/initscript-default-debian
|-
! InitStyles
| http://oldwiki.linux-vserver.org/InitStyles
|-
! IpCopInAvserver
| http://oldwiki.linux-vserver.org/IpCopInAvserver
|-
! IPv6
| http://oldwiki.linux-vserver.org/IPv6
|-
! IrcQuestions
| http://oldwiki.linux-vserver.org/IrcQuestions
|-
! Kernel-Knowledge
| http://oldwiki.linux-vserver.org/Kernel-Knowledge
|-
! KernelHowto
| http://oldwiki.linux-vserver.org/KernelHowto
|-
! KernelHowto-French
| http://oldwiki.linux-vserver.org/KernelHowto-French
|-
! Legacy-To-Newstyle-Config
| http://oldwiki.linux-vserver.org/Legacy-To-Newstyle-Config
|-
! Linux-Vserver+FAQ
| http://oldwiki.linux-vserver.org/Linux-Vserver+FAQ
|-
! Linux-Vserver+FAQ-French
| http://oldwiki.linux-vserver.org/Linux-Vserver+FAQ-French
|-
! Linux-VServer-Paper-00-French
| http://oldwiki.linux-vserver.org/Linux-VServer-Paper-00-French
|-
! Linux-VServer-Paper-01-French
| http://oldwiki.linux-vserver.org/Linux-VServer-Paper-01-French
|-
! Linux-VServer-Paper-02-French
| http://oldwiki.linux-vserver.org/Linux-VServer-Paper-02-French
|-
! Linux-VServer-Paper-03-espaniol
| http://oldwiki.linux-vserver.org/Linux-VServer-Paper-03-espaniol
|-
! Linux-VServer-Paper-03-French
| http://oldwiki.linux-vserver.org/Linux-VServer-Paper-03-French
|-
! Linux-VServer-Paper-04-French
| http://oldwiki.linux-vserver.org/Linux-VServer-Paper-04-French
|-
! Linux-VServer-Paper-05-French
| http://oldwiki.linux-vserver.org/Linux-VServer-Paper-05-French
|-
! Linux-VServer-Paper-06-French
| http://oldwiki.linux-vserver.org/Linux-VServer-Paper-06-French
|-
! Linux-VServer-Paper-07-French
| http://oldwiki.linux-vserver.org/Linux-VServer-Paper-07-French
|-
! Linux-VServer-Paper-08-French
| http://oldwiki.linux-vserver.org/Linux-VServer-Paper-08-French
|-
! Linux-VServer-Paper-09-French
| http://oldwiki.linux-vserver.org/Linux-VServer-Paper-09-French
|-
! Linux-VServer-Paper-10-French
| http://oldwiki.linux-vserver.org/Linux-VServer-Paper-10-French
|-
! Linux-VServer-Paper-11-French
| http://oldwiki.linux-vserver.org/Linux-VServer-Paper-11-French
|-
! Linux-VServer-Paper-12-French
| http://oldwiki.linux-vserver.org/Linux-VServer-Paper-12-French
|-
! Linux-VServer-Paper-13-French
| http://oldwiki.linux-vserver.org/Linux-VServer-Paper-13-French
|-
! Linux-VServer-Paper-14-French
| http://oldwiki.linux-vserver.org/Linux-VServer-Paper-14-French
|-
! Linux-VServer-Paper-15-French
| http://oldwiki.linux-vserver.org/Linux-VServer-Paper-15-French
|-
! Linux-VServer-Paper-French
| http://oldwiki.linux-vserver.org/Linux-VServer-Paper-French
|-
! linux-vserver_administrators_gide
| http://oldwiki.linux-vserver.org/linux-vserver_administrators_gide
|-
! linux-vserver_administrators_guide
| http://oldwiki.linux-vserver.org/linux-vserver_administrators_guide
|-
! Memory+Allocation
| http://oldwiki.linux-vserver.org/Memory+Allocation
|-
! Memory+Management
| http://oldwiki.linux-vserver.org/Memory+Management
|-
! MoreUbuntu
| http://oldwiki.linux-vserver.org/MoreUbuntu
|-
! Network+Bandwidth+Management
| http://oldwiki.linux-vserver.org/Network+Bandwidth+Management
|-
! New-Howto
| http://oldwiki.linux-vserver.org/New-Howto
|-
! NFS+and+portmap
| http://oldwiki.linux-vserver.org/NFS+and+portmap
|-
! OpenVPN
| http://oldwiki.linux-vserver.org/OpenVPN
|-
! OpenwallHowto
| http://oldwiki.linux-vserver.org/OpenwallHowto
|-
! PartsList
| http://oldwiki.linux-vserver.org/PartsList
|-
! Per+Context+Quota
| http://oldwiki.linux-vserver.org/Per+Context+Quota
|-
! ProblematicPrograms-French
| http://oldwiki.linux-vserver.org/ProblematicPrograms-French
|-
! Quota+and+Disk+Limits
| http://oldwiki.linux-vserver.org/Quota+and+Disk+Limits
|-
! Recipes
| http://oldwiki.linux-vserver.org/Recipes
|-
! Release+FAQ-French
| http://oldwiki.linux-vserver.org/Release+FAQ-French
|-
! Remote+Server+Repartitioning
| http://oldwiki.linux-vserver.org/Remote+Server+Repartitioning
|-
! Scheduler
| http://oldwiki.linux-vserver.org/Scheduler
|-
! Scheduler+Parameters
| http://oldwiki.linux-vserver.org/Scheduler+Parameters
|-
! Security
| http://oldwiki.linux-vserver.org/Security
|-
! short+presentation-French
| http://oldwiki.linux-vserver.org/short+presentation-French
|-
! SlackwareVserverHowto
| http://oldwiki.linux-vserver.org/SlackwareVserverHowto
|-
! Snapshots
| http://oldwiki.linux-vserver.org/Snapshots
|-
! some_hints_from_john
| http://oldwiki.linux-vserver.org/some_hints_from_john
|-
! sparc64
| http://oldwiki.linux-vserver.org/sparc64
|-
! Standard+non-shared+quota
| http://oldwiki.linux-vserver.org/Standard+non-shared+quota
|-
! Step-by-Step+Guide
| http://oldwiki.linux-vserver.org/Step-by-Step+Guide
|-
! Step-by-Step+Guide+2.6
| http://oldwiki.linux-vserver.org/Step-by-Step+Guide+2.6
|-
! SuseVserverHowTo
| http://oldwiki.linux-vserver.org/SuseVserverHowTo
|-
! Syscall+Switch+Info
| http://oldwiki.linux-vserver.org/Syscall+Switch+Info
|-
! TestScripts
| http://oldwiki.linux-vserver.org/TestScripts
|-
! TestWorkingPrograms
| http://oldwiki.linux-vserver.org/TestWorkingPrograms
|-
! ttyHowto
| http://oldwiki.linux-vserver.org/ttyHowto
|-
! UbuntuVserverHowTo
| http://oldwiki.linux-vserver.org/UbuntuVserverHowTo
|-
! Util-VServer+for+RH9
| http://oldwiki.linux-vserver.org/Util-VServer+for+RH9
|-
! util-vserver+on+sarge
| http://oldwiki.linux-vserver.org/util-vserver+on+sarge
|-
! Virtual+Context+Separation
| http://oldwiki.linux-vserver.org/Virtual+Context+Separation
|-
! Virtual+Init+Task
| http://oldwiki.linux-vserver.org/Virtual+Init+Task
|-
! VirtualiseNTP
| http://oldwiki.linux-vserver.org/VirtualiseNTP
|-
! VirtualizeHowto
| http://oldwiki.linux-vserver.org/VirtualizeHowto
|-
! VisualAids
| http://oldwiki.linux-vserver.org/VisualAids
|-
! vsched+explained
| http://oldwiki.linux-vserver.org/vsched+explained
|-
! Vserver+Completion
| http://oldwiki.linux-vserver.org/Vserver+Completion
|-
! Vserver+DRBD
| http://oldwiki.linux-vserver.org/Vserver+DRBD
|-
! VServer+installation+Fedora+Core+4
| http://oldwiki.linux-vserver.org/VServer+installation+Fedora+Core+4
|-
! VServer+installation+Fedora+Core+5
| http://oldwiki.linux-vserver.org/VServer+installation+Fedora+Core+5
|-
! vserver-autostart
| http://oldwiki.linux-vserver.org/vserver-autostart
|-
! VServerBook
| http://oldwiki.linux-vserver.org/VServerBook
|-
! VserverDocumentationProject
| http://oldwiki.linux-vserver.org/VserverDocumentationProject
|-
! VServerKernelInstall
| http://oldwiki.linux-vserver.org/VServerKernelInstall
|-
! VServerManual
| http://oldwiki.linux-vserver.org/VServerManual
|-
! VServerUtilitiesInstall
| http://oldwiki.linux-vserver.org/VServerUtilitiesInstall
|-
! VSkel
| http://oldwiki.linux-vserver.org/VSkel
|-
! VSkel-French
| http://oldwiki.linux-vserver.org/VSkel-French
|-
! WorkingPrograms
| http://oldwiki.linux-vserver.org/WorkingPrograms
|}

Secure ProcFS Entries

2009-03-27T13:41:46Z

Jze: migrated from old wiki Proc-Security

The Linux-VServer project provides a mechanism to protect entries in the proc filesystem from being seen in every context, this has been introduced in development release 1.3.5 and stable release 1.23.

The system consists of three flags: admin, watch and hide. To view/set these, a recent version of the util-vserver package, containing setattr and showattr, is required. (There is another tool called vproc, but this won't be discussed here). The logic behind these flags has been changed in experimental release 0.09, and new devel / stable releases that also use this logic, are coming soon, so the old logic won't be explained here (if you're running an older version of Linux-VServer, you probably already figured it out yourself anyways).

'''Note:''' When referring to the flags, I'll follow the syntax used by the showattr tool of the util-vserver package, where '''a''' means admin, '''w''' means watch and '''h''' means hide, also lower case means disabled and upper case means enabled.

== Flag logic (Linux-VServer 2.4 branch > 1.3.7 / 2.6 branch > 0.08) ==
The flags have the following meanings:
{|class="wikitablenowrap"
!Flag
!Meaning
|-
|admin
| always visible in context 0
|-
|watch
| always visible in context 1
|-
|hide
| hidden
|}

This means a mapping of flagging to visibility according to this table:
{|class="wikitablenowrap"
!Flags
!Visibility
|-
|<tt>* * h</tt>
|Visible everwhere (admin and watch flags don't matter)
|-
|<tt>A w H</tt>
|Visible only in context 0
|-
|<tt>a W H </tt>
|Visible only in context 1
|-
|<tt>A W H </tt>
|Visible in contexts 0 and 1
|-
|<tt>a w H</tt>
|Totally invisible (cannot be reverted without rebooting!)
|}

== Default flagging ==
As of now the stable vs1.2.x (2.4 kernel defaults to all proc entries visible everywhere, stable vs2.0.x (2.6 kernel), development and experimental versions default to all proc entries only visible in context 0 and 1.

==Setting flags==
To set those flags you'll need the setattr tool from a recent util-vserver package (0.30.193 works), the usage is pretty much self-explanatory from the command-line help. To make the /proc/loadavg entry visible everywhere, you have to unset the hide flag:
setattr --~hide /proc/loadavg

The admin and watch flag can be in any state as hiding is controlled by the hide flag only.

To keep vservers from reading the interrupt information, you need to hide the /proc/interrupts entry. If you want this to be accessible in the admin context (0) only use:
setattr --hide --admin --~watch /proc/interrupts

==vprocunhide ==
With alpha util-vserver comes a tool called vprocunhide that sets reasonable flags for a number of proc entries that are generally needed to be visible. There is also an init script, normally located at /usr/local/etc/init.d/vprocunhide that you can use to include it in your boot process.

Memory Management

2009-03-27T13:34:39Z

Jze: migrated from old wiki Memory+Management

== Basic intro to virtual memory ==
When folks talk about Memory, they usually mean the expensive modules they buy and plug into the (typically x86) based machines. The operating system, in our case Linux, handles that physical memory according to the mechanisms of the architecture (in this case x86). Most architectures used nowadays have the concept of '''virtual memory''' which basically is ''linear'' address space, in units of pages, which can be real pages in memory or just not there. The operating system now knows about several types of such '''page'''s, for example, there is the file system based page, which can be a file or an executable (of course, such a file will usually require several such pages) and, an important detail here is, the pages do not necessarily have to be in RAM. Then there are anonymous pages, which are used by some application (those are usually read-write) and if there is swapping enabled, those pages can also be written to some swap area. In addition to those types, there are a bunch of special pages and methods to handle those pages: for example, the so called '''zero page''', which is (at least) a page just containing read-only zeros. It will usually be used if you request some memory area from the [http://en.wikipedia.org/wiki/Memory_management memory management system (mm)]. The read-only property causes a trap (page fault) once you write to that page, which then will be replaced by actual memory. A similar thing happens with shared memory pages, which are basically marked read-only and copied on write. Pages which get swapped out (to swap space) will not be freed immediately, they are kept as swap cache; similar happens to file caches (inode cache): they are marked as 'unused' but will not be freed until somebody requires a page.

Now, on x86, the total addressable space is 4GB and this is also the maximum of virtual address space an application (or the kernel) can see. To simplify the transition of memory from userspace to kernelspace, the address space is divided between kernel and userspace.

== The application's point of view ==
:'''Q.''' OK, I think I understand all that. But i'm not sure about it from the other perspective - i.e. what happens when i run a program. So, say i run something - editing a text file, for example (something simple to start with) then that will use some pages to keep track of what i am doing, correct?

That's actually quite complex, maybe lets start with something like 'true' first! Let's further assume the binary (program) is not compiled dynamically but is static and fits into 4k and it does not have any data section (usually not true, but it's simpler). When it is executed, the kernel 'maps' the executable into memory, and creates an userspace task, with a stack page, and starts executing the just mapped memory. The file will be read into real memory (i.e. RAM), marked as read-only but executable and it will be added to the inode cache; the virtual address will be at some fixed address coded into the executable and it will call the kernel via syscalls requesting things like exit()

When you execute it a second time, the file is already in the inode cache, so all that happens is a new mapping into the virtual adress space of that task. Now, I mentioned already that the address space is shared by userspace and kernel. Typically, the split is 3/1 - where userspace gets 3GB of "space" and the kernel only 1GB; there are now split patches and recent changes to mainline which allow for other splits too such as 2/2 or 1/3. In whichever case, the userspace is allocated first, starting at 0, and (normally), the kernel starts at 0xc0000000 - which is 3GB.

Now usually this leads to the question: ''but what if I have only 1GB of RAM?'' The answer is simple, it will still be 3GB userspace and 1GB kernel space: as mentioned before, the virtual space does not have to be backed by any real RAM. You could, for example, fill the entire 3GB space with mappings of the zero page, using only a single 4k RAM area at any location. This also means that a physical address can be mapped at different virtual addresses and, of course, several times - even in the same task space. Also, the 3GB (or actually 4GB) address space is ''per process'' so the processes do not have to share that space in any way.

Now to get back to the editor example: this will cause
* the executable pages to be mapped somewhere,
* the file you 'open' to be mapped too (which will be done via the inode cache).

Then it will require stack and data pages to do the actual work (editing) and it will request a writeback to the file, which will make those pages buffer caches for write back I/O, which in turn might update the inode cache once it is written. If, for some reason, the editor is very large (i.e has many executable pages), it might happen that when you are low on physical RAM (or the swap system is tuned to do optimistic swap out) that some pages of your editor (which are not used right now) will simply be dropped and some of the data pages (editor memory) will be swapped out.

So, as you can see, the relation between processes and physical RAM is not straightforward and simple :)

==The size of the word depends on the architecture==
:'''Q.''' This may be stupid, but why isn't the virtual memory size equivalent to the available physical memory plus swap space? It seems it is larger than the hardware can handle (unless you have 4gigs of physical memory). But I guess when you say 3GB of virtual memory, its more of a page of pointers or something, rather than actual memory.

Yes, that is right, but let me answer that with another question: why is an int 32-bit and not just ld(N) ? That is, to represent the value 20 you need just 5 bits (10100 in binary), so why 'waste' 32 bits for that? IMHO the answer is simple and straight forward: the hardware has to have certain limits, for the int this is 32bit; for the address space that is 4GB on x86.

:'''Q.''' Is that due to the instruction set on the CPU itself?

Well, actually the 32bit address space and the [http://en.wikipedia.org/wiki/Memory_management_unit Memory Management Unit MMU)]: { 2^32 = 4294967296 = 4GB }. The x86_64 has a much larger address space (as it is 64-bit based) and the MMU there usually has 48bits at least.

:'''Q.''' So if there's more than 4 gigs, does that mean it is or isn't used?
As I said before, a mapping is required between virtual adresses and physical RAM. Without 'dirty' tricks (read [http://www.microsoft.com/whdc/system/platform/server/PAE/pae_os.mspx PAE]) 4GB is the maximum on x86. Beyond that, it is the dreaded HIGHMEM support (which is a special case below the 4GB). To access those >4gigs you do so at a cost, so its slower. Even with 4GB RAM, the kernel can only address 1GB (in the default split) directly. The thing here is, changing the mapping from virtual to physical memory is expensive and a kernel which can address 1GB will have to reserve a certain area for mapping in and out the remaining 3GB (on a 4GB system). This "mapping window," where the "high" memory pages are mapped in and out is called high mem so with the default 3/1 split, you can get roughly 970MB of memory. even with 2GB RAM this will not change, only enabling the dynamic mapping (highmem) will give you access to that

:'''Q.''' you said the virtual memory isn't backed by RAM, but is it backed by anything?

Sometimes, it depends on the mapping.

==Applying this to vservers==
:'''Q.''' So how does this all map onto VSZ and RSS (in vserver-stat) or VIRT/RES/SHR in top/vtop stats?

Good questions, and well, they are simply answered for a task:
* the VSZ for a task is the amount of pages which have a mapping
* the RSS (resident set size) is the amount of pages which are currently in RAM (physical memory)
* shared is memory that is mapped between two applications

VSZ=VIRT = number of pages currently mapped
RSS=RES = number of pages currently in RAM

This accounting is a little more problematic if you want to do it for, let's say two processes. First, what do you do about the address space? look for identical mappings and count them only once, or take the maximum of both? or just add them up? And it's even more complicated for the RSS because we can have shared RAM (e.g. inode caches, executables and we can have shared but copy on write pages and we can also have purely anonymous pages, that only belong to a single task. well, actually shared memory can belong to no task, but that probably complicates things for now, so let's say a single task.

Linux-Vserver tries to be as unintrusive as possible here and, of course, we try to keep it simple and efficient too. So what we do is mainly accounting the allocations and deallocations of those pages per context, which gives values (and if limited limits) which might not be directly mappable to physical RAM (or swap space, which we didn't even mention yet). We decided to 'simply add up' the address space of all tasks and call that VM/AS.
VM/AS = virtual memory pages (total) in a context

=== swap ===
We also decided not to account the shared pages special as [OVZ] does, instead we simply add them up in separate counters. A currently missing accounting/limit is the swap space because accounting the swap space properly would require a 'tag' on each memory page to know which context it belongs to, which is something I don't want to do without good reason, as there are
* many pages, and
* this stuff is really performance critical!

User:Jze

2009-03-27T13:15:11Z

Jze:

;Real Name: Jesper Zedlitz
;Location: Kiel, Germany

User talk:Hollow

2009-03-27T13:14:15Z

Jze: Extension:ParserFunctions

Haha, I guess that I'm not the only one deleting spam from this Wiki anymore :P --[[User:Daniel15|Daniel15]] 13:22, 20 October 2006 (CEST)

== Migrated pages ==

I have migrated these pages from the old to the new wiki:
* [[Namespaces/fr]]
* [[Namespaces]]
* [[Installation on Slackware]]
* [[Vservers and X]]
--[[User:Jze|Jze]] 13:47, 27 March 2009 (CET)

== Syntax highlighting ==
It would be nice if you could install this extension in the VServer-Wiki: http://www.mediawiki.org/wiki/Extension:SyntaxHighlight_GeSHi

Scripts would be much better readable with very little effort. --[[User:Jze|Jze]] 13:47, 27 March 2009 (CET)

== SVG support ==
Is it possible to activate SVG support for this wiki? I have redrawn the "computer-memory-pyramid" figure from the old wiki. Visualization is always helpfull and much easier to editable with vector graphics. --[[User:Jze|Jze]] 13:47, 27 March 2009 (CET)

== Extension:ParserFunctions ==

Can you also install the Extension:ParserFunctions?
http://www.mediawiki.org/wiki/Extension:ParserFunctions

It can be used to generate language selection boxes like this [[Template:Language]] with the existing languages automatically shown. --[[User:Jze|Jze]] 14:14, 27 March 2009 (CET)

Template:Language

2009-03-27T13:14:00Z

Jze: Language moved to Template:Language: It is a template.

<div style="margin-top: 0.5em;">
<table width="100%" style="clear: both;border: 1px solid #807060;border-collapse: collapse;padding: 0.2em;margin: 0;font-size: 85%;margin: 0 1px;">
<tr valign="top" style="background: #f5e5d0">
<td style="width: 25px; padding-left: 0.5em;">[[Image:Geographylogo.png|25px|Languages]]</td>
<td style="width: 10px; white-space: nowrap; padding: 4px 1em 0 0.5em; border-right: 1px solid #807060;">'''Languages:''' </td><td style="padding: 1px 1em 0; background: #f5e5d0;">
'''[[{{{1|:{{NAMESPACE}}:{{BASEPAGENAME}}}}}|English]]'''
{{Languages/Lang|de|{{{1|}}}}}
{{Languages/Lang|fr|{{{1|}}}}}
</td></tr></table></div>

[[Category:Language templates]]

Language

2009-03-27T13:14:00Z

Jze: Language moved to Template:Language: It is a template.

#REDIRECT [[Template:Language]]

Template:Language

2009-03-27T12:58:31Z

Jze: adjusted colors

File:Geographylogo.png

2009-03-27T12:53:00Z

Jze: This file is from the Open Clip Art Library, which released it explicitly into the public domain, using the Creative Commons Public Domain Dedication

This file is from the Open Clip Art Library, which released it explicitly into the public domain, using the Creative Commons Public Domain Dedication

Template:Language

2009-03-27T12:52:41Z

Jze: New page: <div class="LanguageLinks"> <table width="100%"> <tr valign="top" style="background: #EEF3E2"> <td style="width: 25px; padding-left: 0.5em;">Languages</td>...

<div class="LanguageLinks">
<table width="100%">
<tr valign="top" style="background: #EEF3E2">
<td style="width: 25px; padding-left: 0.5em;">[[Image:Geographylogo.png|25px|Languages]]</td>
<td style="width: 10px; white-space: nowrap; padding: 4px 1em 0 0.5em; border-right: 1px solid #aaaaaa;">'''Languages:''' </td><td style="padding: 1px 1em 0; background: #F6F9ED;">
'''[[{{{1|:{{NAMESPACE}}:{{BASEPAGENAME}}}}}|English]]'''
{{Languages/Lang|de|{{{1|}}}}}
{{Languages/Lang|fr|{{{1|}}}}}
</td></tr></table></div>

[[Category:Language templates]]

Template:Languages/Lang

2009-03-27T12:51:41Z

Jze: New page: <includeonly>{{#ifexist: {{#if: {{{2|}}} | {{{2}}} | {{#if: {{NAMESPACE}} | {{NAMESPACE}}:}}{{BASEPAGENAME}}}}/{{{1}}} |  • <span lang="{{{1}}}">{{#if: {{{2|}}}|[[{{{2}}}/{{...

<includeonly>{{#ifexist: {{#if: {{{2|}}} | {{{2}}} | {{#if: {{NAMESPACE}} | {{NAMESPACE}}:}}{{BASEPAGENAME}}}}/{{{1}}} |  • <span lang="{{{1}}}">{{#if: {{{2|}}}|[[{{{2}}}/{{{1}}}|{{#language:{{{1}}}}}]]| [[:{{NAMESPACE}}:{{BASEPAGENAME}}/{{{1}}}|{{#language:{{{1}}}}}]]}}</span>|<span></span>}}<includeonly>
[[Category:Language templates]]