Articles dans la catégorie ’Logiciels



14
Fév

Puppet : utilisation de conditions dans les templates

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.

30
Mai

Fedora 17 : le pare-feu dynamique firewalld

Fedora 17 permet de remplacer le pare-feu traditionnel statique (outils iptables et fichier /etc/sysconfig/iptables) par un pare-feu dynamique nommé firewalld possédant une interface d-bus. Il est ainsi possible de modifier les règles à la volée sans avoir à redémarrer le daemon.

Installation :

Firewalld n’est pas actif par défaut sous Fedora 17. A priori, cela est prévu pour Fedora 18, le temps pour les développeurs de finaliser les outils spécifiques et d’adapter ceux existants à ce nouveau pare-feu.

L’installation se fait simplement à l’aide de la commande :

yum install firewalld

Il convient alors de désactiver le lancement du pare-feu statique installé par défaut afin que celui-ci n’interfère pas avec firewalld :

systemctl stop iptables.service
systemctl disable iptables.service

Nous pouvons ensuite permettre le démarrage automatique de firewalld :

systemctl start firewalld.service
systemctl enable firewalld.service

La commande firewall-cmd :

La commande firewall-cmd permet de contrôler le pare-feu dynamiquement (liste des règles actives, ouverture/fermeture de port, …)
firewalld supporte le concept de « zone de réseau » permettant de gérer des profils de règles à appliquer en fonction du réseau sur lequel on se trouve ( par exemple tout fermer lorsque l’on est sur un réseau
public et ouvrir ssh et samba lorque l’on est sur un réseau professionnel).

Pour connaître la zone par défaut, il faut utiliser la commande :

  firewall-cmd  --get-default-zone

Par défaut, sous Fedora, la commande retournera public.
La zone a lancer par défaut est fixée dans le fichier /etc/firewalld/ firewalld.conf :

# default zone
# The default zone used if an empty zone string is used.
# Default: public
DefaultZone=public

Pour connaître la zone en cours d’exécution, nous pouvons utiliser la commande :

firewall-cmd  --get-active-zones

La réponse fournie ici est « public: em1 » ce qui signifie que le profil public est en cours d’execution sur l’interface réseau em1.

Pour obtenir la liste des services autorisés pour le profil public, il suffit de taper :

firewall-cmd  --zone=public --list-service

Pour obtenir la liste des ports ouvert pourle profil public, il suffit de taper :

firewall-cmd  --zone=public --list=port

L’ensemble des profils définis s’obtient avec la commande :

firewall-cmd --get-zones

Par défaut, sous Fedora les profils drop work internal external trusted home dmz public block sont présents.

Le liste des services pré-définis se trouve sous le répertoire /usr/lib/firewalld/services :

Ce sont de simples fichiers xml. Il nous est donc possible de créer un fichier de services par exemple pour une application fonctionnant sur le port 9000 en créant le fichier /etc/firewalld/services/monappli.xml :

<?xml version="1.0" encoding="utf-8"?>
<service name="monappli">
  <short>MonAppli (9000)</short>
  <description>Mon serveur d'applications.</description>
  <port protocol="tcp" port="9000"/>
</service>

Pour que firewalld prenne connaissance de ce nouveau service, il est nécessaire de le redémarrer :

systemctl restart firewalld.service

Pour activer le service monappli dans le profil home, il suffit ensuite de faire :

firewall-cmd --zone=home --add --service=monappli

Pour connaître l’ensemble des services actifs sous le profil home :

 firewall-cmd  --zone=home --list=service

Pour retirer un service d’un profil (par exemple ipp-client du profil home), il faut taper :

firewall-cmd --zone=home --remove  --service=ipp-client

Plutôt que de passer par des services prédéfinis, nous pouvons également ouvrir des ports directement :

 firewall-cmd  --zone=home --add --port=9000/tcp

Pour activer le profil home, il suffit de faire :

firewall-cmd --set-default-zone=home

Attention, ceci est un changement permanent (cela modifie le fichier /etc/firewalld/firewalld.conf). Lors du prochain redémarrage de firewalld, le profil chargé par défaut sera home

Cependant, les services/ports activés ou désactivés à l’aide de la commande firewall-cmd seront perdus. En effet, cette commande n’impacte que la session courante du service firewalld.
Si nous voulons effectuer des modifications permanentes, il faut modifier les fichiers de configurations des zones.

Par exemple pour rajouter de manière permanent le service monappli au profil de zone home, il faut tout d’abord copier le fichier par défaut de cette zone dans le répertoire /etc/firewalld/zones :

cp /usr/lib/firewalld/zones/home.xml /etc/firewalld/zones/

Puis modifier le fichier /etc/firewalld/zones/home.xml :

<?xml version="1.0" encoding="utf-8"?>
<zone name="home">
  <short>Home</short>
  <description>For use in home areas. You mostly trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
  <service name="ssh"/>
  <service name="ipp-client"/>
  <service name="mdns"/>
  <service name="samba-client"/>
  <service name="dhcpv6-client"/>
  <service name="monappli"/>
</zone>

Comme nous l’avons vu, le nouveau pare-feu firewalld permet de changer les règles à la volée mais nous sommes dans l’obligation de modifier les fichiers de configuration à la main dés que nous voulons que les changements opérés soient permanents. Cependant, le concept de zone peut être utile pour les ordinateurs mobiles. firewalld permet également, via l’option –timeout, d’ouvrir un port/service pour une durée determinée.

Par exemple, pour autoriser le service monappli sur le profil home (en cours d’execution) pendant 10s il faut faire:

firewall-cmd  --zone=home --add --service=monappli --timeout=10

Ainsi s’achève ce tour d’horizon de firewalld …

2
Fév

Puppet : utilisation des templates

Dans les précédents articles ( installation de puppet et configuration simple ), nous avons vu comment installer et utiliser puppet à l’aide de fichiers de configurations statiques, ne variant pas d’un hôte à l’autre.

Dans cet article nous allons voir comment utiliser les templates. Un template est un fichier de configuration qui sera envoyé à un client mais dont le contenu sera adapté à ce dernier. Puppet fait usage du moteur de template ERB développé pour ruby. Les variable utilisés par les templates peut être soit des « facts », soit des variables positionnées manuellement.

Utilisation des facts

Les facts sont des scripts ruby (placés sous /usr/lib/ruby/facter/) et exécutés sur la partie cliente de puppet. Ces scripts positionnent des variables en fonction le l’environnement d’exécution. La commande système facter | less permet de lister les variables affectées.

Dans le précedent article, nous avons utilisé dans le module ssh des lignes du type name => $operatingsystem afin de déterminer le système d’exploitation du client. La variable $operatingsystem est positionnée par le fact operatingsystem.rb.

Dans l’exemple que nous allons détailler, nous allons utiliser des variables assignées par les facts pour générer un fichier /etc/motd sur les postes clients.

Tout d’abord, créons les répertoires du module que nous allons appeler motd :

mkdir -p /etc/puppet/modules/motd/{files,templates,manifests}

Ensuite, créons le fichier /etc/puppet/modules/motd/manifests/init.pp :

class motd::config {
        file {"/etc/motd":
                        owner  => 'root',
                        group  => 'root',
                        mode   =>  0644,
                        content=> template("/etc/puppet/modules/motd/templates/motd.erb"),
        }
}

class motd {
        include motd::config
}

La classe motd est plutôt simple puisqu’elle ne s’occupe du fichier /etc/motd.
Contrairement à un fichier statique dont la source serait définie par une syntaxe du type source => « puppet:///modules/files/motd », ici la syntaxe pour l’utilisation d’un template comporte le chemin absolu vers celui-ci (content=> template(« /etc/puppet/modules/motd/templates/motd.erb »)).

Créons notre fichier /etc/puppet/modules/motd/templates/motd.erb :

Welcome to <%= @hostname %> running <%= @operatingsystem %> <%= @operatingsystemrelease %> ( <%= @kernelrelease %> )
 * Documentation:  https://help.ubuntu.com

Les variables à inclure sont définies entre les balises <%= et %>.
hostname, operatingsystem, operatingsystemrelease et kernelrelease sont des variables affectées par les facts.

Afin d’utiliser la classe motd, il suffit de l’affecter à notre machine poste-client en modifiant le fichier /etc/puppet/manifests/nodes.pp :

node 'poste-client.be-root.com' {
        include         ssh, motd
}

Lorsque le puppet-agent du poste client aura mis en place la nouvelle configuration, nous obtenons le fichier /etc/motd :

Welcome to poste-client running Ubuntu 11.10 ( 3.0.0-15-generic )
 * Documentation:  https://help.ubuntu.com

Il est possible de créer ses propres facts. Ceci est expliqué dans la documentation de puppet

Un peu plus loin avec les templates

Il est possible de définir hôte par hôte des variables à utiliser dans les templates.
Nous allons voir dans cet exemple comment adapter la configuration du serveur proftpd.

Tout d’abord, créons l’arborescence du module proftpd :

mkdir -p /etc/puppet/modules/proftpd/{files,templates,manifests}

Créons le fichier /etc/puppet/modules/proftpd/manifests/init.pp :

class proftpd::install {
        package { "proftpd-basic":
                 ensure => latest,
        }
}

class proftpd::config {
        file {"/etc/proftpd/proftpd.conf":
                        owner  => 'root',
                        group  => 'root',
                        mode   => 0644,
                        content=> template("/etc/puppet/modules/proftpd/templates/proftpd.conf.erb"),
                        require=> Class["proftpd::install"],
                        notify => Class["proftpd::service"],
        }
}

class proftpd::service {
        service { "proftpd":
                        ensure     => running,
                        hasstatus  => true,
                        hasrestart => true,
                        enable     => true,
                        require    => Class["proftpd::config"],
        }
}

class proftpd {
        include proftpd::install, proftpd::config, proftpd::service
}

Si vous avez bien assimilé l’exemple de la classe ssh ainsi que la classe motd, la compréhension de ce fichier ne doit poser aucun problème.

Créons maintenant le fichier /etc/puppet/modules/proftpd/templates/proftpd.conf.erb :

# PROFTPD
# DON'T MODIFY THIS FILE DIRECTLY - MANAGED BY PUPPET
UseIPv6                         off
IdentLookups                    off
ServerName                      <%= @hostname %>
ServerType                      standalone
DeferWelcome                    off
MultilineRFC2228                on
DefaultServer                   on
ShowSymlinks                    on
TimeoutNoTransfer               600
TimeoutStalled                  600
TimeoutIdle                     1200
ListOptions                     "-l"
DenyFilter                      \*.*/

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

Port                            <%= @proftpd_port %>

MaxInstances                    <%= @proftpd_maxinstances %>

# Set the user and group that the server normally runs at.
User                            proftpd
Group                           nogroup

Umask                           022  022
AllowOverwrite                  on

TransferLog /var/log/proftpd/xferlog
SystemLog   /var/log/proftpd/proftpd.log

Nous remarquons que seule la variable hostname est fournie par un fact. Il nous faudra donc positionner les autres.
Nous remarquons que nous pouvons également mettre des instructions ruby dans les balises <% et %> (ici une condition if). Pour plus d’informations, consultez cette page.

Nous allons donc positionner les variables et assigner la classe proftpd à poste-client dans le fichier /etc/puppet/manifests/nodes.pp :

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

Ceci permet, à l’aide d’une seule classe, de pouvoir gérer plusieurs configurations différentes. Par exemple, on peut imaginer avoir :

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

node 'serveur-ftp' {
        $proftpd_chroot         =  true
        $proftpd_port           =  21
        $proftpd_maxinstances   =  300
        include         ssh, proftpd
}

Nous voyons donc qu’il est possible, à l’aide des templates, de pouvoir gérer efficacement et simplement des configurations différentes pour un même service.

Le thème Celadon pour WordPress a été créé par Themes Boutique