2021 tuto
This commit is contained in:
parent
ba77aca73b
commit
c4bb727cd4
29 changed files with 422 additions and 257 deletions
|
|
@ -38,13 +38,15 @@ programmes s'exécutent dans les mêmes *namespaces*.
|
|||
```
|
||||
</div>
|
||||
|
||||
Ici, `self` fait référence au processus actuellement exécuté.
|
||||
Ici, `self` fait référence au processus actuellement exécuté (comme il existe
|
||||
un dossier `/proc/self/`, vous n'avez pas besoin de gérer de cas particulier
|
||||
pour ça !).
|
||||
|
||||
Et pourquoi pas :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
42sh$ unshare -m ./cmpns $$ self
|
||||
42sh# unshare -m ./cmpns $$ self
|
||||
- cgroup: same
|
||||
- ipc: same
|
||||
- mnt: differ
|
||||
|
|
|
|||
|
|
@ -10,8 +10,8 @@ Petite parenthèse avant de parler des *namespaces* ...
|
|||
Au premier abord, les points de montage dans l'arborescence d'un système de
|
||||
fichiers n'ont pas l'air d'être remplis de notions complexes : un répertoire
|
||||
peut être le point d'entrée d'un montage vers la partition d'un disque
|
||||
physique... ou d'une partition virtuelle, comme nous l'avons vu dans la partie
|
||||
précédente.
|
||||
physique... ou d'une partition virtuelle, comme nous l'avons vu dans le TP
|
||||
précédent.
|
||||
|
||||
Mais avez-vous déjà essayé de monter la même partition d'un disque physique à
|
||||
deux endroits différents de votre arborescence ?
|
||||
|
|
@ -214,7 +214,7 @@ mount --make-private mountpoint
|
|||
|
||||
### non-attachable -- *unbindable mount*
|
||||
|
||||
Ce mode interdira tout tentative d'attache à un autre endroit.
|
||||
Ce mode interdira toute tentative d'attache à un autre endroit.
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
|
|
@ -254,8 +254,9 @@ Il n'est pas nécessaire que le point d'accroche que l'on cherche à dupliquer
|
|||
pointe sur un point de montage (c'est-à-dire, dans la plupart des cas : une
|
||||
partition ou un système de fichiers virtuel). Il peut parfaitement pointer sur
|
||||
un dossier, et même sur un simple fichier, à la manière d'un *hardlink*, mais
|
||||
que l'on pourrait faire entre plusieurs partitions et qui ne persisterait pas au
|
||||
redémarrage.
|
||||
que l'on pourrait faire entre plusieurs partitions et qui ne persisterait pas
|
||||
au redémarrage (le *hardlink* persiste au redémarrage, mais doit se faire au
|
||||
sein d'une même partition).
|
||||
|
||||
Nous verrons dans la partie [*namespace* réseau](#net-ns), une utilisation
|
||||
d'attache sur un fichier.
|
||||
|
|
@ -269,7 +270,7 @@ faire même si un fichier est en cours d'utilisation. Il faut cependant veiller
|
|||
à ce que les programmes susceptibles d'aller chercher un fichier à l'ancien
|
||||
emplacement soient prévenus du changement.
|
||||
|
||||
On utilise pour cela l'option `--move` de `mount(8)` :
|
||||
Pour déplacer un point de montage, on utilise l'option `--move` de `mount(8)` :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
|
|
@ -285,9 +286,9 @@ mount --move /dev /newroot/dev
|
|||
```
|
||||
</div>
|
||||
|
||||
Il est courant de faire appel à cette option lorsque l'on souhaite changer la
|
||||
racine de notre système de fichiers : par exemple pour passer de l'*initramfs*
|
||||
au système démarré, de notre système hôte au système d'un conteneur, ...
|
||||
Cette possibilité s'emploie notamment lorsque l'on souhaite changer la racine
|
||||
de notre système de fichiers : par exemple pour passer de l'*initramfs* au
|
||||
système démarré, de notre système hôte au système d'un conteneur, ...
|
||||
|
||||
|
||||
## Aller plus loin {-}
|
||||
|
|
|
|||
|
|
@ -10,8 +10,8 @@ dupliquer certaines structures, habituellement considérées uniques
|
|||
pour le noyau, dans le but de les isoler d'un groupe de processus à un
|
||||
autre.
|
||||
|
||||
On en dénombre sept depuis Linux 4.6 : `cgroup`, `IPC`, `network`,
|
||||
`mount`, `PID`, `user` et `UTS`.
|
||||
On en dénombre sept (le dernier ayant été ajouté dans Linux 4.6) : `cgroup`,
|
||||
`IPC`, `network`, `mount`, `PID`, `user` et `UTS`.
|
||||
|
||||
La notion d'espace de noms est relativement nouvelle et a été intégrée
|
||||
progressivement au sein du noyau Linux. Aussi, toutes les structures
|
||||
|
|
@ -27,12 +27,12 @@ Depuis Linux 2.4.19.
|
|||
|
||||
Cet espace de noms isole la liste des points de montage.
|
||||
|
||||
Chaque processus appartenant à un *namespace* différent peut monter, démonter
|
||||
et réorganiser à sa guise les points de montage, sans que cela n'ait d'impact
|
||||
sur les processus hors de cet espace de noms. Une partition ne sera donc pas
|
||||
nécessairement démontée après un appel à `umount(2)`, elle le sera lorsqu'elle
|
||||
aura effectivement été démontée de chaque *namespace* dans lequel elle était
|
||||
montée.
|
||||
Chaque processus appartenant à un *namespace mount* différent peut monter,
|
||||
démonter et réorganiser à sa guise les points de montage, sans que cela n'ait
|
||||
d'impact sur les processus hors de cet espace de noms. Une partition ne sera
|
||||
donc pas nécessairement démontée après un appel à `umount(2)`, elle le sera
|
||||
lorsqu'elle aura effectivement été démontée de chaque *namespace mount* dans
|
||||
lequel elle était montée.
|
||||
|
||||
Attention il convient cependant de prendre garde aux types de liaison existant
|
||||
entre vos points de montage (voir la partie sur
|
||||
|
|
@ -198,20 +198,23 @@ similaire à :
|
|||
```c
|
||||
#include <sched.h>
|
||||
|
||||
#define STACKSIZE (1024*1024)
|
||||
#define STACKSIZE (1024 * 1024)
|
||||
static char child_stack[STACKSIZE];
|
||||
|
||||
int clone_flags = CLONE_CGROUP | CLONE_NEWNET | SIGCHLD;
|
||||
|
||||
pid_t pid = clone(do_execvp,
|
||||
child_stack + STACKSIZE,
|
||||
clone_flags,
|
||||
&args);
|
||||
pid_t pid = clone(do_execvp, // First function executed by child
|
||||
child_stack + STACKSIZE, // Assume stack grows downward
|
||||
clone_flags, // clone specials flags
|
||||
args); // Arguments to pass to do_execvp
|
||||
```
|
||||
</div>
|
||||
|
||||
Le premier argument est un pointeur sur fonction. Il s'agit de la fonction qui
|
||||
sera appelée par le nouveau processus.
|
||||
Dans cet exemple, le processus fils créé disposera d'un nouvel espace de noms
|
||||
pour les *CGroups* et disposera d'une nouvelle pile réseau.
|
||||
|
||||
Un exemple complet d'utilisation de `clone(2)` et du *namespace* `UTS` est
|
||||
donné dans le `man` de l'appel système.
|
||||
|
||||
|
||||
## Rejoindre un *namespace*
|
||||
|
|
@ -310,6 +313,6 @@ les *namespaces*](https://lwn.net/Articles/531114/) est excellente ! Auquel il
|
|||
faut ajouter [le petit dernier sur le `cgroup`
|
||||
*namespace*](https://lwn.net/Articles/621006/).
|
||||
|
||||
[Cet article de Michael Crosby montrant l'utilisation de clone(2)](http://crosbymichael.com/creating-containers-part-1.html)
|
||||
[Cet article de Michael Crosby montrant l'utilisation de clone(2)](https://web.archive.org/web/20190206073558/http://crosbymichael.com/creating-containers-part-1.html)
|
||||
est également des plus intéressants, pour ce qui concerne la programmation
|
||||
plus bas-niveau.
|
||||
|
|
|
|||
|
|
@ -235,3 +235,7 @@ Pour construire une nouvelle interface de ce type :
|
|||
Pour approfondir les différentes techniques de routage, je vous
|
||||
recommande cet article :
|
||||
[Linux Containers and Networking](https://blog.flameeyes.eu/2010/09/linux-containers-and-networking).
|
||||
|
||||
Appliqué à Docker, vous apprécirez cet article : [Understanding Docker
|
||||
Networking Drivers and their use
|
||||
cases](https://www.docker.com/blog/understanding-docker-networking-drivers-use-cases/).
|
||||
|
|
|
|||
|
|
@ -41,8 +41,8 @@ contenu de `/proc`. D'ailleurs, si l'on affiche le PID du processus courant
|
|||
|
||||
En l'état, beaucoup d'informations sont divulguées. Mais il n'est pas possible
|
||||
de monter le bon `/proc` car il serait également monté pour les processus de
|
||||
notre système initial. Pour s'en sortir, il est nécessaire de s'isoler du
|
||||
*namespace* `mount`.
|
||||
notre système initial. Pour s'en sortir, il est nécessaire de s'isoler dans un
|
||||
*namespace* `mount` séparé.
|
||||
|
||||
|
||||
### Double isolation : ajout du *namespace* `mount`
|
||||
|
|
|
|||
|
|
@ -15,6 +15,9 @@ sera pas pris en compte.
|
|||
|
||||
Pour différencier le rendu du TP, du rendu du projet, ajoutez une balise
|
||||
`[PROJET]` au sujet de votre courriel, afin qu'il soit traité comme tel.
|
||||
N'hésitez pas à indiquer dans le corps du courriel votre
|
||||
ressenti et vos difficultés ou bien alors écrivez votre meilleure histoire
|
||||
drôle si vous n'avez rien à dire.
|
||||
|
||||
Tarball
|
||||
-------
|
||||
|
|
|
|||
|
|
@ -23,8 +23,13 @@ et exclusivement à celle-ci que vous devez envoyer vos rendus. Tout rendu
|
|||
envoyé à une autre adresse et/ou non signé et/ou reçu après la correction ne
|
||||
sera pas pris en compte.
|
||||
|
||||
Afin d'orienter correctement votre rendu, ajoutez une balise `[TP5]` au sujet
|
||||
de votre courriel. N'hésitez pas à indiquer dans le corps du courriel votre
|
||||
ressenti et vos difficultés ou bien alors écrivez votre meilleure histoire
|
||||
drôle si vous n'avez rien à dire.
|
||||
|
||||
Par ailleurs, n'oubliez pas de répondre à
|
||||
[l'évaluation du cours](https://www.epitaf.fr/moodle/mod/quiz/view.php?id=309).
|
||||
[l'évaluation du cours](https://virli.nemunai.re/quiz/7).
|
||||
|
||||
|
||||
Tarball
|
||||
|
|
@ -37,8 +42,8 @@ Voici une arborescence type :
|
|||
|
||||
<div lang="en-US">
|
||||
```
|
||||
login_x-TP4/cmpns.sh
|
||||
login_x-TP4/mydocker_exec.sh
|
||||
login_x-TP4/myswitch_root.sh
|
||||
login_x-TP5/cmpns.sh
|
||||
login_x-TP5/mydocker_exec.sh
|
||||
login_x-TP5/myswitch_root.sh
|
||||
```
|
||||
</div>
|
||||
|
|
|
|||
|
|
@ -1,9 +1,9 @@
|
|||
---
|
||||
title: Virtualisation légère -- TP n^o^ 4
|
||||
title: Virtualisation légère -- TP n^o^ 5
|
||||
subtitle: Linux Internals partie 2
|
||||
author: Pierre-Olivier *nemunaire* [Mercier]{.smallcaps}
|
||||
institute: EPITA
|
||||
date: Mercredi 6 novembre 2019
|
||||
date: Jeudi 12 novembre 2020
|
||||
abstract: |
|
||||
Le but de ce second TP sur les mécanismes internes du noyau va nous
|
||||
permettre d'utiliser les commandes et les appels systèmes relatifs
|
||||
|
|
@ -13,12 +13,11 @@ abstract: |
|
|||
\vspace{1em}
|
||||
|
||||
Tous les exercices de ce TP sont à rendre à <virli@nemunai.re> au
|
||||
plus tard le mercredi 20 novembre 2017 à 13 h 42.
|
||||
plus tard le jeudi 19 novembre 2020 à 12 h 42.
|
||||
|
||||
En tant que personnes sensibilisées à la sécurité des échanges
|
||||
électroniques, vous devrez m'envoyer vos rendus signés avec votre
|
||||
clef PGP. Pensez à
|
||||
[me](https://keys.openpgp.org/search?q=nemunaire%40nemunai.re)
|
||||
faire signer votre clef et n'hésitez pas à [faire signer la
|
||||
En tant que personnes sensibilisées à la sécurité des échanges électroniques,
|
||||
vous devrez m'envoyer vos rendus signés avec votre clef PGP. Pensez à
|
||||
[me](https://keys.openpgp.org/search?q=nemunaire%40nemunai.re) faire signer
|
||||
votre clef et n'hésitez pas à [faire signer la
|
||||
votre](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
|
||||
...
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue