Note exercices, little rework for the book
This commit is contained in:
parent
0794ecaa2b
commit
bbd704d413
|
|
@ -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)`.
|
||||
|
||||
:::::
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
\newpage
|
||||
|
||||
### Exercice : comparaison de *namespace* -- `cmpns.sh`
|
||||
::::: {.exercice}
|
||||
|
||||
### Comparaison de *namespace* -- `cmpns.sh`
|
||||
|
||||
Les *namespaces* d'un programme sont exposés sous forme de liens symboliques
|
||||
dans le répertoire `/proc/<PID>/ns/`.
|
||||
|
|
@ -63,3 +65,5 @@ Et pourquoi pas :
|
|||
- uts: same
|
||||
```
|
||||
</div>
|
||||
|
||||
:::::
|
||||
|
|
|
|||
|
|
@ -1,7 +1,9 @@
|
|||
\newpage
|
||||
|
||||
Exercice : `docker exec`
|
||||
------------------------
|
||||
::::: {.exercice}
|
||||
|
||||
`docker exec`
|
||||
-------------
|
||||
|
||||
Après voir lu la partie concernant les *namespaces*, vous avez dû comprendre
|
||||
qu'un `docker exec`, n'était donc rien de plus qu'un `nsenter(1)`.
|
||||
|
|
@ -46,3 +48,5 @@ d63ceae86395
|
|||
...
|
||||
```
|
||||
</div>
|
||||
|
||||
:::::
|
||||
|
|
|
|||
|
|
@ -13,8 +13,7 @@ systèmes de fichiers.
|
|||
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 le TP
|
||||
précédent.
|
||||
physique... ou d'une partition virtuelle, comme nous l'avons vu précédemment.
|
||||
|
||||
Mais avez-vous déjà essayé de monter la même partition d'un disque physique à
|
||||
deux endroits différents de votre arborescence ?
|
||||
|
|
@ -35,30 +34,30 @@ d'avoir une vision arborescente des points de montage en cours d'utilisation.
|
|||
```
|
||||
TARGET SOURCE FSTYPE OPTIONS
|
||||
/ /dev/sda1 ext4 rw,relatime,data=ordered
|
||||
├─/proc proc proc rw,nosuid,nodev,noexec,relatime
|
||||
├─/sys sysfs sysfs rw,nosuid,nodev,noexec,relatime
|
||||
│ ├─/sys/kernel/security securityfs securityfs rw,nosuid,nodev,noexec,relatime
|
||||
│ ├─/sys/firmware/efi/efivars efivarfs efivarfs ro,relatime
|
||||
│ └─/sys/fs/cgroup cgroup_root tmpfs rw,nosuid,nodev,noexec,relatime,size=10240k,mode=755
|
||||
│ ├─/sys/fs/cgroup/unified none cgroup2 rw,nosuid,nodev,noexec,relatime
|
||||
│ ├─/sys/fs/cgroup/cpuset cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset
|
||||
│ ├─/sys/fs/cgroup/cpu cpu cgroup rw,nosuid,nodev,noexec,relatime,cpu
|
||||
│ ├─/sys/fs/cgroup/cpuacct cpuacct cgroup rw,nosuid,nodev,noexec,relatime,cpuacct
|
||||
│ ├─/sys/fs/cgroup/blkio blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio
|
||||
│ ├─/sys/fs/cgroup/memory memory cgroup rw,nosuid,nodev,noexec,relatime,memory
|
||||
│ ├─/sys/fs/cgroup/devices devices cgroup rw,nosuid,nodev,noexec,relatime,devices
|
||||
│ ├─/sys/fs/cgroup/freezer freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer
|
||||
│ ├─/sys/fs/cgroup/net_cls net_cls cgroup rw,nosuid,nodev,noexec,relatime,net_cls
|
||||
│ ├─/sys/fs/cgroup/perf_event perf_event cgroup rw,nosuid,nodev,noexec,relatime,perf_event
|
||||
│ ├─/sys/fs/cgroup/net_prio net_prio cgroup rw,nosuid,nodev,noexec,relatime,net_prio
|
||||
│ └─/sys/fs/cgroup/pids pids cgroup rw,nosuid,nodev,noexec,relatime,pids
|
||||
├─/dev devtmpfs devtmpfs rw,nosuid,size=10240k,nr_inodes=486250,mode=755
|
||||
│ ├─/dev/pts devpts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000
|
||||
│ ├─/dev/shm tmpfs tmpfs rw
|
||||
│ └─/dev/mqueue mqueue mqueue rw,nosuid,nodev,noexec,relatime
|
||||
├─/home /dev/sda3 ext4 rw,nosuid,nodev,relatime,data=ordered
|
||||
├─/run tmpfs tmpfs rw,nosuid,nodev,noexec,mode=755
|
||||
└─/tmp tmpfs tmpfs rw,nosuid,nodev,noexec,relatime
|
||||
/proc proc proc rw,nosuid,nodev,noexec,relatime
|
||||
/sys sysfs sysfs rw,nosuid,nodev,noexec,relatime
|
||||
├─/sys/kernel/security securityfs securityfs rw,nosuid,nodev,noexec,relatime
|
||||
├─/sys/firmware/efi/efivars efivarfs efivarfs ro,relatime
|
||||
└─/sys/fs/cgroup cgroup_root tmpfs rw,nosuid,nodev,noexec,relatime
|
||||
├─/sys/fs/cgroup/unified none cgroup2 rw,nosuid,nodev,noexec,relatime
|
||||
├─/sys/fs/cgroup/cpuset cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset
|
||||
├─/sys/fs/cgroup/cpu cpu cgroup rw,nosuid,nodev,noexec,relatime,cpu
|
||||
├─/sys/fs/cgroup/cpuacct cpuacct cgroup rw,nosuid,nodev,noexec,relatime,cpuacct
|
||||
├─/sys/fs/cgroup/blkio blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio
|
||||
├─/sys/fs/cgroup/memory memory cgroup rw,nosuid,nodev,noexec,relatime,memory
|
||||
├─/sys/fs/cgroup/devices devices cgroup rw,nosuid,nodev,noexec,relatime,devices
|
||||
├─/sys/fs/cgroup/freezer freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer
|
||||
├─/sys/fs/cgroup/net_cls net_cls cgroup rw,nosuid,nodev,noexec,relatime,net_cls
|
||||
├─/sys/fs/cgroup/perf_event perf_event cgroup rw,nosuid,nodev,noexec,relatime,p_event
|
||||
├─/sys/fs/cgroup/net_prio net_prio cgroup rw,nosuid,nodev,noexec,relatime,net_pri
|
||||
└─/sys/fs/cgroup/pids pids cgroup rw,nosuid,nodev,noexec,relatime,pids
|
||||
/dev devtmpfs devtmpfs rw,nosuid,size=10240k,nr_inodes=486250
|
||||
├─/dev/pts devpts devpts rw,nosuid,noexec,relatime,gid=5,ptmxmod
|
||||
├─/dev/shm tmpfs tmpfs rw
|
||||
└─/dev/mqueue mqueue mqueue rw,nosuid,nodev,noexec,relatime
|
||||
/home /dev/sda3 ext4 rw,nosuid,nodev,relatime,data=ordered
|
||||
/run tmpfs tmpfs rw,nosuid,nodev,noexec,mode=755
|
||||
/tmp tmpfs tmpfs rw,nosuid,nodev,noexec,relatime
|
||||
```
|
||||
</div>
|
||||
|
||||
|
|
|
|||
|
|
@ -63,8 +63,9 @@ Si vous n'avez pas de partition à disposition, vous pouvez utiliser un `tmpfs`
|
|||
|
||||
Placez ensuite dans cette nouvelle racine le système de votre choix.
|
||||
|
||||
::::: {.exercice}
|
||||
|
||||
### Exercice : Changer de racine -- `myswitch_root.sh`
|
||||
### Changer de racine -- `myswitch_root.sh`
|
||||
|
||||
Voici les grandes étapes du changement de racine :
|
||||
|
||||
|
|
@ -150,3 +151,5 @@ par :
|
|||
42sh# exec chroot / command
|
||||
```
|
||||
</div>
|
||||
|
||||
:::::
|
||||
|
|
|
|||
|
|
@ -4,11 +4,11 @@ Je vous recommande la lecture du *man* `namespaces(7)` introduisant et
|
|||
énumérant les *namespaces*.
|
||||
|
||||
Pour tout connaître en détails, [la série d'articles de Michael Kerrisk sur les
|
||||
*namespaces*](https://lwn.net/Articles/531114/) est excellente ! Auquel il faut
|
||||
*namespaces*](https://lwn.net/Articles/531114/)[^lwnns1] est excellente ! Auquel il faut
|
||||
ajouter [l'article sur le plus récent `cgroup`
|
||||
*namespace*](https://lwn.net/Articles/621006/) et [le petit dernier sur le
|
||||
*namespace* `time`](https://lwn.net/Articles/766089/).
|
||||
*namespace*](https://lwn.net/Articles/621006/)[^lwnns2] et [le petit dernier sur le
|
||||
*namespace* `time`](https://lwn.net/Articles/766089/)[^lwnns3].
|
||||
|
||||
[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.
|
||||
[^lwnns1]: <https://lwn.net/Articles/531114/>
|
||||
[^lwnns2]: <https://lwn.net/Articles/621006/>
|
||||
[^lwnns3]: <https://lwn.net/Articles/766089/>
|
||||
|
|
|
|||
|
|
@ -234,8 +234,11 @@ 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).
|
||||
[Linux Containers and Networking](https://blog.flameeyes.eu/2010/09/linux-containers-and-networking)[^netnsmore1].
|
||||
|
||||
Appliqué à Docker, vous apprécierez cet article : [Understanding Docker
|
||||
Networking Drivers and their use
|
||||
cases](https://www.docker.com/blog/understanding-docker-networking-drivers-use-cases/).
|
||||
cases](https://www.docker.com/blog/understanding-docker-networking-drivers-use-cases/)[^netnsmore2].
|
||||
|
||||
[^netnsmore1]: <https://blog.flameeyes.eu/2010/09/linux-containers-and-networking>
|
||||
[^netnsmore2]: <https://www.docker.com/blog/understanding-docker-networking-drivers-use-cases/>
|
||||
|
|
|
|||
|
|
@ -81,8 +81,10 @@ La sécurité du *namespace* `user` a souvent été remise en cause par le pass
|
|||
on lui attribue de nombreuses vulnérabilités. Vous devriez notamment consulter
|
||||
à ce sujet :
|
||||
|
||||
* [Security Implications of User Namespaces](https://blog.araj.me/security-implications-of-user-namespaces/) ;
|
||||
* [Anatomy of a user namespaces vulnerability](https://lwn.net/Articles/543273/) ;
|
||||
* [Security Implications of User Namespaces](https://blog.araj.me/security-implications-of-user-namespaces/) :\
|
||||
<https://blog.araj.me/security-implications-of-user-namespaces/> ;
|
||||
* [Anatomy of a user namespaces vulnerability](https://lwn.net/Articles/543273/) :\
|
||||
<https://lwn.net/Articles/543273/> ;
|
||||
* <http://marc.info/?l=linux-kernel&m=135543612731939&w=2> ;
|
||||
* <http://marc.info/?l=linux-kernel&m=135545831607095&w=2>.
|
||||
|
||||
|
|
|
|||
|
|
@ -21,6 +21,17 @@ function Div(el)
|
|||
el.content,
|
||||
pandoc.RawBlock("latex", "\\end{codebox}"))
|
||||
|
||||
elseif el.classes[1] == "exercice"
|
||||
then
|
||||
-- insert element in front
|
||||
table.insert(
|
||||
el.content, 1,
|
||||
pandoc.RawBlock("latex", "\\noindent\\begin{exercicebox}"))
|
||||
-- insert element at the back
|
||||
table.insert(
|
||||
el.content,
|
||||
pandoc.RawBlock("latex", "\\end{exercicebox}"))
|
||||
|
||||
elseif el.classes[1] == "question"
|
||||
then
|
||||
-- insert element in front
|
||||
|
|
|
|||
|
|
@ -69,7 +69,7 @@ docker run --rm -p 8080:8080 localhost:5000/youp0m
|
|||
```
|
||||
</div>
|
||||
|
||||
::::: {.more}
|
||||
::::: {.question}
|
||||
On notera que ceci est possible exclusivement parce que le registre
|
||||
`localhost:5000` est considéré non-sûr par défaut. C'est à dire qu'il n'a pas
|
||||
besoin de certificat TLS sur sa connexion HTTP pour être utilisé.\
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ Dans un premier temps, nous allons nous contenter de publier un binaire associé
|
|||
|
||||
### Installation et configuration
|
||||
|
||||
Allez c'est parti ! première chose à faire : installer et configurer
|
||||
Aller c'est parti ! première chose à faire : installer et configurer
|
||||
[Gitea](https://gitea.io/) (ceux qui le souhaitent peuvent choisir
|
||||
[gitlab](https://gitlab.org/) ou une autre plate-forme, mais la suite sera
|
||||
moins guidée).
|
||||
|
|
|
|||
|
|
@ -116,14 +116,14 @@ Dans ce dernier exemple, nous n'avons pas besoin de préciser l'hôte, car
|
|||
dans notre conteneur `mytsdb`, il s'agit bien du conteneur où s'exécute
|
||||
localement `influxdb`.
|
||||
|
||||
|
||||
#### Exercice {-}
|
||||
::::: {.exercice}
|
||||
|
||||
Ajoutez à la ligne de commande de lancement du conteneur les bon(s) volume(s)
|
||||
qui permettront de ne pas perdre les données d'influxDB si nous devions
|
||||
redémarrer le conteneur. Aidez-vous pour cela de la [documentation du
|
||||
conteneur](https://hub.docker.com/_/influxdb).
|
||||
|
||||
:::::
|
||||
|
||||
### Collecter les données locales
|
||||
|
||||
|
|
@ -192,11 +192,10 @@ system
|
|||
La nouvelle base a donc bien été créée et tant que nous laissons *Telegraf*
|
||||
lancé, celui-ci va régulièrement envoyer des métriques de cette machine.
|
||||
|
||||
::::: {.exercice}
|
||||
|
||||
### Afficher les données collectées
|
||||
|
||||
#### Exercice {-}
|
||||
|
||||
À vous de jouer pour lancer le conteneur
|
||||
[*Chronograf*](https://store.docker.com/images/chronograf).
|
||||
|
||||
|
|
@ -214,4 +213,6 @@ ceux ci-après :
|
|||
|
||||
:::::
|
||||
|
||||
:::::
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,4 @@
|
|||
Exercice {-}
|
||||
--------
|
||||
::::: {.exercice}
|
||||
|
||||
Pour mettre en pratiques toutes les notions que l'on a vu jusque là, écrivez un
|
||||
script `mycloud-run.sh` pour automatiser le lancement de votre instance
|
||||
|
|
@ -45,3 +44,5 @@ http://localhost:12345/
|
|||
http://localhost:12345/
|
||||
```
|
||||
</div>
|
||||
|
||||
:::::
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
## Exercice {-}
|
||||
::::: {.exercice}
|
||||
|
||||
À vous maintenant de connecter une instance de `nemunaire/fic-admin` à sa base
|
||||
de données.
|
||||
|
|
@ -42,3 +42,5 @@ http://localhost:12345/
|
|||
http://localhost:12345/
|
||||
```
|
||||
</div>
|
||||
|
||||
:::::
|
||||
|
|
|
|||
|
|
@ -217,7 +217,7 @@ une interface `virtual ethernet` :
|
|||
</div>
|
||||
|
||||
|
||||
## Exercice {-}
|
||||
::::: {.exercice}
|
||||
|
||||
Réalisez une recette `vault.yml` démarrant une instance du gestionnaire de
|
||||
secrets [Hashicorp Vault](https://www.vaultproject.io/), utilisant une [base de
|
||||
|
|
@ -241,3 +241,5 @@ conteneurs, sans quoi vos conteneurs risquent d'être tués prématurément.
|
|||
En bonus, vous pouvez gérer la [persistance des
|
||||
données](https://github.com/linuxkit/linuxkit/blob/master/examples/swap.yml)
|
||||
stockées dans Vault.
|
||||
|
||||
:::::
|
||||
|
|
|
|||
|
|
@ -160,7 +160,7 @@ Hello from Docker!
|
|||
</div>
|
||||
|
||||
|
||||
## Exercice {-}
|
||||
::::: {.exercice}
|
||||
|
||||
Réalisez un script pour automatiser l'ensemble de ces étapes :
|
||||
|
||||
|
|
@ -189,3 +189,5 @@ similaire au driver `vfs` : en extrayant chaque tarball l'une au dessus de
|
|||
l'autre, en essayant de gérer les *whiteout files*. Ou bien en suivant le
|
||||
driver `overlayfs`, en montant un système de fichier à chaque couche (dans ce
|
||||
cas, votre script devra être lancé en `root`).
|
||||
|
||||
:::::
|
||||
|
|
|
|||
|
|
@ -124,8 +124,7 @@ ajouter un élément à cette liste, demandant de *bind* :
|
|||
```
|
||||
</div>
|
||||
|
||||
|
||||
## Exercice {-}
|
||||
::::: {.exercice}
|
||||
|
||||
À vous maintenant d'éditer votre `config.json`, pour lancer le service youp0m.
|
||||
|
||||
|
|
@ -146,3 +145,5 @@ Pour cette étape, Considérez que vous avez réussi si vous voyez s'afficher :
|
|||
> `Ready, listening on :8080`
|
||||
|
||||
On ne pourra pas tester davantage sans avoir du réseau dans notre conteneur.
|
||||
|
||||
:::::
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
## Exercice {-}
|
||||
::::: {.exercice}
|
||||
|
||||
Déterminez le nombre de vulnérabilités dans les principales images officielles
|
||||
du [Docker Hub](https://hub.docker.com/explore).
|
||||
|
|
@ -9,3 +9,5 @@ contenant les vulnérabilités les plus inquiétantes. Vous placerez ce rapport
|
|||
dans un fichier `${IMAGE}:${TAG}.html` ou `${IMAGE}:${TAG}.txt`.
|
||||
|
||||
Veillez à utiliser une image __différente__ de `mysql`, utilisée en exemple.
|
||||
|
||||
:::::
|
||||
|
|
|
|||
|
|
@ -133,6 +133,8 @@ Dans un autre terminal, lançons un `docker container ls`, pour consulter la col
|
|||
|
||||
Rendez-vous ensuite dans votre navigateur sur <http://localhost:49153/>.
|
||||
|
||||
:::::: {.exercice}
|
||||
|
||||
#### À vous de jouer {-}
|
||||
|
||||
Utilisez l'instruction `COPY`{.dockerfile} pour afficher votre propre
|
||||
|
|
@ -140,6 +142,7 @@ Utilisez l'instruction `COPY`{.dockerfile} pour afficher votre propre
|
|||
d'inspiration, utilisez [cette page de compte à
|
||||
rebours](https://virli.nemunai.re/countdown.html).-->
|
||||
|
||||
:::::
|
||||
|
||||
### Les caches
|
||||
|
||||
|
|
@ -307,7 +310,7 @@ Consultez <https://docs.docker.com/engine/reference/builder/> pour la liste
|
|||
complète des instructions reconnues.
|
||||
|
||||
|
||||
### Exercice {-}
|
||||
::::: {.exercice}
|
||||
|
||||
Pour mettre en application tout ce que nous venons de voir, réalisons le
|
||||
`Dockerfile` du service web [`youp0m`](https://you.p0m.fr/) que nous avons
|
||||
|
|
@ -329,3 +332,5 @@ WORKDIR /go/src/git.nemunai.re/youp0m
|
|||
RUN go build -tags dev -v
|
||||
```
|
||||
</div>
|
||||
|
||||
:::::
|
||||
|
|
|
|||
|
|
@ -70,6 +70,7 @@ possibilité de le surcharger au moyen d'un argument :
|
|||
```
|
||||
</div>
|
||||
|
||||
::::: {.exerice}
|
||||
|
||||
## Personnalisation basique
|
||||
|
||||
|
|
@ -100,6 +101,7 @@ Pour améliorer la situation, définissez
|
|||
l'[`ENTRYPOINT`{.dockerfile}](https://docs.docker.com/engine/reference/builder/#entrypoint)
|
||||
de votre image sur le binaire `/srv/youp0m`.
|
||||
|
||||
:::::
|
||||
|
||||
## Point d'entrée avancé
|
||||
|
||||
|
|
@ -162,8 +164,7 @@ pouvons obtenir un fichier valide avec :
|
|||
Il faut ensuite passer le chemin du fichier créé sur la ligne de commande grâce
|
||||
à l'option `-htpasswd`.
|
||||
|
||||
|
||||
### Exercice {-}
|
||||
::::: {.exercice}
|
||||
|
||||
Écrivez un script d'`ENTRYPOINT`{.dockerfile}, analysant les variables
|
||||
d'environnement, à la recherche de `YOUP0M_USERNAME` et `YOUP0M_PASSWORD` pour
|
||||
|
|
@ -184,3 +185,5 @@ You are not allowed to perform this request.
|
|||
<!DOCTYPE html>
|
||||
```
|
||||
</div>
|
||||
|
||||
:::::
|
||||
|
|
|
|||
|
|
@ -51,11 +51,14 @@ docker buildx build .
|
|||
```
|
||||
</div>
|
||||
|
||||
::::: {.more}
|
||||
|
||||
Nous ne rentrerons pas plus dans les détails de cette nouvelle commande, mais
|
||||
sachez qu'on la retrouve particulièrement fréquemment dans les *GitHub
|
||||
Actions* :\
|
||||
<https://github.com/marketplace/actions/docker-setup-buildx>
|
||||
|
||||
:::::
|
||||
|
||||
#### Changer la syntaxe de nos `Dockerfile`\
|
||||
|
||||
|
|
@ -113,13 +116,13 @@ ou 1.3 (expérimentale).
|
|||
Les ajouts par rapport à la syntaxe usuelle sont répertoriés sur cette page :\
|
||||
<https://hub.docker.com/r/docker/dockerfile>.
|
||||
|
||||
|
||||
### Exercice {-}
|
||||
::::: {.exercice}
|
||||
|
||||
Faites en sorte que le `Dockerfile` que vous avez créé pour `youp0m` indique un
|
||||
*frontend* BuildKit à utiliser, tout en restant compatible avec la syntaxe du
|
||||
`docker build` classique.
|
||||
|
||||
:::::
|
||||
|
||||
### Des images sans Docker
|
||||
|
||||
|
|
@ -127,7 +130,7 @@ Il est aussi possible de se passer complètement de Docker. La plupart des
|
|||
outils qui sont capables de générer des images de machines virtuelles, sont
|
||||
aussi capable de générer des images Docker. Citons notamment :
|
||||
|
||||
- [Hashicorp Packer](https://www.packer.io/docs/builders/docker)
|
||||
- [Nix et Guix](https://nix.dev/tutorials/building-and-running-docker-images)
|
||||
- [Kubler](https://github.com/edannenberg/kubler)
|
||||
- [Hashicorp Packer](https://www.packer.io/docs/builders/docker),
|
||||
- [Nix et Guix](https://nix.dev/tutorials/building-and-running-docker-images),
|
||||
- [Kubler](https://github.com/edannenberg/kubler),
|
||||
- et bien d'autres.
|
||||
|
|
|
|||
|
|
@ -5,8 +5,8 @@
|
|||
spread sidewards,fuzzy halo=1mm with ForestGreen!50!black}
|
||||
|
||||
\newtcolorbox{alertbox}[1][]{breakable,enhanced,
|
||||
before skip balanced=2mm,after skip balanced=3mm,
|
||||
tile,left=11mm,right=2mm,top=1mm,bottom=1mm,
|
||||
before=\hspace{.7em},after=\hspace{.5em},
|
||||
tile,left=11mm,right=2mm,top=.5em,bottom=.5em,
|
||||
colback=white!0,
|
||||
sharp corners,
|
||||
colback=lightgray!20!white,
|
||||
|
|
@ -15,8 +15,8 @@
|
|||
},#1}
|
||||
|
||||
\newtcolorbox{codebox}[1][]{breakable,enhanced,
|
||||
before skip balanced=2mm,after skip balanced=3mm,
|
||||
tile,left=11mm,right=2mm,top=1mm,bottom=1mm,
|
||||
before=\hspace{.7em},after=\hspace{.5em},
|
||||
tile,left=11mm,right=2mm,top=.5em,bottom=.5em,
|
||||
colback=white!0,
|
||||
sharp corners,
|
||||
colback=lightgray!20!white,
|
||||
|
|
@ -24,9 +24,33 @@
|
|||
\path[fill=black,draw=none] (interior.south west) rectangle node[white]{\huge\bfseries\texttt >\_} ([xshift=10mm]interior.north west);
|
||||
},#1}
|
||||
|
||||
\usetikzlibrary{calc}
|
||||
\newtcolorbox{exercicebox}[1][parbox=false]{breakable,enhanced,
|
||||
before=\hspace{.7em},after=\hspace{.5em},
|
||||
tile,left=2mm,right=12mm,top=.5em,bottom=.5em,
|
||||
frame code={\path[draw=Gold!85!gray,sharp corners,line width=2.5pt] (frame.north west) -- (frame.north) -- (frame.north east);}
|
||||
sharp corners,
|
||||
colback=white,
|
||||
underlay={%
|
||||
\path[fill=Gold!85!gray,draw=none] (interior.south east) rectangle node[white]{\begin{tikzpicture}
|
||||
\draw[fill=white,even odd rule]
|
||||
let
|
||||
\n{dpt} = {360/7}
|
||||
in
|
||||
(0,0) circle (1.2mm) %
|
||||
({\n{dpt}*(0.5)}:2.5mm) \foreach \x in {1,...,7}{ %
|
||||
arc ({\n{dpt}*(\x-0.5)}:{\n{dpt}*(\x-0.25)}:2.5mm) %
|
||||
--++(\x*\n{dpt}:1.5mm) %
|
||||
arc ({\n{dpt}*(\x-0.25)}:{\n{dpt}*(\x+0.25)}:2.5mm) %
|
||||
--++(\x*\n{dpt}:-1.5mm) %
|
||||
arc ({\n{dpt}*(\x+0.25)}:{\n{dpt}*(\x+0.5)}:2.5mm)--%
|
||||
({\n{dpt}*(\x+0.5)}:2.5mm)
|
||||
};\end{tikzpicture}} ([xshift=-10mm]interior.north east);
|
||||
},#1}
|
||||
|
||||
\newtcolorbox{questionbox}[1][]{breakable,enhanced,
|
||||
before skip balanced=2mm,after skip balanced=3mm,
|
||||
tile,left=11mm,right=2mm,top=1mm,bottom=1mm,
|
||||
before=\hspace{.7em},after=\hspace{.5em},
|
||||
tile,left=11mm,right=2mm,top=.5em,bottom=.5em,
|
||||
colback=white!0,
|
||||
sharp corners,
|
||||
colback=lightgray!20!white,
|
||||
|
|
@ -35,8 +59,8 @@
|
|||
},#1}
|
||||
|
||||
\newtcolorbox{morebox}[1][]{breakable,enhanced,
|
||||
before skip balanced=2mm,after skip balanced=3mm,
|
||||
tile,left=7mm,right=7mm,top=1mm,bottom=1mm,
|
||||
before=\hspace{.2em},after=\hspace{.15em},
|
||||
tile,left=7mm,right=7mm,top=.5em,bottom=.5em,
|
||||
colback=white!0,
|
||||
sharp corners,
|
||||
colback=lightgray!20!white,
|
||||
|
|
|
|||
Loading…
Reference in New Issue