From 6e135a40deea45d1f0c2503bff5da7a325a03484 Mon Sep 17 00:00:00 2001 From: Pierre-Olivier Mercier Date: Sat, 9 Apr 2022 02:50:14 +0200 Subject: [PATCH] Don't force line return on #### --- tutorial/3/capabilities.md | 2 +- tutorial/3/cgroups-influx.md | 8 ++++---- tutorial/3/chroot.md | 4 ++-- tutorial/3/oom.md | 2 +- tutorial/3/pseudofs.md | 6 +++--- tutorial/4/howto.md | 4 ++-- tutorial/4/intro.md | 2 +- tutorial/4/lifetime.md | 1 - tutorial/4/mountns.md | 10 +++++----- tutorial/4/networkns.md | 4 ++-- tutorial/4/pidns.md | 2 +- tutorial/4/setns-samples.md | 4 ++-- tutorial/4/setns.md | 8 ++++++-- tutorial/4/setup.md | 6 +++--- tutorial/4/userns.md | 4 ++-- tutorial/docker-orchestration/swarm.md | 12 +++++++----- tutorial/dockerfiles/dockerfile.md | 2 +- tutorial/dockerfiles/goodpractices.md | 4 ++-- tutorial/dockerfiles/others.md | 6 +++--- 19 files changed, 48 insertions(+), 43 deletions(-) diff --git a/tutorial/3/capabilities.md b/tutorial/3/capabilities.md index 51e407d..9dec454 100644 --- a/tutorial/3/capabilities.md +++ b/tutorial/3/capabilities.md @@ -172,7 +172,7 @@ Il s'agit d'une représentation d'une structure du noyau, pas forcément très lisible en l'état. On utilisera `getfacl` pour la version lisible. -#### `ping`\ +#### `ping` De la même manière que l'on peut définir de façon plus fine les droits d'accès par utilisateur, un attribut de l'espace de nom *security* peut être défini diff --git a/tutorial/3/cgroups-influx.md b/tutorial/3/cgroups-influx.md index 6d8f086..9958b11 100644 --- a/tutorial/3/cgroups-influx.md +++ b/tutorial/3/cgroups-influx.md @@ -5,7 +5,7 @@ Poursuivons [notre script de monitoring](#script-monitoring) afin d'envoyer nos résultats vers InfluxDB : nous l'appellerons `./telegraf.sh`. -#### Rappel d'InfluxDB\ +#### Rappel d'InfluxDB Commençons par lancer le conteneur Docker d'InfluxDB (pour éviter de l'installer sur notre machine) : @@ -32,7 +32,7 @@ EOF Vérifiez que la base de données `metrics` a bien été créée. -#### Monitoring vers InfluxDB\ +#### Monitoring vers InfluxDB Maintenant, envoyons nos données vers la base  : @@ -54,7 +54,7 @@ SELECT * from "$my_cgroup_name"; -#### Monitorer davantage de données\ +#### Monitorer davantage de données Liste non exhaustive de données à monitorer : @@ -70,7 +70,7 @@ accessible ici : - v2 : -#### Permettre à l'utilisateur de monitorer des processus\ +#### Permettre à l'utilisateur de monitorer des processus Maintenant, séparons notre script en deux parties afin qu'un utilisateur normal (non-root) puisse utiliser la partie monitoring de notre script. diff --git a/tutorial/3/chroot.md b/tutorial/3/chroot.md index 3ec27b8..64b7426 100644 --- a/tutorial/3/chroot.md +++ b/tutorial/3/chroot.md @@ -98,7 +98,7 @@ Les distributions *à l'ancienne* proposent de télécharger leur système de ba sous forme de tarball : -#### Gentoo\ +#### Gentoo @@ -123,7 +123,7 @@ chroot newroot/ bash -#### Alpine\ +#### Alpine diff --git a/tutorial/3/oom.md b/tutorial/3/oom.md index e2147be..6de07c6 100644 --- a/tutorial/3/oom.md +++ b/tutorial/3/oom.md @@ -55,7 +55,7 @@ ce sujet :\ ::::: {.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 diff --git a/tutorial/3/pseudofs.md b/tutorial/3/pseudofs.md index 7bfe354..188ea18 100644 --- a/tutorial/3/pseudofs.md +++ b/tutorial/3/pseudofs.md @@ -81,7 +81,7 @@ Vous devriez constater l'effet de cette commande sans plus attendre ! ::::: {.exercice} -#### `procinfo`\ +#### `procinfo` Explorons le pseudo système de fichiers `/proc` pour écrire un script qui va afficher des informations sur un processus donné : @@ -125,7 +125,7 @@ uts:[4026531838] -#### `batinfo.sh`, `cpuinfo.sh`\ +#### `batinfo.sh`, `cpuinfo.sh` Explorons le pseudo système de fichiers `/sys` pour écrire un script qui va, en fonction de ce que vous avez de disponible : @@ -188,7 +188,7 @@ Thermal throttle count: 0 N'hésitez pas à rajouter toute sorte d'information intéressantes ! -#### `rev_kdb_leds.sh`, `suspend_schedule.sh`\ +#### `rev_kdb_leds.sh`, `suspend_schedule.sh` Maintenant que vous savez lire des informations dans `/sys`, tentons d'aller modifier le comportement de notre système. Au choix, réalisez l'un des scripts diff --git a/tutorial/4/howto.md b/tutorial/4/howto.md index f084d4a..1af3133 100644 --- a/tutorial/4/howto.md +++ b/tutorial/4/howto.md @@ -22,7 +22,7 @@ Nous allons voir dans cette partie plusieurs méthodes pour utiliser ces espaces de noms. -#### Avec son coquillage\ +#### Avec son coquillage De la même manière que l'on peut utiliser l'appel système `chroot(2)` depuis un shell via la commande `chroot(1)`, la commande `unshare(1)` permet de faire le @@ -55,7 +55,7 @@ Nous avons pu ici modifier le nom de la machine, sans que cela n'affecte notre machine hôte. -#### Les appels systèmes\ +#### Les appels systèmes L'appel système par excellence pour contrôler l'isolation d'un nouveau processus est `clone(2)`. diff --git a/tutorial/4/intro.md b/tutorial/4/intro.md index a65ff61..fef7151 100644 --- a/tutorial/4/intro.md +++ b/tutorial/4/intro.md @@ -1,6 +1,6 @@ \newpage -Les espaces de noms -- *namespaces* {#namespaces} +Les espaces de noms -- *namespaces* =================================== Nous avons vu un certain nombre de fonctionnalités offertes par le noyau Linux diff --git a/tutorial/4/lifetime.md b/tutorial/4/lifetime.md index b8fd50e..e88bba5 100644 --- a/tutorial/4/lifetime.md +++ b/tutorial/4/lifetime.md @@ -30,7 +30,6 @@ obtenir un descripteur de fichier valide vers le *namespace* (pour passer à ::::: {.question} #### Faire persister un *namespace* ? {-} -\ Il n'est pas possible de faire persister un espace de noms d'un reboot à l'autre.\ diff --git a/tutorial/4/mountns.md b/tutorial/4/mountns.md index e3ba2dc..d70b44f 100644 --- a/tutorial/4/mountns.md +++ b/tutorial/4/mountns.md @@ -45,7 +45,7 @@ montage virtuels. Le changement de racine sera donc effectif uniquement dans cet espace de noms. -#### L'environnement\ +#### L'environnement Pour pouvoir changer de racine, il est nécessaire que la nouvelle racine soit la racine d'un point de montage, comme l'explique `pivot_root(2)`. En effet, il @@ -75,7 +75,7 @@ Voici les grandes étapes du changement de racine : 3. `pivot_root` ! -#### S'isoler\ +#### S'isoler Notre but étant de démonter toutes les partitions superflues, nous allons devoir nous isoler sur : @@ -95,7 +95,7 @@ Isolons-nous : -#### Dissocier la propagation des démontages\ +#### Dissocier la propagation des démontages Attention ! avant de pouvoir commencer à démonter les partitions, il faut s'assurer que les démontages ne se propagent pas via une politique de *shared @@ -111,13 +111,13 @@ comme esclaves : -#### Démonter tout !\ +#### Démonter tout ! À vous maintenant de démonter vos points d'attache. Il ne devrait vous rester après cette étape que : `/`, `/dev`, `/sys`, `/proc`, `/run` et leurs fils. -#### Switch !\ +#### Switch ! À ce stade, dans votre console, vous avez plusieurs solutions : utiliser `switch_root(8)` ou `pivot_root(8)`. La première abstrait plus de choses que la diff --git a/tutorial/4/networkns.md b/tutorial/4/networkns.md index f4ac190..d60dd68 100644 --- a/tutorial/4/networkns.md +++ b/tutorial/4/networkns.md @@ -151,7 +151,7 @@ partout, mais c'est loin d'être la technique la plus rapide ou la moins gourmande. -#### VLAN\ +#### VLAN Il est possible d'attribuer juste une interface de VLAN, si l'on a un switch supportant la technologie [802.1q](https://fr.wikipedia.org/wiki/IEEE_802.1Q) @@ -166,7 +166,7 @@ derrière notre machine. -#### MACVLAN\ +#### MACVLAN diff --git a/tutorial/4/pidns.md b/tutorial/4/pidns.md index ffad3f0..37f9d57 100644 --- a/tutorial/4/pidns.md +++ b/tutorial/4/pidns.md @@ -45,7 +45,7 @@ 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`\ +#### Double isolation : ajout du *namespace* `mount` Voici la nouvelle ligne de commande que l'on va utiliser : diff --git a/tutorial/4/setns-samples.md b/tutorial/4/setns-samples.md index f3dbf76..2278743 100644 --- a/tutorial/4/setns-samples.md +++ b/tutorial/4/setns-samples.md @@ -1,4 +1,4 @@ -#### Exemple C\ +#### Exemple C Voici un exemple de code C utilisant `setns(2)` : @@ -36,7 +36,7 @@ main(int argc, char *argv[]) -#### Exemple shell\ +#### Exemple shell Dans un shell, on utilisera la commande `nsenter(1)` : diff --git a/tutorial/4/setns.md b/tutorial/4/setns.md index 46ec337..3bc7b17 100644 --- a/tutorial/4/setns.md +++ b/tutorial/4/setns.md @@ -8,7 +8,7 @@ respectivement un *file descriptor* ou le chemin vers le fichier, lien symbolique, représentant l'espace de nom. -#### Voir les *namespace*s d'un processus\ +#### Voir les *namespace*s d'un processus Chaque processus lancé est rattaché à une liste d'espaces de nom, y compris s'il est issu du système de base (« l'hôte »). @@ -55,7 +55,9 @@ Pour les commandes *shell*, il convient de donner en argument le chemin vers le lien symbolique : la commande se chargera d'`open(2)` le fichier. -#### `*_for_children`\ +::::: {.question} + +##### `*_for_children` {-} Vous avez peut-être remarqué des fichiers `*_for_children` dans le dossier `ns` de vos processus. Nous verrons par la suite que les espaces de noms *PID* et @@ -65,3 +67,5 @@ processus/threads fils. `pid_for_children` et `time_for_children` représentent donc les *namespace*s qui seront attribués aux fils lancés après un `unshare(2)` réussi. + +::::: diff --git a/tutorial/4/setup.md b/tutorial/4/setup.md index 9384cdc..b96a9bd 100644 --- a/tutorial/4/setup.md +++ b/tutorial/4/setup.md @@ -1,7 +1,7 @@ ### Prérequis -#### Noyau Linux \ +#### Noyau Linux Pour pouvoir suivre les exercices ci-après, vous devez disposez d'un noyau Linux, idéalement dans sa version 5.6 ou mieux. Il doit de plus être compilé @@ -55,7 +55,7 @@ Référez-vous, si besoin, à la précédente configuration que l'on a faite pou marche à suivre. -#### Paquets \ +#### Paquets Nous allons utiliser des programmes issus des [`util-linux`](https://www.kernel.org/pub/linux/utils/util-linux/), de @@ -75,7 +75,7 @@ Sous ArchLinux et ses dérivés, ces paquets sont respectivement : * `libcap` -#### À propos de la sécurité de l'espace de noms `user` \ +#### À propos de la sécurité de l'espace de noms `user` 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 diff --git a/tutorial/4/userns.md b/tutorial/4/userns.md index a842433..ecbd7ff 100644 --- a/tutorial/4/userns.md +++ b/tutorial/4/userns.md @@ -34,7 +34,7 @@ garder dans le nouvel espace, que les utilisateurs et les groupes utiles au processus, en les renumérotant au passage si besoin. -#### L'utilisateur -2 : *nobody*\ +#### L'utilisateur -2 : *nobody* Lorsque l'on arrive dans un nouvel espace, aucun utilisateur ni groupe n'est défini. Dans cette situation, tous les identifiants d'utilisateur et de groupe, @@ -45,7 +45,7 @@ l'utilisateur *nobody* et au groupe *nogroup*. non-modification d'un paramètre passé en argument d'une fonction. -#### `uid_map` et `gid_map` \ +#### `uid_map` et `gid_map` Pour établir la correspondance, une fois que l'on a créé le nouveau *namespace*, ces deux fichiers, accessibles dans `/proc/self/`, peuvent être diff --git a/tutorial/docker-orchestration/swarm.md b/tutorial/docker-orchestration/swarm.md index a7b95b4..a782a20 100644 --- a/tutorial/docker-orchestration/swarm.md +++ b/tutorial/docker-orchestration/swarm.md @@ -59,11 +59,13 @@ docker swarm join-token worker Lançons maintenant la commande `join` indiquée, sur une autre machine, en utilisant `docker-machine`. -[^avertVM]: Si vous utilisez Docker dans une VM, il faut que celle-ci soit - configurée en mode bridge pour qu'elle soit sur le même sous-réseau. Il n'y - a pas de problème à avoir des nœuds *workers* derrière un NAT, mais il est - primordial que les managers soient joignables. Vous pouvez tenter de faire - des redirections de ports, mais le résultat n'est pas garanti ! +::::: {.warning} +Si vous utilisez Docker dans une VM, il faut que celle-ci soit +configurée en mode bridge pour qu'elle soit sur le même sous-réseau. Il n'y +a pas de problème à avoir des nœuds *workers* derrière un NAT, mais il est +primordial que les managers soient joignables. Vous pouvez tenter de faire +des redirections de ports, mais le résultat n'est pas garanti ! +:::::
```bash diff --git a/tutorial/dockerfiles/dockerfile.md b/tutorial/dockerfiles/dockerfile.md index 4c31584..12811fe 100644 --- a/tutorial/dockerfiles/dockerfile.md +++ b/tutorial/dockerfiles/dockerfile.md @@ -268,7 +268,7 @@ produit de notre compilation. L'image ainsi générée est minime, car elle ne contient rien d'autre que le strict nécessaire pour s'exécuter. -#### Étapes nommées\ +#### Étapes nommées Nous avons utilisé `--from=0` pour désigner la première image de notre `Dockerfile`. Lorsque l'on réalise des montages plus complexes, on peut vouloir diff --git a/tutorial/dockerfiles/goodpractices.md b/tutorial/dockerfiles/goodpractices.md index a9e18a1..0ff2524 100644 --- a/tutorial/dockerfiles/goodpractices.md +++ b/tutorial/dockerfiles/goodpractices.md @@ -62,7 +62,7 @@ place. ### Ordonnez vos lignes de commandes complexes -#### Allez à la ligne pour séparer les longues lignes de commandes complexes\ +#### Allez à la ligne pour séparer les longues lignes de commandes complexes Aérez vos `Dockerfile` ! @@ -81,7 +81,7 @@ RUN apt-get update && apt-get install -y \ Notez les backslashs à la fin des lignes, indiquant qu'elle n'est pas terminée. -#### Triez les arguments par ordre alphabétique\ +#### Triez les arguments par ordre alphabétique Lorsque c'est possible, ordonnez vos lignes suivant un ordre logique. Par exemple : diff --git a/tutorial/dockerfiles/others.md b/tutorial/dockerfiles/others.md index b38a8f8..17bfb75 100644 --- a/tutorial/dockerfiles/others.md +++ b/tutorial/dockerfiles/others.md @@ -40,7 +40,7 @@ chmod +x ~/.docker/cli-plugins/docker-buildx ```
-#### Utilisation\ +#### Utilisation Nous pouvons réutiliser le `Dockerfile` que vous avez écrit pour `youp0m`, en remplaçant simplement la ligne de `docker build` par celle-ci : @@ -60,7 +60,7 @@ Actions* :\ ::::: -#### Changer la syntaxe de nos `Dockerfile`\ +#### Changer la syntaxe de nos `Dockerfile` Parfois on peut se sentir un peu frustré par la syntaxe des `Dockerfile` ou par son manque d'évolutivité. Avec BuildKit, il est possible de préciser un parseur @@ -107,7 +107,7 @@ notamment : `Dockerfile`, et autres scripts de CI et de tests. -#### `docker/dockerfile:1.3`\ +#### `docker/dockerfile:1.3` La version habituelle de la syntaxe des `Dockerfile` est la version 1.1. En utilisant BuildKit, nous pouvons dès à présent passer à la version 1.2 (stable)