vyos-cloudinit-images

Outillage pour builder des images VyOS avec cloud-init embarqué (absent de l'ISO générique officielle) et les provisionner automatiquement — compte utilisateur, clé SSH, IP d'interface, jusqu'à l'installation non-interactive sur disque. Extrait d'une phase d'exploration sur l'intégration VyOS/UniFi (voir le contexte).

Pourquoi

L'ISO "generic" officielle de VyOS ne contient pas cloud-init — c'est un paquet que VyOS build eux-mêmes et n'inclut que dans certains flavors d'image (AWS, etc.). Ce dépôt automatise la construction d'une image générique avec cloud-init en plus, et fournit des seeds cloud-init (NoCloud) prêts à l'emploi pour un provisionnement clé-en-main.

Détails, preuves et pièges rencontrés : docs/VALIDATION.md.

Quickstart

Prérequis : Docker, et cloud-localds (paquet cloud-image-utils) ou mkisofs/genisoimage (paquet cdrtools) pour fabriquer le seed. Un flake.nix est fourni pour le dev local (nix develop ou direnv allow) si vous préférez ne pas installer ces outils manuellement.

# 1. Builder l'ISO avec cloud-init
scripts/build-image.sh build/

# 2. Adapter examples/user-data.basic.yaml avec votre propre clé SSH publique,
#    puis fabriquer le seed
scripts/make-seed.sh examples/user-data.basic.yaml examples/meta-data.yaml \
  examples/network-config.yaml seed.img

# 3. Tester en QEMU (attend que SSH réponde avec la clé provisionnée)
scripts/boot-test.sh build/*.iso seed.img ~/.ssh/id_ed25519

Pour tester l'installation non-interactive sur disque jusqu'au reboot, utilisez examples/user-data.install.yaml et passez un disque cible en 4ᵉ argument à boot-test.sh :

qemu-img create -f qcow2 install-disk.qcow2 4G
scripts/make-seed.sh examples/user-data.install.yaml examples/meta-data.yaml \
  examples/network-config.yaml seed-install.img
scripts/boot-test.sh build/*.iso seed-install.img ~/.ssh/id_ed25519 install-disk.qcow2

Structure

Chemin	Contenu
scripts/build-image.sh	Build l'ISO VyOS generic + cloud-init via le pipeline Docker officiel
scripts/make-seed.sh	Fabrique un seed cloud-init NoCloud (label cidata)
scripts/boot-test.sh	Boot en QEMU et attend que SSH réponde avec la clé du seed
examples/	user-data/meta-data/network-config validés manuellement
branding/	Assets Cedille (splash boot) + script de régénération
docs/VALIDATION.md	Résultats détaillés des tests de validation

Branding

Le nom "VyOS" et le logo "V" sont des marques déposées, protégées séparément du code (qui est GPL/LGPL) — l'EULA VyOS n'autorise pas de redistribuer une image modifiée sans les remplacer par sa propre marque (vyos.io/legal/eula). scripts/build-image.sh remplace donc automatiquement, à chaque build :

• le splash de boot isolinux et le splash GRUB (branding/splash-*.png, régénérables depuis branding/cedille-logo-orange.png via branding/generate-splash.sh, nécessite ImageMagick)
• les métadonnées de l'ISO (--iso-application/--iso-volume) et le nom affiché dans /etc/os-release (PRETTY_NAME/NAME)

Ce qu'on ne touche pas (portée volontairement limitée) : le nom dans le menu GRUB et les chaînes internes du CLI, qui vivent dans le code Python de vyos-1x — les changer demanderait de forker et rebuilder ce paquet, un effort disproportionné pour un usage interne non-commercial de club.

Le bandeau "Welcome to VyOS!" au login n'a pas besoin d'être patché — c'est déjà exposé comme réglage VyOS standard, surchargeable via cloud-init sans toucher au build :

vyos_config_commands:
  - "set system login banner post-login 'Cedille — build VyOS avec branding remplacé, non affilié à VyOS Networks'"

CI

Deux jobs dans .forgejo/workflows/ci.yml :

• lint — sur ubuntu-latest standard (apt, pas de Nix — pour rester rapide), à chaque push/PR : shellcheck sur les scripts, yamllint + cloud-init schema sur les exemples.
• build-image — build l'ISO complète et la boot-teste en QEMU avec une clé SSH jetable, puis publie l'ISO en artefact (rétention 14 jours). Tourne sur kvm-runner, le runner dédié qui a Docker + /dev/kvm (nécessaires pour build-vyos-image --privileged et l'accélération QEMU). Ce runner est partagé avec d'autres builds d'images (ex. opnsense-cloudinit) et n'a qu'une capacité de 1 job à la fois — le job n'est donc pas déclenché sur chaque push, seulement manuellement (workflow_dispatch, bouton "Run workflow" dans l'UI Forgejo ou fj actions dispatch).