¶ Automation Linux - Présentation Technique
¶ Principe de fonctionnement
1 - Boot Reseau utilisant les fontionnalité iPXE
2 - Les protocoles de broacasts necéssaires au boot réseau sont gérés par une appliance ( mini pc ) connecté au Lan/Vlan d'installation. Ceci permet d'éviter les collisions protocolaire ave le réseau interne.
3 - L'appliance relais les requetes nécessaires à l'installation ( Masquerading )
3 - Le pilotage du déploiement est assuré par une application spécifique ( nommé installer dans le suite du document ) qui peut être installé sur le réseau local ou autre ( Appel d'API en https ).
¶ Axiomes
- Tout PC à un UUID propre ( et autres informations utiles ) connu du BIOS
- Les systèmes pris en charges sont des système ayant intègré un mécanisme d'installation automatique. (eg: Pressed pour debian, Kickstart pour Redhat, cloud-init pour ubuntu ...)
- Sauf impossibilité majeur, Rester compatible avec les protocoles réseaux & mécanismes standards d'installation afin de garder une maintenabilité dans le temps.
- Ne pas dépendre de solutions propriétaires.
- Tout est piloté par l'installer.
¶ Que se passe t'il au boot ?
Grossierement,le BIOS cherche un binaire et l'execute.
Ce binaire peut être sur le disque locale ou sur le réseau
Dans le cas d'un boot réseau:
1- Le Bios du PC utilise des protoles spécifique (BOOTP, PXE ) de type broadcast a destinaton du DHCP du Lan.
2 - Le serveur DHCP délivre les informations nécessaires ( Configuration réseau & fichier binaire à télécharger via TFTP)
3 - Le BIOS execute ce binaire.
Dans le cas d'un linux
- Le binaire est le kernel
- Un second fichier ( initrd ) contient le filesystème minimal racime monté en RAM utilisé durant l'éxécution du kernel
- Des paramêtres d'options de lancement dépendant de chaque distribution
Exemple classique:
Ubuntu
kernel images/ubuntu/xx.xy/amd64/linux <= Kernel telechargé via TFTP
append auto=true [..] url=http://1.2.3.4/seeds/preseed.cfg initrd=images/ubuntu/xx.yz/amd64/initrd.gz --
Redhat
kernel images/centos/7/x86_64/vmlinuz <= Kernel telechargé via TFTP
append initrd=images/centos/7/x86_64/initrd.img textks=http://1.2.3.4/kickstart/centos7.ks [...]
¶ Automation d'installation des linux
Comme l'illustre les deux exemples de configuration, il est possible de téléchargé le fichier de configuration permettant l'installation du système de manière non interactive.
Dans les deux exemple, ce fichier est un fichier texte générique donc statique
Si ce mécanisme est relativement bien adapté aux serveurs ( ip fixe associé à la mac , maitrise de la localisation et du hardware), il pose problème dans le cas des postes ou la combinatoire est plus importante.
Il faudrait que la configuration soit généré dynamiquement et fonction du poste client fortement identifié.
Ces pour cela que la solution d'installation utilise iPXE
- iPXE implemente d'autres protocoles réseaux que TFTP ( http/s, ftp, san .. )
- iPXE dispose d'un language de scripts
Le DHCP, si la requete viens d'iPXE, au lieu d'envoyer un fichier binaire peut communiquer un url du script à executer.
Extrait configuration DHCP (isc-dhcp )
if exists user-class and option user-class = "iPXE" {
filename "https://installer.domain/api/host/ipxe?uuid=${uuid}&mac=${mac}&ip=${net0/ip}&product=${smbios/product}&serial=${smbios/serial}";
} else {
filename "ipxe.efi";
}
Explications
- Si la requete DHCP viensd d'iPXE => Envoie de l'url à requeter
- Sinon ces une requète PXE classique => Envoie du firmare iPXE ( récupéré par TFTP )
¶ Qu'est-ce que ca change ?
Au moment de la requete d'API , iPXE vas renseigner les variables ( ${nom variable} ) avec les informations BIOS.
La requete d'API lancé par iPXE sera par exemple transformé comme suis:
https://installer.domain/api/host/ipxe?uuid="4c4c4544-0037-5710-8039-cac04f503133"&mac="34:48:ed:95:14:b2"&ip="192.168.60.101"&product="Latitude 7400"&serial="J7W9P13"
L'installer a donc, dès le premiers stade de boot, toutes les informations d'identifications du poste permettant, en fonction de la configuration interne, de générer l'ensemble des ressources nécéssaires
A savoir
- Si la machine n'est pas encore connue: enregistrement des informations
- Cette machine machine doit elle être installé ou reinstaller ?
- si oui :
- Quel OS ?
- Quelle configuration ?
- Quelle post confguration ?
- L'application est également informé des differents stade d'avancement en fonction des requetes d'API clientes.
- si non: Machine non define comme devant être installée => boot disque
Exemple de premier boot
PXE charge iPXE ( géré par le dhcp local )
Execution iPXE
Remarque:
Dans l'exemple, j'ai bloqué le boot sur disque local afin d'avoir le temps de capturé le resulat.
Sur l'installer un nouveau PC a été détecté:
Ensemble du parametrage par defaut
1 - Information d'identifications
2 - Génération d'aléas associé à ce PC ( exemple: clef de chiffrement disque )
3 - Status du PC , ici l'installer ne fera rien car le PC n'a pas été definie comme installable (Toinstall n'est pas coché )
Exemple de configuration du poste:
Association d'un Template d'installation ici Debian Bookworm Desktop FR
Son hostame demo
Activation "Toinstall": A la prochaine requete le poste sera installé ou réinstallé
L'interface permet de voir l'ensemble des scripts qui seront générés
Ceci permet entre autre de vérifier que la syntaxe des scripts de template est correct.
Script iPXE
Script Preseed pour Installation Debian Desktop
Script de Post installation :
¶ Comment sont générés ces scripts ?
Chaque host est un object ayant des propriétées propre, outre ces propriétées d'autres object lui sont associés:
- Le Site : Definie le contexe d'installation : quel est mon serveur de fichier , mon domaine dns ...
- Le Template : Définie l'installation elle même ( l'os à installer et la nature de cette installation desktop ? Serveur ? , autre besoins spédifique ?)
- Deux Users: Necessaire pour certain type d'installation demandant des utilisateur par defauts
Il en est de même pour l'objet Template cet objet est associé à trois objects de type Script, chacun de ces scripts sont liés à l'une des phases d'installation
- Boot
- Installation
- Post installation
Ces aux niveau de ces scripts que l'ensemble des propriétés définies dans les différents objets peuvent être utilisés
Syntaxe ERB
Les script sont ecrit en utilisant la syntaxe ERB
Pour chaque génération, l'ensemble des objects associés au host destination sont passés ce qui permet via la syntaxe ERB de généré dynamiquemet le resultat
Exemple pour le script de boot
Vu dans l'editeur:
Dans cette exemple
Si le host est configuré pour etre installé ( valeur true )
La génération executé le block entre if et end
sinon il génére juste boot
Résultat si l'option Toinstall est coché dans l'interface:
#!ipxe
# Boot Debian - V1
set filer_path http://192.168.60.254:8080/images
set os_path ${filer_path}/debian-bookworm
set apiurl https://zeninstall.zen6.info
kernel ${os_path}/linux
initrd ${os_path}/initrd.gz
imgargs linux auto=true fb=false priority=critical preseed/url=${apiurl}/api/host/install?uuid=4c4c4544-0046-5110-8035-c3c04f335832 debian-installer/allow_unauthenticated_ssl=true
boot
Résultat si l'option est décoché :
#!ipxe
# Boot Debian - V1
boot
Les variables sont accessibles via la syntaxe suivante
<%= @nom_de_variable.propriete.sous-propriete.... %>
L'interet de cette implémentation est multiple
1 - Cela permet de ne pas systématiquement patcher l'ensemle du code, si la logique doit être modifié.
2 - La modification du code n'est généralement nécessaire que pour l'ajout de nouvelle propriété ou objets
3 - La syntaxe ERB est relativement simple, d'ailleur si un script n'est pas dynamique, il suffit juste d'écrire le texte de base.
4 - La vérifications des modification et la gestion de version est simple
5 - La configuration est modulaire, tout les Debian ont le même script de boot, si un besoin spécifique est nécéssaire on peut juste modifier le script de post installation par rapport à la configuration de base sans avoir à tout re-ecrire.
6 - Si un PC soit être installé sur une autre site, il suffit juste de modifier sont attachement, rien n'est à modfier dans les script eux-memes. ( nécessite tout de meme un relais local )
¶ Details de l'applications
Ces pour le moment un POC, d'autre fonctions comme la gestion des authorisations sont à implementer.
L'application est écrite en rails 7 ( ruby ) et est containeurisé
Fonctionement de type MVC
La base utilisé est MongoDB également containerisé.
La communication application base de donnée s'effectue sur lan virtuel docker interne au serveur.
La gestion des acces web est géré par traefik:
-
Aucun port applicatif ou de base n'est directement exposés sur le serveur.
-
Ces également traefik qui s'occupe de la couche TLS ceci evite d'avoir des ports non sécurisés exposés en cas de mauvaise configuration applicative.
Le deploiement des containers est effectué via docker compose.
Aucun mot de passe (user & account applicatif ) n'est stocké en clair dans la base.
L'application peut donc être deployé soit sur un serveur soit sur un service de cloud adapté.
Toutes les données étant en base, l'application peut etre "scalé" si besoin
¶ Details du Relais
A besoin de deux cartes reseau ou a minima deux addresse il une implementation 802.1q est disponible.
- service DHCP isc-dhcp en ecoute uniquement sur la patte dédié du lan d'installation afion d'eviter les tempetes de broacast.
- service TFTP nécéssaire à PXE
- service de fichiers http (nginx) & nfs permettant de delivrer les images de base des systemes nécessaire au boot.
- Régles de netfilter permettant de relayer les requetes des postes vers l'exterieur ( masquerading ) nécéssaire pour les requetes d'API et l'accés au repository de paquets externes.
¶ Ce qui à été fait:
-
Installation Debian Bookworm Server & Desktop
-
Installation Debian Ubuntu Server 22.04
-
Installation Debian Ubuntu "Desktop" 22.04
Remarque: La version Desktop ne permet pas l'autoinstallation mais il est possible d'ajouter les paquets nécéssaires sur la version server -
Encryption disque (LUSK ) et stockage de la clé de chiffrement sur YubiKey durant l'installation.
-
Test d'auto-enregistrement du poste dans cfengine en tant que preuve de possibilité d'intégration outils tiers
-
Ajout compte technique ansible ( accès uniquement par clé ssh ) Permettant de déployer des fonctionnalité via playbook ( Enregistrement et authentification via Active Directory, Ajout windows Defender ... )
¶ Ce qui reste a faire:
Applicativement pleins de choses:
- Ajout de roles permettant de separer les doit d'administeur, concepteur de template et utilisateur de template
- Normalisation des logs ( également stockés en base )
- GUI: Trops de choses ( Je ne suis pas trés bon pour les aspects look & feel )
- Gestion intégré du versioning des scripts & configurations
- Mettre en place un lab de test, car je ne dispose actuellement pas du minimum nécessaire pour implementer ceci sur site.
Optionnel
- Ecriture d'Exporter prometheus pour avoir la visibilité de l'activé dans un grafana.
- Integration des dumps et restauration de la bases dans l'applications
- Stokage externe des script & template dans une repository de type git