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/

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/virtual
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

Cette article explique comment mettre en place un dépôt SVN pour les fichiers d’un site web. Le tutoriel est assez global, mais pour information il a été réalisé sur une Fedora 14.

Fonctionnement

Voici briévement comment fonctionne SVN. C’est un système de fichiers virtuels, on ajoute, édite, supprime des fichiers ou répertoires comme dans un système de fichiers traditionnel, mais tout se passe en interne, les différentes révisions des fichiers ne sont pas vraiment physiquement présentes. Pour mettre en pratique ce tutoriel, nous allons tout d’abord créer un dépôt (repository) où toute la gestion sera faite. Puis, dans un second temps nous allons importer un projet existant pour qu’il soit géré par SVN et c’est après que la magie s’opère ^.^

Création d’un dépôt local

Subversion possède deux commandes principales, l’une d’administration svnadmin et la commande de gestion svn. Pour créer un nouveau dépôt svn_projet, nous utilisons la première :

$ svnadmin create --fs-type fsfs /chemin/depot/svn_projet

Un nouveau dossier svn_projet est crée, voici son contenu :

$ ls -l svn_projet/
total 368
drwxr-xr-x  2 fabien subversion   4096 Apr  8 11:52 conf
drwxr-sr-x  6 fabien subversion   4096 Apr  8 11:52 db
-r--r--r--  1 fabien subversion      2 Apr  8 11:52 format
drwxr-xr-x  2 fabien subversion   4096 Apr  8 11:52 hooks
drwxr-xr-x  2 fabien subversion   4096 Apr  8 11:52 locks
-rw-r--r--  1 fabien subversion    229 Apr  8 11:52 README.txt

Il est rare d’aller voir les fichiers à l’intérieur du dépôt et il n’est pas recommandé d’y toucher. Voyons les informations sur notre nouveau dépôt :

$ svn info file:///chemin/depot/svn_projet/
Path: svn_projet
URL: file:///chemin/depot/svn_projet
Repository Root: file:///chemin/depot/svn_projet
Repository UUID: d9d451c0-72b9-4830-93bf-3f8829278afe
Revision: 0
Node Kind: directory
Last Changed Rev: 0
Last Changed Date: 2011-04-08 11:52:00 +0200 (Fri, 08 Apr 2011)

On peut voir que la syntaxe pour interroger ce dépôt commence par file:// pour une gestion locale. Ceci pourrait etre remplacé par http://, ssh://, svn:// ou svn+ssh:// pour un dépôt distant. Pour l’exemple, nous partons avec un projet tout simple composé d’un fichier index.html et d’un fichier style.css dans un répertoire css :

$ tree -a /chemin/projet/web
/chemin/projet/web/
├── css
│   └── style.css
└── index.html
 
1 directory, 2 files

Nous allons maintenant importer les fichiers non encore gérés par SVN dans le dépôt, ceci se fait avec la commande svn import. Je ne vais pas m’attarder là-dessus, mais par convention, il est bon de créer 3 répertoires dans notre dépôt : trunk, tags et branches. Le premier sera les fichiers du projet les plus récents, il s’agit de la version de travail la plus actuelle. tags contiendra en général les versions historisés (version 1, version 2, etc) et branches représente des dérivations dans le temps de l’évolution des éléments.
Assez de blabla, importons!

$ cd projet
$ svn import /chemin/projet/web file:///chemin/depot/svn_projet/trunk -m 'Initial import.'
Adding         web/css
Adding         web/css/style.css
Adding         web/index.html
 
Committed revision 1.

Le projet est importé, celui-ci existe désormais dans le dépôt, il s’agit de la version, plus précisément de la révision 1 et un commentaire est ajouté dans le log avec l’option -m, sans cette option l’éditeur par défaut s’ouvrirait et il serait demandé d’écrire une petite bafouille, sans quoi, pas de commit. L’action commit permet de figer un numéro de révision et ainsi de pouvoir y revenir plus tard. Chaque commit incrémente le compteur.

Nous pouvons vérifier notre log :

$ svn log file:///chemin/depot/svn_projet
------------------------------------------------------------------------
r1 | amannf | 2011-04-15 15:10:46 +0200 (Fri, 15 Apr 2011) | 1 line
 
Initial import.
------------------------------------------------------------------------

A ce stade, il faut comprendre que notre site web est géré par SVN, une première révision existe belle et bien, il est donc possible de supprimer les anciens fichiers non historisés :

$ rm -rf /chemin/projet/web

On se retrouve sans rien… ou presque. Le site est connu de SVN mais nous n’avons plus de fichiers de travail, il faut alors les (re)créer avec l’option checkout de la commande svn, celle-ci permet d’extraire une version qui servira de base au futur développement.

$ mkdir /chemin/travail/web
$ cd /chemin/travail/web
$ svn checkout file:///chemin/depot/svn_projet /chemin/travail/web
A    trunk
A    trunk/css
A    trunk/css/style.css
A    trunk/index.html
Checked out revision 1.

D’accord, mais pourquoi à l’étape précèdente nous avons supprimé nos fichiers pour maintenant les rajouter, car il s’agit des mêmes.. Simplement parce que désormais cette copie va être gérée par SVN, nous pouvons d’ailleurs voir qu’il y a un répertoire .svn à la racine de chaque répertoire et sous-répertoire de notre copie de travail. Attention à ne jamais les supprimer, au risque de passer un précieux temps à remettre sur pieds un dépôt bancal.
Au passage, on peut de nouveau vérifier l’état du dépôt :

$ svn info file:///chemin/depot/svn_projet/
Path: svn_projet
URL: file:///chemin/depot/svn_projet
Repository Root: file:///chemin/depot/svn_projet
Repository UUID: d9d451c0-72b9-4830-93bf-3f8829278afe
Revision: 1
Node Kind: directory
Last Changed Author: amannf
Last Changed Rev: 1
Last Changed Date: 2011-04-08 12:52:00 +0200 (Fri, 08 Apr 2011)

Faire des modifications de structure

Nous allons ajouter un répertoire js contenant un fichier fonctions.js :

$ cd /chemin/travail/web
$ mkdir trunk/js
$ touch trunk/js/fonction.js

Le répertoire doit être pris en compte par le dépôt maintenant. Ceci ne vas pas faire un commit mais juste indiquer au dépôt la présence de ce nouveau dossier (et de ce qu’il contient) :

$ svn add trunk/js
A         trunk/js
A         trunk/js/fonction.js

Notre version a évolué avec ce nouveau répertoire js, il est temps de faire notre premier commit, c’est-à-dire d’incrémenter le numéro de révision de notre site web :

$ svn commit -m 'First commit.'
Adding         trunk/js
Adding         trunk/js/fonction.js
Transmitting file data ..
Committed revision 2.

Voilà, nous sommes passés en révision 2 ^.^ Le principe est le même avec la suppression de fichiers/répertoires, le mot clé est – je vous le donne en mille – delete, par example :

$ svn delete trunk/js/fonctions.js
D         trunk/js/fonction.js

Pour valider le changement :

$ svn commit -m 'Delete fonctions.js file.'
Deleting       trunk/js/fonction.js
 
Committed revision 3.

Et voilà la révision 3. Nous estimons que ceci va correspondre à notre première version officielle, fini la beta! C’est là qu’entre le principe des tags, nous allons créer un tags pour la version 1, c’est-à-dire faire une copie à ce stade, et le développement normal continuera sur le trunk. Vous avez saisi le système du trunk et des branches maintenant. Alors, dans l’ordre cela donne :

$ mkdir tags
$ svn add tags
A         tags
$ svn copy trunk/ tags/version_1.0
A         tags/version_1.0

Voilà, notre version 1.0 est historisée. Presque. Il manque le commit :

$ svn commit -m 'Tagged version 1.0.' tags/
Adding         tags
Adding         tags/version_1.0
Adding         tags/version_1.0/js
Deleting       tags/version_1.0/js/fonction.js
Adding         tags/version_1.0/test
 
Committed revision 4.

Petite vérification du log :

$ svn log file:///chemin/depot/svn_projet/
------------------------------------------------------------------------
r4 | amannf | 2011-04-15 15:57:49 +0200 (Fri, 15 Apr 2011) | 1 line
 
Tagged version 1.0.
------------------------------------------------------------------------
r3 | amannf | 2011-04-15 15:48:30 +0200 (Fri, 15 Apr 2011) | 1 line
 
Delete fonctions.js file.
------------------------------------------------------------------------
r2 | amannf | 2011-04-15 15:41:28 +0200 (Fri, 15 Apr 2011) | 1 line
 
First commit.
------------------------------------------------------------------------
r1 | amannf | 2011-04-15 15:10:46 +0200 (Fri, 15 Apr 2011) | 1 line
 
Initial import.
------------------------------------------------------------------------

Revenir sur une ancienne version

C’est bien beau de gérer les révisions de projets, mais encore faut-il pouvoir au besoin revenir sur une ancienne version. Rien de plus simple. Le plus difficile étant de savoir où revenir, d’où la nécessité de bien documenter ses commits (option -m). Dans notre cas, je veux revenir à la version avec le fichier fonctions.js avant sa suppression donc, d’après notre log du point précédent, on voit qu’il faut revenir en r1 :

$ svn co -r 1 file:///chemin/depot/svn_projet/trunk /nouveau/chemin/
A    css
A    css/style.css
A    index.html
Checked out revision 1.

La révision 1 est désormais accessible sous /nouveau/chemin.

Conclusion

Voici une introduction par la pratique de Subversion, certe un peu rapide, mais les grands principes sont là et cela permet de se lancer dans l’aventure.

Le module SSL devrait être installé par défaut, sinon il faut l’ajouter :

# yum -y install mod_ssl

Création de la clé

Pour accepter les requêtes SSL, Apache a besoin d’une clé pour le serveur et d’un certificat signé. Les noms de ces fichiers n’ayant pas d’importance, dans ce tutoriel, elles seront respectivement nommées server.key et server.crt. Un certificat personnel – gratuit – va ainsi être crée, pour une utilisation professionnelle, il faudrait préférer un certificat – payant – délivré par une autorité comme Verisign. La seule différence avec une clé faîte maison sera un avertissement par le navigateur lors de l’accès à une ressource SSL. La sécurité est la même, que le certificat soit signé par vous même ou par un organisme. La clé va être ajoutée sous /etc/pki/tls/certs :

# cd /etc/pki/tls/certs
# make server.key
umask 77 ; \
/usr/bin/openssl genrsa -des3 1024 > server.key
Generating RSA private key, 1024 bit long modulus
......................................................++++++
.............++++++
e is 65537 (0x10001)
Enter pass phrase: // Entrer une pass phrase
Verifying - Enter pass phrase: // Vérification

Il est ennuyeux de toujours saisir la pass phrase, elle est donc retirée de la clé privée :

# openssl rsa -in server.key -out server.key

Ajout du certificat

Pour la création du certificat, plusieurs renseignements vont être demandés afin d’être incorporés dans celui-ci, certaines informations sont toutefois facultatives :

# make server.csr
umask 77 ; \
/usr/bin/openssl req -utf8 -new -key server.key -out server.csr
 
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]: FR
State or Province Name (full name) [Berkshire]: Lorraine
Locality Name (eg, city) [Newbury]: Ramonchamp // Yes! ;}
Organization Name (eg, company) [My Company Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (eg, your server's hostname) []: mondomaine.net
Email Address []: nom@mondomaine.net
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Création du certificat pour une durée de 10 ans :

# openssl x509 -in server.csr -out server.crt -req -signkey server.key -days 3650
Signature ok
subject=/C=FR/ST=Lorraine/L=Ramonchamp/O=mondomaine/OU=mondomaine/CN=mondomaine.net/emailAddress=nom@mondomaine.net Getting Private key

On change les droits sur ces fichiers désormais importants avant de passer à la suite :

# chmod 400 server.*

Directives Apache

Il ne reste plus qu’à ajouter les directives Apache pour prendre en compte le SSL. Comme Fedora fait bien le boulot, ce travail est pré-mâché dans un fichier de configuration sous /etc/httpd/conf.d/ssl.conf. Il faut dé-commenter les lignes suivantes dans ce fichier :

DocumentRoot "/var/www/html" // Environ ligne 84
ServerName www.mondomaine.net:443 // Environ ligne 85
SSLCertificateFile /etc/pki/tls/certs/server.crt // Environ ligne 112
SSLCertificateKeyFile /etc/pki/tls/certs/server.key // Environ ligne 119

Redémarrage d’httpd :

# service httpd restart

C’est terminé, les pages peuvent désormais être accédées par https://www.mon-domaine.net/.

Forcer la consultation des pages en https

Ce qui peut être intéressant, c’est de forcer l’accès aux pages en https uniquement, pour faire ceci on va utiliser le mode rewrite. Ajouter ce qui suit au fichier httpd.conf (préfèrable) ou dans un fichier .htaccess :

RewriteEngine On
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^(.*)$  https://%{SERVER_NAME}/admin/? [R=301,L]

Après avoir redémarré Apache, on voit qu’en tapant http://www.mondonaine.net, on passe tout de suite en https://www.mondonaine.net ^.^

Installation et configuration

J’avais originellement écrit cet article pour Archlinux, donc pour cette distro, rTorrent est dans les dépôts, pacman l’installe donc sans soucis, ainsi que screen le multiplexeur de terminaux :

# pacman -S rtorrent screen

Pour du Fedora :

# yum install rtorrent screen

Ensuite, il va falloir structurer les quelques répertoires nécessaires à son bon fonctionnement. J’ai ainsi crée quatre répertoires dans mon home sous ~/bt : data, completed, watch et sessions, qui respectivement serviront à stocker les fichiers en cours de téléchargement, stocker les fichiers completement téléchargés, fournir un répertoire pour les fichiers .torrent que rtorrent scrutera régulièrement et un répertoire pour les sessions en cours :

# mkdir -p ~/bt/{data,sessions,watch,completed}

Il faut maintenant créer le fichier de configuration ~/.rtorrent.rc, voici le mien :

# Limite en upload et download
upload_rate = 30
download_rate = 6000
 
# Répertoire de destination des fichiers téléchargés et des sessions
directory = /home/fabien/bt/data/
session = /home/fabien/bt/sessions
 
# Ports utilisés et diverses options
port_range = 6881-6999
port_random = no
check_hash = yes
max_memory_usage = 268435456
encryption = allow_incoming,enable_retry,prefer_plaintext
 
# Répertoire de dépôt des fichiers .torrent
schedule = watch_directory,15,15,load_start=/home/fabien/bt/watch/*.torrent
schedule = tied_directory,15,15,start_tied=
schedule = untied_directory,15,15,stop_untied=
 
# Répertoire où déplacer les fichiers lorsqu'ils sont complets
system.method.set_key = event.download.finished,move_complete,"execute=mv, \
-u,$d.get_base_path=,/home/fabien/bt/completed ; \
d.set_directory=/home/fabien/bt/completed"
 
# On envoie un email pour prévenir qu'un fichier est téléchargé
system.method.set_key = event.download.finished,notify_me, \
"execute=/home/fabien/bin/rtorrent_mail.sh,$d.get_name="
 
# Ferme le torrent lorsque l'espace disque est minimal
schedule = low_diskspace,5,60,close_low_diskspace=100M
 
# Ratio de 1:1 pour les fichiers inferieurs à 500Mo, sinon ratio de 2:1
ratio.min.set=100
ratio.upload.set=200M
ratio.max.set=200

Je passe sur son explication, c’est assez explicite. Pour plus d’informations, se reporter à la documentation du site de rTorrent.

Pour aider au lancement du programme, voici un script bash lançant rTorrent dans un screen :

#!/bin/bash
screen -dmS rtorrent nice -n 15 rtorrent

Ce deuxième script permet de visualiser le déroulement de rTorrent (en ré-attachant le screen) :

#!/bin/bash
stty stop undef
stty start undef
screen -rd bt

En ce qui me concerne, mes scripts sont sous ~/bin, ne pas oublier de leur attribuer les droits en exécution :

$ chmod +x ~/bin/btlaunch ~/bin/btview

Et voici un script rc qui permet de gérer rTorrent à la sauce Archlinux et de le démarrer en tant que daemon avec la machine, rtorrent :

#!/bin/bash
 
. /etc/rc.conf
. /etc/rc.d/functions
 
case "$1" in
start)
stat_busy "Starting rtorrent"
su fabien -c 'screen -d -m -S bt rtorrent' &> /dev/null
if [ $? -gt 0 ]; then
stat_fail
else
add_daemon rtorrent
stat_done
fi
;;
stop)
stat_busy "Stopping rtorrent"
killall -w -s 2 /usr/bin/rtorrent &> /dev/null
if [ $? -gt 0 ]; then
stat_fail
else
rm_daemon rtorrent
stat_done
fi
;;
restart)
$0 stop
sleep 1
$0 start
;;
*)
echo "usage: $0 {start|stop|restart}"
esac
exit 0

Et enfin le petit bash d’envoi de l’email en fin de téléchargement, rtorrent_mail.sh :

#!/bin/bash
echo "$(date) : $1 - Download completed." | mail -s "[rtorrent] - Download completed : $1" mon@adresse.net

Lancement et utilisation

Voilà, c’est terminé, il ne reste plus qu’à lancer le daemon et accessoirement de visualiser l’état avec les scripts :

$ ~/bin/btlaunch.sh
$ ~/bin/btview.sh

Lancement/arrêt/re-démarrage avec la commande rc :

# /etc/rc.d/rtorrent start
# /etc/rc.d/rtorrent stop
# /etc/rc.d/rtorrent restart

Mais pour voir l’évolution, il faut bien entendu ajouter des torrents, pour se faire, copier simplement les fichiers .torrent dans le répertoire watch. Et vous verrez les téléchargements débuter. Ensuite l’utilisation se fait par quelques commandes, en voici quelques unes :

CTRL+d         Stoppe un torrent (ou supprime un torrent arrêté)
CTRL+q         Quitte rTorrent (ferme le screen)
CTRL+s         Démarre un torrent arrêté
CTRL+a puis d     Détache le screen (rTorrent tourne toujours)
a ou s ou d ou     Augmente l’upload de 1Kb/s ou 5Kb/s ou 50Kb/s
z ou x ou c     Réduit l’upload de 1Kb/s ou 5Kb/s ou 50Kb/s
A ou S ou D ou     Augmente le download de 1Kb/s ou 5Kb/s ou 50Kb/s
Z ou X ou C     Réduit le download de 1Kb/s ou 5Kb/s ou 50Kb/s

​

Cet article fut publié pour la première fois le 18 février 2008.

# mkdir /usr/home/toto/music
# mount_nullfs /dataraid/zfsdata/music /usr/home/toto/music

L’arborescence /dataraid/zfsdata/music est désormais aliasée et ainsi disponible dans le home de toto. La grosse différence entre ceci et un lien symbolique est que le chemin de cette nouvelle arborescence est réellement vu à l’endroit indiqué /usr/home/toto/music. Ainsi :

# cd /usr/home/toto/music/
# realpath .
/usr/home/alex/music
# stat .
134283012 107 drwxr-xr-x 342 fabien wheel 0 345 "Dec 22 03:01:29 2009" "Dec 19 17:00:43 2009" "Dec 19 17:00:43 2009" "Dec  9 20:32:31 2009" 4096 27 0 .

Le realpath retourne bien notre système de fichiers et non celui d’origine sous /dataraid/zfsdata/music. stat quant à lui nous indique qu’il s’agit bien d’un répertoire et non d’un lien symbolique.

Pour faire ce montage (en lecture-écriture) automatiquement au démarrage dans le fstab, ajouter cette ligne :

/dataraid/zfsdata/music    /usr/home/toto/music nullfs  rw      0       0