L’installation se fait avec yum :

# yum install vsftpd

Ensuite, on passe à une rapide étape de configuration basique du fichier /etc/vsftpd/vsftpd.conf, dont voici ce que j’ai modifié :

# ligne 12: no anonymous
anonymous_enable=NO
 
# line 82,83: décommenter
ascii_upload_enable=YES
ascii_download_enable=YES
 
# line 97, 98: décommenter
# les utilisateurs seront ainsi chrootés dans leur home
chroot_local_user=YES
chroot_list_enable=YES
 
# line 100: décommenter
# les utilisateurs listés dans ce fichier pourront aller au delà du chroot
chroot_list_file=/etc/vsftpd/chroot_list
 
# line 106: décommenter
ls_recurse_enable=YES
 
# use localtime
use_localtime=YES

On ajoute les utilisateurs qui peuvent aller hors de leur home dans le fichier /etc/vsftpd/chroot_list. On (re)démarre le serveur et éventuellement on dit au système de le démarrer avec la machine :

# systemctl start vsftpdservice
# systemctl enable vsftpdservice

C’est tout.

Installation du paquet

L’installation se fait toujours avec yum, pour CentOS 5.x et Fedora avant F11:

# yum install vnc-server

Pour CentOS 6.x et Fedora après F11, on utilise TigerVNC :

# yum install tigervnc-server

Attribuer un mot de passe VNC à l’utilisateur

Se connecter en tant que l’utilisateur pour l’accès VNC, puis lui attribuer un mot de passe avec cette commande :

vncpasswd

Ceci va créer le répertoire .vnc et stocker le mot de passe.

Configurer le serveur

Il faut éditer le fichier /etc/sysconfig/vncservers avec quelque chose comme ceci :

VNCSERVERS="2:fabien toto:6"
VNCSERVERARGS[2]="-geometry 1024x768 -localhost"
VNCSERVERARGS[6]="-geometry 800x600"

Ce qui signifie que fabien va avoir un écran de 1024x768px accessible sur le port VNC 2 (port VNC 5900 + 2 = 5902) seulement en local, alors que toto utilisera le port 6 avec une résolution de 800x600px.

Démarrage et initialisation du serveur

Le serveur doit etre lancé une fois pour initialiser le fichier de configuration ~/.vnc/xstartup des utilisateurs :

# /sbin/service vncserver start
# /sbin/service vncserver stop

Il ne reste plus que quelques modifications à effectuer pour accéder à sa session à distance. Dans le cas de XFCE, je remplace simplement twm & par startxfce4 & (gnome-session & pour Gnome ou startkde & pour KDE). La ligne XKL_XMODMAP_DISABLE=1 est nécessaire pour éviter des problèmes de mappage de clavier, il est bon de ne pas l’oublier. Voici mon fichier xstartup :

#!/bin/sh
 
# Uncomment the following two lines for normal desktop:
#unset SESSION_MANAGER
#exec /etc/X11/xinit/xinitrc
 
[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
xsetroot -solid grey
vncconfig -iconic &
xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
#twm &
startxfce4 &

Tunnel SSH

L’option -localhost n’autorise l’accès qu’en local. Pour accèder à ce serveur en VNC il faut donc au préalable établir une connexion SSH entre la machine cliente et celui-ci en créant un tunnel qui redirigera le port 5904 du serveur vers le port – par exemple – 6004 du client. Voici comment instancier cette connexion SSH depuis un client linux :

$ ssh -L 6002:localhost:5902 IP_SERVEUR

Et voici la configuration de ce tunnel avec puTTY sous Windows :

Une fois la connexion effectuée, il suffit d’utiliser son client VNC avec localhost et le port 6004 pour accéder au serveur en toute sécurité. En ligne de commande sous linux avec le client vncviewer :

$ vncviewer localhost:6002

Et sous Windows par exemple avec le client UltraVNC :

De cette façon, il n’est pas possible de se connecter à la machine depuis une autre IP que la locale (127.0.0.1).

DRBD réplique au niveau des périphériques de bloc, pour plus d’informations sur son fonctionnement, je vous renvoie à la page Wikipedia de DRBD.

Pré-requis

Ce tutoriel est réalisé avec deux machines sous CentOS 6, celles-ci sont respectivement nommées centos-ha1 (IP : 192.168.1.10) et centos-ha2 (IP : 192.168.1.11), le terme de nœud sera utilisé pour les désigner.
SELinux est désactivé et le port 7789 ouvert au niveau du firewall.

DRBD fonctionnant au niveau bloc, il faut un disque ou une partition dédiée à cela. Dans l’exemple de ce billet, on part d’un groupe de volumes LVM nommé vg_storage avec un unique volume logique lv_storage qui est libre pour créer notre ressource DRBD. Un volume logique étant un périphérique de bloc aux yeux de Linux, cela convient parfaitement. Celui-ci n’a pas besoin (et ne doit pas) d’être formatté.

Installation

Depuis CentOS 6, les paquets DRBD ne sont plus dans les dépots de base, il faut donc ajouter ceux de atRPMS. Pour ce faire, ajouter le fichier atrpms.repo sous /etc/yum.repos.d contenant ceci :

[atrpms]
name=CentOS $releasever - $basearch - ATrpms
baseurl=http://dl.atrpms.net/el$releasever-$basearch/atrpms/stable
gpgkey=http://atrpms.net/RPM-GPG-KEY.atrpms
gpgcheck=1

Vérification de la présence de paquets relatifs à DRBD :

# yum search drbd
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* base: ftp.plusline.de
* extras: ftp.plusline.de
* updates: mirrors.prometeus.net
========================================= Matched: drbd =========================================
drbd.i686 : Distributed Replicated Block Device.
drbd-kmdl-2.6.32-131.0.15.el6.i686.i686 : Distributed Redundant Block Device.
drbd-kmdl-2.6.32-131.12.1.el6.i686.i686 : Distributed Redundant Block Device.
drbd-kmdl-2.6.32-131.2.1.el6.i686.i686 : Distributed Redundant Block Device.
drbd-kmdl-2.6.32-131.4.1.el6.i686.i686 : Distributed Redundant Block Device.
drbd-kmdl-2.6.32-131.6.1.el6.i686.i686 : Distributed Redundant Block Device.
drbd-kmdl-2.6.32-71.14.1.el6.i686.i686 : Distributed Redundant Block Device.
drbd-kmdl-2.6.32-71.18.1.el6.i686.i686 : Distributed Redundant Block Device.
drbd-kmdl-2.6.32-71.18.2.el6.i686.i686 : Distributed Redundant Block Device.
drbd-kmdl-2.6.32-71.24.1.el6.i686.i686 : Distributed Redundant Block Device.
drbd-kmdl-2.6.32-71.29.1.el6.centos.plus.i686.i686 : Distributed Redundant Block Device.
drbd-kmdl-2.6.32-71.29.1.el6.i686.i686 : Distributed Redundant Block Device.
drbd-kmdl-2.6.32-71.7.1.el6.i686.i686 : Distributed Redundant Block Device.

Nous pouvons installer le paquet drbd ainsi que le module du noyau correspondant au noyau en cours. Je vérifie quel noyau j’ai sur mon système :

# uname -r
2.6.32-71.29.1.el6.i686

J’installe le module correspondant :

# yum install drbd drbd-kmdl-2.6.32-71.29.1.el6.i686.i686

Il faut charger le nouveau module dans le noyau :

# modprobe drbd

Et bien sur on veut qu’il se charge au démarrage de la machine, on ajoute donc cette ligne au fichier /etc/rc.local.

Configuration

La configuration de DRBD se situe sous /etc/drbd.conf, mais pour plus de lisibilité, ce fichier fait appel à ceux situés sous /etc/drbd.d/, la configuration se fait donc d’une part dans global_common.conf pour la configuration commune et dans un fichier r0.res que nous allons créer pour notre nouvelle ressource. Ce nom r0 est arbitraire.
Donc pour commencer, vérifier que le fichier global_common.conf possède les options suivantes :

global {
  usage-count yes;
}
common {
  net {
    protocol C;
    verify-alg sha1;
    csums-alg sha1;
  }
}

L’option protocol C signifie que la réplication s’effectue de façon synchrone. Avec ce mode de fonctionnement synchrone, l’écriture de données n’est considérée terminée que lorsque le nœud secondaire a terminé d’écrire, validant ainsi l’opération. verify-alg sha1 vérifie l’intégrité des données bloc par bloc entre les nœuds. csums-alg sha1 active la synchronisation avec somme de contrôle (checksum). Comme expliqué dans la documentation, la synchronisation n’est pas la même chose que la réplication des périphériques. La seconde se fait en temps réel, c’est le fonctionnement normal de DRBD, alors que la première s’effectue lorsqu’il y a eu perte d’un des deux nœuds (pour quelque raison que ce soit) et une (re)synchronisation est nécessaire.

Il est temps de créer la vraie ressource dans un nouveau fichier r0.res contenant ces informations :

resource r0 {
	on mailsrv-ha1 {
    	address   192.168.1.10:7789;
    	device    /dev/drbd1;
		disk      /dev/mapper/vg_storage-lv_storage;
		meta-disk internal;
  	}
  	on mailsrv-ha2 {
    	address   192.168.1.11:7789;
    	device    /dev/drbd1;
		disk      /dev/mapper/vg_storage-lv_storage;
		meta-disk internal;
  	}
}

Petite explication sur la configuration de cette ressource qui dans son ensemble parle d’elle-même. On définit les deux nœuds avec le mot-clé on suivi du nom de l’hôte. On spécifie l’IP du nœud et le port utilisé – ici 7789. Le périphérique de bloc logique est définit par device suivi du chemin vers celui-ci. Ensuite il faut indiquer la partition de bas niveau sur laquelle le périphérique de bloc logique se posera grace au mot-clé disk suivi de son chemin. meta-disk internal indique que la zone réservée aux données de contrôle sera sur la même partition, toujours au niveau bloc (plus d’informations sur ce sujet sur la documentation officielle).

On voit que certaines options (presque toutes sauf l’IP) sont les mêmes, on peut donc simplifier notre fichier r0.res comme ceci :

resource r0 {
	device    /dev/drbd1;
    disk      /dev/mapper/vg_storage-lv_storage;
    meta-disk internal;
	on mailsrv-ha1 {
    	address   192.168.137.201:7789;
  	}
  	on mailsrv-ha2 {
    	address   192.168.137.203:7789;
  	}
}

Activation de la ressource

Voilà, tout est bien configuré, on peut activer la ressource. Je répète que le système de fichiers de bas niveau /dev/mapper/vg_storage-lv_storage doit être démonté et ne doit pas être formatté. Si tel est le cas, son contenu va de toutes façons être perdu.

On commence par créer les meta-données du périphérique :

# drbdadm create-md r0

Si des erreurs sont retournées, c’est que le système de fichiers existe, on le détruit donc :

# dd if=/dev/zero of=/dev/mapper/vg_storage-lv_storage bs=1M count=128

On relance la commande de création des meta-données. Tout devrait bien se passer, on peut activer la ressource :

# drbdadm up r0

Il faut faire de même sur l’autre nœud. Lorsque la deuxième machine est prête on initialise la première synchronisation par cette commande :

# drbdadm primary --force r0

Alors que se passe-t-il? Lorsque la ressource est activée, les deux nœuds sont marquées comme secondaires, une première synchronisation est nécessaire, on va donc forcer (avec l’option --force) cette opération sur le nœud que l’on veut primaire.

A ce stade, il est possible de vérifier l’état de DRBD par la commande :

# drbd-overview 
  1:r0/0  SyncSource Primary/Secondary UpToDate/Inconsistent C r----- 
	[>....................] sync'ed:  0.6% (53340/53652)M

On voit que la ressource est en cours de synchronisation, suivant la taille de la partition, cela peut être long. On a plus d’info avec :

# cat /proc/drbd 
version: 8.4.0 (api:1/proto:86-100)
GIT-hash: 28753f559ab51b549d16bcf487fe625d5919c49c build by gardner@, 2011-08-26 23:24:30
 
 1: cs:SyncSource ro:Primary/Secondary ds:UpToDate/Inconsistent C r-----
    ns:1482108 nr:0 dw:0 dr:1487544 al:0 bm:90 lo:0 pe:2 ua:5 ap:0 ep:1 wo:b oos:53461324
	[>....................] sync'ed:  2.7% (52208/53652)M
	finish: 0:41:59 speed: 21,216 (22,100) K/sec

On voit que le processus de synchronisation est en cours (cs:SyncSource), que le nœud primaire est à jour mais le secondaire est encore dans un étant incohérent (ds:UpToDate/Inconsistent).
Il n’est pas nécessaire d’attendre la fin de la synchronisation pour créer le système de fichiers, donc allons-y, créons un système de fichiers ext4 et montons-le :

mkfs.ext4 -L storage /dev/drbd1
mkdir /mnt/storage
mount /dev/drbd1 /mnt/storage

Le système de fichiers est maintenant utilisable et va être répliqué en temps réel. On peut vérifier l’état de synchronisation :

# cat /proc/drbd 
version: 8.4.0 (api:1/proto:86-100)
GIT-hash: 28753f559ab51b549d16bcf487fe625d5919c49c build by gardner@, 2011-08-26 23:24:30
 
 1: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r-----
    ns:56499808 nr:36 dw:1557816 dr:54944894 al:422 bm:3354 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0

Voilà, c’est fini, notre resource est connectée (cs:Connected), on est sur le noeud primaire (ro:Primary/Secondary) et elle est à jour des deux cotés (ds:UpToDate/UpToDate). Avec drbd-overview on obtient plus d’informations, en particulier sur la taille du stockage :

# drbd-overview 
  1:r0/0  Connected Primary/Secondary UpToDate/UpToDate C r----- /mnt/storage ext4 52G 730M 49G 2%

Toute modification sur la ressource peut se faire en temps réel, après un changement, il faut copier le fichier de configuration sur le second nœud et opérer cette commande (sur les deux nœuds) :

# drbdadm adjust r0

Vérification en ligne automatique

Nous avons vu que l’option verify-alg permet de vérifier l’intégrité des données en ligne, pour faire ce test il suffit d’invoquer la commande :

# drbdadm verify r0

DRBD commence alors la vérification et s’il détecte des blocs non synchronisés, il les marque comme tel et l’inscrit dans le log du noyau. Il est bon d’automatiser cette tâche en l’ajoutant dans le cron. Pour ce faire, ajouter un fichier /etc/cron.d/drbd-verify avec – par exemple – ce contenu :

42 0 * * 0    root    /sbin/drbdadm verify r0

Par ailleurs, si des blocs non synchronisés ont été détectés, il faut les re-synchroniser comme ceci :

drbdadm disconnect r0
drbdadm connect r0

Restauration manuelle après un split-brain

Un split-brain se produit lorsque pour une raison quelconque les deux nœuds se retrouvent déconnectés, lorsque la connectivité revient, DRBD détecte que les 2 nœuds sont en mode primaire, DRBD rompt alors immédiatement la connexion de réplication par sécurité. Après le split-brain, un nœud passe en mode StandAlone et l’autre passe soit en mode secondaire ou en WFConnection. Il est temps d’intervenir.

Pour repartir sans corrompre les données – pour que le primaire sache qu’il est « maitre » – il faut aller sur le (futur) nœud secondaire et le déclarer comme tel, puis on connecte la ressource en lui disant d’oublier ses données :

drbdadm secondary r0
drbdadm connect --discard-my-data r0

On passe sur le primaire que l’on connecte et que l’on déclare primaire :

drbdadm connect r0
drbdadm primary r0

Notre ressource r0 est repartie.

Tester la réplication

Il est temps de tester un peu le fonctionnement de la réplication. Créons un fichier quelconque de 500Mo sous /mnt/storage :

# dd if=/dev/zero of=/mnt/storage/toto.dat bs=10M count=50
50+0 records in
50+0 records out
524288000 bytes (524 MB) copied, 31.4183 s, 16.7 MB/s
# ls -l /mnt/storage/
-rw-r--r--  1 root root 524288000 Sep 22 11:04 toto.dat

Celui-ci devrait maintenant exister également sur centos-ha2, pour le vérifier il faut suivre les étapes suivantes, sur le primaire : démonter le système de fichiers, le passer en secondaire, et sur le secondaire : le passer en primaire et monter le système de fichiers. Cela donne :

[centos-ha1 ~]# umount /mnt/storage
[centos-ha1 ~]# drbdadm secondary r0
 
[centos-ha2 ~]# drbdadm primary r0
[centos-ha2 ~]# mount /dev/drbd1 /mnt/storage
[centos-ha2 ~]# ls -l /mnt/storage
-rw-r--r--  1 root root 524288000 Sep 22 11:04 toto.dat

Tout est parfait, même si cela semble un peu long. Il ne faut pas oublier que le système de fichiers sur le nœud secondaire n’est pas accessible en l’état (il n’est d’ailleurs pas monté). Dans un environnement de production, la manipulation est un peu fastidieuse, c’est pourquoi il vaut mieux utiliser un CRM (Cluster Resource management) – comme Pacemaker – qui fera ce travail automatiquement. Ce sera l’objet d’un prochain article.

^.^

Ressources :

• The DRBD User’s Guide
• Wikipedia : DRBD
• CentOS 6
• Dépôt atRPMS

Création du certificat

La création du certificat s’effectue avec la commande openssl, comme suit :

# openssl req -new -x509 -days 3650 -nodes -out /etc/postfix/mailserver.pem -keyout /etc/postfix/mailserver.pem

C’est parti pour une série de questions, peu importe les réponses données, seul le Common Name est important et doit refléter le nom d’hôte du serveur, dans notre exemple : mail.example.net. Le certificat sera valide 10 ans (10 x 365 jours).
Il faut veiller à placer les bonnes permissions sur le fichier :

# chmod 600 /etc/postfix/mailserver.pem

Postfix

On ajoute les bonnes directives au main.conf de Postfix, par exemple en fin de fichier :

smtpd_tls_key_file = /etc/postfix/mailserver.pem
smtpd_tls_cert_file = /etc/postfix/mailserver.pem
smtpd_tls_security_level = encrypt
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom
smtp_tls_loglevel = 3

Redémarrage de Postfix :

# postfix reload

Tout est en place, le serveur SMTP devrait pouvoir instantier une connexion TLS maintenant, essayons en telnet, si une nouvelle ligne STARTTLS apparait et que le serveur répond correctement, c’est tout bon :

$ telnet mail.example.net 25
Trying 91.127.162.55...
Connected to mail.example.net.
Escape character is '^]'.
220 mail.example.net ESMTP Postfix
EHLO localhost
250-mail.example.net
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

STARTTLS est bien présent, on tape la commande STARTTLS :

STARTTLS
220 2.0.0 Ready to start TLS

La serveur dit qu’il est pret, sinon revoir ses certificats, les chemins et les bonne options dans main.cf. Cependant il reste un petit problème de sécurité, il faut que l’authentification SMTP AUTH PLAIN ne soit disponible que lorsque l’utilisateur utilise TLS. Ainsi Postfix va effectuer le SMTP AUTH uniquement après que la couche soit TLS soit établie. Pour ce faire il suffit de rajouter cette ligne au main.cf :

smtpd_tls_auth_only = yes

On redémarre Postfix :

# postfix reload

On re-telnet :

$ telnet mail.example.net 25
Trying 91.127.162.55...
Connected to mail.example.net.
Escape character is '^]'.
220 mail.example.net ESMTP Postfix
EHLO localhost
250-mail.example.net
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

On voit que maintenant SMTP AUTH ne sera disponible qu’après avoir établit la liaison TLS (les lignes AUTH ne sont plus visibles à ce niveau).

Dovecot SSL

Au tour de Dovecot de passer en SSL. C’est très simple, nous allons utiliser le même certificat que pour Postfix. On ajoute les lignes suivantes au fichier dovecot.conf :

protocols = imap imaps
ssl_disable = no
# ssl = yes pour les versions supérieures à v1.2.beta1
ssl_cert_file = /etc/postfix/ssl/postfix.pem
ssl_key_file = /etc/postfix/ssl/postfix.pem
verbose_ssl = yes

Un petit rappel sur les permissions du certificat qui ne doit etre accessible que par l’utilisateur root : root:root 0444. Autre petit point qui a son importance, on refuse désormais les connexions LOGIN à moins que TLS/SSL soit établi. Pour ce faire, on modifie cette ligne :

disable_plaintext_auth = yes

On re-démarre le serveur IMAP :

# service dovecot restart

On peut le tester :

$ openssl s_client -connect mail.example.net:imaps
CONNECTED(00000003)
depth=0 /C=IT/ST=Lazio/L=Roma/O=example.net/OU=mailserver/CN=mail.example.net/emailAddress=fabien@feub.net
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=IT/ST=Lazio/L=Roma/O=example.net/OU=mailserver/CN=mail.example.net/emailAddress=fabien@feub.net
verify return:1
---
Certificate chain
 0 s:/C=IT/ST=Lazio/L=Roma/O=example.net/OU=mailserver/CN=mail.example.net/emailAddress=fabien@feub.net
   i:/C=IT/ST=Lazio/L=Roma/O=example.net/OU=mailserver/CN=mail.example.net/emailAddress=fabien@feub.net
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDojCCAwugAwIBAgIJAKn3cs1HiGLvMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYD
VQQGEwJJVDEOMAwGA1UECBMFTGF6aW8xDTALBgNVBAcTBFJvbWExFzAVBgNVBAoT
DmZhYmllbmFtYW5uLmV1MRMwEQYDVQQLEwptYWlsc2VydmVyMRwwGgYDVQQDExNt
YWlsLmZhYmllbmFtYW5uLmV1MRkwFwYJKoZIhvcNAQkBFgpfQGZldWIubmV0MB4X
DTExMDgwNDEzNTY1OFoXDTIxMDgwMTEzNTY1OFowgZMxCzAJBgNVBAYTAklUMQ4w
DAYDVQQIEwVMYXppbzENMAsGA1UEBxMEUm9tYTEXMBUGA1URChMOZmFiaWVuYW1h
bm4uZXUxEzARBgNVBAsTCm1haWxzZXJ2ZXIxHDAaBgNVBAMTE21haWwuZmFiaWVu
YW1hbm4uZXUxGTAXBgkqhkiG9w0BCQEWCmZAZmV1Yi5uZXQwgZ8wDQYJKoZIhvcN
AQEBBQADgY0AMIGJAoGBAO5esAspC+j2yVIPRsSQ6aUsbR+8iS/u5H4LgwL8OQd5
799lXzG9hWmn0uMR+6SutjgDFbDL+w+zdXzGZ2UQi6OjKjKo+L/pwEkdokRRIpNw
mhyIum+F+7XcfP1KHdVQu85cDphd+rhPDkDtYNUMD8Nd8ClmaftTeVVaV5T1MEGt
AgMBAAGjgfswfafaHQYDVR0OBBYEFKCxvAc+P1gk+ILQWc3NXvdxNxYRMIHIBgNV
HSMEgcAwgb2AFKCxvAc+P1gk+ILQWc3nXvdxNxYRoYGZpIGWMIGTMQswCQYDVQQG
EwJJVDEOMAwGA1UECBMFTGF6aW8xDTALBgNVBAcTBFJvbWEXFzAVBgNVBAoTDmZh
YmllbmFtYW5uLmV1MRMwEQYDVQQLEwptYWlsc2VydmVyMRwwGgYDVQQDExNtYWls
LmZhYmllkikiFtYW5uLmV1MRkwFwYJKoZIhvcNAQkBFgpmQGZldWIuV0ggkAqfdy
zUeIYu8wDAYDVR0TBAUwAwEB/zANBgkqhdiG9w0BAQUFAAOBgQAyESbxZh8WID39
Qwr/NjotqatAsKqGXCIuW5WROo+7ZVvmPoVx/OLvnYQnF5DzCnMF/9E7kuiW2feg
BmQPYT5UXU5cH2R5fBkT/bnIgPTEr33L75RFDWiKE4vKzvtTDneUIWxXxw+goGOz
SK3TyKQawclFSbVC9nvBixw5+4hbfg==
-----END CERTIFICATE-----
subject=/C=IT/ST=Lazio/L=Roma/O=example.net/OU=mailserver/CN=mail.example.net/emailAddress=fabien@feub.net
issuer=/C=IT/ST=Lazio/L=Roma/O=example.net/OU=mailserver/CN=mail.example.net/emailAddress=fabien@feub.net
---
No client certificate CA names sent
---
SSL handshake has read 1505 bytes and written 319 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : DHE-RSA-AES256-SHA
    Session-ID: 7A7619EB698CEF9463774C06E6729F0A2CE9D9E551DD96439C00D7BA3001641D1
    Session-ID-ctx: 
    Master-Key: 89E6DA90F03046C65F4C330A9D24209D3260A4DE134EC4287D6516B344AFBE80BCAE0FDCE037177B384E2F166C17CBCE
    Key-Arg   : None
    Krb5 Principal: None
    Start Time: 1312960774
    Timeout   : 300 (sec)
    Verify return code: 18 (self signed certificate)
---
* OK Dovecot ready.

Le serveur de messagerie est maintenant plus sécurisé avec cette couche TLS/SSL qui crypte les communications et authentifie l’identité du serveur. L’utilisation d’un cryptage à clé publique permet au client de vérifier que le serveur possède un certificat valide et ainsi ce client sait pour des utilisations ultérieures qu’il peut faire confiance à ce serveur. L’utilisateur qui se connecte est également vérifié dans ce processus.

En complément :

• Première partie : Serveur de messagerie simple avec Postfix et Dovecot
• Deuxième partie : Postfix SASL avec Dovecot
• Troisième partie : Ajouter le support TLS à Postfix
• http://www.postfix.org/
• http://www.dovecot.org/

# postconf -a

Configurer Dovecot SASL

Le server POP/IMAP Dovecot possède bien entendu son propre système d’authentification des clients POP/IMAP. Lorsque Postfix utilise Dovecot SASL, celui-ci ré-utilise cette configuration. La communication se fait par l’intermédiaire d’un socket Unix. Le chemin vers ce socket ainsi que la liste des méthodes d’authentification proposées doivent être spécifiées dans dovecot.conf. Voici ce qu’il faut ajouter au fichier de configuration de Dovecot existant :

auth default {
  mechanisms = plain login  
  socket listen {
    client {
      # Un socket est exporté pour pouvoir etre utilisé par un client.
      # Ici c'est notre serveur SMTP Postfix
      path = /var/run/dovecot/auth-client
      mode = 0660
      user = postfix
      group = postfix
    }
  }
}

On relance Dovecot :

# service dovecot restart

La partie Postfix

Maintenant il faut dire à Postfix comment utiliser SASL. Par défaut celui-ci gère du Cyrus SASL, il faut donc explicitement lui dire que l’on utilise le mécanisme de Dovecot, on renseigne le chemin vers le socket et on lui passe quelques options de sécurité. Voici la partie SASL à ajouter au main.cf :

# On utilise le SASL de Dovecot
smtpd_sasl_type = dovecot
# Chemin vers le socket Unix
smtpd_sasl_path = /var/run/dovecot/auth-client
# On active le SASL
smtpd_sasl_auth_enable = yes
# Quelques options de sécurité assez parlantes
smtpd_recipient_restrictions =  permit_mynetworks,
    permit_sasl_authenticated, reject_unauth_destination
# Ceci assure une compatibilité avec d'anciens clients (Outlook par ex.)
broken_sasl_auth_clients = yes
# Pas de connexions anonymes
smtpd_sasl_security_options = noanonymous

On re-charge Postfix :

# postfix reload

Test de la configuration

La configuration est terminée, il est temps de tester le bon fonctionnement du SMTP Auth en telnet:

$ telnet mail.example.net 25
Trying 90.112.151.15...
Connected to mail.example.net.
Escape character is '^]'.
220 mail.example.net ESMTP Postfix
EHLO localhost
250-mail.example.net
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

On voit les deux lignes AUTH indiquant que le SASL est pris en compte. Pourquoi deux lignes? La deuxième avec le signe égal est pour la compatibilité avec les anciens clients (option : broken_sasl_auth_clients = yes).

MAIL FROM:<lulu>
250 2.1.0 Ok
RCPT TO: fabien@feub.net
554 5.7.1 <fabien@feub.net>: Relay access denied

La connexion est refusée, il faut maintenant penser à s’authentifier avec la commande AUTH. Mais attention, en telnet il est nécessaire d’encoder le couple nom d’utilisateur/mot de passe en base64, par exemple avec :

$ echo -ne '\000username\000password' | openssl base64

Ce qui donne :

AUTH PLAIN AGhvbnTHY3RAZmDiavVuKikI7hbm5uZVBAc3BjKXRuoJWsK
235 2.0.0 Authentication successful
RCPT TO: fabien@feub.net
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Yes!
.
250 2.0.0 Ok: queued as E72163EB1E
quit
221 2.0.0 Bye
Connection closed by foreign host.

Le message devrait être délivré sous peu ^.^

En complément :

• Première partie : Serveur de messagerie simple avec Postfix et Dovecot
• Deuxième partie : Postfix SASL avec Dovecot
• Troisième partie : Ajouter le support TLS à Postfix
• http://www.postfix.org/
• http://www.dovecot.org/

Je suis donc sur une machine en Fedora 14 15 et voici un petit descriptif de ma config et des quelques outils que j’utilise. Je précise qu’il y a de l’Open-Source ET du propriétaire. Je suis un grand défenseur du libre, mais je pense également qu’il y a des limites et qu’à partir d’un certain moment la productivité est la priorité par rapport aux principes (et bien sur si je ne peux pas travailler, mon patron ne sera pas content).
Je suis toujours ouvert aux propositions que vous pouvez soumettre dans les commentaires, c’est même un peu le but de ce billet, d’échanger des idées et des points de vue :)

Donc, en vrac, je suis sous Fedora 15 et l’adaptation est un peu chahotique, mais on s’adapte. A propos de ce billet de début juin, je suis depuis retourné vers Gnome 3, bien sur avec l’aide de Gnome Tweak Tool qui facilite un peu l’expérience.

Développement web

Mon principal job étant le développement PHP (avec MySQL et DB2), j’utilise Netbeans comme IDE, mais je dois dire que l’ergonomie et certaines fonctionalités de Dreamweaver me manquent énormément, et le faire tourner sous Wine ou en VM ne sont pas des solutions pour moi.

Partie graphique

Coté design graphique, c’est un peu beaucoup à la traine, je n’ai jamais supporté The GIMP, désolé, je jongle donc entre celui-ci pour les petites retouches rapides et Photoshop en VM pour le plus sérieux.

Administration machines

J’administre également des serveurs GNU/Linux (CentOS) et Windows avec Terminator et Gnome-RDP.

Voilà donc un peu mon environnement général, sans rentrer dans les détails. Visuellement mon bureau Fedora / Gnome Shell ressemble à celà au jour d’aujourd’hui :

J’ai donc décidé de m’essayer à …. KDE, et j’ai été plutot séduit (mention +++ pour le gestionnaire de fichiers Krusader), mais après quelques heures de boulot, mes ressources enflaient et ma machine devenait vraiment lente. J’ai donc viré du coté de XFCE que je connais un peu pour l’avoir utilisé sur quelques serveurs avec gestionnaire de bureaux. Mais, car il y a encore une fois un mais, il me manquait des choses, je n’étais pas à l’aise et je ressentais trop de limites. Après un re-passage à Gnome 3 et en ce moment depuis 2 jours sous LXDE qui ne me convient pas vraiment non plus (encore plus léger que XFCE, mais c’est le but du projet), je lance un appel à l’aide et des conseils de votre part, vos retours d’expériences ou simplement savoir sur quoi vous travaillez.

J’attends vos inspirations dans les commentaires, merci ^.^

Update 17/06/2011 : Mon choix n’est pas gravé dans le marbre, mais depuis ce billet je suis un utilisateur KDE, il me convient plutôt bien, même si des petites choses me chagrinent, mais c’est seulement parce que je n’ai pas trouvé le temps pour tweaker tout ça.

Crédit photo.

Il gérera des boîtes aux lettres virtuelles – c’est-à-dire indépendantes des comptes systèmes – d’autant d’utilisateurs et de domaines que ce soit.

Pour la suite des opérations, la machine utilisée est sous Fedora, le tutoriel pourra donc convenir aux utilisateurs de CentOS et de Red Hat. On supposera qu’elle s’appelle monhostname.local.mondomaine.net. C’est parti ^.^

Postfix

L’installation se fait naturellement avec yum :

# yum install postfix

Afin de préparer le terrain, il faut créer l’arborescence qui accueillera les boîtes aux lettres virtuelles et l’utilisateur/groupe de celles-ci. Pour ce faire, ajouter un utilisateur vmail et un groupe du même nom ayant tout deux des uid et gid non réservés, par exemple 6000. Le home de cet utilisateur sera /home/vmail, c’est ici que les BAL seront construites :

# groupadd -g 6000 vmail
# useradd -d /home/vmail -m -u 6000 -g 6000 -s /dev/null vmail

On change les droits et le propriétaire des répertoires pour plus de sécurité :

# chmod -R 750 /home/vmail/
# chown -R vmail:vmail /home/vmail/

Les fichiers de configuration Postfix se situent sous /etc/postfix et c’est main.conf qui nous intéresse. Je vais juste copier-coller le mien ci-dessous, pour plus de renseignement sur ses paramètres, voir cet article.

alias_database = $alias_maps
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
delay_warning_time = 4h
html_directory = no
inet_interfaces = all
mail_owner = postfix
mailbox_transport = lmtp:unix:/var/lib/imap/socket/lmtp
mailbox_size_limit = 512000000
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
masquerade_domains = mondomaine.net
message_size_limit = 50000000
mydestination = $myhostname, localhost.$myhostname, localhost
mydomain = mondomaine.net
myhostname = monhostname.local.mondomaine.net
mynetworks = 192.168.1.0/24, 127.0.0.0/8
myorigin = $myhostname
newaliases_path = /usr/bin/newaliases
queue_directory = /var/spool/postfix
readme_directory = no
recipient_delimiter = +
relayhost = [smtp.sfr.fr]
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
smtp_generic_maps = hash:/etc/postfix/generic
smtpd_banner = $myhostname ESMTP
smtpd_recipient_limit = 50
unknown_local_recipient_reject_code = 550
virtual_alias_maps = hash:/etc/postfix/user_aliases
virtual_gid_maps = static:6000
virtual_mailbox_base = /home/vmail
virtual_mailbox_domains = /etc/postfix/domains
virtual_mailbox_limit = 512000000
virtual_mailbox_maps = hash:/etc/postfix/user_mailboxes_path
virtual_minimum_uid = 6000
virtual_uid_maps = static:6000

Astuce : Si comme moi, le serveur est sur un domaine local (monhostname.local.mondomaine.net), quelques difficultés vont être rencontrées lors de l’envoi de message vers l’extérieur, la machine de relai [smtp.sfr.fr] va refuser d’acheminer les emails car le domaine n’est pas enregistré sur la toile : Sender address rejected: Domain not found. Pour remédier à cela, il faut substituer l’adresse de l’émetteur en ajoutant ceci dans /etc/postfix/generic :

@monhostname.local.mondomaine.net       @mondomaine.net

On compile ce fichier avec postmap avant de relancer Postfix :

# postmap /etc/postfix/generic

Pour savoir où délivrer le courrier, le système va lire le nom des domaines virtuels gérés dans le fichier domains et les adresses emails ainsi que leur chemin seront dans user_mailboxes_path, tout deux toujours sous /etc/postfix. Il suffit d’ajouter des domaines séparés par des retours ligne, comme suit :

mondomaine.net
monautredomaine.com

Et pour les boîtes aux lettres virtuelles :

tutu@mondomaine.net mondomaine.net/tutu/
toto@monautredomaine.com monautredomaine.com/toto/

Noter le / (slash) de fin important pour indiquer qu’il s’agit de boîtes au format Maildir.

On ajoute un alias pour par exemple rediriger le courrier de toto@monautredomaine.com vers l’adresse tutu@mondomaine.net dans user_aliases :

toto@monautredomaine.com tutu@mondomaine.net

Et pour fignoler, on redirige le courrier de root – qui arrive sous /var/mail/root – vers une adresse virtuelle pour que la lecture des courriers important du système soit facilité. Ceci ce fait dans le fichier /etc/aliases :

root: tutu@mondomaine.net

Postfix ne lit pas ce genre de fichier tel quel, il faut comme pour le fichier generic le compiler pour créer le fichier de base de données grâce à la commande postmap, comme ceci :

postmap /etc/postfix/user_mailboxes_path
postmap /etc/postfix/user_aliases

Les alias locaux eux se compilent avec la commande :

newaliases

Une fois les changements effectués, on recharge Postfix :

# service postfix reload

On peut désormais faire un petit essai d’envoi d’email :

# "Email test" | mail -s "Test email root" root

Le message doit arriver dans /home/vmail/mondomaine.net/tutu/new/, l’arborescence étant créée automatiquement par Postfix dès réception de l’email.
A noter qu’il est préférable d’avoir un champ MX mondomaine.net dans vos zones DNS pour que le courrier soit bien acheminé.

Dovecot

Comme le dit le site sur lequel je me suis inspiré, recevoir du courrier c’est bien, pouvoir le lire c’est mieux. Pour cela, il faut installer Dovecot que l’on utilisera en serveur IMAP.

# yum install dovecot

Le fichier de configuration se situant sous /etc/dovecot/dovecot.conf, on l’édite comme suit :

# On veut des BAL IMAP
protocols = imap
 
# Chemin des les logs
log_path = /var/log/dovecot.log
info_log_path = /var/log/dovecot-info.log
 
# Je ne veux pas de SSL
ssl_disable = yes
disable_plaintext_auth = no
 
# Les BAL seront au format Maildir
mail_location = maildir:/home/vmail/%d/%n
 
# Optimisations
dotlock_use_excl=yes
maildir_copy_with_hardlinks=yes
 
# Configuration de l'authentification
auth_verbose = yes
auth default {
    mechanisms = plain
    passdb passwd-file {
        # Chemin vers les utilisateurs dovecot (les adresses email gérées)
        args = /etc/dovecot/passwd
    }
    userdb static {
        # Chemin vers les BAL
        args = uid=vmail gid=vmail home=/home/vmail/%d/%n/
    }
}

Maintenant il faut créer les utilisateurs (adresses emails) et les mots de passes associés pour accèder aux BAL dans le fichier /etc/dovecot/passwd :

echo "tutu@mondomaine.net:`dovecotpw -p lemotdepasse`" >> /etc/dovecot/passwd

On démarre Dovecot :

# service dovecot start

Et voilà, c’est fini! Il ne reste plus qu’à le tester. On peut commencer par essayer d’accéder à une BAL en telnet sur le port 143 :

$ telnet monhostname.mondomaine.net 143
Trying 127.0.0.1...
Connected to monhostname.mondomaine.net.
Escape character is '^]'.
* OK Dovecot ready.
1 login tutu@mondomaine.net motdepasse
 
1 OK Logged in.
2 select inbox
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags permitted.
 
* 1 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1217314075] UIDs valid
 
* OK [UIDNEXT 15] Predicted next UID
2 OK [READ-WRITE] Select completed.
 
3 list "" *
* LIST (\HasNoChildren) "." "Drafts"
* LIST (\HasNoChildren) "." "Sent"
* LIST (\HasNoChildren) "." "Trash"
* LIST (\HasNoChildren) "." "INBOX"
 
3 OK List completed.

Si cela fonctionne, vous pouvez essayer avec un vrai client (Thunderbird, Mail.app, Claws Mail, Outlook). Sinon, il faut aller voir d’où vient le problème dans les logs sous /var/log et mieux vaut lire et relire les documentations (voir ci-dessous).

En complément :

• Première partie : Serveur de messagerie simple avec Postfix et Dovecot
• Deuxième partie : Postfix SASL avec Dovecot
• Troisième partie : Ajouter le support TLS à Postfix
• http://www.postfix.org/
• http://www.dovecot.org/
• lairdutemps.org

Les bases de cet article à l’origine pour Arch Linux datent du 29 juillet 2008, c’est une sorte de re-publication un peu mise-à-jour pour Fedora et un transfert de Joomla vers WordPress.

Ce petit tutoriel est fait sur une distribution CentOS et c’est la procèdure de sauvegarde que j’utilise pour mon compte Gmail (Google Apps). La boite aux lettres de destination est de type Maildir, c’est-à-dire que chaque courrier est dans un fichier unique contrairement à Mbox qui place tous les courriers dans un fichier unique.

Installation de getmail

Choisissez votre gestionnaire de paquets préféré, pour les habitués des distributions à base de Red Hat, ce sera yum :

# yum install getmail

Création des répertoires

Le script ne crée pas par lui-même les répertoires et fichiers nécessaires au bon fonctionnement de getmail, il faut donc les ajouter à la main. On commence par l’arborescence de type Maildir qui accueillera les emails :

$ mkdir -p ~/Maildir/{new,tmp,cur}

Je ne m’attarde pas sur les trois répertoires cur, tmp et new, c’est l’arborescence de fonctionnement de Maildir. Ensuite, il faut créer le répertoire qui contiendra le fichier de configuration et les logs de getmail :

$ mkdir ~/.getmail
$ vim ~/.getmail/gmailrc
$ chmod -R 700 ~/.getmail

Configuration

Voici mon fichier de configuration pour sauvegarder un compte Google Apps en utilisant IMAP :

[retriever]
type = SimpleIMAPSSLRetriever
server = imap.gmail.com
mailboxes = ("[Gmail]/All Mail",)
username = nom@domaine.net
password = mot_de_passe
 
[destination]
type = Maildir
path = ~/Maildir/
 
[options]
# Mode verbeux
# 0 : n'affiche que les warnings et les erreurs
# 1 : affiche les notifications de récupération et de suppression de messages
# 2 : toutes les actions
verbose = 2
message_log = ~/.getmail/gmail.log
 
# ne récupére que les nouveaux messages
# idéal pour de la sauvegarde régulière
read_all = false
 
# n'altère pas les messages
delivered_to = false
received = false

Lancement du script

$ getmail -r ~/.getmail/gmailrc

Le script commence le rapatriement des messages et les place dans l’arborescence Maildir.

Note : Google n’autorise le transfert que d’un nombre limité de messages à la fois, si votre boite aux lettres est assez importante il faut relancer cette commande plusieurs fois, car seuls les nouveaux messages sont récupérés, ou alors le faire de façon automatisée (voir ci-dessous).

Automatisation

Afin d’automatiser cette sauvegarde, un job peut être ajouté dans le cron. L’option -q rend l’opération silentieuse, sauf pour les erreurs :

# Le script est lancé à la 7ème minute de chaque heure ^.^
7 * * * * /usr/bin/getmail -q -r /home/fabien/.getmail/getmailrc