Auteur/autrice : Cyril

Puppet : utilisation de conditions dans les templates

CyrilLeave a comment

Pour faire suite à l’article sur l’utilisation des templates, nous allons developper ici l’utilisation de structures conditionnelles dans
l’utilisation des templates.

Nous avions vu dans le précédent article une structure conditionnelle définie côté serveur. Dans le fichier proftpd.conf.erb , nous avions :

<% if @proftpd_chroot == true %>
 DefaultRoot ~
<% end %>

et dans le fichier /etc/puppet/manifests/nodes.pp :

node 'poste-client' {
        $proftpd_chroot         =  false
        include         ssh, motd, proftpd
}

Ainsi, il est possible de passer en paramètres, via la déclaration du noeud, des variables qui peuvent être utilisées dans une structure conditionnelle pour personnaliser un fichier de configuration en fonction du noeud.

Il est également possible de définir avec puppet des structures conditionnelles qui seront évaluées côté client, grace aux facts.

Imaginons maintenant que nous possédons 3 réseaux privés (192.168.0.0/24, 192.168.1.0/24, 192.168.2.0/24). Sur chacun de ces réseaux, la passerelle (192.168.0.254 ,192.168.1.254 ,192.168.2.254) fait également office de serveur ntp.
Nous voulons générer un fichier /etc/cron.daily/ntpdate en fonction du réseau sur lequel se trouve la machine ou est installé le client puppet :
Nous ne reviendrons pas sur la création du module puppet, abordée dans le précédent article mais on allons juste nous intéresser à la création du template.

La commande système facter permet de connaître la liste des variables affectée sur le client. Ainsi nous voyons que la variable network_eth0 permet de savoir sur quel réseau la machine est branchée (nous considérons que le client ne possède qu’une
interface réseau).

Nous pouvons donc definir le template ntpdate.erb de la manière suivante :

#!/bin/sh

<%if (@network_eth0=='192.168.0.0') then %>/usr/sbin/ntpdate 192.168.0.254<% end %>
<%if (@network_eth0=='192.168.1.0') then %>/usr/sbin/ntpdate 192.168.1.254<% end %>
<%if (@network_eth0=='192.168.2.0') then %>/usr/sbin/ntpdate 192.168.2.254<% end %>

Ainsi la structure conditionnelle est évaluée non plus en fonction de variable positionnées sur le serveur mais en fonction des variables positionnées par les facts sur le poste client.

Autre exemple, dans cet article, nous avions vu comment mettre en place un réplicat openldap en mode mirroir.
Si nous voulons « puppetiser » le fichier slapd.conf, nous remarquons que le fichier est identique sur ldap-1.be-root.com et ldap-1.be-root.com mis sauf pour les paramètres serverID et provider.
Avec ce que nous venons de voir, générer les deux fichiers slapd.conf à partir des templates et des variables positionnées par les facts devient très simple. Nous allons utiliser la variable hostname qui contient le nom court du client :

...
<% if (@hostname=='ldap-1'>) then %> serverID    1 <% else %> serverID      2 <% end %>
...
syncrepl   rid=001
           <% if (@hostname=='ldap-1'>) then %> provider=ldaps://ldap-2.be-root.com:636 <% else %> provider=ldaps://ldap-1.be-root.com:636<% end %>
           type=refreshAndPersist
...

Nous voyons donc que les structures conditionnelles permettent de simplifier les déclarations dans puppet et d’avoir une grande adaptabilité des templates.

Installation de Cisco Packettracer 6 sur Ubuntu 13.10 64bits

Cyril7 Comments

Cisco Packettracer est un puissant outil de simulation de réseaux. Cependant, lorsqu’on l’installe sur une ubuntu 64 bits de base, il ne fonctionne pas. Sur les versions d’ubuntu inférieures à la 13.10, pour résoudre ce problème il suffisait d’installer le paquet ia32-libs. Cependant, depuis le passage à la version 13.10, ce paquet n’existe plus. Voici la marche à suivre pour faire fonctionner Cisco PacketTracer 6 sur une Ubuntu 13.10 :

Tout d’abord, il faut activer le support du multi-arch :

sudo dpkg --add-architecture i386

Ensuite, il ne reste plus qu’a installer les libraires 32 bits nécessaires :

sudo apt-get install libnss3-1d:i386 libqt4-qt3support:i386 libssl1.0.0:i386 libqtwebkit4:i386 libqt4-scripttools:i386

Problème de serveur DNS avec Windows 7 et dhcp (dans un cas bien particulier)

Cyril1 Comment

Imaginons un serveur isc dhcpd configuré de la sorte (centos 6.4) :


...
subnet 192.168.0.0 netmask 255.255.255.0 {
option domain-name-servers  192.168.0.1;
option  routers 192.168.0.254;
authoritative;
deny client-updates;
deny
pool {
allow unknown-clients;
range 192.168.0.100 192.168.0.200;
}
host  monposte.be-root.com {
option domain-name-servers  192.168.0.2;
hardware ethernet xx:xx:xx:xx:xx:xx;
fixed-address 192.168.0.10;
}
}

Symptômes :

Sur la machine monposte :
si l’on boote sur un livecd (ubuntu), nous obtenons comme paramètres via le dhcp 192.168.0.10/255.255.255.0 et le serveur DNS 192.168.0.2 (les paramètres sont donc ceux attendus)
si l’on boote sur windows 7, nous obtenons comme paramètres via le dhcp 192.168.0.10/255.255.255.0 et le serveur DNS 192.168.0.1  (le serveur dns n’est pas celui déclaré dans la section host. Il s’agit du dns déclaré dans la section subnet).

Si sous windows 7, nous effectuons un ipconfig /renew alors les parametres sont 192.168.0.10/255.255.255.0 et le serveur DNS 192.168.0.2. Cependant, au redémarrage suivant, les paramètres sont de nouveau 192.168.0.10/255.255.255.0 et le serveur DNS 192.168.0.1.

Analyse :
Si l’on sniffe l’echange entre le poste windows 7 et le serveur dhcp, on remarque :
-1 requête DHCP Request de la part du client
-1 réponse DHCP ACK de la part du serveur DHCP lui fournissant les paramètres  192.168.0.10/255.255.255.0 et le serveur DNS 192.168.0.2 (donc corrects).
-1 requête DHCP Inform de la part du client précisant sont adresse 192.168.0.10 et demandant les paramètres subnet mask/domain name/ router/ domain name server/…/private-proxy autodiscovery
-1 réponse DHCP ACK de la part du serveur dhcp lui fournissant la passerelle 192.168.0.254 et le dns 192.168.0.1 (donc erronés).
– …
A priori, tant que le client ne reçoit pas de réponses valides pour la recherche automatique de proxy, il continue a faire des requêtes DHCPInform toutes les 100 secondes.
La norme concernant les requêtes DCHP Inform stipule :

The server SHOULD check the network address in a DHCPINFORM message for consistency, but MUST NOT check for an existing lease.

Ainsi, le serveur dhcpd n’utilise pas les informations de son fichier de leases pour répondre avec les même paramètres que ceux envoyés lors du DHCP Request mais parcours le fichier de configuration.
Comme l’adresse ip indiquée dans la requête DHCP Inform fait partie du subnet 192.168.0.0, il répond avec les paramètres globaux de la zone.

Résolution :
On peut contourner de problème de plusieurs façons :

  • Virer le paramètre authoritative dans le subnet. Le serveur ne répondra plus aux requêtes DHCP Inform … (moyen)
  • Supprimer les déclarations globales de serveurs dns et les mettre par hôte/pool. (long et pas très pratique).
  • Si l’on n’utilise pas la fonctionnalité de découverte automatique de proxy (wpad) : sur le client Windows7, lancer l’éditeur de base de registres.
    Sous HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\Identifiant-de-l-interface , créer une clé nommée UseInform de type DWORD. Initialiser à la valeur 0.
    Ainsi le client Windows 7 ne fera plus de requêtes DHCP Inform et donc conservera les informations retournées par lors de la première transaction DHCP Request.