Template on Zwindler's Reflection

Récupérer les informations sur la distribution avec les facts Ansible

Wed, 21 Nov 2018 12:45:40 +0000

Les facts d’Ansible

Si vous suivez le blog, vous savez que j’utilise énormément Ansible. J’ai même été faire un talk sur le sujet à BDX I/O 2018, à l’ENSEIRB.

Aujourd’hui, plutôt que de vous donner un playbook tout fait pour installer sans effort une des multiples applications dont j’ai automatisé le déploiement avec Ansible, je vous propose d’explorer une des features les plus importantes et utiles d’Ansible, les facts, par le biais d’un petit exemple.

C’est quoi les facts dans Ansible

Si vous avez déjà lancé un playbook, vous avez sûrement remarqué lors de son exécution, que la première tâche qui est réalisée n’est pas une tâche que vous avez demandée explicitement.

ansible-playbook -i inventory/prod/blop -u blop --private-key=blop.key configure-blop.yml
[...]]
TASK [Gathering Facts] *********************************************************
ok: [blop-vm1]

Cette tâche [Gathering Facts], qui ne fait à première vue rien, correspond en fait à la connexion à la ou les machines sur lesquelles seront exécutées les playbooks. Si la connexion échoue, le playbook échouera sur cette cible, et continuera éventuellement sur les autres (s’il en reste). Si l’hôte répond, alors Ansible en profite pour récupérer moult informations en rapport avec cette machines et les stockent dans une variable ansible_facts.

A quoi ça ressemble ?

Comme je ne disais, à première vue, cette commande de fait rien. Si on ne sait pas qu’elle stocke des informations dans une variables, on ne peut rien en faire.

Un bon moyen d’avoir un premier aperçu de ce qu’on peut en faire est de les afficher. On peut faire ça avec le module « setup », qui est en réalité le même module qui est appelé lors de l’étape [Gathering facts].

Le retour se fera au format JSON, ce qui est certes peu digeste, mais facilitera grandement les manipulations de type « filtre » (via le flag filter intégré ou via l’utilitaire jq par exemple).

ansible blop-vm1 i inventory/prod/blop -m setup
blop-vm1 | SUCCESS => {
"ansible_facts": {
"ansible_all_ipv4_addresses": [
"10.1.1.10"
],
"ansible_apparmor": {
"status": "enabled"
},
[...]

Je ne vous copie-colle pas tout, rien que pour cette machine, j’ai 719 lignes… La quantité d’informations disponible est impressionnante, et on peut même en venir à se demander à quoi ça va bien pouvoir nous servir.

Ok, on en fait quoi ?

Du coup je profite de cet article pour faire un tuto tout simple et qui peut être utile dans de nombreux cas, réaliser des opérations différentes en fonction de la distribution de la machine concernée.

L’information qui va nous intéresser ici concerne donc les remontées en tant que « nom » ou « version » d’une distribution. Je vais vous économiser la lecture de nos 700+ lignes, et vous indiquer que vous pouvez trouver ces informations en filtrant sur les mots clés « ansible_distribution… » et « ansible_os… »

Voilà ce qu’on pourrait obtenir sur une machine CentOS :

ansible blop-vm1 -m setup -a 'filter=ansible_distribution*'
blop-vm1 | SUCCESS => {
"ansible_facts": {
"ansible_distribution": "CentOS",
"ansible_distribution_major_version": "7",
"ansible_distribution_release": "Core",
"ansible_distribution_version": "7.2.1511"
},
"changed": false
}
ansible blop-vm1 -m setup -a 'filter=ansible_os_family'
blop-vm1 | SUCCESS => {
"ansible_facts": {
"ansible_os_family": "RedHat"
},
"changed": false
}

Et sur une machine Ubuntu :

ansible blop-vm2 -m setup -a 'filter=ansible_distribution*'
ansible blop-vm2 | SUCCESS => {
"ansible_facts": {
"ansible_distribution": "Ubuntu",
"ansible_distribution_file_parsed": true,
"ansible_distribution_file_path": "/etc/os-release",
"ansible_distribution_file_variety": "Debian",
"ansible_distribution_major_version": "16",
"ansible_distribution_release": "xenial",
"ansible_distribution_version": "16.04"
},
"changed": false
}
ansible blop-vm2 -m setup -a 'filter=ansible_os*'
blop-vm2 | SUCCESS => {
"ansible_facts": {
"ansible_os_family": "Debian"
},
"changed": false
}

Utiliser les facts dans un playbook

Pour continuer dans l’exemple, on va faire une chose qu’il ne faut jamais faire : désactiver le firewall et SELinux.

Imaginons que vous souhaitiez quand même le faire. Si vous lancez ce playbook sur tout votre parc et qu’il n’est pas homogène, vous allez tomber sur des groupes de machines Ubuntu, CentOS 5, 6, 7…

Un moyen de gérer les cas particuliers pourrait être de les classer tous vos hosts dans des groupes, et de créer un playbook pour chaque OS/version, restreint à un groupe de machines uniquement.

---
- hosts: rhelcentos6only
tasks:
[…]

Ce n’est d’ailleurs pas une mauvaise idée, surtout pour gérer les distrib aussi différentes que RHEL et Ubuntu par exemple.

En revanche, dans le cas de RHEL, on a des différences qui apparaissent à partir de la RHEL 7, notamment la gestion du Firewall qui passe de IPtables à firewalld.

On va donc faire appel à la clause when: de ansible, qui conditionne l’exécution d’une tâche (ou d’un rôle ou d’un block) à une validation. Et ça donnerait quelque chose comme ça :

---
- hosts: rhelcentos6only
tasks:
- name: "shutdown and disable IPtables for RHEL <= 6"
service:
name=iptables
state=stopped
enabled=no
when: (ansible_distribution == "CentOS" or ansible_distribution == "RedHat") and
(ansible_distribution_major_version <= "6")
- name: "shutdown and disable firewalld for RHEL >= 7"
service:
name=firewalld
state=stopped
enabled=no
when: (ansible_distribution == "CentOS" or ansible_distribution == "RedHat") and
(ansible_distribution_major_version >= "7")
- name: "disable selinux"
selinux:
state=disabled

Dans cet exemple, lors de l’exécution du playbook, on aura donc, pour chaque VM CentOS ou RHEL, une tâche qui sera exécutée, et l’autre qui sera marquée « skipping » (en bleu clair) et le playbook marchera pour toutes les RHEL, quelque soit leur version.

Aller plus loin

Il existe une page spécifique sur la documentation d’Ansible pour parler des conditions dans les playbooks, accessible à l’adresse suivante : https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_conditionals.html

Vous pouvez aussi utiliser les facts dans les options des tasks, et dans les templates, en encadrant le nom de la variable souhaitée avec des « doubles curly braces » : {{ xxx }}

- command: "echo {{ ma_super_variable }}"

Sources

Déployer des VM VMware avec Ansible – part 2

Tue, 14 Nov 2017 12:45:27 +0000

Où est ce qu’on en était ?

La dernière fois qu’on a parlé de [machines virtuelles déployées à l’aide d’Ansible sur une infrastructure VMware][1], on avait un playbook fonctionnel, mais il me manquait encore un petit quelque chose.

En fait, à l’issue du déploiement de la VM, je n’avais pas encore trouvé la possibilité d’enchaîner sur l’exécution d’autres playbooks permettant de configurer la VM. L’objectif ultime étant de faire en une seule étape de :

déployer la VM (que j’appellerai « déploiement »)
et de la configurer, c’est à dire modifier les fichiers de configuration de la VM, installer les logiciels, etc… (que j’appellerai « configuration »).

Premier problème, connection:local

Pour rappel, le premier problème quand on veut déployer une VM qui n’existe pas encore… est justement le fait qu’elle n’existe pas encore !

Si j’exécute un playbook deploy_vm.yml sur une VM « ma-vm » tel quel, je vais me prendre un message d’erreur (pour plus de détails, lire l’article précédent) car Ansible tente de se connecter à la machine pour récupérer des informations sur elle.

La méthode pour s’affranchir de ce genre de problèmes est de feinter Ansible en lui disant :

de ne pas récupérer les informations de la machine
d’exécuter le playbook sur une autre machine (le plus simple c’est localhost)

Pour le premier point, la solution est mettre en haut du playbook l’option gather_facts: false. Cela aura un impact mais on verra ça plus loin.

Pour le second point, il existe 2 solutions. La première, que je préconisais dans l’article précédent, consiste à utiliser en haut du playbook l’option connection: local. Cette option permet d’exécuter l’ensemble du playbook sur la machine locale et non pas la machine qu’on déploie.

En réalité, il est en fait plus simple d’utiliser l’option delegate_to, qui se limite à une seule tâche ou à un rôle, ce qui permet de déléguer la partie déploiement à localhost, puis tenter d’exécuter les autres playbooks sur la VM qu’on veut configurer.

Un problème de nom … pas si facile à résoudre

Vous avez vu le jeu de mot ? Ok, je sors…

Bien sûr, on va se heurter à plusieurs problèmes… Le premier est la résolution de nom. A moins d’avoir réalisé la mise à jour de votre DNS à l’avance (à la main du coup… c’est nul), dès que le déploiement sera terminé et qu’on passera à la partie configuration de la VM, Ansible essayera de contacter votre nouveau serveur.

Le plus propre serait d’ajouter à la partie « déploiement » une tâche permettant de mettre à jour le DNS. Dans mon environnement professionnel, le service DNS est géré par un serveur Windows Active Directory. La simple mise à jour du DNS depuis Linux est un vrai casse tête et le plus simple est d’intégrer la machine (qu’elle soit Windows ou Linux) dans le domaine Active Directory qui se charge alors de mettre à jour le DNS lui même.

C’est un gros sujet et je ferai un article à part dessus. Dans un premier temps on peut se contenter de juste mettre à jour le fichier /etc/hosts de la machine localhost.

- name: add to /etc/hosts file
lineinfile:
dest: /etc/hosts
line: '{{ custom_ip }} {{ inventory_hostname }} {{ inventory_hostname }}.zwindler.fr'
with_items: '{{play_hosts}}'
when: "hostvars[item].inventory_hostname == inventory_hostname"
delegate_to: localhost

Accès concurrents

Si vous vous y connaissez un peu en Ansible, vous remarquerez que je ne me suis pas contenté d’un simple lineinfile, mais que j’ai utilisé un with_items et un when.

En fait, on peut utiliser mon playbook pour déployer en parallèle un grand nombre de VMs en même temps. Le souci que j’ai rapidement eu a été un accès concurrent sur le fichier, et des noms de VMs ont alors manqué.

Il existe une fonction « serial » qui permet de désactiver la parallélisation des tâches, mais malheureusement, on ne peut l’appliquer qu’au playbook entier. Peut être qu’un jour la fonctionnalité sera ajoutée (la demande est référencée sur Github)

J’ai donc du passer par une boucle pour enregistrer tous les serveurs du play courant.

Clé SSH

OK, maintenant, on sait résoudre la (ou les) machine(s) qu’on vient d’ajouter. Cependant on est pas sorti de l’auberge !

En partant du principe que vous n’avez pas oublié de déposer la clé SSH du serveur localhost pour qu’Ansible puisse se connecter sur votre nouvelle machine, voilà ce qui va se passer :

TASK [gather facts] *************************************************************************************************************************************************************************
The authenticity of host 'zwindler01 (x.x.x.x)' can't be established.
Are you sure you want to continue connecting (yes/no)? The authenticity of host 'zwindler02 (x.x.x.x)' can't be established.
Are you sure you want to continue connecting (yes/no)? The authenticity of host 'zwindler03 (x.x.x.x)' can't be established.

Ansible bloque à la première connexion SSH vers votre VM nouvellement crée car il faut accepter l’empreinte de chaque VM manuellement au préalable. Même si on essaye de renseigner yes à toutes les questions, ce n’est clairement pas idéal et encore moins automatisé !

La solution temporaire, host_key_checking=False

Il existe un paramètre dans Ansible qui permet de passer outre la vérification de l’empreinte de la machine, soit en modifiant le fichier de configuration ansible.cfg, soit ajouter un flag à l’exécution de playbook, soit configurer une variable d’environnement.

ansible-playbook -l zwindler* -i hosts_deploy -e 'host_key_checking=False' deploy_vmware_guest.yml
#OU
export ANSIBLE_HOST_KEY_CHECKING=False
ansible-playbook -l zwindler* -i hosts_deploy deploy_vmware_guest.yml

Vous trouverez plus d’informations sur cette solution de contournement sur les sites suivants :

Cette solution de contournement est à proscrire en production, car elle va ignorer l’empreinte de TOUTES les machines et pour TOUS vos playbooks. Au delà du problème évident de sécurité que ça pose, si vous enlevez l’option à un moment donné, c’est retour à la case départ. Vous aurez de nouveau la question sur tous les serveurs dont vous n’avez pas explicitement accepté l’empreinte.

ssh-keyscan à la rescousse

On va donc ajouter la tâche suivante à notre playbook de déploiement :

- name: accept new ssh fingerprints
shell: ssh-keyscan {{ custom_ip }},{{inventory_hostname}} >> ~/.ssh/known_hosts
with_items: '{{play_hosts}}'
when: "hostvars[item].inventory_hostname == inventory_hostname"
delegate_to: localhost

Je sais… c’est terrible : la solution que j’ai à l’heure actuelle, bien que fonctionnelle, N’EST PAS IDEMPOTENTE… :-( mais elle fonctionne.

Et on fini par un petit setup pour récupérer les facts.

- name: gather facts
setup:

Et maintenant ?

Et bien ! Maintenant, ça marche ! Vous pouvez enchainer d’autres tâches (ou des rôles) en ne mettant plus delegate_to, et ces tâches de « configuration » seront bien lancées sur le serveur que vous venez de déployer, dans un seul et même playbook.

---
- hosts: all
gather_facts: false
vars_prompt:
- name: "vsphere_password"
prompt: "vSphere Password"
- name: "esxi_host"
promt: "ESXi host"
private: no
- name: "notes"
prompt: "VM notes"
private: no
default: "Deployed with ansible"
roles:
- deploy_vmware_guest
- other_role_for_configuration

Pari réussi !

Et le playbook, il est où ?

Une fois de plus, je suis sympa, je vous donne un exemple de code sur mon Github !

Automatisation de la supervision avec Centreon et Ansible (3)

Wed, 07 Dec 2016 13:00:47 +0000

Articles précédents sur Centreon et Ansible

Cet article fait suite aux deux articles rédigés en mai 2015 par Cédric Temple (ici et ici) qui donnent des pistes pour automatiser l’ajout de nœuds à superviser dans un console Centreon grâce à Ansible et CLAPI.

Pour ceux qui ne connaissent pas Ansible, je vous invite fortement à vous documenter sur cet outil de déploiement et de gestion de configuration très complet et qui bénéficie en ce moment d’un fort engouement, surtout depuis qu’Ansible a été racheté par RedHat ;-).

Et pour ceux qui ne connaissent pas CLAPI, il s’agit d’une API mise à disposition avec Centreon. Elle est installée par défaut dans les dernières versions. Elle permet de réaliser la totalité des opérations pouvant être faites depuis la console web en ligne de commande.

Les deux articles sur Monitoring-fr que je cite au début sont une bonne base pour appréhender ces deux sujets. Pour autant, on peut encore aller un peu plus loin et c’est pourquoi je vous propose de repartir de là où s’arrête l’article précédent.

L’exemple de l’ajout de l’hôte

A la fin de l’article précédent, on sait donc :

installer automatiquement les clients de supervision sur un nouvel hôte
et réaliser de manière unitaire via Ansible et des playbooks l’ajout et la modification d’hôtes dans Centreon.

J’aimerai revenir sur l’ajout d’hôtes dans Centreon. Pour reprendre l’exemple du playbook d’ajout d’hôtes de Cédric :

cat centreon_add_host.yml
- name: centreon add host
shell: /usr/share/centreon/www/modules/centreon-clapi/core/centreon -u admin -p admin -o HOST -a add -v '{{ inventory_hostname }};{{ inventory_hostname }};{{ ansible_default_ipv4.address }};generic-host;central;ALL_HOST'
delegate_to: superviseur.company.lan

Et voici le fichier d’inventaire dans lequel on déclare l’ensemble de nos serveurs, triés par groupes.

cat /etc/ansible/hosts #fichier hosts d'Ansible
#ne pas confondre avec le hosts d'un serveur Linux
[serveurs-centreon]
superviseur.company.lan
pollerprod.company.lan
[serveurs-prod]
srv-prod-01
srv-prod-02
[serveurs-rect]
srv-rect-01
srv-rect-02
[nouveaux]
srv-nouveau-01
srv-nouveau-02
[serveurs-linux:children]
serveurs-prod
serveurs-rect
nouveaux

Dans cet exemple simple, la première chose qu’on se dit si on regarde un peu rapidement, c’est qu’on aurait pu réaliser cet ajout à la main (ou via un script) avec CLAPI.

Le gain apporté par Ansible se situe « seulement » dans l’apport des variables inventory_hostname et ansible_default_ipv4.address.

Ici on tire partie de la faculté qu’a Ansible de récupérer des « facts » sur les machines, telle que l’adresse IP, que nous n’avons pas eu à renseigner.

C’est déjà un bon point par rapport à un script ou une commande à la main … mais on peut faire mieux !!

Aller plus loin : avec les variables de groupes

La première chose que je vais montrer dans cet article est qu’on peut également affecter aux groupes d’hôtes dans Ansible des variables.

Dans notre exemple, je vais donc créer un répertoire group_vars dans lequel je vais créer des fichiers de configuration dédiés à chaque groupe. J’en créé un par groupe (ou pas), et Ansible analysera automatiquement le répertoire group_vars et appliquera à mes hôtes toutes ces variables en fonction de ses groupes.

cat /etc/ansible/group_vars/serveurs-linux.yml
#NRPE Servers
nrpe_servers: ['192.168.100.10', '192.168.100.11']
#Poller Centreon
centreon_server: 'superviseur.company.lan'
centreon_pollername : 'Central'
centreon_clapi_username : 'admin'
centreon_clapi_password : 'admin'
centreon_clapi_path : '/usr/share/centreon/www/modules/centreon-clapi/core/centreon'

Je modifie donc mon playbook de la façon suivante :

cat centreon_add_host.yml
---
- name: centreon add host
shell: '{{centreon_clapi_path}}' -u '{{ centreon_clapi_username }}' -p '{{ centreon_clapi_password }}' -o HOST -a add -v '{{ inventory_hostname }};{{ inventory_hostname }};{{ ansible_default_ipv4.address }};generic-host;{{ centreon_pollername }};ALL_HOST'
delegate_to: '{{centreon_server}}'

Le playbook est beaucoup plus réutilisable qu’avant. Qu’est ce qui a changé ?

J’ai variabilisé le chemin vers le binaire d’appel de CLAPI, qui était quand même vraiment long (Même si on préfèrera probablement plutôt ajouter le chemin dans le PATH, simplement) !
Je n’ai plus à renseigner le username et le mot de passe pour CLAPI à chaque appel.
Si j’ai plusieurs serveurs Centreon (plusieurs réseaux distincts par exemple), je n’ai qu’à créer un groupe et un fichier de variables dans group_vars dans lequel je renseignerai « centreon_server », « clapi_username » et « clapi_password » différents. Mon playbook restera inchangé.
Si j’ai plusieurs pollers (pollerprod pour la prod dans cet exemple), je peux affecter le serveur directement au bon poller avec la variable « centreon_pollername ».

Encore un peu plus loin : avec les groupes et l’héritage

Dans la configuration exemple que je donne plus haut, vous aurez peut être remarqué le groupe serveurs-linux qui regroupe tous les serveurs des groupes serveurs-prod, serveurs-rect et nouveaux.

[serveurs-linux:children]
serveurs-prod
serveurs-rect
nouveaux

De cette manière, tous les paramètres communs à tous les serveurs linux peuvent être configurés au niveau serveurs-linux. Les variables seront héritées lors de l’exécution du playbook.

On peut aussi utiliser les groupes comme conditions de l’exécution d’un playbook. Ainsi, le playbook suivant ne s’exécutera que si le serveur fait parti du groupe serveurs-prod.

cat centreon_add_host_prod.yml
---
- name: centreon add host when in serveurs-prod
shell: '{{centreon_clapi_path}}' -u '{{ centreon_clapi_username }}' -p '{{ centreon_clapi_password }}' -o HOST -a add -v '{{ inventory_hostname }};{{ inventory_hostname }};{{ ansible_default_ipv4.address }};generic-host;{{ centreon_pollername }};ALL_HOST'
delegate_to: '{{centreon_server}}'
when: "'serveurs-prod' in group_names"

Toujours plus loin : avec les variables et les templates

Les variables sont vraiment un gros plus !

Elles me permettent notamment de configurer les fichiers nrpe.conf (ou ntpd.conf, snmpd, resolv.conf, …) pour accepter les connexions des bons serveurs en fonction de la localisation ou du groupe.

La fonctionnalité la plus utile dans ce cas là est l’utilisation de templates. Il s’agit de fichiers de configurations variabilisés qui sont déployés uniquement si nécessaire sur les serveurs cibles en fonction de leurs variables.

Exemple d’un template de fichier nrpe.conf

{{ ansible_managed }}
cat nrpe.conf.j2
log_facility=daemon
pid_file=/var/run/nrpe.pid
server_port=5666
nrpe_user=nagios
nrpe_group=nagios
allowed_hosts={% for i in nrpe_servers %} {{ i }}, {% endfor %}
debug=0
command_timeout=60
connection_timeout=300
command[check_users]=/libexec/check_users -w 5 -c 10
[...]

Le playbook suivant permettra de le déployer sur l’ensemble de mes serveurs CentOS et Redhat le package du client nrpe et ses dépendances et configurer le fichier nrpe.cfg en fonction du contexte (pour ceux qui n’ont pas encore ce fichier ou une version différente).

cat nrpe.yml
---
- hosts: all
tasks:
- yum: name={{ item }} state=installed
with_items:
- nrpe.x86_64
- net-snmp
- sysstat
- ...
- template: src=nrpe.cfg.j2 dest=/etc/nagios/nrpe.cfg

Une fois exécuté avec la commande suivante, Ansible balayera l’ensemble des serveurs renseignés dans le fichier /etc/ansible/hosts, vérifiera qu’ils ont tous les packages nrpe d’installés, puis déploiera sur les serveurs nécessaires le fichier de configuration en fonction des variables de chacun.

ansible-playbook -i /etc/ansible/hosts /etc/ansible/nrpe.yml

Et dans mon exemple on obtiendra un fichier de la forme suivante :

# Ansible managed: nrpe.cfg.j2 modified on 2016-08-14 10:52:51 by ansible on hostname
log_facility=daemon
pid_file=/var/run/nrpe.pid
server_port=5666
nrpe_user=nagios
nrpe_group=nagios
allowed_hosts=192.168.100.10, 192.168.100.11,
debug=0
command_timeout=60
connection_timeout=300
command[check_users]=/libexec/check_users -w 5 -c 10
[...]

Mais Ansible est avant tout un gestionnaire de configuration

Ansible ne sert pas uniquement à déployer des applications sur un serveur ou à exécuter des tâches automatisables. Au delà de ces rôles qu’il rempli à merveille, Ansible est surtout un gestionnaire de configuration (comme Puppet, Salt, …).

Ansible is the simplest way to automate apps and IT infrastructure. Application Deployment + Configuration Management + Continuous Delivery.

On le voit avec mon dernier exemple : le but est de garantir qu’un ensemble de serveurs donnés, on a toujours la même configuration.

C’est le principe fondamental des outils de gestion de configuration et on comprend vite le gain :

Si une modification est réalisée par erreur, elle sera automatiquement corrigée au prochain passage du playbook => on n’aura pas besoin d’attendre qu’un administrateur passe par hasard sur un serveur pour remarquer une anomalie sur le NTP par exemple.

Appliqué à la supervision et Centreon

Je garanti que tous les serveurs inscris dans Ansible sont automatiquement ajoutés dans Centreon, en fonction de leur groupe. Si un administrateur oublie d’ajouter un serveur ou en supprime un, il sera ré-ajouté à l’exécution d’après sans intervention manuelle.

C’est donc de cette manière qu’il est conseillé d’utiliser Ansible. Le playbook n’est pas là pour être joué une fois par serveur, au fil de l’eau, car c’est source d’erreur ou d’oublis. On préférera plutôt exécuter régulièrement l’ensemble des playbooks qui définissent le SI sur l’ensemble des serveurs pour s’assurer qu’ils sont tous « conformes », sur tous les aspects dont la supervision.

Le réel gain en terme d’automatisation ce trouve ici.

Et dans l’article qui va suivre ?

Et c’est sur cette deuxième partie que nous nous attarderons dans le prochain article : la gestion de playbook pour automatiser la configuration de la supervision pour l’ensemble de nos hôtes via des playbooks idempotent (#teasing) !

Une erreur grave s’est produite lors de l’exécution de sysprep sur l’ordinateur

Sat, 05 Mar 2016 13:00:52 +0000

Dépassement du nombre de sysprep autorisé

A force d’(ab)user de virtualisation de serveurs, on prend forcément gout aux fonctionnalités offertes par l’infrastructure. Hormis VMware qui fait encore payer les templates (tacle gratuit, même si on peut s’en sortir comme ceci), la plupart des éditeurs d’hyperviseurs proposent gratuitement la fonctionnalité qui permet, à partir d’une machine virtuelle existante, de créer un modèle qui servira de socle pour les déploiement futurs.

On gagnera un temps fou en s’évitant l’installation de l’OS à chaque fois (même si ça s’automatise d’autres façons je l’accorde) et surtout à toujours reparametrer les mêmes choses comme les DNS, le NTP, le client de supervision, …

Ça marchera plutôt bien sur vos bons vieux Linux (sauf dans pour la gestion du réseau CentOS/RHEL6, corrigé en 7), mais Microsoft, lui, ne l’entendra pas de cette oreille !

Lorsque vous déployez un serveur ou un poste de travail sous Windows, vous êtes limités dans le nombre de sysprep consécutifs que vous pouvez exécuter pour réinitialiser les variables de types SID dans le registre de la machine.

Or, pour des raisons de stabilité et de sécurité, de nombreux administrateurs réalisent un sysprep une fois que leur template est terminé, ce qui permet de réinitialiser le SID du modèle, ce qui rendra par la suite la future VM unique au moment de son déploiement. Et si vous modifiez régulièrement vos templates, la limite peut arriver vite.

L’erreur et sa solution

Lorsque l’on déploie une image sur un poste ou un serveur et qu’on reçoit le message d’erreur suivant :

Une erreur grave s’est produite lors de l’exécution de sysprep sur l’ordinateur

A fatal error occurred while trying to sysprep the machine

La procédure pour contourner le compteur de Microsoft se passe en plusieurs étapes.

Regedit

Premièrement, il faut commencer par modifier les trois chaînes regedit suivantes :

HKEY_LOCAL_MACHINE\SYSTEM\Setup\Status\SysprepStatus\CleanupState:2
HKEY_LOCAL_MACHINE\SYSTEM\Setup\Status\SysprepStatus\GeneralizationState:7
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform\SkipRearm:1

Éventuellement, on peut préférer exécuter un fichier .reg contenant les lignes suivantes :

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\Setup\Status\SysprepStatus]
"GeneralizationState"=dword:00000007
"CleanupState"=dword:00000002
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform]
"SkipRearm"=dword:00000001

Deuxièmement, effectuer deux commandes (dans l’invité de commandes ou exécuter Powershell en tant qu’administrateur), en attendant 5 à 10 secondes entre chaque commandes. Cette opération est réellement nécessaire car j’ai eu des échecs en essayant de ne pas le faire, pour voir.

msdtc -uninstall
msdtc -install

Dernière étape avant le sysprep : le skiprearm.xml

Attention, ce fichier dépend de votre version. Suite à un commentaire je me suis rendu compte que le fichier que je fournissais ne fonctionne plus sur les versions « récentes » de Windows.

Pour les vielles versions (2003 jusqu’à 2008 mais pas trop à jour?)

Troisièmement, créer un fichier nommé c:\Windows\system32\sysprep\skiprearm.xml contenant le texte suivant :

<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
<settings pass="generalize">
<component name="Microsoft-Windows-Security-Licensing-SLC" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<SkipRearm>1</SkipRearm>
</component>
</settings>
</unattend>

Pour les versions plus récentes et à jour

<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
<settings pass="generalize">
<component name="Microsoft-Windows-Security-SPP" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<SkipRearm>1</SkipRearm>
</component>
</settings>
</unattend>

Le sysprep

Une fois que ces trois étapes ont été réalisées, on reboot le serveur et on peut exécuter le sysprep en ligne de commande à la suite.

cd c:\windows\system32\sysprep
sysprep /generalize /oobe /shutdown /unattend:c:\Windows\system32\sysprep\skiprearm.xml

Dans mon exemple, je ne fais que couper la machine en fin de processus, il n’y a pas de reboot. Ceci me permet de transformer ma machine virtuelle en modèle à la suite. Ainsi, les VMs qui seront déployées avec ce modèle auront déjà eu leur sysprep au moment du premier boot, ce qui me gagne du temps.

Note complémentaire

Il y a débat sur le fait que le sysprep soit toujours nécessaire aujourd’hui, surtout depuis l’article du TechNet « The Machine SID Duplication Myth (and Why Sysprep Matters) » de Mark Russinovich, auteur de NewSID.exe, l’Utilitaire (avec un grand U) utilisé pour réinitialiser les SID sous XP/2003.

On y apprend en gros qu’il n’y a aucun risques à cloner des machines Windows sans réinitialiser les SID et que dans la grande majorité des cas, le sysprep n’est donc pas nécessaire depuis 2008. C’est d’ailleurs pour cela que l’auteur indique ne plus maintenir son NewSID.exe.

Pour autant, je peux attester personnellement de deux contextes en Windows 2008 et pour lesquels la duplication du SID a provoqué un dysfonctionnement majeur du fonctionnement des applications Microsoft (notamment l’installation d’un domaine Active Directory). Donc jusqu’à preuve du contraire, je continuerai à faire des sysprep sur mes clones/templates Windows Server.

Nombre de sysprep restants

Il existe une commande pour vérifier le nombre de sysprep qu’on peut encore refaire (trouvé sur Power Shell) :

slmgr.vbs /dlv

Sources additionnelles

Centreon / hostgroups / modèles d’hôtes, la réponse de Centreon à mon article

Sat, 18 Apr 2015 21:05:59 +0000

J’ai reçu une réponse par commentaire d’une personne de chez Centreon (apparemment) à la suite de mon article </2014/09/11/rage-non-centreon-nautorise-pas-les-hostgroups-pour-les-modeles-dhotes/>

Pour rappel, Centreon gère les héritages via les modèles d’une façon un peu différente de Nagios. Au moment de la création de l’hôte dans Centreon, l’héritage est « aplati » et les services sont unitairement créés sur l’hôte, qui devient autonome. La configuration ainsi générée est simplifiée.
S’il y a surement de nombreuses raisons pour procéder de la sorte, une des conséquences et que, lorsqu’on met à jour un modèle d’hôte, les hôtes déjà créés ne bénéficient pas de cette mise à jour.

Je propose dans l’article en question plusieurs méthodes de contournement sans pour autant avoir de solution idéale, notamment via la liaison par de services à des groupes d’hôtes, qui eux restent dynamiques malgré quelques limitations.

Laurent Pinsivy (si c’est bien lui, on ne sait jamais trop avec L’Internet) en propose une autre.

La « solution »

Admettons que je mette à jour mon modèle d’hôte Win_2K (par exemple, j’ajoute un service grâce à un modèle de service).
Pour que les serveurs prennent en compte l’ajout du nouveau service, je commence par filtrer l’ensemble des serveurs qui héritent de ce modèle :

Je peux ainsi sélectionner l’ensemble des serveurs qui héritent directement (c’est important) de ce modèle, puis via l’option « Changement Massif » les modifier tous d’un coup.

Pour que les paramètres modifiés dans le modèle soient propagés dans les hôtes en héritant, je coche l’option « Créer aussi les services liés au modèle ». Centreon réitère le processus d’aplatissement de l’héritage -comme lors de la création de l’hôte- ce qui a pour effet de remettre à jour nos hôtes.

Petite subtilité : selon ce que l’on souhaite faire, il faut positionner le mode de mise à jour à « Incrémentale » dans le cas d’un ajout dans le modèle et « Remplacement » pour une modification d’un des attributs du modèle.

Mon avis après test

J’ai quand même de gros doutes sur cette « solution » :

[à mon gout] c’est beaucoup moins souple/pratique que le mode d’héritage de Nagios, voire même l’utilisation des services par groupes d’hôtes (même si il faut bidouiller pour gérer les exceptions).
J’ai donné ici l’exemple d’un ajout ou de la modification d’un service existant. Pour la suppression d’un modèle, je ne suis sûr ni des impacts ni même que ça fonctionne…
Si je modifie un modèle (generic-host par exemple) dont hérite un modèle fils (win_2k), et que je filtre sur le modèle père, je ne vais sélectionner que les hôtes qui héritent explicitement du modèle père.
On « oublie » alors tous ceux qui héritent du modèle fils (et donc implicitement du modèle père), alors qu’ils sont pourtant potentiellement concernés si le modèle fils n’écrase pas certains paramètres. C’est pourtant souvent le cas, c’est l’intérêt même de l’héritage multiple.

Une fois encore, je peux rater quelque chose. Mais en l’état, pour moi, le manque reste entier ;-)

Créer un modèle/template VM Windows XP sous ESXi sans vCenter

Sun, 20 Mar 2011 21:58:23 +0000

VMare a beau prétendre proposer un hyperviseur gratuit, la plupart des fonctions vitales d’un hyperviseur y sont absentes si on ne dispose pas d’une licence, contrairement aux concurrents (libres ou non). Sans prôner le libre à tout prix (je veux bien comprendre qu’il faut vivre de son produit, et ajouter des fonctionnalités selon les licences n’est pas une stratégie marketing dénuée de sens), il est quand même vraiment dommage de proposer un produit gratuit sans donner la possibilité de l’utiliser dans un environnement réel. Ça donne un peu le gout amer de shareware…

Parmi ces fonctions vitales qui n’ont aucunes raisons d’être payantes selon moi, j’ai nommé :

La possibilité de disposer d’un moyen de copier facilement des machines virtuelles pour déployer en peu de temps un SI virtualisé. Rien de plus horrible que de devoir se taper une demi heure de réponses débiles dans l’écran d’installation d’un OS. N’importe quel admin système a désespérément besoin de cette fonctionnalité, aussi petit soit le SI en question, et sans laquelle la virtualisation perd une bonne partie de son avantage en terme de gain de temps par rapport à une architecture physique…

Mais heureusement, il y a une petite astuce assez simple pour s’en affranchir.

Ne cherchez pas dans votre vSphere, la fonctionnalité pour copier des VMs n’apparaitra pas si vous ne disposez pas d’un vCenter. Cependant, en fouillant bien, on retrouve des fonctionnalités utilisant une notion un peu similaire, qui est la notion de template…

vSphere propose de créer et d’importer des virtuals appliances. Pour faire simple, ce sont des machines virtuelles « prêtes à fontionner », généralement diffusées sur Internet dans le but de fournir des produits logiciels un peu complexe sans installation (OS de supervision prêt à l’emploi, VM faisant office de pare feu, …).

En détournant cette fonctionnalité à notre avantage, il est donc possible de créer des templates (littéralement « modèle » ou « gabarit ») qui représentent des copies complètes de machines virtuelles à un instant donné. A partir de ce template, il sera donc possible de recréer autant de machines virtuelles identiques que l’on souhaite. CQFD

Voici donc un petit tuto dans la lignée du précédent (rien de techniquement agressif et probablement beaucoup trop détaillé) pour créer un template de VM Windows XP en prenant garde de modifier les paramètres qui doivent rester uniques. En effet, deux machines virtuelles créées à partir d’un template ne peuvent pas fonctionner sur un même réseau, pour les raisons suivantes :

Si la carte réseau virtuelle était configurée avec une adresse IP, elles auront la même adresse IP
Si elles hébergent un système d’exploitation Windows :
- Elles auront le même identifiant supposé unique (SID)
- Elles auront le même nom complet sur le réseau

Comme les données du disque dur sont enregistrées dans le template, il est conseillé de créer des templates avec le moins de données possible sur le disque dur, autant pour des raisons d’économie de l’espace disque que pour gagner en temps de création/déploiement.

Ainsi, il deviendra possible de recréer en quelques minutes des machines virtuelles minimalistes préconfigurées pour une tâche. Attention à ne pas tomber dans l’excès non plus : il est tout de même malin d’installer toutes les mises à jour et tous les logiciels susceptibles d’être installé sur tous les postes, le but de la création de template étant de gagner du temps!

Pour faciliter le déploiement de VM sous Windows, il est conseillé d’ajouter l’utilitaire NewSID.exe qui sera bine utile pour modifier les identifiants uniques de la machine avant de l’introduire sur le réseau.

Créer un template à partir du client vSphere

Choisir une machine à exporter en template, et l’éteindre
Sélectionner la machine virtuelle choisie
Cliquer sur File/Export/Export OVF Template
Entrer un nom et un répertoire de destination pour le template [Next]
Choisir le format d’enregistrement (OVF ou OVA) [Finish]

Ces deux formats sont tous les deux des valeurs possibles. OVF (Open Virtualization Format) est plus standard que OVA, il sera donc plus simple d’importer des fichiers OVF sur un autre système de virtualisation. Cependant, OVA offre la possibilité de tout stocker dans un seul fichier, contrairement à OVF qui génèrera plusieurs fichiers (configuration et disque dur).

Exporter un template à partir du client vSphere

Cliquer sur File/Deploy OVF Template
Choisir un template sur le disque ou depuis une url [Next]
L’assistant affiche une description du template [Next]
Entrez un nom pour la nouvelle machine virtuelle (qui n’existe pas déjà sur le serveur de virtualisation!) [Next]
Choisir dans quel pool la machine virtuelle doit être affectée [Next]
Choisir un Datastore dans lequel la machine virtuelle et sa configuration seront stockées [Next]
[Finish]

Une fois ces opérations terminées, la machine virtuelle est prête à être démarrée par le serveur ESXi. Cependant, il reste quelques opérations à effectuer :

Si la machine est sous Windows :
- Il faut changer le SID de la machine car cet SID est supposé unique. Or, toutes les machines déployées avec ce template auront le même SID : il faut donc en générer un nouveau. Ceci peut être fait à l’aide du programme NewSID.exe (voir la section « utilisation de NewSID.exe »). La modification de ce paramètre ne peut prendre effet qu’après redémarrage de la machine.
- Il faut donner un nouveau nom complet à la machine, car ce nom est supposé unique sur le réseau, et des noms identiques pourraient provoquer des conflits. L’utilitaire NewSID.exe permet de changer ce nom complet, après avoir généré un nouvel SID. Une autre manière de le faire est de d’effectuer l’opération suivante : Panneau de configuration/Système/Nom de l’ordinateur/Modifier et entrer un nom unique sur le réseau. La modification de se paramètre ne peut prendre effet qu’après redémarrage de la machine.
Attribuer à l’interface réseau virtuelle une adresse IP unique en fonction du plan d’adressage du réseau, un masque de réseau adéquat et l’adresse IP du serveur DNS.
Intégrer la machine nouvellement configurée au domaine. Pour se faire, il faut effectuer l’opération suivante : Panneau de configuration/Système/Nom de l’ordinateur/Modifier, sélectionner Membre de Domaine, et entrez le nom du domaine à intégrer.

Utilisation de NewSID.exe

Pour pouvoir modifier le SID et le nom complet de la machine, il faut suivre les étapes suivantes :

Exécuter NewSID.exe [Next]
L’utilitaire affiche le SID actuel, et propose d’en générer un nouveau [Next]
[Next]
L’utilitaire propose de renommer la machine, entrer un nouveau nom complet [Next]
[Next]

Normalement, après ces étapes, le SID sera modifié dans le registre, le nom complet sera modifié, et la machine redémarrera d’elle-même à la fin de la procédure.

Création d’un template CentOS 5.5 pour XenServer 5.6

Tue, 15 Feb 2011 21:46:29 +0000

Depuis quelques temps, ma solution de virtualisation est en place, mes VMs ronronnent, et je me suis lancé un peu plus profondément dans la supervision et tout ce qui s’en approche. Ceux qui lisent mes lignes de temps à autres sauront que j’avais déjà travaillé sur EyesOfNetwork et Nagios, mais j’ai voulu m’attaquer à quelque chose de nouveau et (à mon avis) mieux pensé.

Je parle bien évidemment de l’épopée Shinken, démarrée par un gars de la région, qui a aussi fait mon école, et dont je suis la progression depuis maintenant un moment (pratiquement le début en fait, même si ca à souvent été d’un œil distrait). Seulement voilà, pour pouvoir tester Shinken au maximum de ses capacitées, j’ai besoin de plusieurs VM vierges.

Fini l’époque bénie des VMs construites sur l’envie du moment : j’en ai marre! Il à donc bien fallut s’y résoudre : Créer des templates pour déployer rapidement (et proprement) un réseau complet.

Donc rien de bien « techniquement agressif » (comme dirait l’autre) aujourd’hui, je vous propose un petit tuto pour créer de bout en bout un template CentOS 5.5 sur un XenServer 5.6 (qui ne supporte théoriquement que CentOS jusqu’à 5.4 même si nous verrons que ce n’est vraiment pas un problème).

La première chose à faire pour créer un template c’est de commencer par créer la VM qui nous servira de modèle. Ceux qui auront toujours la même version 5.6 de XenServer que moi s’apercevront qu’il n’y a pas de template prédéfini pour CentOS 5.5. Nous prenons donc un 5.4, ça ne pose pas de problèmes dans le cas d’une installation par le Net (ce que je présenterai ici). Dans le cas d’une installation par l’iso, je crois que c’est plus problématique, et qu’il n’y a pas vraiment de solution à par installer via un DVD 5.4 puis changer de version par la suite (à vérifier).

Comme je l’ai sous-entendu plus haut, je vais profité du fait qu’il est possible d’installer CentOS via HTTP pour pouvoir disposer directement d’une version CentOS 5.5 dans ma VM.

Dans le cas où vous passez par un DVD, il est possible de réaliser cette installation par le net de la même façon, en sélectionnant le média FTP ou HTTP lors de l’installation.

URL : mirrors.centos.org
Directory : centos/5.5/os/x86_64

CentOS se met donc à s’installer sur la VM, une fois que vous avez répondu à toutes les questions. Pour tous les paramètres réseaux, comme il s’agit d’un template, il vaut mieux se contenter de garder des paramètre simple : Si possible, laisser le DHCP, on pourra reconfigurer l’IP de la VM au cas par cas sans risquer de provoquer de conflit d’IP lors de gros déploiement.

Si tout se passe bien, il fini par rebooter au bout d’un moment. La première chose à faire une fois que la VM est fonctionnelle, c’est d’installer les XenServer-Tools. En effet, ce sont eux qui permettent à la VM d’être complètement « consciente » de son état de VM et donc d’atteindre ~~l’ataraxie~~ la paravirtualisation (gain de performance et gain en contrôle sur la VM). Par défaut, ces XenServer Tools sont situées dans un iso que l’on monte donc sur la VM.

Et on lance les commandes suivantes pour monter et exécuter le programme d’installation :

mkdir /mnt/cdrom
mount /dev/xvdd /mnt/cdrom
/mnt/cdrom/Linux/install.sh

Une fois le programme installé, un reboot s’impose! Selon les gouts « shutdown -r now » ou « init 6 ». Une fois que c’est fait, il faut mettre son système à jour avec « yum upgrade », et pourquoi pas installer tous les produits et logiciels indispensable à tout votre parc? Pourquoi pas non plus ajouter des repos additionnels tant qu’on y est (cf cette page du wiki.centos.org (lien mort, remplacé par Internet Archive))?

wget http://packages.sw.be/rpmforge-release/rpmforge-release-0.5.2-2.el5.rf.x86_64.rpm
rpm --import http://apt.sw.be/RPM-GPG-KEY.dag.txt
rpm -K rpmforge-release-0.5.2-2.el5.rf.*.rpm
rpm -i rpmforge-release-0.5.2-2.el5.rf.*.rpm

yum list htop

pour vérifier que l’importation à bien fonctionné (d’ailleur il y a la base des rpms dispo qui devrait se reconstruire dans la foulée)

Voilà, on a maintenant le parfait candidat pour un template! Pour pouvoir le créer, on doit éteindre la VM. Pour créer ce template, on a plusieurs possibilités. D’abord, on peut créer une Appliance, qui est en fait un template destiné à être exporté sur le web dans un format standardisé (.ovf). Typiquement, ce mécanisme est utilisée par des personnes qui fournissent une VM fournissant un service préinstallé, ou, dans le cas de la virtualisation VMware, par les utilisateurs de ESXi sans vCenter pour contourner l’absence de cette fonctionnalité :-p (je ferai un article là dessus bientôt).

Sinon on peut aussi convertir la VM en un template (opération « définitive ») et elle n’apparaitra plus dans la liste comme une VM mais bien comme un template. C’est ce que je vais faire ici.

Il est désormais possible de créer très rapidement des VMs à partir de ce template. Les seules choses à modifier une fois le déploiement terminés sont donc

le hostname (bah oui, c’est quelque chose d’unique!)
supprimer l’interface eth0.bak créée par XenServer lors du déploiement
et éventuellement modifier les infos IP de la machine

rm /etc/sysconfig/networking/devices/ifcfg-eth0.bak
rm /etc/sysconfig/network-scripts/ifcfg-eth0.bak
system-config-network
service network restart