{"id":5,"date":"2026-09-11T14:03:29","date_gmt":"2026-09-11T14:03:29","guid":{"rendered":"https:\/\/noteback.chabod.eu\/?p=5"},"modified":"2026-09-11T14:03:29","modified_gmt":"2026-09-11T14:03:29","slug":"doc-00-installation-k3","status":"publish","type":"post","link":"https:\/\/noteback.chabod.eu\/?p=5","title":{"rendered":"R\u00e9installation de k3 en Ubuntu 26.04 LTS"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\"><em>Document g\u00e9n\u00e9r\u00e9 automatiquement depuis <code>\/home\/jerome\/pub\/docs\/00-installation-k3.md<\/code> sur kimsufi3, le 11 September 2026 \u00e0 14:03. Toute modification faite ici sera \u00e9cras\u00e9e \u00e0 la prochaine r\u00e9g\u00e9n\u00e9ration : \u00e9diter le fichier source.<\/em><\/p>\n\n\n<p>Phase 0 du projet de paire actif\/veille. Ce document est la marche \u00e0 suivre compl\u00e8te, du manager OVH jusqu&#8217;au premier transfert de donn\u00e9es.<\/p>\n<blockquote>\n<p><strong>k3 sera int\u00e9gralement effac\u00e9.<\/strong> Tout ce qui lui \u00e9tait propre a \u00e9t\u00e9 sauvegard\u00e9 dans <code>~\/claude\/dockersync\/sauvegarde-k3-avant-reinstall\/<\/code> sur k4 (r\u00e9pertoire en mode 700 : il contient le topic ntfy, qui est un secret).<\/p>\n<\/blockquote>\n<h2 id=\"ce-qui-est-d\u00e9j\u00e0-v\u00e9rifi\u00e9\">Ce qui est d\u00e9j\u00e0 v\u00e9rifi\u00e9<\/h2>\n<table>\n<thead>\n<tr>\n<th>Point<\/th>\n<th>\u00c9tat<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Ubuntu 26.04.1 LTS \u00ab Resolute Raccoon \u00bb<\/td>\n<td>disponible (sortie du 23\/04\/2026)<\/td>\n<\/tr>\n<tr>\n<td>Docker CE pour <code>resolute<\/code><\/td>\n<td><strong>29.8.0<\/strong>, soit exactement la version de k4<\/td>\n<\/tr>\n<tr>\n<td>Sonde <code>sonde-chabod.sh<\/code><\/td>\n<td>sauvegard\u00e9e ; ne diff\u00e8re de la source de v\u00e9rit\u00e9 que par un commentaire<\/td>\n<\/tr>\n<tr>\n<td><code>\/etc\/crontab<\/code> de k3<\/td>\n<td>sauvegard\u00e9 (les 4 lignes rsync partent \u00e0 la poubelle)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h2 id=\"\u00e9tape-1--avant-de-lancer-quoi-que-ce-soit\">\u00c9tape 1 \u2014 Avant de lancer quoi que ce soit<\/h2>\n<p><strong>a. <del>V\u00e9rifier que k3 ne contient rien d&#8217;unique.<\/del> FAIT le 09\/09\/2026.<\/strong> Voir <code>01-audit-k3-avant-effacement.md<\/code>. Verdict : <strong>feu vert<\/strong>, rien d&#8217;unique sur k3. Le courrier y est r\u00e9pliqu\u00e9 \u00e0 la minute pr\u00e8s et sa structure est identique \u00e0 celle de k4 ; les 14 d\u00e9p\u00f4ts Subversion sont archiv\u00e9s et v\u00e9rifi\u00e9s sur k4 ; le reste est du r\u00e9sidu. Au passage : <strong>254 Go des 1004 Go sont des d\u00e9chets<\/strong> accumul\u00e9s faute de <code>--delete<\/code>, dont <strong>223 Go pour la seule base tt-rss, qui fait 84 Mo sur k4<\/strong>.<\/p>\n<p><strong>b. Abaisser les TTL DNS \u2014 \u00e0 faire maintenant, c&#8217;est le geste le plus rentable.<\/strong> <code>kimsufi4.chabod.eu<\/code> est \u00e0 <strong>86 400 s (24 h)<\/strong>, et il couvre 7 sous-domaines. Abaisser un TTL ne prenant effet qu&#8217;apr\u00e8s expiration de l&#8217;ancien, aucune bascule ne peut aboutir rapidement tant que ce n&#8217;est pas fait <strong>depuis plus de 24 h<\/strong>. Le minimum chez LWS est 900 s. Voir <code>04-dns-bascule.md<\/code> pour le d\u00e9tail des 6 enregistrements et la r\u00e9partition LWS \/ OVH.<\/p>\n<p><strong>c. <del>Sauvegarder l&#8217;identit\u00e9 SSH de k3.<\/del> FAIT le 09\/09\/2026.<\/strong> Les 6 cl\u00e9s d&#8217;h\u00f4te sont dans <code>sauvegarde-k3-avant-reinstall\/identite-hote\/ssh_host_keys.tar<\/code> (mode 600 : il contient des <strong>cl\u00e9s priv\u00e9es<\/strong>). Les restaurer apr\u00e8s r\u00e9installation \u00e9vite que tous tes clients affichent <code>REMOTE HOST IDENTIFICATION HAS CHANGED<\/code>.<\/p>\n<p><strong>d. V\u00e9rifier que la sauvegarde quotidienne de k4 a tourn\u00e9 cette nuit.<\/strong> Pendant la r\u00e9installation et le retransfert, <code>NCData<\/code> n&#8217;existera qu&#8217;en un seul exemplaire. <code>\/opt\/backup\/daily-backup-2.tar.encrypt<\/code> ne le contient pas \u2014 c&#8217;est un trou connu \u2014 mais le reste doit \u00eatre sain.<\/p>\n<h2 id=\"\u00e9tape-2--manager-ovh\">\u00c9tape 2 \u2014 Manager OVH<\/h2>\n<p>Serveur <code>kimsufi3<\/code> \u2192 <strong>R\u00e9installer<\/strong> \u2192 installation personnalis\u00e9e.<\/p>\n<ul>\n<li><strong>Syst\u00e8me<\/strong> : Ubuntu 26.04 LTS (server, 64 bits)<\/li>\n<li><strong>Nom d&#8217;h\u00f4te<\/strong> : <code>kimsufi3.chabod.eu<\/code><\/li>\n<li><strong>Cl\u00e9 SSH<\/strong> : y d\u00e9poser la cl\u00e9 publique <code>jerome@kimsufi4<\/code> (<code>~\/.ssh\/id_ed25519.pub<\/code> sur k4) pour avoir un acc\u00e8s imm\u00e9diat<\/li>\n<li><strong>Partitionnement<\/strong> : personnalis\u00e9 (voir ci-dessous). C&#8217;est la raison principale de cette r\u00e9installation, ne pas laisser le sch\u00e9ma par d\u00e9faut.<\/li>\n<li><strong>Script post-installation<\/strong> : le laisser <strong>vide<\/strong>. Voir ci-dessous.<\/li>\n<\/ul>\n<h3 id=\"pourquoi-ne-pas-utiliser-le-script-post-installation-dovh\">Pourquoi ne pas utiliser le script post-installation d&#8217;OVH<\/h3>\n<p>Le manager propose de faire ex\u00e9cuter un script en root \u00e0 la fin de l&#8217;installation, depuis une URL. Ce n&#8217;est pas le bon outil ici :<\/p>\n<table>\n<tbody>\n<tr>\n<td><strong>Exposition<\/strong><\/td>\n<td>Le script devrait \u00eatre publi\u00e9 sur une URL publique. Il contient les 9 cl\u00e9s publiques <strong>avec leurs commentaires<\/strong> (<code>jerome@dellg3<\/code>, <code>JuiceSSH<\/code>, <code>SHADOW-LS26FAO4<\/code>\u2026) : ce ne sont pas des secrets, mais c&#8217;est la cartographie du parc offerte \u00e0 qui passe.<\/td>\n<\/tr>\n<tr>\n<td><strong>Inefficace<\/strong><\/td>\n<td>La restauration de l&#8217;identit\u00e9 d&#8217;h\u00f4te reste impossible par ce canal \u2014 le tar contient des cl\u00e9s <strong>priv\u00e9es<\/strong>. Or c&#8217;est elle qui \u00e9vite de reconfigurer tous les clients. Une passe manuelle resterait donc n\u00e9cessaire.<\/td>\n<\/tr>\n<tr>\n<td><strong>Sans filet<\/strong><\/td>\n<td>Le script coupe l&#8217;acc\u00e8s root et change le port SSH. Sans supervision, si cloud-init repasse derri\u00e8re, on ne le d\u00e9couvre qu&#8217;en tentant de se connecter \u2014 et le seul recours est le mode rescue.<\/td>\n<\/tr>\n<tr>\n<td><strong>Sans gain<\/strong><\/td>\n<td><code>deployer-sur-k3.sh<\/code> fait d\u00e9j\u00e0 tout en une commande, avec points d&#8217;arr\u00eat et v\u00e9rification des empreintes.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>Le champ <strong>\u00ab cl\u00e9 SSH \u00bb<\/strong> du manager, lui, est \u00e0 utiliser : il \u00e9vite l&#8217;\u00e9tape <code>ssh-copy-id<\/code>.<\/p>\n<h3 id=\"partitionnement-cible\">Partitionnement cible<\/h3>\n<p>Le sch\u00e9ma actuel gaspille 495 Go : <code>\/<\/code> fait 503 Go pour 8,5 Go utilis\u00e9s, alors que <code>\/var<\/code> \u2014 le seul qui compte \u2014 est satur\u00e9 \u00e0 81 %.<\/p>\n<table>\n<thead>\n<tr>\n<th>Point de montage<\/th>\n<th>Type<\/th>\n<th>Taille<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><code>\/boot<\/code><\/td>\n<td>ext4<\/td>\n<td>1 Go<\/td>\n<\/tr>\n<tr>\n<td><code>\/<\/code><\/td>\n<td>ext4<\/td>\n<td><strong>120 Go<\/strong><\/td>\n<\/tr>\n<tr>\n<td><code>swap<\/code><\/td>\n<td>swap<\/td>\n<td><strong>8 Go<\/strong> (contre 512 Mo aujourd&#8217;hui)<\/td>\n<\/tr>\n<tr>\n<td><code>\/var<\/code><\/td>\n<td>ext4<\/td>\n<td><strong>tout le reste<\/strong>, ~1,67 To<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>Le swap \u00e0 8 Go n&#8217;est pas un luxe : k3 n&#8217;a que 3,8 Go de RAM et devra porter mailcow, Home Assistant et Nextcloud simultan\u00e9ment.<\/p>\n<h2 id=\"\u00e9tape-3--post-installation\">\u00c9tape 3 \u2014 Post-installation<\/h2>\n<p><strong>Dans le manager OVH, d\u00e9pose la cl\u00e9 publique de k4 au moment de la r\u00e9installation.<\/strong> C&#8217;est ce qui rend la suite automatique. Sinon OVH envoie un mot de passe root par courriel, et il faudra d&#8217;abord faire, depuis un vrai terminal :<\/p>\n<div class=\"sourceCode\" id=\"cb1\"><pre class=\"sourceCode bash\"><code class=\"sourceCode bash\"><span id=\"cb1-1\"><a href=\"#cb1-1\" aria-hidden=\"true\" tabindex=\"-1\"><\/a><span class=\"ex\">ssh-copy-id<\/span> <span class=\"at\">-p<\/span> 22 <span class=\"at\">-i<\/span> ~\/.ssh\/id_ed25519.pub root@kimsufi3.chabod.eu<\/span><\/code><\/pre><\/div>\n<p>Ensuite, une seule commande depuis k4 :<\/p>\n<div class=\"sourceCode\" id=\"cb2\"><pre class=\"sourceCode bash\"><code class=\"sourceCode bash\"><span id=\"cb2-1\"><a href=\"#cb2-1\" aria-hidden=\"true\" tabindex=\"-1\"><\/a><span class=\"fu\">bash<\/span> ~\/claude\/dockersync\/scripts\/deployer-sur-k3.sh<\/span><\/code><\/pre><\/div>\n<p>Elle encha\u00eene les huit \u00e9tapes : contr\u00f4le de joignabilit\u00e9, purge de <code>known_hosts<\/code>, transfert du script et de l&#8217;identit\u00e9, restauration de l&#8217;identit\u00e9, <strong>v\u00e9rification que les empreintes sont bien celles d&#8217;origine<\/strong>, configuration compl\u00e8te, puis validation de l&#8217;acc\u00e8s sur le port 22103.<\/p>\n<h3 id=\"pourquoi-ce-script-existe--la-cl\u00e9-dh\u00f4te-change-deux-fois\">Pourquoi ce script existe : la cl\u00e9 d&#8217;h\u00f4te change deux fois<\/h3>\n<p>C&#8217;est le pi\u00e8ge de l&#8217;op\u00e9ration, et il n&#8217;est pas \u00e9vident :<\/p>\n<ol type=\"1\">\n<li>La r\u00e9installation donne \u00e0 k3 une <strong>nouvelle<\/strong> cl\u00e9 d&#8217;h\u00f4te \u2192 k4 refuse la connexion (<code>HOST KEY CHANGED<\/code>) tant que <code>known_hosts<\/code> n&#8217;est pas purg\u00e9.<\/li>\n<li><code>--restaurer-identite<\/code> lui rend son <strong>ancienne<\/strong> cl\u00e9 \u2192 elle change donc une <strong>seconde fois<\/strong>, et il faut purger \u00e0 nouveau.<\/li>\n<\/ol>\n<p>Le script purge aux deux moments, dans le bon ordre. \u00c0 la fin, il compare les empreintes obtenues \u00e0 celles relev\u00e9es avant l&#8217;effacement :<\/p>\n<pre><code>SHA256:+R1BfgFFUgpC3NF4ygNirV8BOz7ZdE\/Mtt77xpjcN4U (RSA)\nSHA256:luVObYOfse3Pn3dBh6rnsJuYG2NZFEJSDlcRRldnsOw (ECDSA)\nSHA256:biSvhMMQS\/h3Ef7BCcxc\/6XtqWZagijoVXkPhJa5OQU (ED25519)<\/code><\/pre>\n<p>Si ces trois empreintes reviennent identiques, <strong>aucun de tes clients n&#8217;aura quoi que ce soit \u00e0 reconfigurer<\/strong>. Si elles diff\u00e8rent, le script le dit et s&#8217;interrompt pour confirmation : c&#8217;est le seul contr\u00f4le qui prouve que la restauration a r\u00e9ellement fonctionn\u00e9.<\/p>\n<blockquote>\n<p>Le <code>.tar<\/code> contient des <strong>cl\u00e9s priv\u00e9es d&#8217;h\u00f4te<\/strong>. Il n&#8217;est pas embarqu\u00e9 dans le script, se transf\u00e8re \u00e0 part, et le script le d\u00e9truit par <code>shred -u<\/code> juste apr\u00e8s usage.<\/p>\n<\/blockquote>\n<p>Le script <code>post-install-k3.sh<\/code> fait, dans l&#8217;ordre :<\/p>\n<ol type=\"1\">\n<li>contr\u00f4le du <strong>partitionnement<\/strong> (<code>\/var<\/code> \u2265 1,4 To, swap \u2265 7 Go) \u2014 c&#8217;est la raison de la r\u00e9installation, autant le v\u00e9rifier tout de suite ;<\/li>\n<li>fuseau <strong><code>Europe\/Luxembourg<\/code><\/strong> ;<\/li>\n<li>paquets de base : <code>rsync<\/code>, <code>jq<\/code>, <code>curl<\/code>, <code>git<\/code>, <code>util-linux<\/code> ;<\/li>\n<li><strong>purge d&#8217;<code>apache2<\/code> et de <code>mysql-server<\/code><\/strong> s&#8217;ils sont pr\u00e9sents ;<\/li>\n<li><strong>Docker CE depuis <code>download.docker.com<\/code><\/strong>, pas le paquet Ubuntu ;<\/li>\n<li>utilisateur <code>jerome<\/code> en <strong>uid\/gid 1001<\/strong>, groupe <code>docker<\/code>, <code>sudo<\/code> NOPASSWD, et les <strong>9 cl\u00e9s clientes<\/strong> reprises de k4 \u2014 chacune valid\u00e9e par <code>ssh-keygen<\/code> avant installation ;<\/li>\n<li><code>net.ipv4.ip_unprivileged_port_start=0<\/code>, requis par Traefik ;<\/li>\n<li><strong>authentification par cl\u00e9 uniquement<\/strong> (voir plus bas) ;<\/li>\n<li><code>Port 22103<\/code> <strong>en gardant le port 22 ouvert<\/strong>.<\/li>\n<\/ol>\n<h3 id=\"le-port-ssh-est-le-point-dangereux\">Le port SSH est le point dangereux<\/h3>\n<p>k3 est une machine distante : perdre <code>sshd<\/code>, c&#8217;est perdre la machine. Le script ouvre donc <strong>22103 en gardant le port 22<\/strong>, et v\u00e9rifie que 22103 \u00e9coute avant de rendre la main. La fermeture du 22 est une <strong>seconde commande, d\u00e9lib\u00e9r\u00e9e<\/strong> :<\/p>\n<div class=\"sourceCode\" id=\"cb4\"><pre class=\"sourceCode bash\"><code class=\"sourceCode bash\"><span id=\"cb4-1\"><a href=\"#cb4-1\" aria-hidden=\"true\" tabindex=\"-1\"><\/a><span class=\"co\"># 1. valider depuis k4 que le nouveau port r\u00e9pond<\/span><\/span>\n<span id=\"cb4-2\"><a href=\"#cb4-2\" aria-hidden=\"true\" tabindex=\"-1\"><\/a><span class=\"fu\">ssh<\/span> <span class=\"at\">-p<\/span> 22103 jerome@kimsufi3.chabod.eu <span class=\"st\">&#39;id&#39;<\/span><\/span>\n<span id=\"cb4-3\"><a href=\"#cb4-3\" aria-hidden=\"true\" tabindex=\"-1\"><\/a><\/span>\n<span id=\"cb4-4\"><a href=\"#cb4-4\" aria-hidden=\"true\" tabindex=\"-1\"><\/a><span class=\"co\"># 2. seulement alors, fermer le 22<\/span><\/span>\n<span id=\"cb4-5\"><a href=\"#cb4-5\" aria-hidden=\"true\" tabindex=\"-1\"><\/a><span class=\"fu\">ssh<\/span> <span class=\"at\">-p<\/span> 22103 jerome@kimsufi3.chabod.eu <span class=\"st\">&#39;sudo bash \/root\/post-install-k3.sh --fermer-22&#39;<\/span><\/span><\/code><\/pre><\/div>\n<p>Sur Ubuntu 24.04 et suivantes, c&#8217;est <code>ssh.socket<\/code> qui \u00e9coute, pas <code>sshd<\/code>. Un g\u00e9n\u00e9rateur (<code>sshd-socket-generator<\/code>) relit <code>sshd_config<\/code> et r\u00e9g\u00e9n\u00e8re le socket : poser <code>Port 22103<\/code> suffit donc, \u00e0 condition de faire <code>systemctl daemon-reload<\/code> puis <code>restart ssh.socket<\/code> \u2014 ce que le script fait.<\/p>\n<h3 id=\"authentification-par-cl\u00e9-uniquement\">Authentification par cl\u00e9 uniquement<\/h3>\n<p>Trois directives, pas une :<\/p>\n<pre><code>PasswordAuthentication no\nKbdInteractiveAuthentication no\nPermitRootLogin no<\/code><\/pre>\n<p><code>PasswordAuthentication no<\/code> seul <strong>ne suffit pas<\/strong> : avec <code>UsePAM yes<\/code>, un mot de passe passe encore par le canal clavier-interactif. Il faut couper les deux.<\/p>\n<p>Le script ne se contente pas d&#8217;\u00e9crire ces lignes, il <strong>v\u00e9rifie qu&#8217;elles sont effectives<\/strong> avec <code>sshd -T<\/code>, qui donne la configuration r\u00e9ellement appliqu\u00e9e une fois tous les fragments de <code>sshd_config.d\/<\/code> fusionn\u00e9s. Ubuntu en pose deux (<code>50-cloud-init.conf<\/code>, <code>60-cloudimg-settings.conf<\/code>) : sur k3 et k4 ils mettent d\u00e9j\u00e0 <code>PasswordAuthentication no<\/code>, donc pas de conflit, mais c&#8217;est le genre de fichier qui r\u00e9active silencieusement les mots de passe apr\u00e8s une r\u00e9installation. V\u00e9rifier la config effective plut\u00f4t que celle qu&#8217;on croit avoir \u00e9crite est le seul contr\u00f4le qui vaille.<\/p>\n<p>Si un fragment prenait le dessus, le script le signale et indique quoi inspecter.<\/p>\n<h3 id=\"les-cl\u00e9s-c\u00f4t\u00e9-serveur-et-c\u00f4t\u00e9-h\u00f4te\">Les cl\u00e9s, c\u00f4t\u00e9 serveur et c\u00f4t\u00e9 h\u00f4te<\/h3>\n<p>Deux choses distinctes, souvent confondues :<\/p>\n<table>\n<thead>\n<tr>\n<th><\/th>\n<th>R\u00f4le<\/th>\n<th>Effet si on ne fait rien<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><code>authorized_keys<\/code><\/td>\n<td>qui a le droit d&#8217;entrer<\/td>\n<td>plus personne ne peut se connecter<\/td>\n<\/tr>\n<tr>\n<td>cl\u00e9s d&#8217;<strong>h\u00f4te<\/strong> (<code>\/etc\/ssh\/ssh_host_*<\/code>)<\/td>\n<td>l&#8217;identit\u00e9 de la machine<\/td>\n<td>tous les clients alertent et refusent<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>Le script traite les deux. Restaurer l&#8217;identit\u00e9 d&#8217;h\u00f4te n&#8217;est pas qu&#8217;un confort : habituer des utilisateurs \u00e0 passer outre <code>REMOTE HOST IDENTIFICATION HAS CHANGED<\/code> est pr\u00e9cis\u00e9ment ce qui rendrait une vraie attaque invisible. C&#8217;est l\u00e9gitime ici parce que la r\u00e9installation est volontaire \u2014 <strong>\u00e0 ne pas faire si la machine avait \u00e9t\u00e9 compromise<\/strong>, son identit\u00e9 pouvant alors \u00eatre entre d&#8217;autres mains.<\/p>\n<p>La cl\u00e9 <code>root@kimsufi3<\/code> est <strong>volontairement exclue<\/strong> du jeu r\u00e9install\u00e9 : sa partie priv\u00e9e dispara\u00eet avec le disque, et c&#8217;est justement l&#8217;acc\u00e8s root de k3 vers k4 que le projet cherche \u00e0 fermer.<\/p>\n<h3 id=\"identit\u00e9s-\u00e0-respecter\">Identit\u00e9s \u00e0 respecter<\/h3>\n<p><code>jerome<\/code> doit avoir <strong>uid 1001 et gid 1001<\/strong>, comme sur k4. OVH cr\u00e9e souvent le premier compte en uid 1000 ; le script corrige. Sans cette correspondance, les fichiers r\u00e9pliqu\u00e9s avec <code>--numeric-ids<\/code> arriveraient avec un propri\u00e9taire inexistant. Le store ACME, lui, est en <code>2000:2000<\/code> sans compte h\u00f4te associ\u00e9 \u2014 c&#8217;est normal, Traefik tourne sous ces num\u00e9ros.<\/p>\n<h2 id=\"\u00e9tape-4--premier-transfert\">\u00c9tape 4 \u2014 Premier transfert<\/h2>\n<p>Priorit\u00e9 absolue \u00e0 <code>NCData<\/code> (725 Go) : c&#8217;est la donn\u00e9e qui n&#8217;existe nulle part ailleurs. Une nuit suffit en intra-OVH (2 ms de latence entre les deux machines).<\/p>\n<p>Le reste (mailcow, <code>\/opt\/dockerscripts<\/code>, <code>\/var\/www<\/code>) suit ensuite ; c&#8217;est l&#8217;affaire de quelques minutes.<\/p>\n<h2 id=\"apr\u00e8s-cette-phase\">Apr\u00e8s cette phase<\/h2>\n<p>Phase 1 : m\u00e9canisme de r\u00f4le actif\/veille. Voir le plan complet dans <code>~\/.claude\/plans\/<\/code>.<\/p>","protected":false},"excerpt":{"rendered":"<p>Document g\u00e9n\u00e9r\u00e9 automatiquement depuis \/home\/jerome\/pub\/docs\/00-installation-k3.md sur kimsufi3, le 11 September 2026 \u00e0 14:03. Toute modification faite ici sera \u00e9cras\u00e9e \u00e0 la prochaine r\u00e9g\u00e9n\u00e9ration : \u00e9diter le fichier source. Phase 0 du projet de paire actif\/veille. Ce document est la marche \u00e0 suivre compl\u00e8te, du manager OVH jusqu&#8217;au premier transfert de donn\u00e9es. k3 sera int\u00e9gralement effac\u00e9. [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-5","post","type-post","status-publish","format-standard","hentry","category-exploitation-dockersync"],"_links":{"self":[{"href":"https:\/\/noteback.chabod.eu\/index.php?rest_route=\/wp\/v2\/posts\/5","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/noteback.chabod.eu\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/noteback.chabod.eu\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/noteback.chabod.eu\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/noteback.chabod.eu\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=5"}],"version-history":[{"count":0,"href":"https:\/\/noteback.chabod.eu\/index.php?rest_route=\/wp\/v2\/posts\/5\/revisions"}],"wp:attachment":[{"href":"https:\/\/noteback.chabod.eu\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=5"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/noteback.chabod.eu\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=5"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/noteback.chabod.eu\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=5"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}