Gestion de déploiement centralisée

Magazine
Marque
GNU/Linux Magazine
Numéro
118
Mois de parution
juillet 2009


Résumé
Travaillant dans un environnement de production comprenant près de 100 serveurs et 250 postes de travail basés sur les systèmes d'exploitation RedHat Enterprise Linux 5, CentOS 5.2 et Fedora Core 10, la gestion manuelle de chaque machine est particulièrement fastidieuse. L'installation passe par la configuration manuelle des serveurs DHCP et DNS, et le déploiement de la configuration passe par des copies massives à base de boucles for et de scp. Nous avons donc mis en œuvre une solution de gestion centralisée de la configuration des machines.

Body

Cette solution utilise les outils suivants :

- Cobbler pour le provisioning du système d'exploitation via PXE, la gestion DHCP et DNS ;

- Puppet pour le provisioning des fichiers de configuration sur les différentes machines ;

- Subversion pour l'historisation des versions de la configuration.

Je ne reviendrai pas sur l'utilisation de Puppet et Subversion qui ont été couverts récemment dans GNU/Linux Magazine (cf. Bibliographie). Je connaissais déjà Subversion et l'article sur Puppet nous a permis de débuter sur la gestion de configuration centralisée. Cela nous a permis de gagner beaucoup de temps pour le déploiement des nouvelles machines et la distribution des modifications de configuration. Et, au passage, nous avons entamé une démarche basée sur les méthodologies ITIL (Information Technology Infrastructure Library) avec la création d'une CMDB (Configuration Management DataBase).

ITIL est un ensemble de bonnes pratiques recensées par l'Office Britannique du Commerce pour la bonne gestion d'un système d'information. Ces bonnes pratiques ont pour objectif d'aider un organisme (public ou privé) à améliorer la stabilité de son SI, d'en réduire les coûts et les risques. Néanmoins, il ne s'agit pas d'une méthode miracle, mais plutôt d'un regroupement de pratiques guidées par le bon sens et un pragmatisme très anglo-saxon. L'une des pierres angulaires de ces bonnes pratiques est la mise en œuvre d'une base de données (pas forcément au sens technique du terme ; n'imaginez pas cela comme une base MySQL) regroupant les informations de configuration du système d'information. La finesse du détail de ces informations n'est pas prédéfinie par ITIL et dépend surtout de la maturité de la DSI sur ITIL, ainsi que des besoins : nous pouvons y trouver aussi bien un inventaire du matériel et des logiciels que des procédures de gestion de workflow métiers (un wiki est souvent un composant simple de CMDB). Dans notre cas, nous commençons « petit » par un inventaire de notre matériel (Cobbler) et de la configuration des systèmes d'exploitation Linux (Puppet). Pour plus d'information sur ITIL, je vous conseille le site de l'itSMF France [0] (Association de promotion d'ITIL en France).

Introduction sur Cobbler

Pour faire court, Cobbler [1] est un outil permettant de centraliser les informations liées à vos machines et de les déployer simplement. Ce couteau suisse de l'installation de machines permet de relier facilement une machine à une distribution (Linux, mais pas seulement), des dépôts de packages (RPM, mais pas seulement), un serveur DHCP et un serveur TFTP pour le boot PXE, un serveur DNS et un serveur hébergeant des machines virtuelles. Quand je dis « relier », il faut comprendre qu'il est capable d'endosser tous ces rôles ou de simplement s'interfacer avec. Dans cet article, j'ai fait le choix de vous en montrer un maximum et donc de configurer Cobbler pour qu'il gère des miroirs de dépôts de packages, l'arborescence du serveur TFTP, la configuration DHCP et la configuration DNS. Pour cela, Cobbler stocke les informations dans ses fichiers et génère des fichiers de configuration pour ces services en utilisant des templates ; le moteur de rendu pour les templates est Cheetah [2].

Le schéma ci-dessous vous montre les interactions de Cobbler avec son environnement. La terminologie sera explicitée au fur et à mesure de l'article.

Cobbler

Cobbler est issu de la communauté Fedora. À ce titre, il a débuté en permettant le déploiement des distributions Fedora, RedHat et CentOS. Néanmoins, il supporte de plus en plus de distributions. Je vous invite donc à consulter le site du projet [3] pour en savoir plus. La suite de cet article a été réalisée sur CentOS 5.2.

1. Installation et configuration de Cobbler

1.1. Installation de base

Pour commencer, nous installons les packages nécessaires :

yum install cobbler

Cette commande installe un certain nombre de dépendances, dont :

- httpd : pour mettre à disposition dépôts, kickstarts... et fournir une interface d'administration

- tftp-server : pour mettre à disposition les images systèmes pour l'installation via PXE

- rsync : pour mettre à jour les dépôts basés sur rsync.

Pour que Cobbler puisse fonctionner, nous devons définir quelques éléments de configuration dans le fichier /etc/cobbler/settings. Le premier à positionner est le nom du serveur sur lequel le serveur est amené à fonctionner ; dans notre cas, il s'agit de cobbler.local :

sed -i '/^server:/s/:.*$/: cobbler.local/' /etc/cobbler/settings

Le second paramètre est le mot de passe par défaut du compte root, dans un format chiffré, pour l'installation des machines. Vous pouvez vous baser sur les mots de passe stockés dans le fichier /etc/shadow :

sed -i '/^default_password_crypted:/s/:.*$/: "mot_de_passe_chiffre"/' /etc/cobbler/settings

Si vous utilisez le firewall de votre serveur, il suffit des règles iptables suivantes (le port est configurable dans /etc/cobbler/settings via la variable xmlrpc_port) :

iptables -A INPUT -i lo -p tcp -m state --state NEW -dport 25151 -j ACCEPT

Il suffit maintenant de démarrer le service cobblerd :

service cobblerd start

chkconfig cobblerd on

Maintenant que Cobbler a démarré avec une configuration simple, nous allons ajouter les fonctionnalités qui font sa puissance.

1.2. Configuration du service DHCP

La première fonctionnalité que nous implémentons est la gestion du service DHCP. Pour cela, nous commençons par installer les packages nécessaires :

yum install dhcp

Nous modifions ensuite la configuration de Cobbler pour qu'il prenne en charge le service DHCP :

sed -i '/^manage_dhcp:/s/:.*$/: 1/' /etc/cobbler/settings

Cobbler est capable de gérer les serveurs DHCP ISC et dnsmasq. Il suffit de modifier une option dans /etc/cobbler/modules.conf. Par défaut, c'est le serveur ISC qui est pris en charge, et, ça tombe bien, c'est celui que nous avons installé.

Le principal fichier à modifier est /etc/cobbler/dhcp.template ; en effet, Cobbler utilise ce fichier pour générer le fichier /etc/dhcpd.conf. La principale modification à y apporter concerne les informations réseau que nous souhaitons utiliser : adresse et masque du sous-réseau, routeur par défaut, serveur(s) DNS... Si vous avez quelque peu l'habitude du fichier /etc/dhcpd.conf, vous vous y retrouverez facilement.

Une fois la configuration adaptée à nos besoins, il suffit de redémarrer Cobbler et de le synchroniser. La synchronisation a pour effet de générer les fichiers de configuration à partir de la configuration de Cobbler.

service cobblerd restart

cobbler sync

Vous pouvez constater que le fichier /etc/dhcpd.conf a été généré et que le service dhcpd a été démarré. Vous n'avez plus besoin de vous soucier de ce service. Il a été « cobblerisé ». Assurons-nous qu'il sera lancé au prochain démarrage du serveur :

chkconfig dhcpd on

La règle IPTables à appliquer est la suivante :

iptables -A INPUT -i eth0 -p udp --dport 67:68 --sport 67:68 -j ACCEPT

1.3. Configuration du service DNS

Le serveur DNS que nous allons utiliser est le célèbre Bind. Il nous suffit donc de l'installer :

yum install bind

Configurons maintenant Cobbler pour qu'il gère le service DNS. Cobbler sait gérer les serveurs DNS Bind et dnsmasq. Par défaut, il gère Bind et c'est tant mieux : ça nous fera ça de moins à configurer ;) (au besoin, cela se configure dans /etc/cobbler/modules.conf). Il suffit d'activer la gestion du DNS et d'indiquer les zones que nous voulons gérer dans le fichier /etc/cobbler/settings. Dans notre cas, la zone s'appelle local et la zone inverse correspondante 10.0.0.0/24 :

sed -i '/^manage_dns:/s/:.*$/: 1/' /etc/cobbler/settings

sed -i '/^manage_forward_zones:/s/:.*/: ["local"]/' /etc/cobbler/settings

sed -i '/^manage_reverse_zones:/s/:.*/: ["10.0.0"]/' /etc/cobbler/settings

De la même façon que pour le service DHCP, Cobbler s'appuie sur des templates : /etc/cobbler/named.template et /etc/cobbler/zone.template. Le premier fichier gère la configuration globale de votre serveur Bind et le second vous permet de personnaliser vos zones. Une méthode élégante pour gérer des zones complexes est l'utilisation du répertoire /etc/cobbler/zone_templates : si vous déposez un fichier dont le nom correspond au nom d'une zone gérée par Cobbler, ce fichier sera utilisé comme template pour cette zone. Dés lors, en vous basant sur le fichier /etc/cobbler/zone.template, vous pouvez créer des fichiers plus complexes gérant les enregistrements CNAME, SRV, MX... Il suffit de les ajouter à la fin du fichier de template. Nous allons d'ailleurs utiliser cette méthode pour gérer notre zone local (cela n'est pas nécessaire pour les zones inverses) :

mkdir /etc/cobbler/zone_templates

cp /etc/cobbler/zone.template /etc/cobbler/zone_templates/local

Comme nous avons modifié le fichier /etc/cobbler/settings, nous devons redémarrer le service cobblerd, puis nous synchronisons Cobbler pour qu'il génère les fichiers de configuration :

service cobblerd restart

cobbler sync

Vous constater que, cette fois-ci, le service named a été démarré lors de la synchronisation. Vous pouvez aussi vérifier que la configuration est correcte dans les fichiers /etc/named.conf, /var/named/local et /var/named/10.0.0. Assurons-nous que le service sera lancé au prochain démarrage :

chkconfig named on

La règle IPTables à appliquer est la suivante :

iptables -A INPUT -i eth0 -d cobbler.local -p tcp -m state --state NEW --dport 53 -j ACCEPT

Les plus paranoïaques (dont je fais partie) auront pris soin de modifier /etc/cobbler/named.template pour que le service n'écoute que sur l'adresse IP du serveur.

1.4. Configuration du service TFTP

Le prochain service à configurer est le service TFTP. Cette fois, les packages utiles ont déjà été installés par Cobbler : tftp-server et xinetd. En effet, tftp-server n'est pas lui-même à l'écoute des requêtes. C'est xinetd qui les lui transmet.

Nous devons donc faire en sorte que le service xinetd accepte les requêtes TFTP et qu'il soit lancé au démarrage du serveur. Et ensuite, nous pouvons ajouter l'adresse du serveur TFTP dans la configuration de Cobbler (/etc/cobbler/settings) :

sed -i "/disable/s/= yes/= no/" /etc/xinetd.d/tftp

sed -i '/^next_server:/s/:.*/: cobbler.local/' /etc/cobbler/settings

service xinetd start ; chkconfig xinetd on

service cobblerd restart

cobbler sync

La règle IPTables à appliquer est la suivante :

iptables -A INPUT -i eth0 -d cobbler.local -p udp --dport 69 -j ACCEPT

Comme pour le service DNS, il est possible de limiter l'adresse d'écoute en ajoutant la ligne bind = cobbler.local au fichier /etc/xinetd.d/tftp.

1.5. Configuration du service HTTP

Le dernier composant à configurer est le serveur web Apache pour qu'il fournisse un accès API de Cobbler, ainsi qu'aux dépôts de packages. Cobbler s'appuie sur des webservices implémentés en Python et fournit deux fichiers de configuration pour le serveur Apache : /etc/httpd/conf.f/cobbler.conf et /etc/httpd/conf.f/cobbler_svc.conf. Par défaut, Apache inclut tous les fichiers du répertoire /etc/httpd/conf.d ; il n'est donc pas nécessaire de modifier la configuration d'Apache. Il suffit donc de démarrer Apache et de faire en sorte qu'il soit lancé au prochain démarrage du serveur :

service httpd start

chkconfig httpd on

La configuration d'un serveur Apache n'est pas l'objet de cet article, mais je vous conseille de vous plonger dans la documentation plutôt fournie disponible sur le site httpd.apache.org. Vous y apprendrez comment limiter l'accès à votre serveur, cloisonner l'application Cobbler dans un VirtualHost...

La règle IPTables à appliquer est la suivante :

iptables -A INPUT -i eth0 -d cobbler.local -p tcp -m state --state NEW --dport 80 -j ACCEPT

2. Injection massive de données dans Cobbler

Au cours des étapes précédentes, nous avons monté le squelette de Cobbler, et configuré les services qu'il gère. Nous allons pouvoir nous attaquer au peuplement de l'application. En effet, pour que Cobbler montre toute sa puissance, rien de mieux que de le voir en action.

Dans le monde de Cobbler, il existe 4 types d'objets principaux :

- Les dépôts qui sont des arborescences contenant des packages. Les utilisateurs Fedora connaissent bien le dépôt RPMFusion qui fournit, entre autres, des packages de logiciels non libres, et le dépôt « updates » qui contient les mises à jour.

- Les distributions qui correspondent aux médias d'installation. Une distribution est un instantané des packages d'un dépôt correspondant à une release du système d'exploitation.

- Les systèmes qui sont les descriptifs des machines gérées par Cobbler. On y trouve par exemple l'adresse MAC utilisée pour générer la configuration DHCP.

- Les profils qui font le lien entre tous ces éléments. Un profil est un ensemble de propriétés communes à plusieurs systèmes qui permettent de les grouper ; parmi ces propriétés, on trouve la distribution, le(s) dépôt(s) et le fichier Kickstart à utiliser pour installer le système.

- Les données à installer en priorité sont donc les dépôts et les distributions qui nous permettront d'installer des machines. Et, comme le volume de données peut vite être important, commençons rapidement...

2.1. Import du dépôt Updates de Centos 5.2 64bits

Comme il s'agit de l'opération la plus longue, nous commençons par ajouter un dépôt de packages RPM. Un mode de fonctionnement classique est d'utiliser notre serveur Cobbler comme un miroir local des dépôts officiels afin de limiter la consommation de bande passante lors des installations et mises à jour (ce qui est vraiment utile quand on a plusieurs dizaines de machines). Il est néanmoins possible de fournir simplement l'URL du dépôt (Cobbler gère plusieurs protocoles : HTTP, RSYNC...) avec l'option --mirror-locally=N pour que Cobbler ne fasse que référencer cette URL et l'intègre à la configuration des machines. Dans notre exemple, nous allons au bout du concept et nous créons un miroir du dépôt CentOS 5.2 - x86_64 - Updates ; les commandes sont assez explicites :

cobbler repo add --name=centos-5.2-server-x86_64-updates \

    --mirror=http://ftp.free.fr/mirrors/ftp.centos.org/5.2/updates/x86_64/ \

    --mirror-locally=Y

Si vous pensez manquer d'espace sur la partition contenant /var/www/cobbler, je vous conseille fortement de lire cette page du wiki [4] pour déplacer les données de Cobbler sans tout casser ; un déplacement de répertoire et un lien symbolique suffisent... alors n'hésitez pas.

Nous avons donc déclaré le dépôt ; il ne reste plus qu'à lancer la synchronisation :

cobbler reposync

En fonction du nombre de dépôts que vous avez déclarés et surtout de leur volume, l'opération peut prendre beaucoup de temps. Dans mon cas, le dépôt représente 3,8 Go sur disque et le téléchargement a pris environ 3 heures (c'est pas si mal). Bien entendu, nous souhaitons automatiser cette synchronisation pour rester à jour ; il suffit de rajouter une tâche cron à la fréquence qui vous convient (perso, une fois par semaine me convient) :

cat > /etc/cron.weekly/cobbler_reposync << EOF

#!/bin/bash

cobbler reposync --tries=3 --no-fail

EOF

chmod 0755 /etc/cron.weekly/cobbler_reposync

2.2. Import de la distribution CentOS 5.2 64bits

Nous avons installé notre serveur à partir du DVD de la distribution CentOS en version 64 bits et nous synchronisons le dépôt Updates associé. Alors, nous allons continuer sur cette voie pour notre exemple. Il existe une commande d'import qui prend en argument le nom que nous souhaitons donner à la distribution et le chemin dans lequel est stocké l'arborescence. Sur mon serveur, l'automount des médias amovibles est activé et il m'a donc suffi de lancer la commande suivante :

cobbler import --name=centos-5.2-server-x86_64 --mirror=/media/CentOS-5.2-x86_64-bin-DVD

L'opération n'est pas très longue et si vous êtes un peu habitué aux dépôts RPM (ou si vous avez regardé ce qui défile à l'écran lors de la synchronisation des dépôts), vous remarquerez que le chemin vers le contenu de la distribution est traité comme un dépôt. A la fin de l'importation, Cobbler analyse la structure du « dépôt » et crée automatiquement un (des) profil(s) pour cette distribution :

cobbler profile list

centos-5.2-server-x86_64

centos-5.2-server-xen-x86_64

Ces profils ne sont pas complets, mais forment un bon point de départ. Nous allons d'ailleurs tout de suite voir comment les enrichir. Au passage, vous remarquez qu'un profil xen a été créé. Il nous servira plus tard.

2.3. Personnalisation d'un profil

Les profils générés à l'import d'une distribution ont comme principal défaut de ne connaître que la distribution dont ils sont issus. Mais, nous ne pouvons pas leur en vouloir pour ça et nous allons les aider à s'améliorer. Tout d'abord, regardons les informations stockées dans un profil, à l'aide d'une option que vous trouverez assez vite indispensable :

cobbler profile report --name=centos-5.2-server-x86_64

profile              : centos-5.2-server-x86_64

distro               : centos-5.2-server-x86_64

...

kickstart            : /var/lib/cobbler/kickstarts/default.ks

...

repos                : []

...

Pour plus de lisibilité, j'ai limité le contenu affiché aux champs qui vont nous intéresser immédiatement. Les autres viendront plus tard. Chaque chose en son temps...

Nous observons donc que le champ distro a pour valeur le nom de la distribution dont le profil est issu (c'est rassurant) et qu'un fichier Kickstart est associé au profil. Par contre, aucun dépôt n'est associé. Nous remédions donc tout de suite à cela :

cobbler profile edit --name=centos-5.2-server-x86_64

    --repos='centos-5.2-server-x86_64-updates'

Cette commande relativement simple a ajouté les deux dépôts dont nous sommes miroir. Notez simplement la syntaxe : lorsqu'un champ contient une liste de valeurs, il faut les mettre entre quotes et les séparer par une espace. Et nous pouvons vérifier le résultat :

cobbler profile report --name=centos-5.2-server-x86_64

profile              : centos-5.2-server-x86_64

distro               : centos-5.2-server-x86_64

...

kickstart            : /var/lib/cobbler/kickstarts/default.ks

...

repos                : [u'centos-5.2-server-x86_64-updates']

...

Les petits curieux seront déjà allés fouiller dans /var/lib/cobbler/kickstarts pour voir à quoi ressemble le fichier Kickstart associé au profil et ils sont probablement un peu déçus : en effet, le fichier default.ks ne contient aucune instruction. Bien sûr, les plus néophytes d'entre vous s'inquiètent, mais, soyez tout de suite rassurés. Il y a dans ce même répertoire un fichier Kickstart d'exemple qui est complètement fonctionnel : sample.ks. Je ne vous en expliquerai pas la syntaxe, car cela pourrait faire l'objet de deux articles (un sur Kickstart [5] et l'autre sur Cheetah (le moteur de templates utilisé)). Nous allons simplement faire en sorte que notre profil soit associé à ce Kickstart. Pour cela, il y a deux possibilités : renommer sample.ks en default.ks ou modifier le profil pour pointer sur sample.ks. Personnellement, j'utilise la première méthode, car le nom default.ks correspond parfaitement à mon besoin : un profil basique utilisable pour n'importe quelle machine, mais la seconde méthode est plus didactique :

cobbler profile edit --name=centos-5.2-server-x86_64 \

    --kickstart=/var/lib/cobbler/kickstarts/sample.ks

Nous avons à présent un profil utilisable pour installer des machines. Il ne nous reste plus qu'à déclarer lesdites machines dans Cobbler. Comme j'aime bien la récursivité, je vais vous montrer comment déclarer le serveur sur lequel est installé Cobbler. En effet, il est basé sur la distribution et le dépôt que nous avons intégrés dans Cobbler. C'est parti !

2.4. Ajout du système cobbler.local

L'un des objectifs de Cobbler étant de centraliser les informations réseau de nos machines, la déclaration d'un système comporte nécessairement des informations sur ses caractéristiques réseau. Les caractéristiques système sont principalement liées au profil. Ainsi, la déclaration de notre serveur donne :

cobbler system add --name=cobbler --profile=centos-5.2-server-x86_64 \

    --interface=eth0 --mac=00:1a:4d:59:21:d7 --static=1 \

    --ip=10.0.0.11 --subnet=255.255.255.0 --gateway=10.0.0.2 \

     --dns-name=cobbler.local --hostname=cobbler

Si nous décortiquons cette belle ligne de commande, nous retrouvons :

- la configuration du profil (et donc de la distribution, des dépôts et du fichier Kickstart) via l'option –profile ;

- la configuration DHCP via les options --hostname, --mac, --ip, --subnet et --gateway ;

- la configuration DNS via les options --dns-name et --ip.

Notre serveur est maintenant déclaré (la commande cobbler system report cobbler vous permet de le vérifier). Il ne manque plus que la génération des fichiers de configuration pour les différents services gérés par Cobbler :

cobbler sync

Vous pouvez constater dans /etc/dhcpd.conf et /var/named/local que la configuration du serveur a bien été intégrée dans les configurations des différents services, qui ont d'ailleurs été rafraîchis par Cobbler. Si vous rebootez le serveur en mode PXE, il sera réinstallé, mais ce n'est pas forcément ce que nous voulons. Je vous donne donc un tuyau pour éviter qu'une machine configurée dans son BIOS (ou sa ROM) pour démarrer en mode PXE ne boucle indéfiniment sur l'installation

cobbler system edit --name=cobbler --netboot-enabled=N

...et la page de man et le wiki renferment d'autres astuces utiles.

Bien, maintenant que vous avez une petite idée de ce que l'on peut faire avec Cobbler, faisons entrer en piste son colocataire : Koan...

3. (Ré)Installation d'un système

Vous savez déclarer une machine physique dans Cobbler et faire en sorte qu'elle démarre. Jusque-là, tout va bien. Mais aujourd'hui, votre patron vous demandera de vous pencher sur « les possibilités de rationalisation des coûts de production du système d'information au travers de la virtualisation » et vous vous lancerez dans la mise en production de gros serveurs avec plein de CPU et de mémoire pour héberger vos services dans des machines virtuelles. Et comme vous avez quand même un peu votre mot à dire sur le sujet, vous partez sur une solution basée sur Xen (disponible sur toutes les distributions Linux (ou presque))... Eh bien, Koan va vite devenir votre ami.

Vous pourrez aussi vous pencher sur KVM qui est intégré au noyau Linux depuis la version 2.6.20. Néanmoins, j'ai préféré rester sur Xen, car la distribution RedHat (pas mal utilisée en production (sans chercher de Troll)) n'a pas encore intégré KVM, pour des raisons de support du noyau, freezé en version 2.6.18.

Koan est un outil qui permet sur une machine cliente de réaliser des tâches liées au déploiement en utilisant les données de Cobbler. Ses fonctionnalités sont :

- l'installation de machines virtuelles sur un serveur hôte au travers de libvirt. Koan récupère les caractéristiques de la machine virtuelle à installer et s'appuie sur la libvirt pour la créer et l'installer automatiquement.

- la réinstallation d'une machine depuis cette même machine : Koan s'appuie sur les caractéristiques de la machine (physique ou virtuelle) pour générer une entrée Grub qui réinstallera la machine. C'est le pendant du boot PXE, mais pour une machine disposant d'un Grub fonctionnel.

Dans la suite, nous allons installer une machine virtuelle via Koan, puis la réinstaller, pour voir ces deux fonctionnalités en action.

3.1. Mise en place de Koan et des outils de virtualisation

Pour que cela puisse fonctionner, nous allons avoir besoin des outils de virtualisation. Leur installation est particulièrement simple :

yum install xen libvirt

chkconfig libvirtd on ; chkconfig xend on

vi /boot/grub/grub.conf

reboot

Pour Koan, l'installation est tout aussi simple :

yum install koan

Et voilà, vous avez tout ce dont vous avez besoin pour créer des machines virtuelles avec Koan.

3.2. Ajout du système virtuel dans la configuration

Si vous regardez la configuration des profils centos-5.2-server{,-xen}-x86_64 créés à l'import de la distribution, vous constaterez qu'il y a des champs commençant par virt. Ces champs sont les informations pour générer des machines virtuelles :

cobbler profile report --name=centos-5.2-server-xen-x86_64

profile              : centos-5.2-server-xen-x86_64

...

virt bridge          : xenbr0

virt cpus            : 1

virt file size       : 5

virt path            :

virt ram             : 512

virt type            : xenpv

Les noms des champs sont explicites, mais je vais quand même vous les détailler un peu. Le champ virt type indique quel type de virtualisation utiliser : xenpv correspond à l'utilisation de Xen. Le champ virt bridge indique quel bridge virtuel utiliser pour relier nos machines virtuelles à la machine hôte : xenbr0 est le bridge par défaut créé par Xen. Les champs virt cpus et virt ram indiquent respectivement le nombre de processeurs et la quantité de mémoire à attribuer à la machine virtuelle ; par défaut, nous attribuons 1 processeur et 512 Mo de mémoire. Les champs virt file size et virt path indiquent la taille et l'emplacement du disque virtuel à attribuer à la machine virtuelle : par défaut, le système se voit attribuer 5 Go d'espace et le chemin n'est pas précisé pour que cela soit spécifié système par système.

Il s'agit des valeurs par défaut et nous allons les modifier un petit peu. Nous allons réduire la quantité de mémoire à 256 Mo, la taille du disque virtuel à 4 Go et spécifier un chemin par défaut pour stocker les disques virtuels.

cobbler profile edit --name=centos-5.2-server-xen-x86_64 \

    --virt-ram=256 --virt-file-size=4 \

    --virth-path=/var/lib/libvirt/images

La commande cobbler profile report centos-5.2-server-xen-x86_64 vous permet de vérifier que c'est appliqué. Nous pouvons maintenant associer un système virtuel :

cobbler system add --name=vmtest --profile=centos-5.2-server-xen-x86_64 \

    --interface=eth0 --mac=ff:00:00:01:00:00 --static=1 \

    --ip=10.0.0.100 --subnet=255.255.255.0 --gateway=10.0.0.2 \

    --dns-name=vmtest.local --hostname=vmtest

Vous constatez que la déclaration est quasi identique à celle d'une machine physique. La seule différence se situe au niveau de l'adresse MAC qui est positionnée arbitrairement hors des adresses officielles (les adresses commençant par ff: n'ont pas été attribuées par l'IEEE). Personnellement, j'utilise les trois champs suivants pour identifier la machine (16777216 machines possibles !), le 5ème champ pour le numéro d'interface (00 pour eth0) et le 6ème champ pour le numéro d'interface fille (00:00 pour eth0, 00:01 pour eth0:1...), mais vous pouvez faire comme vous voulez...

Si vous regardez la configuration du système nouvellement déclaré, vous constatez que les champs virt ont pour valeur <<inherit>>. Cela vient du fait que notre déclaration de système n'a pas surchargé les valeurs définies dans le profil ; elles sont donc identiques à celles que nous avons positionnées dans le profil, ce qui tombe bien.

cobbler system report --name=vmtest

system                : vmtest

profile               : centos-5.2-server-xen-x86_64

...

virt cpus             : <<inherit>>

virt file size        : <<inherit>>

virt path             : <<inherit>>

virt ram              : <<inherit>>

virt type             : <<inherit>>

...

interface        : eth0

...

  virt bridge    :

Seul virt bridge n'est pas positionné et c'est parce que Cobbler ne souhaite pas relier l'interface au réseau sans que nous le spécifiions explicitement. Nous aurions pu le faire à la déclaration du système ; nous le corrigeons a posteriori très simplement :

cobbler system edit --name=vmtest \

--interface=eth0 --virt-bridge=xenbr0

cobbler sync

Nous sommes maintenant prêt à installer la machine virtuelle.

3.3. Installation du système virtuel via Koan

Je vous préviens tout de suite, ce n'est impressionnant que par sa simplicité :

koan --server=cobbler.local --system=vmtest --virt --nogfx

Cette commande indique à koan de se connecter au serveur cobbler.local, de récupérer les informations du système vmtest et de l'installer comme une machine virtuelle (--virt) sans périphérique d'affichage graphique (--nogfx). À l'écran, vous verrez quelques messages indiquant que le disque dur virtuel est créé, que le noyau et l'inirtd sont récupérés et que la machine virtuelle a démarré. Pour vous connecter à la console de cette machine virtuelle, il vous suffit de taper virsh console vmtest. Vous verrez défiler l'installation du système basée sur le Kickstart déclaré dans le profil.

3.4. Réinstallation du système via Koan

Allons un peu plus loin ! Vous avez écrit un fichier Kickstart qui installe de manière complètement automatisée un serveur Web (via des scripts de post-installation, par exemple) et vous voulez le tester sur la machine vmtest. Vous pouvez soit arrêter la machine virtuelle, la supprimer et la recréer comme vu précédemment, soit la réinstaller depuis elle-même. Pour cela, il vous suffit d'installer Koan sur vmtest et lancer la commande suivante :

koan --server=cobbler.local --system=vmtest --replace-self

Cette commande ajoute une ligne dans /boot/grub/grub.conf indiquant au système que, au prochain boot, il devra démarrer en utilisant le Kickstart déclaré dans le profil associé à vmtest. Cette méthode est aussi valable pour des machines physiques. Remasteriser un serveur devient dès lors un jeu d'enfant.

4. Pour aller plus loin

Comme indiqué en introduction, Cobbler peut se coupler à Puppet via le mécanisme d'External Nodes disponible dans Puppet. Ce mécanisme consiste à déporter la définition des nodes de Puppet dans une entité externe ; Cobbler implémente ce mécanisme au travers de l'attribut --mgmt-classes qui permet d'affecter des classes Puppet au système. Une page du wiki est dédiée [6] à l'implémentation de ce mécanisme. Je vous conseille vivement de parcourir le wiki qui répond à de nombreuses questions : gestion multi-réseau du DHCP, installation à partir d'images ISO (Windows par exemple), génération de CD/DVD à partir d'un profil...

Je vous parlais aussi en introduction de l'utilisation de Subversion pour gérer les versions de notre configuration. Nous avions déjà des dépôts Subversion pour certains projets internes et nous avons donc continué avec Subversion. Pour cela, il nous a suffi de versionner les répertoires /etc/cobbler et /var/lib/cobbler qui contiennent la configuration de Cobbler (pour Puppet, il faut versionner /etc/puppet).

Je tiens néanmoins à vous signaler une option de Cobbler permettant de versionner automatiquement la configuration avec Git [7] : positionner à 1 la variable scm_track_enabled dans le fichier /etc/cobbler/settings. Comme l’indique le commentaire figurant dans le fichier, cette option « active un trigger qui versionne tous les changements dans /var/lib/cobbler quand une opération d'ajout, d'édition ou de synchronisation est effectuée. Cela peut être utilisé pour faire un retour à des versions précédentes de la base de données, générer des flux RSS ou pour des besoins d'audit ou de sauvegarde. Git est le système de Gestion de Configuration Logicielle (Software Configuration Management (SCM) en anglais) recommandé pour cette fonctionnalité ». Il vous suffit donc d'installer Git (yum install git) et d'activer cette option.

Bibliographie

[0] Le site de l'itSMF : http://www.itsmf.fr/

[1] Site officiel de Cobbler : https://fedorahosted.org/cobbler/

[2] Cheetah website : http://www.cheetahtemplate.org/

[3] Cobbler : Support for other distros : https://fedorahosted.org/cobbler/wiki/SupportForOtherDistros

[4] Cobbler : Relocating your install : https://fedorahosted.org/cobbler/wiki/RelocatingYourInstall

[5] RedHat Documentation - Kickstart Installations : http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Installation_Guide/ch-kickstart2.html

[6] Cobbler : Using Cobbler With ConfigManagement System : https://fedorahosted.org/cobbler/wiki/UsingCobblerWithConfigManagementSystem

[7] Article sur Puppet : « Les sysadmins jouent à la poupée », GLMF n°112.

[8] Article sur Subversion : « Gardez l'historique des changements de /etc grâce aux outils de suivi de version (svn, svnk) », GLMF n°115.




Article rédigé par

Par le(s) même(s) auteur(s)

Virtualisation basée sur les LinuX Containers, aka LXC

Magazine
Marque
GNU/Linux Magazine
Numéro
159
Mois de parution
avril 2013
Spécialité(s)
Résumé
Cet article a pour objectif de vous présenter la technologie de virtualisation LXC [0.1]. Le terme de virtualisation n'est d'ailleurs pas vraiment adapté, car il n'y a pas de création de machine virtuelle en tant que telle. La page d'accueil du projet dit que LXC est parfois décrit comme « chroot gonflé aux stéroïdes », ce qui colle bien à l'esprit du projet. Au cours des prochaines pages, nous aborderons l'installation des outils LXC, la création d'un conteneur très simple à base de Busybox, puis un conteneur plus riche basé sur CentOS 6 et nous survolerons les aspects sécurité et intégration avec Libvirt.

Architecture DNS sécurisée

Magazine
Marque
GNU/Linux Magazine
Numéro
154
Mois de parution
novembre 2012
Spécialité(s)
Résumé
Pierre angulaire de l'infrastructure réseau, le service DNS est la cible de nombreuses attaques. Certains veulent le faire taire (déni de service), d'autres le faire mentir (empoisonnement de cache) ou s'appuyer sur lui pour attaquer d'autres serveurs DNS (récursivité mal configurée). Lorsque vous mettez en place ce service, vous avez à votre disposition plusieurs mécanismes qui limitent les risques face aux méchants pirates de l'Internet. Cet article vous guidera dans l'installation d'une architecture DNS multiniveau et implémentant DNSSEC.

Cluster basé sur Red Hat Cluster Suite

Magazine
Marque
GNU/Linux Magazine
Numéro
133
Mois de parution
décembre 2010
Résumé

Dans une production informatique, certains services sont particulièrement critiques. Pour assurer la disponibilité de ces services, nous avons à notre disposition les technologies de cluster. Cet article présente la mise en place d'un cluster à trois nœuds pour héberger les services critiques de notre infrastructure : nous passerons en revue la clusterisation aussi bien de LVM que des services.

Les derniers articles Premiums

Les derniers articles Premium

Quarkus : applications Java pour conteneurs

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Initié par Red Hat, il y a quelques années le projet Quarkus a pris son envol et en est désormais à sa troisième version majeure. Il propose un cadre d’exécution pour une application de Java radicalement différente, où son exécution ultra optimisée en fait un parfait candidat pour le déploiement sur des conteneurs tels que ceux de Docker ou Podman. Quarkus va même encore plus loin, en permettant de transformer l’application Java en un exécutable natif ! Voici une rapide introduction, par la pratique, à cet incroyable framework, qui nous offrira l’opportunité d’illustrer également sa facilité de prise en main.

De la scytale au bit quantique : l’avenir de la cryptographie

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Imaginez un monde où nos données seraient aussi insaisissables que le célèbre chat de Schrödinger : à la fois sécurisées et non sécurisées jusqu'à ce qu'un cryptographe quantique décide d’y jeter un œil. Cet article nous emmène dans les méandres de la cryptographie quantique, où la physique quantique n'est pas seulement une affaire de laboratoires, mais la clé d'un futur numérique très sécurisé. Entre principes quantiques mystérieux, défis techniques, et applications pratiques, nous allons découvrir comment cette technologie s'apprête à encoder nos données dans une dimension où même les meilleurs cryptographes n’y pourraient rien faire.

Les nouvelles menaces liées à l’intelligence artificielle

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Sommes-nous proches de la singularité technologique ? Peu probable. Même si l’intelligence artificielle a fait un bond ces dernières années (elle est étudiée depuis des dizaines d’années), nous sommes loin d’en perdre le contrôle. Et pourtant, une partie de l’utilisation de l’intelligence artificielle échappe aux analystes. Eh oui ! Comme tout système, elle est utilisée par des acteurs malveillants essayant d’en tirer profit pécuniairement. Cet article met en exergue quelques-unes des applications de l’intelligence artificielle par des acteurs malveillants et décrit succinctement comment parer à leurs attaques.

Abonnez-vous maintenant

et profitez de tous les contenus en illimité

Je découvre les offres

Déjà abonné ? Connectez-vous