[PACKER] soucis avec cd_files

john.c

@jeremie1977 said:

Bonjour,
Nous sommes en plein POC de Vates et je test le build de nos images RHEL avec Packer (d'ailleurs un grand merci à @bvivi57 et @ataxyanetwork pour les tutos et exemples qui m'ont fait gagner un temps précieux ^^ ).

J'ai remarqué que le paramètre "cd_files" ne permettait pas de monter le kickstart au boot
Le provider expose cd_files, mais le contenu n'est pas visible par l'installeur (ou n'est pas attaché à la VM...je n'ai pas sût identifier).
J'ai même tenté avec "floppy_files"...idem.
Est-ce normal ? Voulu ?

Du coup, dans des environnements sans DHCP pendant l'installation, cela empêche l'utilisation d'un kickstart embarqué et oblige à mettre en place une IP via la "boot_command" avec une configuration réseau statique (ce qui oblige a multiplié les builds si plusieurs environnements/site)
Rien de dramatique en soit mais sur les provider Packer Vmware et Nutanix que nous utilisons par ex, cd_files nous permet de couvrir les environnements isolés (air-gapped) et/ou sans DHCP et simplifie grandement les builds automatisés en rendant le code le plus idempotent possible.

L'intérêt est multiple :
Environnements air-gapped : aucun serveur HTTP nécessaire.
Moins de dépendances : le build est autonome.
Compatibilité avec les autres builders Packer (VMware, Nutanix, QEMU...), où nous utilisons cette fonctionnalité pour nos Builds
Sécurité : le kickstart n'est pas exposé sur le réseau, même temporairement.

Si la raison pour laquelle le fichier Kickstart ne peut pas être connecté en réseau ou autrement accessible, c'est parce qu'il contient des secrets. Cela peut valoir la peine de regarder et de vérifier le logiciel de service de détenteur sécurisé secret OpenBao (https://openbao.org/). Qui est un fork public open source de Hashicorp Vault, avant l'entrée en vigueur de la licence BUSL dans les versions ultérieures de Vault. Un autre conseil utile est de combiner l'isolation du masque de sous-réseau avec l'isolation basée sur le VLAN.

Quoi qu'il en soit, saviez-vous qu'une instance de Cockpit, exécutant Cockpit Image Builder peut être utilisée comme Packer, pour créer des images "dorées" de VM via OSBuild ?

Quoi qu'il en soit, bonjour et bienvenue dans la communauté Vates VMS, j'espère que vous la trouverez utile, épanouissante, accueillante et/ou amusante.

Sincèrement,

Jean C.

AtaxyaNetwork

@jeremie1977 Bonjour !

Pas de soucis pour les tutos, c'est normal de partager !

Je vais essayer de reproduire votre soucis. Pour etre sur votre environnement:

RHEL (10?)
UEFI ?
Boot sans DHCP
Et un fichier Kickstart a passer sans la méthode HTTP ?

olivierlambert

@john.c I really liked your "Jean C." signature before your edit You should keep it

john.c

@olivierlambert said:

@john.c I really liked your "Jean C." signature before your edit You should keep it

I learned a bit of French in 6th form college many years ago now, as part of learning your culture. As part of a Skillpower course unit assignment. As part of this course during Sept 2001 to Summer 2006 went on an academic day trip visit to Boulogne, France.

But it was to a level that was useful for when going on holidays, so wasn’t very fluent.

jeremie1977

@poddingue : Je fait mes builds en bios (RHEL 9.8) et la version du plugin est la v0.11.4_x5.0
J'ai tenté en uefi, j'ai le même comportement

@ataxyanetwork : C'est très cool ce partage en tous cas.
Voilà l'environnement:

RHEL 9.8
bios
Boot sans DHCP
fichier kickstart passé via le cd_files et renseigné via boot_command

D'ailleurs sur le plugin Nutanix il existe un paramètre : `

cd_label          = "OEMDRV"

qui permet de se passer complétement de boot_command.
Le paramètre cd_label = "OEMDRV" permet à Anaconda de détecter automatiquement un disque ou une partition étiquetée OEMDRV et d'y chercher un fichier ks.cfg
Ce serait top de retrouver ce paramètre pour le plugin xcp-ng

jeremie1977

@john.c C'est un sujet sur lequel je me penche également en ce moment afin de créer un kickstart "à la volée" avec des secrets dans Vault. (notre code Packer est majoritairement dans un Git versionné)

On utilise Packer par "habitude et facilité" ^^ car on a une infra assez diversifié tant en terme de sites que d'hyperviseurs/Clouds...et Packer y répond bien.
Mais je note OSBuild, ça semble intéressant

AtaxyaNetwork

@jeremie1977 Merci !

Je teste ça de mon coté et je fais un feedback vite !

AtaxyaNetwork

@jeremie1977 j'ai un packer qui fonctionne avec RHEL 10 (c'est ce que j'avais sous la main), uefi, sans dhcp, et un cd file qui sert le ks

Le code est ici: https://github.com/disruptivemindseu/xcpng-template-builder/tree/rhel-airgapped/packer/distros/rhel/10/uefi-airgapped

Je vais essayer avec une RHEL 9 ce week-end, il y a peut-etre une subtilité entre les deux versions

poddingue

Merci pour les précisions, elles écartent ma piste. Si vous reproduisez en BIOS comme en UEFI, le ticket #151 ne colle pas, d'autant qu'il parle de l'installeur Windows et pas d'Anaconda : je l'avais résumé un peu vite.
La différence intéressante est peut-être RHEL 9 contre RHEL 10, puisque @AtaxyaNetwork a un build qui fonctionne en 10 avec cd_files et sans DHCP, et son test en 9 ce week-end devrait trancher.
Sur cd_label = "OEMDRV", je n'ai trouvé ni issue ni PR dans le dépôt du plugin, donc ça n'existe visiblement pas encore : si ça vous va, ça ferait une demande propre à ouvrir sur https://github.com/vatesfr/packer-plugin-xenserver, en reprenant l'argument air-gapped que vous détaillez plus haut, qui est plus convaincant que ce que j'écrirais moi.

Je ne connais pas assez le plugin pour dire si c'est simple à ajouter, donc je préfère ne rien promettre.
Merci en tout cas de documenter tout précisément, ça servira sans doute bien au-delà de votre POC.

AtaxyaNetwork

Du coup j'ai testé avec RHEL 9, ça fonctionne aussi.

Faut bien prendre l'iso "dvd", pas "boot" en revanche ! (je me suis fait avoir en téléchargeant l'image)