Editing
Paper/fr
(section)
From Linix VServer
Jump to navigation
Jump to search
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
== 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]
Summary:
Please note that all contributions to Linix VServer may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see
Linix VServer:Copyrights
for details).
Do not submit copyrighted work without permission!
Cancel
Editing help
(opens in new window)
Navigation menu
Page actions
Page
Discussion
Read
Edit
History
Page actions
Page
Discussion
More
Tools
Personal tools
Not logged in
Talk
Contributions
Create account
Log in
About
Overview
Paper
News
Developers
Donations
Search
Getting Started
Downloads
FAQs
Documentation
Support
Participate
How to participate
Report a Bug
Communicate
Teams/Projects
Hall of Fame
Resources
Archives
Recent Wiki Changes
Pastebin
Related Projects
VServer Hosting
Happy VServer Users
Tools
What links here
Related changes
Special pages
Page information