SEC.01

Le playbook

Le run démarre en lecture seule : les sondes de reconnaissance décident de la suite. Les étapes qui suivent sont adaptées à la distribution et à l'état trouvés — une vraie machine est rarement propre.

1. 01reconHeadscale déjà présent ? version
2. 02reconservice actif ? config existante (server_url, listen_addr) ?
3. 03reconports 8080/9090/50443 libres ? 80/443 tenus par un reverse proxy ?
4. 04reconreverse proxy présent (Caddy ou Nginx) pour le TLS
5. 05reconDebian ≥ 12 ou Ubuntu ≥ 22.04, architecture
6. 06agirLe domaine pointe sur ce serveurvérif
7. 07agirTélécharger le paquet officielvérif
8. 08agirInstaller Headscalevérif
9. 09agirConfigurer server_urlvérif
10. 10agirActivervérif
11. 11agirReverse proxy TLSvérif
12. 12agirCréer le premier utilisateurvérif

SEC.02

Ce qu'elle vérifie

Chaque étape embarque sa propre vérification. Le run ne continue que si elle passe, donc ce que la recette annonce comme fait est ce qui est réellement sur le serveur.

1. 01vérifLe domaine pointe sur ce serveurVérifié pargetent ahostsv4 ${domain} | head -1; curl -4fsS https://api.ipify.orgattendu : la même IP deux fois (sinon stop : le TLS échouerait)
2. 02vérifTélécharger le paquet officielVérifié pardpkg-deb -f /tmp/headscale.deb Versionattendu : 0.29.5
3. 03vérifInstaller HeadscaleVérifié parheadscale versionattendu : v0.29.5
4. 04vérifConfigurer server_urlVérifié parheadscale configtest && grep -c "^server_url: https://${domain}" /etc/headscale/config.yamlattendu : pas d’erreur puis 1
5. 05vérifActiverVérifié parsystemctl is-active headscale && curl -s -o /dev/null -w '%{http_code}' http://127.0.0.1:8080/healthattendu : active puis 200
6. 06vérifReverse proxy TLSVérifié parcurl -s -o /dev/null -w '%{http_code}' https://${domain}/healthattendu : 200
7. 07vérifCréer le premier utilisateurVérifié parheadscale users list | grep -cw ${hs_user}attendu : 1

SEC.03

Les garde-fous

Les consignes non négociables que le run doit respecter, quoi qu'il trouve sur le serveur.

SEC.04

Les variables

Ce que vous choisissez avant de lancer — la recette s'occupe du reste.

SEC.05

Comment une recette s'exécute dans Servor

Servor est zero-knowledge : la plateforme ne peut rien exécuter seule. Quand vous lancez cette recette, un run lit la reconnaissance, planifie les étapes et demande votre validation. Chaque commande approuvée est signée par votre navigateur — avec une clé que le serveur ne voit jamais — puis relayée telle quelle à l'agent, qui vérifie la signature localement avant d'exécuter.

SEC.06

Bouton Deploy on Servor

Vous maintenez Headscale ou un projet qui en dépend ? Ajoutez ce bouton à votre README ou à votre site : en un clic, vos utilisateurs l'installent sur leur propre serveur.

SEC.07

D'autres recettes réseau

1. 01TailscaleVPN mesh Tailscale : auth key ou lien de connexion, sans toucher au DNS du serveur.
2. 02WireGuardServeur VPN WireGuard + un premier client, sans toucher au routage. Destructif : interface réseau.
3. 03Pi-holePi-hole v6 (DNS + blocage de pubs) en conteneur, sur l’IP choisie. Destructif en écoute 0.0.0.0 (port 53).
4. 04AdGuard HomeDNS filtrant AdGuard Home, interface en local. Destructif : peut libérer le port 53.
5. 05OpenVPNServeur OpenVPN via le script road-warrior (angristan), premier client créé. Destructif : réseau.