XCP-ng
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login
    1. Home
    2. jeremie1977
    J Online
    • Profile
    • Following 0
    • Followers 0
    • Topics 1
    • Posts 2
    • Groups 0

    jeremie1977

    @jeremie1977

    1
    Reputation
    2
    Profile views
    2
    Posts
    0
    Followers
    0
    Following
    Joined
    Last Online

    jeremie1977 Unfollow Follow
    • [PACKER] soucis avec cd_files

      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.

      posted in French (Français)
      J
      jeremie1977
    • RE: [PACKER] soucis avec cd_files

      @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

      posted in French (Français)
      J
      jeremie1977
    • [PACKER] soucis avec cd_files

      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.

      posted in French (Français)
      J
      jeremie1977