{"id":8126,"date":"2026-11-10T06:00:00","date_gmt":"2026-11-10T05:00:00","guid":{"rendered":"https:\/\/www.blaess.fr\/christophe\/?p=8126"},"modified":"2026-11-08T01:54:27","modified_gmt":"2026-11-08T00:54:27","slug":"les-mises-a-jour-du-systeme-eris-linux","status":"publish","type":"post","link":"https:\/\/www.blaess.fr\/christophe\/2026\/11\/10\/les-mises-a-jour-du-systeme-eris-linux\/","title":{"rendered":"Les mises \u00e0 jour du syst\u00e8me Eris Linux"},"content":{"rendered":"
\n
\"\"<\/a><\/figure>\n<\/div>\n\n\n

Eris Linux<\/strong> offre un socle logiciel maintenu et ma\u00eetris\u00e9 sur lequel les applications m\u00e9tiers peuvent \u00eatre ex\u00e9cut\u00e9es en toute s\u00e9curit\u00e9 dans des containers. La mise \u00e0 jour<\/strong> r\u00e9guli\u00e8re du socle syst\u00e8me est r\u00e9alis\u00e9e par nos soins, au gr\u00e9 des correctifs int\u00e9gr\u00e9s dans les recettes de Yocto Project<\/em> et des n\u00e9cessit\u00e9s li\u00e9es \u00e0 la d\u00e9couverte de vuln\u00e9rabilit\u00e9s comme nous l’avons \u00e9voqu\u00e9 dans les pr\u00e9c\u00e9dents articles.<\/p>\n\n\n\n

Nous allons mettre \u00e0 l’\u00e9preuve<\/strong> le syst\u00e8me de mise de jour d’Eris Linux, en v\u00e9rifiant sa robustesse dans des circonstances difficiles volontairement provoqu\u00e9es.<\/p>\n\n\n\n\n\n\n\n

Installation initiale<\/h1>\n\n\n\n

Je commence par installer Eris Linux sur un Raspberry Pi 4.<\/p>\n\n\n\n

Pour cela, je me rends sur www.eris-linux.net<\/code>, je me connecte, et dans l’onglet My devices<\/em> je clique sur le bouton New device<\/em>.<\/p>\n\n\n

\n
\"\"<\/a>
Fig. 1 – Choix d’une image \u00e0 installer<\/figcaption><\/figure>\n<\/div>\n\n\n

Dans la liste qui appara\u00eet, je choisis une image Graphical<\/em> pour Raspberry Pi 4. Je pr\u00e9cise que la carte pourra acc\u00e9der \u00e0 Internet par son port Ethernet avec une adresse fournie par DHCP. Au bout de quelques minutes, je re\u00e7ois un mail m’indiquant que l’image est pr\u00eate.<\/p>\n\n\n

\n
\"\"<\/a>
Fig. 2 – Image pr\u00eate \u00e0 installer.<\/figcaption><\/figure>\n<\/div>\n\n\n

Je r\u00e9cup\u00e8re le fichier au format .img.bz2<\/code> , je le d\u00e9compresse, et je l’installe sur la carte SD<\/strong> branch\u00e9e sur mon PC. Personnellement j’utilise cp<\/code> pour cela mais on peut tr\u00e8s bien pr\u00e9f\u00e9rer dd<\/code> ou un utilitaire comme Etcher<\/em> par exemple.<\/p>\n\n\n\n

$ bunzip2  eris-linux_Raspberry-Pi-4_1.1.0-dev-*.img.bz2<\/strong>\n$ lsblk<\/strong>\n  [...]\nsdc          8:32   1  14.4G  0 disk\n$ sudo  umount  \/dev\/sdc?<\/strong>\n$ sudo  cp  eris-linux_Raspberry-Pi-4_1.1.0-dev-*.img  \/dev\/sdc<\/strong><\/code><\/pre>\n\n\n\n
(Remplacez sdc<\/code> par le nom de p\u00e9riph\u00e9rique correspondant \u00e0 votre carte SD tel qu’indiqu\u00e9 par lsblk<\/code>)<\/p>\n\n\n\n
Je branche mon Raspberry Pi, et au bout de quelques minutes (le temps de formater et chiffrer la partition de donn\u00e9es) je le vois appara\u00eetre sur le Device Manager<\/em>.<\/p>\n\n\n
\n
\"\"<\/a>
Fig. 3 – Premi\u00e8re apparition du device<\/em><\/figcaption><\/figure>\n<\/div>\n\n\n
Je renomme la carte Update-Test<\/strong><\/em>. Dans cette nouvelle version, elle contacte le serveur toutes les minutes, les mises \u00e0 jour du socle syst\u00e8me sont automatiques et le red\u00e9marrage apr\u00e8s mise \u00e0 jour a \u00e9galement lieu automatiquement. Bien entendu ces param\u00e8tres sont configurables en fonction de vos besoins fonctionnels.<\/p>\n\n\n\n
J’ai install\u00e9 un container de d\u00e9monstration<\/strong> dans le premier emplacement, ce qui me permet de v\u00e9rifier sur l’\u00e9cran HDMI connect\u00e9 \u00e0 la carte si le d\u00e9marrage des containers est correct. Comme on le voit sur la figure 4, la version du socle logiciel install\u00e9 est 1.1.0-dev-0<\/strong><\/code> (les versions suffix\u00e9es -dev-x<\/code> sont produites par une branche de d\u00e9veloppement utilis\u00e9e en interne uniquement).<\/p>\n\n\n
\n
\"\"<\/a>
Fig. 4 – Version 1.1.0-dev-0<\/figcaption><\/figure>\n<\/div>\n\n\n
Premi\u00e8res mises \u00e0 jour<\/h1>\n\n\n\n
Je pr\u00e9pare sur le serveur Eris-Linux une mise \u00e0 jour 1.1.0-dev-1<\/strong><\/code> identique \u00e0 la version pr\u00e9c\u00e9dente. Au bout de quelques instants le Raspberry Pi se met \u00e0 jour. Sur le tableau de bord du Device Manager<\/em>, le champ \u00ab\u00a0System status<\/em>\u00a0\u00bb passe par \u00ab\u00a0Update in progress<\/em>\u00a0\u00bb , \u00ab\u00a0Update Ok<\/em>\u00a0\u00bb puis \u00ab\u00a0Restarting<\/em>\u00a0\u00bb et enfin \u00ab\u00a0System Ok<\/em>\u00a0\u00bb avec le nouveau num\u00e9ro de version.<\/p>\n\n\n
\n
\"\"<\/a>
Fig. 5 – Version 1.1.0-dev-1<\/figcaption><\/figure>\n<\/div>\n\n\n
Nous utilisons un syst\u00e8me de mise \u00e0 jour de type A\/B am\u00e9lior\u00e9<\/strong> (s’appuyant sur deux partitions en alternance et un initramfs<\/em> de secours). Une nouvelle version n\u2019\u00e9crase donc jamais directement le syst\u00e8me actuellement valid\u00e9. Elle est install\u00e9e sur la partition inactive puis essay\u00e9e au red\u00e9marrage. Elle ne devient la version confirm\u00e9e que lorsque le d\u00e9marrage a \u00e9t\u00e9 valid\u00e9.<\/p>\n\n\n\n
Je r\u00e9it\u00e8re donc l’op\u00e9ration deux fois<\/strong> pour \u00eatre s\u00fbr de passer par toutes les transitions de partition en fonctionnement nominal, en m’affranchissant de l’image initialement install\u00e9e.<\/p>\n\n\n
\n
\"\"<\/a>
Fig. 6 – Version 1.1.0-dev-2<\/figcaption><\/figure>\n<\/div>\n\n\n
<\/p>\n\n\n
\n
\"\"<\/a>
Fig. 7 – Version 1.1.0-dev-3<\/figcaption><\/figure>\n<\/div>\n\n\n
Nous voyons que le syst\u00e8me de mise \u00e0 jour fonctionne bien<\/strong> lorsqu’aucun grain de sable ne vient gripper ses rouages. Nous allons pourtant lui jeter quelques poign\u00e9es de sable dans les op\u00e9rations \u00e0 venir !<\/p>\n\n\n\n
\u00c9chec de mise \u00e0 jour et rollback<\/em><\/h1>\n\n\n\n
Pour l’\u00e9tape suivante je veux forcer l’\u00e9chec de d\u00e9marrage<\/strong> d’une image suite \u00e0 une mise \u00e0 jour. Ce cas peut malheureusement arriver en situation r\u00e9elle. Imaginons par exemple que l’on a envoy\u00e9 par erreur une mise \u00e0 jour consid\u00e9rant que l’\u00e9quipement doit obligatoirement avoir un contr\u00f4leur d’\u00e9cran HDMI en oubliant que certaines cartes plus anciennes n’ont qu’un contr\u00f4leur graphique LVDS.<\/p>\n\n\n\n
Je vais simuler cette erreur en for\u00e7ant l’\u00e9chec du programme qui est appel\u00e9 en fin de d\u00e9marrage normal pour v\u00e9rifier que tout le socle logiciel s’est initialis\u00e9 correctement (ind\u00e9pendamment des containers<\/em> qui peuvent \u00e9chouer pour des raisons applicatives).<\/p>\n\n\n\n
J’ai ajout\u00e9 temporairement une boucle infinie vide dans le programme de v\u00e9rification du d\u00e9marrage correct. La version 1.1.0-dev-4<\/strong><\/code> ne pourra donc pas d\u00e9marrer compl\u00e8tement.<\/p>\n\n\n\n
Je vois passer l’installation de la nouvelle version :<\/p>\n\n\n
\n
\"\"<\/a>
Fig. 8 – Installation de la version 1.1.0-dev-4<\/figcaption><\/figure>\n<\/div>\n\n\n
Puis le red\u00e9marrage de la carte :<\/p>\n\n\n
\n
\"\"<\/a>
Fig. 9 – D\u00e9marrage de la version 1.1.0-dev-4<\/figcaption><\/figure>\n<\/div>\n\n\n
Sur l’\u00e9cran HDMI du Raspberry Pi, je vois bien que le boot d\u00e9marre<\/strong> sur la version 1.1.0-dev-4<\/code>, mais au bout de quelques minutes le syst\u00e8me, incapable de terminer son initialisation correctement, red\u00e9marre<\/strong>. La photo de l’\u00e9cran est de pi\u00e8tre qualit\u00e9.<\/p>\n\n\n
\n
\"\"<\/a>
Fig. 10 – \u00c9cran de d\u00e9marrage de la version 1.1.0-dev-4<\/figcaption><\/figure>\n<\/div>\n\n\n
Au bout de trois tentatives, le syst\u00e8me de mise \u00e0 jour abandonne et revient sur la version pr\u00e9c\u00e9dente<\/strong>. C’est ce qu’on appelle un rollback<\/strong><\/em>.<\/p>\n\n\n
\n
\"\"<\/a>
Fig. 11 – Retour sur la version 1.1.0-dev-3<\/figcaption><\/figure>\n<\/div>\n\n\n
On notera le message \u00ab\u00a0Update rejected<\/em>\u00a0\u00bb dans le champ \u00ab\u00a0System Status<\/em>\u00a0\u00bb . En effet, le device<\/em> n’acceptera plus la version 1.1.0-dev-4<\/code> m\u00eame si le Device Manager<\/em> lui propose \u00e0 nouveau. C’est uniquement cette version qui est bloqu\u00e9e, les suivantes seront accept\u00e9es et install\u00e9es.<\/p>\n\n\n\n
J’envoie \u00e0 pr\u00e9sent une nouvelle version 1.1.0-dev-5<\/strong><\/code> correcte. La mise \u00e0 jour et le red\u00e9marrage se font normalement.<\/p>\n\n\n
\n
\"\"<\/a>
Fig. 12 – Version 1.1.0-dev-5<\/figcaption><\/figure>\n<\/div>\n\n\n
Partition de donn\u00e9es d\u00e9grad\u00e9e et restaur\u00e9e<\/h1>\n\n\n\n
Le syst\u00e8me ayant besoin de stocker des donn\u00e9es applicatives de des param\u00e8tres de configuration, une partition est accessible en \u00e9criture. Dans le cas o\u00f9 une coupure d’alimentation \u00e9lectrique<\/strong> se produit au mauvais moment, on peut imaginer que cette partition souffre d’incoh\u00e9rences au re-d\u00e9marrage.<\/p>\n\n\n\n
Le choix qui est fait dans Eris Linux est de privil\u00e9gier le fonctionnement applicatif<\/strong>, et de pouvoir red\u00e9marrer le syst\u00e8me quitte \u00e0 perdre des donn\u00e9es pr\u00e9c\u00e9demment enregistr\u00e9es. Si le besoin s’en fait sentir, n’h\u00e9sitez pas \u00e0 nous contacter pour obtenir le fonctionnement inverse : privil\u00e9gier la sauvegarde des donn\u00e9es (syst\u00e8me d’enregistrement \u00e0 la mani\u00e8re des bo\u00eetes noires par exemple) m\u00eame si la fonctionnalit\u00e9 applicative est interrompue.<\/p>\n\n\n\n
Je ne vais pas essayer de reproduire une corruption al\u00e9atoire provoqu\u00e9e par une coupure \u00e9lectrique inopin\u00e9e, mais je vais \u00eatre nettement plus brutal en d\u00e9truisant volontairement les 256 premiers Mo de la partition<\/strong> de donn\u00e9es. Je vais prendre la carte SD du Raspberry Pi, l’ins\u00e9rer sur un PC et \u00e9craser le d\u00e9but de cette partition<\/strong> avec des z\u00e9ros.<\/p>\n\n\n\n
$ lsblk<\/strong>\n  [...]\nsdc           8:32   1  14.4G  0 disk \n\u251c\u2500sdc1        8:33   1 166.4M  0 part \/run\/media\/cpb\/boot\n\u251c\u2500sdc2        8:34   1 738.9M  0 part \n\u251c\u2500sdc3        8:35   1 739.4M  0 part \n\u2514\u2500sdc4        8:36   1  12.8G  0 part \n  [...]\n$<\/code><\/pre>\n\n\n\n
La partition de donn\u00e9es est la quatri\u00e8me, elle a \u00e9t\u00e9 \u00e9tendue pour remplir tout l’espace disponible sur la m\u00e9moire flash<\/em>. <\/p>\n\n\n\n
Attention :<\/strong> les commandes dd<\/code> qui suivent d\u00e9truisent volontairement des donn\u00e9es. Ne les reproduisez que sur un support de test dont vous avez v\u00e9rifi\u00e9 le nom de p\u00e9riph\u00e9rique. Une erreur sur \/dev\/sdX<\/code> peut d\u00e9truire imm\u00e9diatement les donn\u00e9es d\u2019un autre disque.<\/p>\n\n\n\n
$ sudo  dd  if=\/dev\/zero  of=\/dev\/sdc4  bs=1M  count=256<\/strong>\n256+0 records in\n256+0 records out\n268435456 bytes (268 MB, 256 MiB) copied, 0.368766 s, 729 MB\/s\n$<\/code><\/pre>\n\n\n\n
Nous venons d’\u00e9craser les 256 premiers Mo de la partition de donn\u00e9es.<\/p>\n\n\n\n
Je red\u00e9marre le syst\u00e8me. Au bout de quelques minutes, le Device Manager<\/em> m’indique qu’il a bien retrouv\u00e9 notre \u00e9quipement. Le temps de red\u00e9marrage est comparable au premier boot<\/em> du syst\u00e8me, il faut le temps de formater et chiffrer la partition de donn\u00e9es.<\/p>\n\n\n
\n
\"\"<\/a>
Fig. 13 – Version 1.1.0-dev-5 r\u00e9par\u00e9e<\/figcaption><\/figure>\n<\/div>\n\n\n
Soyons clair, cette r\u00e9cup\u00e9ration a n\u00e9cessit\u00e9 de r\u00e9initialiser enti\u00e8rement la partition en perdant les donn\u00e9es pr\u00e9c\u00e9demment \u00e9crites<\/strong> tout en restaurant les donn\u00e9es de fonctionnement permettant l’identification de l’\u00e9quipement par le Device Manager<\/em>. Ceci \u00e9vite d’avoir un device<\/em> \u00ab\u00a0briqu\u00e9\u00a0\u00bb (incapable de red\u00e9marrer du point de vue de l’utilisateur) n\u00e9cessitant un retour en r\u00e9paration.<\/p>\n\n\n\n
Comme je l’ai dit plus t\u00f4t, nous pouvons vous proposer sur demande des versions alternatives, o\u00f9 les donn\u00e9es restantes sont conserv\u00e9es et l’\u00e9quipement se met en d\u00e9faut, impliquant un retour en maintenance pour le restaurer en r\u00e9cup\u00e9rant, au moins partiellement, les donn\u00e9es restantes.<\/p>\n\n\n\n
Environnement de U-boot<\/h1>\n\n\n\n
Nous utilisons le bootloader<\/em> U-boot<\/strong> pour charger le noyau Linux. La configuration de U-boot s’appuie sur des variables d’environnement dans lesquelles nous venons enregistrer des donn\u00e9es (num\u00e9ro de partition en cours d’utilisation, partition candidate pour l’installation d’une nouvelle image, version bloqu\u00e9e par une mise \u00e0 jour \u00e9chou\u00e9e, etc.)<\/p>\n\n\n\n
Nous devons donc pouvoir r\u00e9-\u00e9crire l’environnement de U-boot.<\/strong> Il s’agit de deux zones redondantes se trouvant la m\u00e9moire flash<\/em> de la carte, hors des partitions utilis\u00e9es par le syst\u00e8me. Lorsqu’on extrait la carte SD pour l’analyser sur un PC, on peut voir les deux copies de l’environnement aux offsets 0x100000<\/code> et 0x200000<\/code>.<\/p>\n\n\n\n
$ sudo hexdump -C -s 0x100000 -n 0x4000 \/dev\/sdc<\/strong>\n00100000  5e fd f7 7d 03 5f 62 6f  6f 74 5f 6f 6e 3d 30 00  |^..}._boot_on=0.|\n00100010  5f 69 6e 69 74 72 61 6d  66 73 3d 30 00 5f 69 6e  |_initramfs=0._in|\n00100020  69 74 72 61 6d 66 73 5f  73 69 7a 65 3d 30 00 5f  |itramfs_size=0._|\n00100030  76 61 6c 75 65 3d 30 00  61 72 63 68 3d 61 72 6d  |value=0.arch=arm|\n00100040  00 62 61 75 64 72 61 74  65 3d 31 31 35 32 30 30  |.baudrate=115200|\n00100050  00 62 6f 61 72 64 3d 72  70 69 00 62 6f 61 72 64  |.board=rpi.board|\n00100060  5f 6e 61 6d 65 3d 34 20  4d 6f 64 65 6c 20 42 00  |_name=4 Model B.|\n  [...]\n\n$ sudo hexdump -C -s 0x200000 -n 0x4000 \/dev\/sdc<\/strong>\n00200000  0b 24 78 3d 04 5f 62 6f  6f 74 5f 6f 6e 3d 30 00  |.$x=._boot_on=0.|\n00200010  5f 69 6e 69 74 72 61 6d  66 73 3d 30 00 5f 69 6e  |_initramfs=0._in|\n00200020  69 74 72 61 6d 66 73 5f  73 69 7a 65 3d 30 00 5f  |itramfs_size=0._|\n00200030  76 61 6c 75 65 3d 30 00  61 72 63 68 3d 61 72 6d  |value=0.arch=arm|\n00200040  00 62 61 75 64 72 61 74  65 3d 31 31 35 32 30 30  |.baudrate=115200|\n00200050  00 62 6f 61 72 64 3d 72  70 69 00 62 6f 61 72 64  |.board=rpi.board|\n00200060  5f 6e 61 6d 65 3d 34 20  4d 6f 64 65 6c 20 42 00  |_name=4 Model B.|\n  [...]<\/code><\/pre>\n\n\n\n
Avec une pointe de cruaut\u00e9, j’\u00e9crase les 4 premiers kilo-octets du premier environnement (ce qui suffit \u00e0 d\u00e9truire son en-t\u00eate et sa somme de contr\u00f4le), le rendant inutilisable. Je v\u00e9rifie que la zone soit bien remplie de z\u00e9ros.<\/p>\n\n\n\n
$ sudo dd if=\/dev\/zero of=\/dev\/sdc bs=4k seek=$((0x100)) count=1<\/strong>\n\n$ sudo hexdump -C -s 0x100000 -n 0x4000 \/dev\/sdc<\/strong>\n00100000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|\n*\n00104000<\/code><\/pre>\n\n\n\n
Apr\u00e8s r\u00e9insertion de la carte SD, je peux v\u00e9rifier que U-boot a bien d\u00e9tect\u00e9 que cet environnement est invalide et a choisi d’utiliser la copie au second offset<\/em>.<\/p>\n\n\n
\n
\"\"<\/a>
Fig. 14 – Version 1.1.0-dev-5 avec environnement U-boot restaur\u00e9<\/figcaption><\/figure>\n<\/div>\n\n\n
Nous pouvons prolonger l’exp\u00e9rience en refaisant la m\u00eame op\u00e9ration, sur le second emplacement<\/strong> contenant l’environnement. Ceci permettra de s’assurer que la premi\u00e8re copie de l’environnement a \u00e9t\u00e9 restaur\u00e9e lors du dernier boot<\/em>.
<\/p>\n\n\n\n
Bien entendu, je n’\u00e9crase pas les deux copies simultan\u00e9ment, sinon je n’ai aucune chance de voir le syst\u00e8me
se r\u00e9parer.<\/p>\n\n\n\n
$ sudo dd if=\/dev\/zero of=\/dev\/sdc bs=4k seek=$((0x200)) count=1<\/strong>\n1+0 records in\n1+0 records out\n4096 bytes (4.1 kB, 4.0 KiB) copied, 0.000504819 s, 4.1 MB\/s\n\n$ sudo hexdump -C -s 0x200000 -n 0x4000 \/dev\/sdc<\/strong>\n00200000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|\n*\n00204000<\/code><\/pre>\n\n\n\n
Et le syst\u00e8me red\u00e9marre bien<\/strong> apr\u00e8s r\u00e9cup\u00e9ration de l’environnement U-boot.<\/p>\n\n\n
\n
\"\"<\/a>
Fig. 15 – Version 1.1.0-dev-5 second environnement restaur\u00e9<\/figcaption><\/figure>\n<\/div>\n\n\n
Conclusion<\/h1>\n\n\n\n
Nous avons volontairement soumis le m\u00e9canisme de mise \u00e0 jour d\u2019Eris Linux \u00e0 plusieurs situations anormales :<\/p>\n\n\n\n
    \n
  • une nouvelle version incapable de terminer<\/strong> son d\u00e9marrage,<\/li>\n\n\n\n
  • la destruction<\/strong> de la partition de donn\u00e9es,<\/li>\n\n\n\n
  • la corruption<\/strong> successive des deux copies de l\u2019environnement U-Boot.<\/li>\n<\/ul>\n\n\n\n
    Dans chacun de ces cas, le syst\u00e8me a pu retrouver automatiquement un \u00e9tat permettant son red\u00e9marrage<\/strong>, sans intervention sur l\u2019\u00e9quipement d\u00e9ploy\u00e9.<\/p>\n\n\n\n
    C\u2019est pr\u00e9cis\u00e9ment l\u2019objectif du m\u00e9canisme de mise \u00e0 jour d\u2019Eris Linux : une mise \u00e0 jour distante ne doit pas transformer un \u00e9quipement fonctionnel en syst\u00e8me inutilisable sans intervention physique.<\/p>\n\n\n\n
    <\/p>","protected":false},"excerpt":{"rendered":"
    Eris Linux offre un socle logiciel maintenu et maîtrisé sur lequel les applications métiers peuvent être exécutées en toute sécurité dans des containers. La mise à jour régulière du socle système est réalisée par nos soins, au gré des correctifs intégrés dans les recettes de Yocto Project et des nécessités liées à la découverte de […]<\/p>","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[8],"tags":[],"class_list":["post-8126","post","type-post","status-publish","format-standard","hentry","category-linux-2"],"_links":{"self":[{"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/posts\/8126","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/comments?post=8126"}],"version-history":[{"count":25,"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/posts\/8126\/revisions"}],"predecessor-version":[{"id":8190,"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/posts\/8126\/revisions\/8190"}],"wp:attachment":[{"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/media?parent=8126"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/categories?post=8126"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/tags?post=8126"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}