We currently migrate to MediaWiki from our old installation, but not all content has been migrated yet. Take a look at the Wiki Team page for instructions how to help or browse through our new wiki at wiki.linux-vserver.org to find the information already migrated.

05. 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.

05.0. Drapeaux de 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 permet d'indiquer les drapeaux disponibles, et un mécanisme de déclanchement spécial, qui offre la possibilité d'activer un drapeau au démarrage, puis de le désactiver en causant un évennement ou une action associée.

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

[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)
limit the number of processes in a context to the initial NPROC value.
[3] VXF_INFO_PRIVATE historique)
do not allow to join this context from outside.
[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
use the context token bucket for calculating the process priorities
[10] VXF_SCHED_PAUSE
put all processes in this context on the hold queue, not scheduling them any longer
[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
virtualize the uptime, beginning with the time of context creation
[18] VXF_VIRT_CPU
[24] VXF_HIDE_MOUNT
show empty proc/{pid}/mounts
[25] VXF_HIDE_NETIF
hide network interfaces and addresses not permitted by the network context

Voir Exemple [XX]

05.1. Capacités par contexte

As the Linux Capabilities have almost reached the maximum number that is possible without heavy modifications to the kernel, it was a natural step to add a context-specific capability system.

The Linux-VServer context capability set acts as a mechanism to fine tune existing Linux capabilities. It is not visible to the processes within a context, as they would not know how to modify or verify it.

In general there are two ways to use those capabilities:

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:

[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.

05.2. Comptabilité par Contexte (accounting)

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.

Il y a principalement deux types de propriétés comptables, 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 facon spécifique, comme cela est décrit dans la section qui suit.

Good candidates for Context Accounting are:

Voir Exemple [E41]

05.3. 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.

To provide a general framework for all kinds of limits, Context Limits allow the configuration of three different values for each limit-able resource: the minimum, a soft limit and a hard limit (maximum).

At the time this is written, only the hard limits are supported and not all of them are actually enforced, but here is a list of current and planned Context Limits:

Additionally the context limit system keeps track of observed maxima and resource limit hits, to provide some feedback for the administrator.

Voir Exemple [E42]

05.4. Virtualization

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:

Voir Exemple [E43]

05.5. Sécurité Améliorée

Proc-FS Security provides a mechanism to protect dynamic entries in the proc filesystem from being seen in every context.

The system consists of three flags for each Proc-FS entry: Admin, Watch and Hide.

The Hide flag enables or disables the entire feature, so any combination with the Hide flag cleared will mean total visibility.

The Admin and Watch flags determine where the hidden entry remains visible; so for example if Admin and Hidden are set, the Host Context will be the only one able to see this specific entry.

Voir Exemples [E44] et [E45]

05.6. Kernel Helper

For some purposes, it makes sense to have an user-space tool to act on behalf of the kernel, when a process inside a context requests something usually available on a real server, but naturally not available inside a context.

The best, and currently only example for this is the Reboot Helper, which handles the reboot() system call, invoked from inside a context on behalf of the Kernel. It is executed, in Host side user-space to take appropriate actions - either reboot or just shutdown (halt) the specified context.

While the helper is designed to be flexible and handle different things in a similar way there are no other users of this helper at the moment. It might be replaced by an event interface in near future.

Voir Exemple [XX]

[Sommaire] [Précédent] [Suivant]