OSCDIMG.exe est un utilitaire en ligne de commande fourni par Microsoft, permettant de créer des fichiers image ISO. Il est inclus dans le Windows Assessment and Deployment Kit (ADK), qui remplace le Windows Automated Installation Kit (AIK). Cet outil est particulièrement utile pour automatiser la création d’images ISO, notamment dans des environnements de virtualisation ou de déploiement.
Installation de l’ADK et d’OSCDIMG.exe
Téléchargement de l’ADK :
Rendez-vous sur le site officiel de Microsoft pour télécharger la version de l’ADK correspondant à votre version de Windows.
Assurez-vous de sélectionner l’option “Outils de déploiement” lors de l’installation, car c’est elle qui contient OSCDIMG.exe.
Vérification de l’installation :
Par défaut, OSCDIMG.exe est installé dans le répertoire C:\Program Files (x86)\Windows Kits\<version>\Assessment and Deployment Kit\Deployment Tools\amd64\Oscdimg\.
Ajoutez ce chemin à la variable d’environnement PATH pour pouvoir exécuter OSCDIMG.exe depuis n’importe quel emplacement dans l’invite de commandes.
Création d’une image ISO
Une fois l’ADK installé, vous pouvez créer une image ISO à partir d’un répertoire source en utilisant la commande suivante :
-m : Ignore la limite de taille maximale pour l’image ISO.
-l"Nom_Volume" : Définit le nom du volume de l’image ISO. Remplacez "Nom_Volume" par le nom souhaité.
Automatisation de la création d’images ISO
Pour automatiser la création d’une image ISO, vous pouvez intégrer la commande ci-dessus dans un script batch (.bat) et planifier son exécution à l’aide du Planificateur de tâches de Windows. Cela est particulièrement utile si le contenu du répertoire source change fréquemment et que vous devez générer régulièrement une nouvelle image ISO.
Cas d’utilisation dans un environnement virtualisé
Imaginons que vous disposez d’une plateforme de test composée de plusieurs machines virtuelles isolées du réseau de production. Si vous souhaitez que certaines données de production (par exemple, des exports DNS, WINS, DHCP, signatures antivirus) soient transférées quotidiennement sur ces machines, vous pouvez :
Placer les données à jour dans le répertoire source.
Créer une image ISO de ce répertoire en utilisant OSCDIMG.exe.
Monter cette image ISO sur les machines virtuelles. Cette opération peut également être automatisée.
Accéder aux données depuis les machines virtuelles.
Cette méthode garantit que vos machines virtuelles disposent toujours des données les plus récentes sans nécessiter de connexions réseau directes avec l’environnement de production.
C’est un cas peu commun et qui m’a donné du fil à retordre (on parle de 3h d’essais/erreurs), c’est suffisamment barbu pour que je prenne la peine de partager l’info, en redonnant du contexte et un peu plus d’explications quand même.
Le contexte, donc
Nous sommes dans une migration de jobs qui s’exécutaient sur Jenkins à la main et qui doivent être refaits dans Gitlab-CI. Une grande partie de la facilité vient du fait que tout est basé sur Ansible, ce qui fait qu’on a finalement qu’à gérer « l’autour » de la logique des jobs, à savoir le setup de l’environnement d’exécution pour Ansible. Certains de ces jobs ciblent des serveurs sous Windows, d’autres sous Linux (Ansible fait ça très bien, via WinRM/Powershell pour Windows, SSH/Python pour Linux). Pour les Windows, un compte technique dans l’annuaire utilisé pour les environnements de préproduction fera le taf à la place de… variables utilisateurs/mots de passe fournies aux jobs à l’exécution. Pour les Linux, ça repose sur un compte dédié avec une clé SSH exploitée par Jenkins.
En temps normal personne se poserait de question, sauf que là, mon problème est que la clé est protégée par une phrase de passe, en anglais passphrase, et c’est particulièrement compliqué de travailler avec, au point que la plupart des gens recommandent de virer la phrase de la clé. Sauf que là, c’est hors de question, j’ai pas le droit d’y toucher. Au moins je peux la récupérer depuis un Vault Hashicorp privé. Et donc, mon premier symptôme, c’est ça :
debug1: Trying private key: /home/appuser/.ssh/id_rsa
debug1: read_passphrase: can\'t open /dev/tty: No such device or address
SSH, ça s’automatise bien normalement, et puis…
Le fameux tty qu’on voit, c’est l’interface qui doit permettre à l’utilisateur d’interagir, et donc de saisir la passphrase au moment souhaité, à savoir quand il doit la présenter pour la connexion. On comprend donc le problème avec un pipeline Gitlab-CI: point de TTY. Et pas la peine d’y penser, le client SSH n’a aucune autre méthode directe pour accepter ladite phrase (c’est pas comme l’installation du SDK Android où on peux suffixer < yes pour répondre automatiquement aux questions d’acceptation des licences).
À force de chercher et de torturer mes termes de recherche, je finis par tomber sur cet article. Fait intéressant, il mentionne des options/variables d’Ansible pour manipuler justement les clés et éviter de fournir la phrase à chaque fois. Mais le problème, c’est que pour ansible_ssh_prompt, on doit indiquer l’intitulé de la question à laquelle on doit répondre par la passphrase et qu’il va devoir « capturer ». Question qui n’est jamais posée puisque pas de TTY pour ça. Ce n’est donc toujours pas exploitable, mais une réponse suivante sur la même page me mets sur la voie.
La documentation d’ssh-add va répondre à mes questions:
DISPLAY, SSH_ASKPASS et SSH_ASKPASS_REQUIRE
Si ssh-add a besoin d'une phrase secrète, il la lira sur le terminal actif s'il a été lancé dans un terminal. Si ssh-add n'a aucun terminal associé alors que DISPLAY et SSH_ASKPASS sont défi‐
nies, il exécutera le programme spécifié par SSH_ASKPASS (par défaut « ssh-askpass ») et ouvrira une fenêtre X11 pour lire la phrase secrète. Cela s’avère particulièrement utile lors de l'appel
de ssh-add depuis un fichier .xsession ou un script similaire.
Je tente donc la solution, mais fait face à un nouveau message d’erreur:
ssh_askpass: exec(/home/appuser/.ssh/.print_ssh_password): Exec format error
Là, ça m’a pris beaucoup moins de temps, et la solution finale était tout près, il manque le shebang au script que je fournis (.print_ssh_password). Au passage, et contrairement à la majorité des posts que j’ai pu lire sur le sujet, j’utilise une base python-alpine pour le job et pas Debian/Ubuntu, ce n’est donc pas bash qui est aux commandes, et donc il faut adapter un chouia la séquence, mais ça a donné ça :
Ouais, la brochette de v à la fin permet d’avoir le moindre bout de message d’erreur, franchement abusez-en pendant une telle opération c’est super pratique.
Donc, qu’est-ce qu’on a fait ? En amont, via Vault, on récupère la clé privée dans la variable key et sa passphrase dans la variable passphrase, rien de très original là-dedans. En passant, comme cette récupération se fait pendant l’exécution du job, job qui se lance dans un runner Kubernetes, il n’y a pas de stockage persistant de ces variables. On crée le dossier .ssh avec les bonnes permissions à la racine du dossier utilisateur de l’image, et on y place un petit script dont le seul rôle est d’afficher le contenu de la variable passphrase. On démarre le ssh-agent, puis on traite le contenu de la variable key (pour virer d’éventuels retours chariot à la Windows), avant de l’envoyer à ssh-add (le tiret à la fin permet de dire qu’on lui envoie la clé directement, sans passer par un fichier), à qui on précise les variables DISPLAY et SSH_ASKPASS pour éviter de chercher à poser la question à un humain, la réponse étant directement fournie par le script.
C’est vrai quoi, une API finalement c’est mieux pour faire tout ça non ?
J’avais envie de troller un peu, mais plus sérieusement, étant donné qu’il y a aussi un annuaire pour gérer les connexions utilisateurs sous Linux, je suis surpris que la méthode repose sur ce genre de mécanisme avec un compte local et une clé SSH et pas un compte technique de la même nature que pour les Windows, ce qui aurait simplifié le processus tout en harmonisant les configurations.
En tout cas, j’étais soulagé et heureux d’avoir pu trouver la solution et continuer mes migrations. Et vous, vos connexions SSH dans Gitlab-CI, vous les gérez comment ?
Microsoft vient de franchir un pas de plus dans l’amélioration de ses outils d’IA générative. Lors sa conférence Ignite, la société a présenté Copilot Actions. Il s’agit d’une extension innovante de son outil Microsoft 365 Copilot qui promet de révolutionner le quotidien des utilisateurs en automatisant des tâches répétitives. En plus de ceci, la firme ... Lire plus
Le dernier Magic Quadrant de la RPA met en avant l'importance du packaging des offres, dans un contexte de convergence avec des segments adjacents du marché IT.
Connexion
