Cloud-init et images machine
Deux façons d'éviter l'installation manuelle : coller un modèle cloud-init lorsque vous créez un VPS, ou construire une image machine qui a déjà tout d'installé.
Cloud-init (un serveur à la fois)
panel/deploy/cloud-init.yaml est un modèle de données utilisateur. Modifiez les quelques
réglages du haut, collez-le dans le champ « user data » de votre fournisseur lors de la création
du serveur, et le panneau est prêt une fois le serveur démarré. La progression et toute défaillance
aboutissent dans /var/log/nimbopanel-provision.log.
Ne traitez pas les données utilisateur comme un coffre à secrets
C'est la partie qui mérite d'être lue deux fois. Chez tous les grands fournisseurs, les données
utilisateur restent récupérables depuis l'intérieur de l'instance en cours d'exécution via HTTP
à 169.254.169.254 — et cette adresse est joignable par n'importe quel processus de la machine,
y compris le script PHP d'un client hébergé.
Ainsi, une clé de licence collée dans les données utilisateur est lisible par chaque client que vous hébergez, à moins que quelque chose ne l'en empêche. Le modèle l'en empêche en deux étapes, dans cet ordre :
- il ferme le service de métadonnées à tous sauf root, avant que la clé n'atteigne le disque ;
- une fois que l'installateur a stocké la clé dans une configuration réservée à root, il détruit la copie sur disque des données utilisateur.
Si vous préférez ne pas y mettre la clé du tout, laissez-la vide et saisissez-la ensuite depuis le panneau. Le serveur fonctionne sans licence jusqu'à ce que vous le fassiez, ce qui est un état pris en charge.
Images machine (plusieurs serveurs à partir d'une seule construction)
panel/deploy/packer/nimbopanel.pkr.hcl construit une image avec toute la pile installée. C'est là
que passent les minutes — paquets, PHP, messagerie, DNS, la base de données — et rien de tout cela
ne diffère d'un serveur à l'autre.
L'erreur qui fait de chaque clone le même serveur
Une image ne doit contenir aucune identité. Si elle en contient, chaque serveur construit à partir d'elle partage cette identité :
| Intégré par erreur | Ce qui arrive sur chaque clone |
|---|---|
| Clés d'hôte SSH | Ils présentent tous la même clé. Quiconque se place entre un client et son serveur peut l'usurper, sur tous, sans qu'aucun avertissement ne s'affiche |
| L'instance-id Nimbopanel | L'empreinte de licence en dérive, et l'installateur ne ré-amorce jamais un id qui existe déjà — de sorte que mille serveurs ressemblent à une seule activation |
/etc/machine-id |
systemd, les baux DHCP et l'identité journald entrent en collision |
| La base de données et la configuration du panneau | Mot de passe admin, clé de licence et chaque compte sont livrés dans un fichier que des inconnus téléchargent |
| Clés DKIM, certificats TLS | Émis pour la machine de construction ; sans valeur sur un clone, et divulgués à quiconque possède l'image |
Aucun de ces éléments ne s'annonce. Ils sont découverts plus tard, par quelqu'un d'autre.
panel/deploy/image-deidentify.sh supprime tout cela, et la construction Packer l'exécute en
dernière étape puis le relance avec --check, de sorte qu'une construction échoue plutôt que de
produire un instantané qui n'a que l'air propre. Tout ce qui est supprimé est recréé au premier
démarrage du clone : sshd génère de nouvelles clés d'hôte, systemd écrit un nouveau machine-id,
l'installateur amorce un instance-id neuf.
/etc/machine-id est laissé vide, non supprimé — systemd lit un fichier vide comme « en générer
un au démarrage », alors qu'un fichier manquant empêche certaines images de démarrer du tout.
Vérifiez avant de publier
sudo ./image-deidentify.sh # remove
sudo ./image-deidentify.sh --check # confirm, exits non-zero if anything survives
Exécutez aussi la vérification sur un clone démarré, pas seulement au moment de la construction. Si elle signale quoi que ce soit, ne publiez pas l'image.
Fiches sur les places de marché
Les programmes « 1-click app » des fournisseurs (Vultr, DigitalOcean, Linode, Contabo) ont chacun leur propre format de soumission et leur propre revue. L'image ci-dessus est l'artefact qu'ils demandent ; la paperasse est propre à chaque fournisseur et n'est pas quelque chose que cet outillage peut faire à votre place.