Note exercices, little rework for the book
This commit is contained in:
parent
0794ecaa2b
commit
bbd704d413
29 changed files with 210 additions and 120 deletions
|
|
@ -68,17 +68,17 @@ depuis un conteneur, par exemple :
|
|||
|
||||
<div lang="en-US">
|
||||
```
|
||||
42sh$ docker run -it --rm alpine
|
||||
42sh$ docker run -it --rm alpine
|
||||
|
||||
(ctnr)# apk add --no-cache acl iputils
|
||||
(1/4) Installing libacl (2.2.53-r0)
|
||||
(2/4) Installing acl (2.2.53-r0)
|
||||
(3/4) Installing libcap (2.50-r0)
|
||||
(4/4) Installing iputils (20210202-r0)
|
||||
(ctnr)# apk add --no-cache acl iputils
|
||||
(1/4) Installing libacl (2.2.53-r0)
|
||||
(2/4) Installing acl (2.2.53-r0)
|
||||
(3/4) Installing libcap (2.50-r0)
|
||||
(4/4) Installing iputils (20210202-r0)
|
||||
|
||||
(ctnr)# su -s/bin/ash daemon
|
||||
(ctnr)# su -s/bin/ash daemon
|
||||
|
||||
(ctnr)$ _
|
||||
(ctnr)$ _
|
||||
```
|
||||
</div>
|
||||
|
||||
|
|
@ -87,10 +87,10 @@ tests en retirant le *setuid* :
|
|||
|
||||
<div lang="en-US">
|
||||
```
|
||||
(ctnr)# chmod u-s /bin/ping
|
||||
(ctnr)# chmod u-s /bin/ping
|
||||
|
||||
(ctnr)$ ping epita.fr
|
||||
ping: socket: Operation not permitted
|
||||
(ctnr)$ ping epita.fr
|
||||
ping: socket: Operation not permitted
|
||||
```
|
||||
</div>
|
||||
|
||||
|
|
@ -98,10 +98,10 @@ Puis en ajoutant la *capability* :
|
|||
|
||||
<div lang="en-US">
|
||||
```
|
||||
(ctnr)# setcap cap_net_raw+p /bin/ping
|
||||
(ctnr)# setcap cap_net_raw+p /bin/ping
|
||||
|
||||
(ctnr)$ ping epita.fr
|
||||
PING epita.fr (172.67.156.141) 56(84) bytes of data.
|
||||
(ctnr)$ ping epita.fr
|
||||
PING epita.fr (172.67.156.141) 56(84) bytes of data.
|
||||
```
|
||||
</div>
|
||||
|
||||
|
|
@ -200,8 +200,9 @@ du fichier ; et on peut l'afficher dans sa version plus lisible :
|
|||
```
|
||||
</div>
|
||||
|
||||
::::: {.exercice}
|
||||
|
||||
### Exercice : visualisateur de capabilities d'un processus {-}
|
||||
### Visualisateur de capabilities d'un processus {-}
|
||||
|
||||
Écrivons maintenant un programme permettant de voir les *capabilities*
|
||||
d'un processus :
|
||||
|
|
@ -241,6 +242,7 @@ courant.
|
|||
|
||||
Astuces : `capget(2)`, X-macros, ...
|
||||
|
||||
:::::
|
||||
|
||||
### Pour aller plus loin {-}
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
::::: {.exercice}
|
||||
|
||||
### Exercice (obligatoire pour les SRS -- optionnel pour les GISTRE)
|
||||
|
||||
Poursuivons [notre script de monitoring](#script-monitoring) afin d'envoyer nos
|
||||
|
|
@ -85,3 +87,5 @@ particuliers.
|
|||
42sh$ ./telegraf.sh my_cgroup_name memhog 500
|
||||
```
|
||||
</div>
|
||||
|
||||
:::::
|
||||
|
|
|
|||
|
|
@ -79,10 +79,10 @@ l'une de ces trois situations :
|
|||
```
|
||||
</div>
|
||||
|
||||
::::: {.question}
|
||||
Avant d'aller plus loin, notez que les exemples seront donnés pour les deux
|
||||
versions des `cgroup`s à chaque fois.
|
||||
|
||||
::::: {.question}
|
||||
La principale différence entre les deux est la fusion des différents
|
||||
sous-systèmes au sein d'une même arborescence. Dans la première version, chaque
|
||||
sous-système disposait de sa propre arborescence et il fallait créer les
|
||||
|
|
@ -179,11 +179,15 @@ En validant cette commande, nous avons déplacé le processus dans ce groupe, il
|
|||
n'est alors plus dans aucun autre groupe (pour ce *cgroup*, il ne bouge pas
|
||||
dans les autres *cgroup*s).
|
||||
|
||||
::::: {.question}
|
||||
|
||||
Malgré l'utilisation de la redirection `>` (et non `>>`), il s'agit bel et
|
||||
bien d'un ajout au fichier et non d'un écrasement. Il faut garder en tête que
|
||||
le système de fichier est entièrement simulé et que certains comportements sont
|
||||
adaptés.
|
||||
|
||||
:::::
|
||||
|
||||
|
||||
### Consultation de l'état
|
||||
|
||||
|
|
@ -233,7 +237,9 @@ echo 0 > /sys/fs/cgroup/virli/cgroup.freeze # v2
|
|||
</div>
|
||||
|
||||
|
||||
### Exercice : script de monitoring {- #script-monitoring}
|
||||
::::: {.exercice}
|
||||
|
||||
### Script de monitoring {- #script-monitoring}
|
||||
|
||||
À nous maintenant de concevoir un script qui va enregistrer vers une base de
|
||||
données des statistiques issues des *cgroup*s, tel `telegraf`.
|
||||
|
|
@ -266,7 +272,6 @@ mémoire.
|
|||
```
|
||||
</div>
|
||||
|
||||
::::: {.question}
|
||||
Le modèle de sortie standard de votre script `monitor` n'a pas d'importance, il
|
||||
doit cependant être possible d'y trouver des statistiques intéressantes, dont
|
||||
la quantité de mémoire utilisée. Ici nous affichons au début le PID du
|
||||
|
|
@ -285,7 +290,6 @@ Où :
|
|||
- `group_name` correspond au nom du/des *cgroup*(s) à créer/rejoindre.
|
||||
- `prog [args [...]]` est la commande que l'on souhaite monitorer, à exécuter
|
||||
dans le *cgroup*.
|
||||
:::::
|
||||
|
||||
::::: {.warning}
|
||||
Si vous n'avez pas le *cgroup* *memory*, il est possible qu'il ne soit pas
|
||||
|
|
@ -293,6 +297,7 @@ activé par défaut par votre système. Si vous êtes dans ce cas, essayez
|
|||
d'ajouter `cgroup_enable=memory` à la ligne de commande de votre noyau.
|
||||
:::::
|
||||
|
||||
:::::
|
||||
|
||||
### Fixer des limites {#Fixer-des-limites}
|
||||
|
||||
|
|
@ -357,5 +362,8 @@ limites que vous avez définies :
|
|||
### Pour aller plus loin {-}
|
||||
|
||||
Pour tout connaître en détails, [la série d'articles de Neil Brown sur les
|
||||
Control groups](https://lwn.net/Articles/604609/) est excellente ! Plus [cet
|
||||
article sur la version 2](https://lwn.net/Articles/679786/).
|
||||
Control groups](https://lwn.net/Articles/604609/)[^lwncgroups] est excellente !
|
||||
Plus [cet article sur la version 2](https://lwn.net/Articles/679786/)[^lwncgroupsv2].
|
||||
|
||||
[^lwncgroups]: <https://lwn.net/Articles/604609/>
|
||||
[^lwncgroupsv2]: <https://lwn.net/Articles/679786/>
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
::::: {.exercice}
|
||||
|
||||
## Exercice (SRS seulement) {-}
|
||||
|
||||
Écrivons maintenant un programme dont le seul but est de s'échapper du `chroot` :
|
||||
|
|
@ -26,3 +28,5 @@ Mais une fois votre programme `escape` exécuté, vous devriez pouvoir !
|
|||
bash# cat /path/to/foo
|
||||
```
|
||||
</div>
|
||||
|
||||
:::::
|
||||
|
|
|
|||
|
|
@ -1,8 +1,6 @@
|
|||
Prérequis
|
||||
---------
|
||||
|
||||
### Noyau Linux
|
||||
|
||||
Pour pouvoir suivre les exemples et faire les exercices qui suivent, vous aurez
|
||||
besoin d'un noyau Linux récent (une version 5.x sera très bien). Il doit de
|
||||
plus être compilé avec les options suivantes (lorsqu'elles sont disponibles
|
||||
|
|
@ -29,10 +27,18 @@ General setup --->
|
|||
```
|
||||
</div>
|
||||
|
||||
Si vous utilisez un noyau standard fourni par votre distribution, les options
|
||||
requises seront a priori déjà sélectionnées et vous n'aurez donc pas à compiler
|
||||
votre propre noyau. Néanmoins, nous allons nous interfacer avec le noyau, il
|
||||
est donc nécessaire d'avoir les en-têtes de votre noyau.
|
||||
|
||||
#### Vérification via `menuconfig`\
|
||||
Sous Debian, vous pouvez les installer via le paquet au nom semblable à
|
||||
`linux-headers`. Le paquet porte le même nom sous Arch Linux et ses dérivés.
|
||||
|
||||
L'arbre ci-dessous correspond aux options qui seront *built-in* (signalées par
|
||||
|
||||
### Vérification via `menuconfig`
|
||||
|
||||
L'arbre ci-dessus correspond aux options qui seront *built-in* (signalées par
|
||||
une `*`) ou installées en tant que module (signalées par un `M`). En effet,
|
||||
chaque noyau Linux peut être entièrement personnalisé en fonction des options
|
||||
et des pilotes que l'on voudra utiliser.
|
||||
|
|
@ -50,7 +56,7 @@ make menuconfig
|
|||
</div>
|
||||
|
||||
|
||||
#### Vérification via `/boot/config-xxx`\
|
||||
### Vérification via `/boot/config-xxx`
|
||||
|
||||
Les distributions basées sur Debian ont pour habitude de placer le fichier de
|
||||
configuration ayant servi à compiler le noyau et ses modules dans le dossier
|
||||
|
|
@ -80,22 +86,10 @@ CONFIG_CGROUP_NET_CLASSID=y
|
|||
</div>
|
||||
|
||||
|
||||
#### Vérification via `/proc/config.gz`\
|
||||
### Vérification via `/proc/config.gz`
|
||||
|
||||
Dans la plupart des autres distributions, la configuration est accessible à
|
||||
travers le fichier `/proc/config.gz`. Comme vous ne pouvez pas écrire dans
|
||||
`/proc` pour décompresser le fichier, utilisez les outils `zcat`, `zgrep`, ...
|
||||
|
||||
Vous devez retrouver les mêmes options que celles de la section précédente.
|
||||
|
||||
|
||||
|
||||
### Présence des en-têtes
|
||||
|
||||
Si vous utilisez un noyau standard fourni par votre distribution, les options
|
||||
requises seront a priori déjà sélectionnées et vous n'aurez donc pas à compiler
|
||||
votre propre noyau. Néanmoins, nous allons nous interfacer avec le noyau, il
|
||||
est donc nécessaire d'avoir les en-têtes de votre noyau.
|
||||
|
||||
Sous Debian, vous pouvez les installer via le paquet au nom semblable à
|
||||
`linux-headers`. Le paquet porte le même nom sous Arch Linux et ses dérivés.
|
||||
|
|
|
|||
|
|
@ -42,20 +42,24 @@ jusqu'à ce que le système retrouve sa sérénité.
|
|||
## Esquiver l'OOM killer ?
|
||||
|
||||
Au sein d'un *cgroup* *memory*, les fichiers `memory.oom_control` (v1) ou
|
||||
`memory.events` (v2) peuvent être utilisé afin de recevoir une notification du
|
||||
`memory.events` (v2) peuvent être utilisés afin de recevoir une notification du
|
||||
noyau avant que l'OOM-killer ne s'attaque à un processus de ce groupe.
|
||||
|
||||
Grâce à cette notification, il est possible de figer le processus pour
|
||||
l'envoyer sur une autre machine. Et ainsi libérer la mémoire avant que l'OOM
|
||||
killer ne passe.
|
||||
|
||||
Jetez un œil à [cet article parru sur LWN](https://lwn.net/Articles/590960/) à
|
||||
ce sujet.
|
||||
Jetez un œil à [cet article paru sur LWN](https://lwn.net/Articles/590960/) à
|
||||
ce sujet :\
|
||||
<https://lwn.net/Articles/590960/>
|
||||
|
||||
::::: {.exercice}
|
||||
|
||||
## À vous de jouer {-}
|
||||
#### À vous de jouer {-}\
|
||||
|
||||
Continuons l'exercice précédent où nous avions [fixé les
|
||||
limites](#Fixer-des-limites) de mémoire que pouvez réserver les processus de
|
||||
notre groupe. Que se passe-t-il alors si `memhog` dépasse la quantité de
|
||||
mémoire autorisée dans le `cgroup` ?
|
||||
|
||||
:::::
|
||||
|
|
|
|||
|
|
@ -57,7 +57,7 @@ exemple, pour modifier les paramètres du noyau, on passe par le fichier
|
|||
`/etc/sysctl.conf` et du programme `sysctl`.
|
||||
|
||||
|
||||
#### Consultation et modification\
|
||||
### Consultation et modification
|
||||
|
||||
La consultation d'un élément se fait généralement à l'aide d'un simple `cat` :
|
||||
|
||||
|
|
@ -79,7 +79,7 @@ La modification d'un élément se fait avec `echo`, comme ceci :
|
|||
Vous devriez constater l'effet de cette commande sans plus attendre !
|
||||
|
||||
|
||||
### Exercices
|
||||
::::: {.exercice}
|
||||
|
||||
#### `procinfo`\
|
||||
|
||||
|
|
@ -158,7 +158,7 @@ Remaining time: N/A
|
|||
```
|
||||
</div>
|
||||
|
||||
Pour les détails sur l'organisation de ce dossier, regardez :
|
||||
Pour les détails sur l'organisation de ce dossier, regardez :\
|
||||
<https://www.kernel.org/doc/Documentation/power/power_supply_class.txt>.
|
||||
|
||||
|
||||
|
|
@ -243,7 +243,7 @@ Voici un exemple d'utilisation :
|
|||
|
||||
Vous aurez besoin de définir une alarme au niveau de votre RTC, via le
|
||||
fichier :\
|
||||
`/sys/class/rtc/rtcX/wakealarm`
|
||||
`/sys/class/rtc/rtcX/wakealarm`\
|
||||
|
||||
::::: {.warning}
|
||||
Attention au fuseau horaire utilisé par votre RTC, si votre système principal
|
||||
|
|
@ -251,7 +251,7 @@ est Windows, elle utilisera sans doute le fuseau horaire courant. Sinon, ce
|
|||
sera UTC.
|
||||
:::::
|
||||
|
||||
::::: {.more}
|
||||
Un article très complet sur le sujet est disponible ici :
|
||||
Un article très complet sur le sujet est disponible ici :\
|
||||
<https://www.linux.com/tutorials/wake-linux-rtc-alarm-clock/>
|
||||
|
||||
:::::
|
||||
|
|
|
|||
|
|
@ -77,7 +77,7 @@ seccomp(SECCOMP_SET_MODE_FILTER, 0, &prog);
|
|||
</div>
|
||||
|
||||
|
||||
### Exercice {-}
|
||||
::::: {.exercice}
|
||||
|
||||
Écrivez un programme filtrant un appel système, à l'aide de `seccomp` :
|
||||
|
||||
|
|
@ -90,3 +90,5 @@ sleep: cannot read realtime clock: Operation not permitted
|
|||
</div>
|
||||
|
||||
Dans cet exemple, l'appel système filtré est `nanosleep(2)`.
|
||||
|
||||
:::::
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue