Don't force line return on ####

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

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
 <https://docs.influxdata.com/influxdb/v1.8/guides/write_data/> :
@@ -54,7 +54,7 @@ SELECT * from "$my_cgroup_name";
 </div>
 
 
-#### Monitorer davantage de données\
+#### Monitorer davantage de données
 
 Liste non exhaustive de données à monitorer :
 
@@ -70,7 +70,7 @@ accessible ici :
 - v2 : <https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html>
 
 
-#### 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.

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
 
 <http://gentoo.mirrors.ovh.net/gentoo-distfiles/releases/amd64/autobuilds/current-stage3-amd64-openrc/stage3-amd64-openrc-20211128T170532Z.tar.xz>
 
@@ -123,7 +123,7 @@ chroot newroot/ bash
 </div>
 
 
-#### Alpine\
+#### Alpine
 
 <https://dl-cdn.alpinelinux.org/alpine/v3.14/releases/x86_64/alpine-minirootfs-3.14.2-x86_64.tar.gz>
 

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

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]
 </div>
 
 
-#### `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

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)`.

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

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.\

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 :
 </div>
 
 
-#### 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 :
 </div>
 
 
-#### 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

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.
 </div>
 
 
-#### MACVLAN\
+#### MACVLAN
 
 <!-- https://hicu.be/bridge-vs-macvlan -->
 

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 :
 

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[])
 </div>
 
 
-#### Exemple shell\
+#### Exemple shell
 
 Dans un shell, on utilisera la commande `nsenter(1)` :
 

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.
+
+:::::

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

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

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
+::::: {.warning}
-    configurée en mode bridge pour qu'elle soit sur le même sous-réseau. Il n'y
+Si vous utilisez Docker dans une VM, il faut que celle-ci soit
-    a pas de problème à avoir des nœuds *workers* derrière un NAT, mais il est
+configurée en mode bridge pour qu'elle soit sur le même sous-réseau. Il n'y
-    primordial que les managers soient joignables. Vous pouvez tenter de faire
+a pas de problème à avoir des nœuds *workers* derrière un NAT, mais il est
-    des redirections de ports, mais le résultat n'est pas garanti !
+primordial que les managers soient joignables. Vous pouvez tenter de faire
+des redirections de ports, mais le résultat n'est pas garanti !
+:::::
 
 <div lang="en-US">
 ```bash

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

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 :

tutorial/dockerfiles/others.md

@@ -40,7 +40,7 @@ chmod +x ~/.docker/cli-plugins/docker-buildx
 ```
 </div>
 
-#### 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)