jeremie1977

@poddingue Bonne idée !
Je pense ouvrir une PR pour "cd_files" en rapport avec les environnements air-gapped.
En tous cas merci de te pencher sur mon soucis

@ataxyanetwork Je pense avoir mis le doigt sur le soucis...
J'ai repris ton code de la version air-gapped à l'identique (en modifiant un peu pour que cela colle à mon infra, comme l'agent positionné dans "http" pour l'installer car je ne peux pas sortir sur le net, etc).
En ne mettant qu'un seul disque : aucuns soucis le build réussi ^^ (que ce soit de la RHEL 9 ou 10)

Par contre en mettant plusieurs disques (nos builds comportent 3 disques) ça ne passe plus...
Il ne trouve pas le ks.cfg...
il m'indique "please insert CDROM containing '/ks.cfg' "

D'ailleurs la doc du plugins est erronée pour le multi-disk, il est dit de mettre :

  disk {
    disk_name = "root"
    disk_size = 20480    
  }
  disk {
    disk_name = "multidisk-is-working"
    disk_size = 10240    
  }

au build cela met en erreur avec :
Blocks of type "disk" are not expected here. Did you mean "disks"?
Il faut mettre "disks"

@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

@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

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.