Autoconfig pour Thunderbird

Depuis la version 3.0 de Mozilla Thunderbird, à la création d’un compte de messagerie, ce dernier cherche par plusieurs moyen à configurer automatiquement les paramètres des serveurs de messagerie. Les paramètres peuvent ainsi être renseignés dans un fichier au format XML. La liste des paramètres pouvant être utilisée dans ce fichier XML se trouve à l’adresse https://wiki.mozilla.org/Thunderbird:Autoconfiguration:ConfigFileFormat

 

Supposons que l’on rentre l’adresse toto@mondomaine.com.
La recherche de la configuration se déroule suivant plusieurs étapes. En cas d’échec à une étape, on passer à la suivante. En cas de succès à une étape, les étapes suivantes ne seront pas effectuées :

  • Recherche sur le disque dur d’un fichier domaine.com.xml situé dans le répertoire isp présent dans le répertoire d’installation de thunderbird
  • Téléchargement du fichier http://autoconfig.domaine.com/mail/config-v1.1.xml?emailaddress=toto@domaine.com
  • Téléchargement du fichier http://domaine.com/.well-known/autoconfig/mail/config-v1.1.xml
  • Recherche DNS d’un enregistrement TXT contenant une URL indiquant à quelle adresse télécharger le fichier XML
  • Téléchargement sur la base mozilla : https://autoconfig-live.mozillamessaging.com/autoconfig/domaine.com
  • Recherche heuristique ( imap.domaine.com, pop.domaine.com, …)
  • Saisie manuelle

Nous allons donc implémenter la solution utilisant le téléchargement du fichier http://autoconfig.domaine.com/mail/config-v1.1.xml?emailaddress=toto@domaine.com.

Cette solution présente l’avantage de pouvoir récupérer côté serveur l’adresse email de la personne cherchant à configurer son compte. Ainsi il sera possible de générer un fichier xml personnalisé qui contiendra son login de messagerie. En effet, il est possible que, pour l’adresse toto@domaine.com, le login à utiliser ne soit pas toto mais un login tout autre.
La solution que nous allons implémenter permet de rechercher le login associé à l’adresse toto@domaine.com soit dans un annuaire ldap soit dans une base mysql (ou d’utiliser toto tout simplement).

Les autres solutions ne fournissent qu’une configuration « générale » dans lequel l’identifiant de messagerie ne peut être que soit l’adresse mail complète, soit la partie située avant l’arobase dans l’adresse.

Tout d’abord il faut créer un enregistrement DNS autoconfig.domaine.com. pointant vers un serveur hébergeant une solution apache+php.

Considérons que le serveur apache+php soit installé sous Centos 5. Il nous faut créer un vhost autoconfig.domaine.com. Par exemple :

<VirtualHost *:80>
        ServerName      autoconfig.domaine.com
        ServerAdmin     root@domaine.com
        DocumentRoot    /var/www/html/autoconfig/
</VirtualHost>

Dans le fichier  /etc/httpd/conf.d/php.conf modifions la ligne :

AddHandler php5-script .php .xml

Sous /var/www/html/autoconfig, mettons en place un répertoire nommé mail et téléchargeons à l’intérieur de ce répertoire le script de configuration :

mkdir -p /var/www/html/autoconfig/mail/
cd /var/www/html/autoconfig/mail/
wget http://be-root.com/downloads/autoconfig/config-v1.1.xml

Modifiez les variables présentes au début de ce script en fonction de votre configuration et redémarrez votre serveur apache.

En allant à l’url  http://autoconfig.domaine.com/mail/config-v1.1.xml avec un navigateur, vous devriez voir apparaître le code xml contenant les balises <username>%EMAILLOCALPART%</username>.

Si vous avez défini un driver (ldap ou mysql) pour faire une correspondance entre l’adresse email d’un utilisateur et son login, alors, en allant à l’url http://autoconfig.domaine.com/mail/config-v1.1.xml?emailaddress=utilisateur.existant@domaine.com
vous devriez voir une balise <username>login_utilisateur</username>.

Si cette étape fonctionne correctement, alors, lorsque vous configurerez votre compte sous Thunderbird, la configuration des serveurs pop/imap/smtp se fera alors correctement.

 

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.

Puppet : une première configuration simple

Nous partirons dans la configuration présentée dans l’article précédent sur Puppet.

Pour rappel, Puppet est un logiciel permettant de gérer les configurations de serveurs/machines esclaves depuis un serveur maître appelé puppetmaster. Un agent, appelé puppet agent, est installé sur chaque machine esclave (appelée nœud). A intervalle régulier, l’agent se connecte au puppetmaster et vérifie la configuration actuelle du nœud par rapport à la configuration de référence définie sur le puppet master pour ce nœud. En fonction des différences de configurations constatées, l’agent modifie la configuration du nœud pour la rendre identique à celle définie sur le puppetmaster.

Dans notre exemple, nous avons un serveur puppetmaster fonctionnant sous Centos 6 et un nœud installé sous Ubuntu exécutant l’agent puppet.

La configuration globale de puppet est effectuée dans le répertoire /etc/puppet/ sur le puppetmaster.
La structure du répertoire /etc/puppet est la suivante :

.
|-- auth.conf
|-- fileserver.conf
|-- manifests
|   |-- nodes.pp
|   `-- site.pp
|-- modules
|-- puppet.conf

Configuration des autorisations

Le fichier auth.conf permet de paramétrer les autorisations d’accès entre les nœuds et le puppetmaster (par l’api REST). Son contenu, par défaut, est le suivant :

# Allow authenticated nodes to retrieve their own catalogs:

path ~ ^/catalog/([^/]+)$
method find
allow $1

# Allow authenticated nodes to access any file services --- in practice, this results in fileserver.conf being consulted:

path /file
allow *

# Allow authenticated nodes to access the certificate revocation list:

path /certificate_revocation_list/ca
method find
allow *

# Allow authenticated nodes to send reports:

path /report
method save
allow *

# Allow unauthenticated access to certificates:

path /certificate/ca
auth no
method find
allow *

path /certificate/
auth no
method find
allow *

# Allow unauthenticated nodes to submit certificate signing requests:

path /certificate_request
auth no
method find, save
allow *

# Deny all other requests:

path /
auth any

Bien évidemment, il est possible de remplacer allow * par allow 192.168.0.* ou allow *.be-root.com.

Le fichier fileserver.conf permet de gérer les autorisations d’accès au serveur de fichier de puppet.Dans notre exemple, nous n’utiliserons le transfert de fichiers qu’a travers les modules. Le contenu de ce fichier est alors le suivant :

[modules]
        allow 192.168.0.*

Enfin, le fichier de configuration globale puppet.conf a été crée dans le précédent article.

Définition du site et des noeuds

Par défaut, puppet va lire la configuration globale dans le fichier de site /etc/puppet/manifests/site.pp.
Dans ce fichier, nous allons y mettre :

import "nodes.pp"
$puppetserver="puppet.be-root.com"

# Configuration du Filebucket
filebucket { "main":
  server => puppet,
  path   => false,
}

File { backup => main }

La première ligne permet d’importer le fichier nodes.pp qui contiendra la définition des configurations de tous les nœuds. Nous pourrions très bien, en fonction des besoins organisationnels, rajouter d’autres clauses import et ainsi séparer la configuration des hôtes dans plusieurs fichiers.

La seconde ligne contient le fqdn du serveur puppet. La fin du fichier permet de configurer le filebucket. Le filebucket est un service permettant d’avoir une copie de sauvegarde des fichiers modifiés ou remplacés sur les nœuds.

Dans notre exemple, nous voulons installer le service openssh sur le nœud poste-client.

Nous allons donc définir le noeud poste-client et lui affecter le module ssh que nous définirons plus tard.
Voici donc le contenu du fichier /etc/puppet/manifest/nodes.pp :

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

Rappel : Pour connaitre le nom du poste tel qu’il est identifié par le puppetmaster, on peut utiliser la commande :

puppetca list --all

Il nous est bien sûr possible de créer par la suite d’autres modules permettant d’autres actions de configuration et le rajouter les clauses include correspondantes dans la définition de l’hôte.

Dans cette configuration, nous allons assigner les modules hôte par hôte. Nous pouvions, si nous avions voulu une configuration globale pour l’ensemble des hôtes, utiliser le nœud spécial default

node default {
       include ssh
}

De même, nous pouvons inclure une notion d’héritage entre les nœuds. Imaginons 2 serveurs web web1.be-root.com, web2.be-root.com et un serveur de mails mail.be-root.com. Sur l’ensemble des 3 serveurs, nous voulons installer ssh et sudo. Sur les serveurs web, nous installerons apache en plus. Sur le serveur de mails, ce sera postfix. La définition des nœuds pourrait alors être :

node base {
  include ssh, sudo
}
node /^web\d+\.be-root\.com$/ inherits base {
  include httpd
}
node 'mail.be-root.com' inherits base {
  include postfix
}

Remarque : plutôt que de définir le nœud correspondant aux serveurs web à l’aide d’une expression régulière, nous aurions pu la définir comme ceci :

node ‘web1.be-root.com’, ‘web2.be-root.com’ inherits base {

Mais revenons à notre cas d’école, dans lequel nous affectons le module ssh

Création du module ssh

Un module est un regroupement de classes, de fichiers et de templates qui servent à configurer un ou plusieurs service sur les nœuds. Les modules sont stockés sous /etc/puppet/modules/nom_du_module.
Dans notre exemple, nous allons créer le module ssh, qui permettra d’installer et de configurer le service openssh.
Nous allons donc créer la structure du répertoire permettant d’accueillir le module :

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

Le répertoire manifests contiendra le fichier init.pp qui est lu en premier lors de l’appel à un module.
Le répertoire files contiendra le fichier un fichier sshd_config à déployer sur les hôtes.
Nous n’utiliserons pas de templates dans cet exemple mais, par convention, nous créons l’ensemble des trois répertoires. Un template est un modèle de fichier de configuration dont le contenu est « dynamique ». Lors du déploiement, il est adapté et modifié en fonction de chaque hôte.

Nous allons donc créer un fichier /etc/puppet/modules/ssh/files/sshd_config :

# Fichier installé par Puppet
Port 22
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
UsePrivilegeSeparation yes
KeyRegenerationInterval 3600
ServerKeyBits 768
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
RSAAuthentication yes
PubkeyAuthentication yes
IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
UsePAM yes

Nous allons ensuite créer le fichier /etc/puppet/modules/ssh/manifests/init.pp :

class ssh::install {
        package { "openssh":
                name => $operatingsystem ? {
                        /(Red Hat|CentOS|Fedora)/ => "openssh",
                        Ubuntu => "openssh-server",
                        default=> "openssh"
                 },
                 ensure => latest,
        }
}

class ssh::config {
        file {"/etc/ssh/sshd_config":
                        ensure => present,
                        owner  => 'root',
                        group  => 'root',
                        mode   => 0600,
                        source => "puppet:///modules/ssh/sshd_config",
                        require=> Class["ssh::install"],
                        notify => Class["ssh::service"],
        }
}

class ssh::service {
        service { "sshd":
                        name => $operatingsystem ? {
                           /(Red Hat|CentOS|Fedora)/ => "sshd",
                           Ubuntu => "ssh",
                           default=> "sshd"
                        },
                        ensure     => running,
                        hasstatus  => true,
                        hasrestart => true,
                        enable     => true,
                        require    => Class["ssh::config"],
        }
}

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

Dans ce fichier, nous définissons trois classes ssh::install, ssh::config et ssh:service permettant respectivement d’installer les paquets, de déployer le fichier de configuration sshd_config défini précédemment et de lancer le service.
Enfin, nous définissons la classe principale ssh, qui inclus les trois précédentes.

La classe ssh::install :
Dans cette classe, nous définissons le nom du paquet à installer et nous nous assurons d’avoir la dernière version installée.
Du fait des informations fournies par facter, puppet sait quel gestionnaire de paquets utiliser en fonction de la plateforme (apt, yum, portage, …). La liste des providers supportés se trouve ici.

Dans l’exemple, nous faisons une différenciation du nom du paquet à installer en fonction de la plateforme. Si le paquet à le même nom sur l’ensemble des plateformes gérées, nous pourrions avoir simplement :

class ssh::install {
  package { "openssh":
   ensure => latest,
  }
}

Le mot clé latest permet de s’assurer que la dernière version disponible du paquet est installée. Les autres mots clés possibles sont : present, absent, purged, held, latest.

La classe ssh::config :

Cette classe permet de déployer le fichier de configuration sshd_config placé sous le répertoire files. La clause ensure => present permet de s’assurer de la présence du bon fichier.
La cohérence du fichier sur le client est contrôlée par sa signature md5. Si cette signature diffère de celle du fichier présent sur le serveur, le fichier est à nouveau déployé.
Les autres mots clé possibles pour la clause ensure sont absent,present,file,directory,link

Si la clause ensure => absent est utilisée, alors le fichier et supprimé (s’il s’agit d’un répertoire à supprimer, rajouter recurse => true).

La clause ensure permet également de créer un lien symbolique. Par exemple :

file { "/etc/named.conf":
 ensure => link,
 target => "/var/named/chroot/etc/named.conf",
}

A noter que la source, définie par puppet:///modules/ssh/sshd_config correspond sur le disque au fichier /etc/puppet/modules/ssh/files/sshd_config. Les autorisations d’accès sont définies dans le fichier /etc/puppet/fileserver.conf

La classe ssh::service :

Cette classe permet de s’assurer que le service ssh est lancé du fait de la clause ensure => running. Les valeurs possibles sont : stopped ou running.
Comme précédemment, le nom du service (qui correspond au nom du script de démarrage /etc/init.d/……) est défini en fonction de la plateforme.

La clause hasrestart permet de définir si le script de démarrage (/etc/init.d/……) accepte l’argument restart. Les valeurs possibles sont true (par défaut) ou false. Si la valeur choisie est false, alors les commandes stop puis start seront utilisées à la place de la commande restart.

La clause hasstatus permet de définir si le script de démarrage (/etc/init.d/……) accepte l’argument status. Les valeurs possibles sont true (par défaut depuis v2.7.0) ou false. Si le script ne permet pas la commande status, alors une clause status fournissant le nom d’une commande à utiliser pour obtenir l’état du service. Cette commande doit avoir un code de retour à 0 si le service fonctionne.

La clause enable => true permet de définir si le service doit être activé au boot. Les valeurs possibles sont true, false, manual.

L’ensemble des valeurs possibles pour les différentes options se trouve dans la documentation officielle.

Vérification côté client :

Sur la machine poste-client, supprimons le paquet openssh-server si celui-ci était déjà installé.

sudo apt-get remove openssh-server
sudo rm /etc/ssh/sshd_config

L’agent puppet fonctionnant, au bout d’un certain temps, nous voyons dans le fichier /var/log/syslog.conf des lignes du style :

 puppet-agent[11803]: (/Stage[main]/Ssh::Config/File[/etc/ssh/sshd_config]/content) content changed '{md5}8caefdd9e251b7cc1baa37874149a870' to '{md5}e6926fcb58f2cb12a3cdcbd28c3b96c8'
 puppet-agent[11803]: (/Stage[main]/Ssh::Config/File[/etc/ssh/sshd_config]/mode) mode changed '644' to '600'
 puppet-agent[11803]: (/Stage[main]/Ssh::Service/Service[sshd]/enable) enable changed 'false' to 'true'
 puppet-agent[11803]: (/Stage[main]/Ssh::Service/Service[sshd]) Triggered 'refresh' from 1 events
 puppet-agent[11803]: Finished catalog run in 6.26 seconds

Le service ssh est installé, lancé et le fichier sshd_config correspond à celui centralisé sur le serveur puppetmaster.

On remarque que la conformité du fichier est evaluée en fonction de sa signature md5 :

content changed ‘{md5}8caefdd9e251b7cc1baa37874149a870’ to ‘{md5}e6926fcb58f2cb12a3cdcbd28c3b96c8’

Modifions le fichier sshd_config manuellement sur la machine poste-client.
En regardant de nouveau le fichier /var/log/syslog, nous apercevons :

puppet-agent[11803]: (/Stage[main]/Ssh::Config/File[/etc/ssh/sshd_config]/content) content changed '{md5}03b526a2efe419608151356c0ce4185d' to '{md5}e6926fcb58f2cb12a3cdcbd28c3b96c8'
puppet-agent[11803]: (/Stage[main]/Ssh::Service/Service[sshd]) Triggered 'refresh' from 1 events
puppet-agent[11803]: Finished catalog run in 0.92 seconds

Nous nous rendons compte que, puppet ayant remarqué le changement sur le fichier, il va recharger la configuration stockée sur le puppetmaster et cela nous permet donc d’avoir une configuration cohérente.

Cependant, comme indiqué au début de l’article, avant de remplacer le fichier, puppet va effectuer une sauvegarde grace au service filebucket.

Si nous désirons restaurer le fichier que nous avions modifié manuellement, il suffit, sur le poste client, d’éxecuter la commande filebucket en indiquant en argument, la signature md5 du fichier à restaurer et son emplacement :

filebucket restore /etc/ssh/sshd_config 03b526a2efe419608151356c0ce4185d

Bien évidemment, il faut stopper le service puppet sur le poste client sinon, à la prochaine vérification, le fichier sera à nouveau remplacé.

Dans un prochain article, nous détaillerons l’utilisation des templates.

Pour aller plus loin dans l’exploration de puppet, je vous conseille de jeter un oeil au puppet cookbook