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.