J’ai enfin décidé d’héberger mon propre serveur Jabber, pour plusieurs raisons :

• la liste de mes contacts est mieux sur mon serveur que sur un autre ;
• le serveur que j’utilisais (jabber.fr) rencontre parfois quelques difficultés ;
• mon adresse Jabber sera ainsi la même que mon adresse mail (rom suivi de @rom1v.com).

Et c’est simple !

Installation et configuration

Tout d’abord, installer le paquet prosody :

apt-get install prosody

Puis ajouter à la fin du fichier /etc/prosody/prosody.cfg.lua :

Host "nom.de.domaine"

Pour moi :

Host "rom1v.com"

Créer un utilisateur en ligne de commandes et choisir un mot de passe :

prosodyctl adduser user@nom.de.domaine

Certificat

Un certificat TLS/SSL est créé par défaut, mais les champs sont renseignés avec des valeurs non pertinentes (localhost au lieu de nom.de.domaine par exemple). Il est donc préférable d’en générer un nouveau.

Dans le répertoire /etc/prosody/certs, exécuter :

openssl req -new -x509 -nodes -out nom.de.domaine.cert -keyout nom.de.domaine.key

Renseigner les champs demandés (« . » pour laisser un champ vide).

Remplacer le certificat dans le fichier de configuration :

ssl = {
        key = "/etc/prosody/certs/nom.de.domaine.key";
        certificate = "/etc/prosody/certs/nom.de.domaine.cert";
}

Empreinte

Comme c’est un certificat auto-signé, les clients Jabber ne lui feront pas confiance : ils demanderont une confirmation, en présentant son empreinte. Il faudra alors vérifier que le certificat présenté est bien le bon, c’est-à-dire que l’empreinte est la même.

Pour la connaître :

openssl x509 -fingerprint -noout -in nom.de.domaine.cert

Par exemple :

$ openssl x509 -fingerprint -noout -in rom1v.com.cert
SHA1 Fingerprint=C3:6D:9B:65:06:55:C4:84:B4:A5:8D:4B:12:68:2F:08:71:7E:AC:DD

Ports

Les ports TCP 5222 et 5269 doivent être ouverts.

Démarrer

Il ne reste plus qu’à démarrer le service.

service prosody start

Clients

Il est maintenant possible de se connecter en utilisant le nom d’utilisateur et le mot de passe créés :

Backup

Les données du serveur sont stockées dans /var/lib/prosody. Il est donc important de ne pas oublier ce répertoire dans le processus de sauvegarde.

Merci à Cyrille Borne et nicolargo.

Une fois connecté à un tel réseau, lorsqu’avec votre navigateur vous tentez d’accéder à n’importe quel site, vous êtes redirigé vers une page d’authentification demandant votre identifiant et votre mot de passe (parfois il ne s’agit que d’accepter des conditions d’utilisation). Après avoir renseigné ces informations, vous êtes authentifié et pouvez accéder à Internet normalement.

Mais il faut avouer que s’authentifier manuellement à chaque connexion est pénible. D’autant plus que la redirection HTTP vers la page d’authentification ne fonctionne… que pour HTTP. Ainsi, alors que vous êtes connecté au réseau Wifi, votre client mail ne parviendra à récupérer les mails, votre client XMPP n’arrivera pas à se connecter au serveur… mais sans message indiquant la cause du problème.

Le but de ce billet est de mettre en place une authentification automatique lors de la connexion au réseau.

Authentification en ligne de commande

La première étape est de pouvoir réaliser cette authentification en ligne de commande, à partir de l’identifiant et du mot de passe. C’est très simple, il suffit d’imiter ce que fait le navigateur lors du clic sur le bouton Valider.

Pour cela, deux choses sont nécessaires : l’URL de la page de validation d’authentification et les champs de formulaire qu’elle utilise.

Pour les connaître, il faut regarder le code source de la page sur laquelle vous êtes redirigés, en particulier la balise form. Voici un exemple de ce que vous pouvez obtenir (le HTML n’est pas toujours super propre sur ce genre de pages) :

<form method="post" action="http://10.9.0.1:8000/">
Login <input name="auth_user" type="text">
Password <input name="auth_pass" type="password">
<input type="checkbox" name="regagree" value="valeur" onClick="ChangeStatut(this.form)"> J'accepte le règlement
<input name="redirurl" type="hidden" value="http://www.google.com/search?ie=UTF-8">
<input type="submit" name="accept" value="Continuer" disabled>
</form>

Tout y est. La valeur de l’attribut action est l’URL de validation, et le nom des champs utilisés est dans l’attribut name de chaque balise input.

Dans cet exemple, seuls auth_user et auth_pass semblent utiles, mais parfois le serveur effectue des vérifications (étranges) supplémentaires. Ici, il vérifie qu’il y a bien un attribut accept qui vaut Continuer (allez savoir pourquoi).

À partir de ces champs, nous allons construire la chaîne des paramètres sous la forme :

champ1=valeur1&champ2=valeur2&champ3=valeur3

et l’envoyer au serveur en POST, par exemple grâce à la commande POST (en majuscules, ça surprend un peu pour une commande shell) :

POST http://10.9.0.1:8000/ <<< 'auth_user=IDENTIFIANT&auth_pass=MOT_DE_PASSE&accept=Continuer'

Si la page d’authentification est en HTTPS, il faudra installer le paquet libcrypt-ssleay-perl, ou alors utiliser wget :

wget -qO- https://10.9.0.1:8000/ --post-data='auth_user=IDENTIFIANT&auth_pass=MOT_DE_PASSE&accept=Continuer'

Voilà, nous avons reproduit en ligne de commande le comportement du navigateur pour l’authentification.
Nous devons maintenant faire en sorte que cette commande soit exécutée dès la connexion au réseau WiFi.

Exécuter un script lors de la connexion

NetworkManager (le gestionnaire de connexion par défaut d’Ubuntu) permet d’exécuter des scripts lors de la connexion ou la déconnexion. Pour cela, il suffit de placer le script dans /etc/NetworkManager/dispatcher.d/ et de le rendre exécutable.

Le script est appelé avec deux paramètres :

• $1 : l’interface réseau concernée par la connexion ou la déconnexion (wlan0 par exemple) ;
• $2 ayant pour valeur soit up (pour la connexion), soit down (pour la déconnection).

Nous voulons exécuter la commande POST uniquement lors de la connexion de wlan0, et seulement pour le réseau concerné (par exemple celui ayant le nom MonLieuDeVacances).

Il est possible de récupérer le nom du réseau (l’ESSID) auquel nous sommes connectés grâce à iwconfig :

iwconfig wlan0 | grep -o 'ESSID:".*$' | sed 's/^ESSID:"\(.*\)".*$/\1/'

Il faut donc créer un script dans /etc/NetworkManager/dispatcher.d/10auth :

gksudo gedit /etc/NetworkManager/dispatcher.d/10auth

ayant cette structure :

#!/bin/bash
if [ "$1 $2" = 'wlan0 up' ]
then
    essid=$(iwconfig wlan0 | grep -o 'ESSID:".*$' | sed 's/^ESSID:"\(.*\)".*$/\1/')
    case "$essid" in
        'MonLieuDeVacances')
            POST http://10.9.0.1:8000/ <<< 'auth_user=IDENTIFIANT&auth_pass=MOT_DE_PASSE&accept=Continuer' ;;
        'MaGare')
            POST http://192.168.0.1 <<< 'accept_cgu=1' ;;
    esac
fi

Et le rendre exécutable :

sudo chmod +x /etc/NetworkManager/dispatcher.d/10auth

Script pour FreeWifi

Les pages d’authentification varient d’un réseau à l’autre, il faut donc adapter les paramètres de connexion selon le service utilisé.

Voici le script à utiliser (en adaptant votre identifiant et votre mot de passe) pour le réseau FreeWifi (très connu) :

#!/bin/bash
if [ "$1 $2" = 'wlan0 up' ]
then
    essid=$(iwconfig wlan0 | grep -o 'ESSID:".*$' | sed 's/^ESSID:"\(.*\)".*$/\1/')
    case "$essid" in
        'FreeWifi')
            wget -qO- https://wifi.free.fr/Auth --post-data='login=IDENTIFIANT&password=MOT_DE_PASSE' ;;
    esac
fi

Tunnel SSH

Ces réseaux ouverts, gérant éventuellement une authentification HTTP, ne sont pas chiffrés : n’importe qui écoutant ce qui transite dans les airs pourra récupérer tout le contenu de votre trafic.
Si vous avez un ordinateur allumé chez vous (sur un réseau « sûr ») accessible en SSH, je vous conseille de faire passer toutes les connexions dans un tunnel chiffré.

Le principe est simple : dès que vous accédez à un serveur (par exemple en tapant l’URL dans un navigateur web), l’ordinateur ne va pas s’y connecter directement, il va transmettre les informations en passant par un tunnel chiffré à votre serveur SSH, qui lui va s’y connecter, et vous renvoyer la page à travers le tunnel. Techniquement, le tunnel est un proxy SOCKS écoutant sur un port local (par exemple localhost:3128).

Pour démarrer le tunnel :

ssh monserveur -CND3128

Pour configurer le système afin qu’il utilise le tunnel SSH, Système → Préférences → Serveur mandataire (gnome-network-properties), puis configurer comme sur la capture d’écran :

Dans l’onglet Hôtes à ignorer, rajouter l’adresse de la page d’authentification.

Ainsi, toutes les connexions des logiciels utilisant les paramètres proxy du système passeront par le tunnel. Il est également possible de configurer ceci dans chaque logiciel individuellement (s’ils le proposent).

Pour Firefox, il est également recommandé dans about:config de passer la variable network.proxy.socks_remote_dns à true, afin que les DNS soient résolus également de l’autre côté du tunnel (sur le réseau « sûr »).

Vous trouverez plus d’infos sur mon billet concernant SSH.

Conclusion

La connexion à des points d’accès WiFi publics demandant à chaque fois une authentification ou une acceptation des conditions d’utilisation devient rapidement insupportable. Il est donc appréciable de l’automatiser.

De plus, ces réseaux ne sont pas « sûrs », n’importe qui peut écouter le trafic. Il est donc nécessaire de le chiffrer en passant par un réseau de confiance, par exemple avec un tunnel SSH.

Lister les recherches

Si vous utilisez Apache, voici une commande qui liste dans l’ordre alphabétique les recherches Google ayant permis aux internautes d’arriver sur vos sites :

php -r "echo urldecode(\"`zgrep 'http://www\.google\.\w*/' /var/log/apache2/*|grep -o '[?&]q=[^&"]*'|cut -c4-`\");"|sort|uniq -c

EDIT 25/06/2011 : cette commande semble échouer lorsque la liste des recherches est trop longue, celle donnée à la fin du billet est donc à préférer.
(pour les autres moteurs de recherche, il faudrait s’inspirer de ce qu’ont fait les développeurs de Piwik)

Voici à quoi ressemble le résultat de la commande :

      1 ubtunu tiny tiny rss
      5 ubuntu
      1 ubuntu 10.04 change startup screen
      1 ubuntu 10.04 configurer compte messagerie hotmail dans couriel
      3 ubuntu 10.04 cryptage
      1 ubuntu 10.04 écran grub invisible au démarrage
      2 ubuntu 10.04 ecran noir nvidia
      1 ubuntu 10.04 et video nvidia
      1 ubuntu 10.04 grub nvidia
      1 ubuntu 10.04 grub-pc couleur
      4 ubuntu 10.04 installation partition home chiffrée

Le texte correspond aux recherches, le numéro devant indique le nombre de fois où elles ont été effectuées.

Analyse

Billets les plus recherchés

Sans conteste, les deux billets qui amènent le plus d’internautes par Google concernent pluzz et apk. Et parfois ça ne doit pas les aider beaucoup : certains recherchent par exemple « pluzz plus belle la vie » dans Google à partir d’Internet Explorer, je ne suis pas sûr que mon script shell pour pluzz réponde à leurs attentes.

Recherches insolites

Dans la liste, il y a forcément des recherches drôles ou étranges. En voici quelques unes que j’ai trouvées dans mes logs :

• « clitoris.apk » : il y a vraiment une application pour tout !
• « comment afficher 350 sous linux » : c’est si différent que sur les autres systèmes d’exploitation ?
• « comment on invente une machine pour voler à usage individuelle » : dérober ou s’envoler ?
• « du-ble-plein-les-poches es ce une arnaque » : sans doute…
• « est-il possible de prelever de l’argent sans que ça se voit sur le compte » : je veux rester discret…
• « l’ecran d’un ordinateur portable est de 14,1 pouce avec 1024*768 pixel quelle est la taille de l’ecran N*H en cm ? » : le moteur de recherche, j’en suis sûr, va comprendre ma question, faire le calcul, et me répondre…
• « logiciel adopy » : comme ça se prononce !
• « pour quel raison on doit interdire le zoo » : les animaux c’est dangereux !

Il y a certains sites qui s’amusent à référencer ce genre de recherches, par exemple Comment devenir un ninja gratuitement ?

N’hésitez pas à poster les vôtres…

Challenge

J’ai essayé d’écrire la commande la plus courte possible. Je n’ai pas réussi à faire moins de 129 caractères sans perdre d’information ou prendre plus de risque (par exemple on pourrait remplacer apache2 par a*2, mais c’est plus risqué).

Par contre, cette commande ne fonctionne pas correctement si l’on rajoute |less (on ne peut pas se déplacer avec haut et bas), je ne sais pas trop pourquoi ni comment le résoudre (si certains ont une idée).
Une autre commande, sans php (en 141 caractères), ne pose pas ce problème :

zgrep 'http://www\.google\.\w*/' /var/log/apache2/*|grep -o '[?&]q=[^&"]*'|cut -c4-|echo -e $(sed 's/$/\\n/;s/+/ /g;s/%/\\x/g')|sort|uniq -c

Si vous avez des astuces pour faire mieux que 129 (ou 141), ne vous gênez pas

Scripts

D’autres ont fait des scripts plus complets, qui permettent de récupérer des informations supplémentaires, par exemple la page sur laquelle l’internaute est arrivé en effectuant cette recherche…

Motivations

Pourquoi un serveur ?

Il existe de nombreux clients d’agrégateurs de flux, tels que Liferea sous Gnome ou NewsFox dans Firefox.

Cependant, un tel client pose principalement deux problèmes.

• Le premier, c’est le temps d’attente de mise à jour des flux. Lors du démarrage, les flux ne sont pas disponibles immédiatement : il faut patienter le temps qu’il mette à jour chacun des flux auxquels nous sommes abonnés, ce qui peux prendre plusieurs minutes.
• Le second, c’est la synchronisation : nous ne pouvons pas lire nos flux à plusieurs endroits (maison, travail, mobile…) en gardant la synchronisation (les flux que nous avons lu sont marqués comme lus sur un ordinateur, mais pas sur un autre).

Un gestionnaire de flux doit donc, d’après moi, forcément être hébergé sur un serveur.

Pourquoi son serveur ?

De nombreux services en ligne proposent la gestion de flux RSS (Google Reader, NetVibes, etc.).

Pourquoi donc héberger un tel service sur son propre serveur ?

• Par principe. Comme pour le blog ou les mails, autant auto-héberger son propre contenu, qui n’a rien à faire ailleurs.
• Filtrage en entreprise. Les agrégateurs de flux connus sont souvent bloqués par les proxies d’entreprise. Un service perso sur son propre serveur aura beaucoup moins de risque d’être filtré.
• Données personnelles. Les flux auxquels chacun est abonné et les articles lus sont une information importante pour quiconque souhaite renseigner un profil d’utilisateur. Par exemple, pour modifier les résultats d’un moteur de recherche (ou bien d’autres choses).
• Censure. Les flux RSS peuvent être une source d’information essentielle (c’est ma source d’information principale). Si nous en laissons la gestion à un hébergeur, comment nous assurer qu’il ne supprimera pas des flux les informations qui le dérangent ? Par exemple, s’il décide malencontreusement de supprimer tous les articles qui parlent de Wikileaks ? Je sais que ce n’est pas imaginable dans un pays démocratique.
  Mais regardons quand même (au hasard) l’exemple de Google, qui continue d’étendre l’auto-censure de son moteur de recherche, dans un pays exerçant des pressions politiques et commerciales pour retirer des contenus dérangeants hors de toute décision judiciaire (parfois en supprimant des entrées DNS, même pour un contenu légal dans le pays concerné), pressions auxquelles peu d’entreprises résistent, y compris lorsqu’il s’agit d’obtenir des informations politiques… et ils ne comptent pas s’arrêter en si bon chemin, pour lutter contre ce qu’ils appellent « piratage ». Mais non, censurer certains flux pour des raisons politiques est inimaginable dans un pays démocratique.

Installation

Je vais expliquer l’installation de Tiny Tiny RSS pour ma configuration, à savoir Ubuntu Server 11.04, avec Apache et MySQL.
Je vais l’installer dans ~/flux (le répertoire flux de mon home), avec un lien symbolique /var/www/flux. L’application sera accessible à partir de flux.rom1v.com. Adaptez ces valeurs selon vos besoins.

Dépendances

Tiny Tiny RSS a besoin de php5-curl :

sudo apt-get install php5-curl

Téléchargement

Télécharger la dernière version en bas de la page officielle (actuellement la 1.5.4).

Extraire l’archive dans ~/ :

tar xzf tt-rss-1.5.4.tar.gz

Et renommer le répertoire :

mv tt-rss-1.5.4 flux

Base de données

Il faut ensuite initialiser la base de données, grâce aux scripts fournis. Pour cela, aller dans le répertoire des scripts :

cd flux/schema

Puis se connecter à MySQL :

$ mysql -uroot -p
Enter password:

Une fois connecté, créer la base de données flux :

mysql> CREATE DATABASE flux;
Query OK, 1 row affected (0,00 sec)

Puis créer un utilisateur flux avec les droits sur cette base (on pourra générer son mot de passe grâce à pwgen) :

mysql> GRANT ALL PRIVILEGES ON flux.* TO flux@localhost IDENTIFIED BY 'unmotdepasse';
Query OK, 0 rows affected (0.04 sec)

Initialiser la base de données :

mysql> USE flux
Database changed

mysql> \. ttrss_schema_mysql.sql

La base de données est prête.

Configuration

Retourner dans le répertoire ~/flux :

cd ..

Copier le modèle du fichier de configuration :

cp config.php-dist config.php

Puis l’éditer, par exemple :

nano config.php

Modifier les informations de connexion à la base de données :

        define('DB_TYPE', "mysql");
        define('DB_HOST', "localhost");
        define('DB_USER', "flux");
        define('DB_NAME', "flux");
        define('DB_PASS', "unmotdepasse");

Modifier l’URL d’accès à l’application, pour moi :

        define('SELF_URL_PATH', 'http://flux.rom1v.com');

Désactiver le mode utilisateur unique (sans quoi l’accès à l’application sera public sans authentification) :

        define('SINGLE_USER_MODE', false);

Si Tiny Tiny RSS est installé à la racine du site (c’est mon cas : flux.rom1v.com/), il faut modifier le répertoire d’icônes, car /icons est réservé par Apache :

        define('ICONS_DIR', "tt-icons");
        define('ICONS_URL', "tt-icons");

Je conseille de désactiver la vérification des nouvelles versions, car lorsque le site de Tiny Tiny RSS ne répond plus, l’application rencontre des difficultés :

        define('CHECK_FOR_NEW_VERSION', false);

Pour les performances, activer la compression :

        define('ENABLE_GZIP_OUTPUT', true);

Enfin, une fois que la configuration est terminée, modifier la ligne :

        define('ISCONFIGURED', true);

Les modifications du fichier de configuration sont terminés.

Maintenant, renommer le répetoire icons (comme dans le fichier de configuration) :

mv icons tt-icons

Serveur web

Il faut maintenant héberger l’application sur Apache.

Tout d’abord, donner les droits à www-data sur les répertoires où il a besoin d’écrire :

sudo chown -R www-data: cache tt-icons lock

Puis faire un lien symbolique vers le répertoire /var/www/ :

sudo ln -s ~/flux /var/www/

Créer (au besoin) un nouveau VirtualHost pour le site, dans le répertoire /etc/apache2/sites-available (pour moi dans un fichier nommé flux.rom1v.com) :

<VirtualHost *:80>
	DocumentRoot	/var/www/flux
	ServerName	flux.rom1v.com

	<Directory /var/www/flux/>
		Options FollowSymLinks MultiViews
		AllowOverride All
		Order allow,deny
		allow from all
	</Directory>

	ErrorLog	/var/log/apache2/flux_error.log
	CustomLog	/var/log/apache2/flux_access.log combined

</VirtualHost>

Activer le site :

sudo a2ensite flux.rom1v.com

Redémarrer Apache (un simple reload aurait suffit si nous n’avions pas installé php5-curl tout à l’heure) :

sudo service apache2 restart

Configuration utilisateur

Compte utilisateur

L’application doit maintenant fonctionner. S’y connecter, avec l’utilisateur admin et le mot de passe password (l’utilisateur par défaut), puis aller dans la configuration et changer le mot de passe.

Importation et exportation

Tiny Tiny RSS permet l’importation et l’exportation d’un fichier OPML. Il est ainsi possible de migrer facilement d’un gestionnaire de flux à un autre.

Intégration à Firefox

Il est possible d’associer son instance de Tiny Tiny RSS à Firefox : toujours dans la configuration, dans l’onglet Flux, Intégration à Firefox, cliquer sur le bouton.

Pour tester, se rendre sur un site, et afficher la liste des flux disponibles. Pour cela, cliquer sur le petit icône à gauche de l’adresse, puis sur Plus d’informations…, sur l’onglet Flux (s’il y en a un), et enfin sur le flux désiré. Par exemple, pour ce blog :

En cliquant sur S’abonner maintenant, Firefox devrait proposer d’utiliser Tiny Tiny RSS.

Programmation de la mise à jour des flux

Il reste encore une étape importante : le serveur doit régulièrement mettre à jour le contenu de chacun des flux auxquels nous sommes abonnés.

Plusieurs méthodes sont décrites sur cette page. Certaines chargent les flux séquentiellement (par cron notamment), ce qui peut poser problème : supposons que nous soyons abonnés à 300 flux, avec une mise à jour toutes les 30 minutes, ça donne une moyenne de 6 secondes par flux. Si certains sites sont long à répondre, la mise à jour risque de dépasser le temps imparti, et cron va lancer une nouvelle tâche avant que la précédente soit terminée (heureusement Tiny Tiny RSS pose un verrou, donc il ne fera rien la seconde fois, mais du coup nous perdons une mise à jour). Ceci est d’autant plus dommage que l’essentiel de la durée nécessaire est le temps de connexion à chacun des sites : mieux vaut donc paralléliser le chargement.

C’est la raison pour laquelle je préfère la dernière méthode : lancer un démon multi-processus au démarrage du serveur. Par contre, étant donné le fonctionnement du démon proposé, il ne semble pas possible d’en faire un script init.d propre. Le plus simple est donc de rajouter dans /etc/rc.local :

start-stop-daemon -c www-data -Sbx /var/www/flux/update_daemon2.php

Vous pouvez exécuter cette commande maintenant pour charger les flux la première fois.

Ce démon utilise plusieurs processus (par défaut 2), qui mettent à jour les flux par blocs (par défaut, de 100). Pour changer ces variables (par exemple pour avoir 5 processus qui chargent des blocs de 50), dans config.php :

        define('DAEMON_FEED_LIMIT', 50);

et dans update_daemon2.php :

        define('MAX_JOBS', 5);

Autres interfaces

Une interface mobile en HTML est intégrée. Pour y accéder, il suffit d’ajouter à l’URL /mobile.

Pour Android, il existe également une application : ttrss-reader-fork (à tester, mais je la trouve assez buggée). Pour lui permettre l’accès, il est nécessaire de sélectionner « Activer les API externes » dans la page de configuration de Tiny Tiny RSS.

Conclusion

Vous n’avez plus de raison de laisser traîner vos flux RSS n’importe où

Je viens de migrer mon auto-hébergement vers cette nouvelle machine. Elle est très silencieuse (il n’y a pas de ventilateur) et consomme peu.

Je n’envisageais pas d’écrire un billet, mais l’installation d’Ubuntu Server 11.04 ne se déroule pas sans incidents :

Aucune interface réseau n’a été détectée

C’est le genre de problèmes qu’on espère un jour ne plus connaître lorsqu’on installe une distribution… Surtout lorsque ce problème en provoque d’autres… Ceci est donc un aide-mémoire qui me sera utile pour une future installation.

Installation

Tout d’abord, il faut ignorer le message d’erreur, tant pis, l’installation sera effectuée sans réseau.

Ensuite la section Choisir et installer des logiciels, il ne faut surtout pas activer Mail (postfix et dovecot) dans la liste : cela ferait planter le processus d’installation car il ne trouve pas d’interface réseau. En effet, dans /var/log/syslog, on trouve une erreur du genre :

postfix/sendmail: fatal: could not find any active network interfaces

On installera donc le serveur mail plus tard.

En suivant ces conseils, l’installation doit se dérouler correctement.

Récupération des pilotes

À partir d’un autre ordinateur, récupérer la dernière version des sources du pilote (j’en fait une copie chez moi, au cas où).

Ensuite, on est un peu embêté, car on devrait extraire les sources sur le serveur et exécuter sudo make install. Sauf que make n’est pas installé par défaut sur Ubuntu Server (merci Ubuntu !), et pour l’installer, il faut le réseau… qu’on aura une fois qu’on aura installé les pilotes…

Heureusement, on peut s’en sortir manuellement. Pour cela, sur un ordinateur qui possède make (avec le même noyau pour la même architecture), extraire les sources de l’archive dans un répertoire et exécuter :

tar xvjf jme-1.0.7.1.tbz2
cd jmebp-1.0.7.1
make

Cela crée un fichier jme.ko (je suis gentil, je vous donne le fichier déjà compilé pour le noyau 2.6.38-8-server en amd64). Le copier sur une clé USB.

Installation des pilotes

Ensuite, brancher la clé USB sur le serveur, et déterminer son emplacement (sous la forme /dev/sdX1). Pour cela, (une technique parmi d’autres) juste après l’avoir branchée, exécuter :

tail /var/log/syslog

La commande doit afficher plusieurs lignes ressemblant à ceci :

Jun  6 22:33:19 rom-server kernel: [1046971.365046] sd 12:0:0:0: [sdb] Attached SCSI removable disk

Ici, l’emplacement est donc /dev/sdb1.

Monter donc la clé :

sudo mount /dev/sdb1 /mnt

Puis installer le pilote compilé au bon endroit et l’activer :

sudo install -m 644 /mnt/jme.ko /lib/modules/$(uname -r)/kernel/drivers/net
sudo modprobe jme

Finaliser l’installation

Ajouter à la fin de /etc/network/interfaces :

auto eth0
iface eth0 inet dhcp

Et rebooter :

sudo reboot

Normalement, la carte devrait être détectée (on peut tester avec ifconfig).

Si tout est OK, on peut maintenant installer le serveur mail.

MPD est un lecteur audio libre un peu particulier : il fonctionne suivant le modèle client/serveur. Le serveur lit la musique, et les clients font office de télécommande (évoluée).

Typiquement, le serveur est installé sur une machine reliée aux enceintes du salon, et les clients sont installés sur chacun des ordinateurs et des téléphones (ainsi que sur le serveur lui-même s’il est relié à un écran).

Serveur

Installation

L’installation est extrêmement simple (testé sur Ubuntu 10.10), il suffit d’installer mpd :

sudo apt-get install mpd

Ensuite, il y a quelques petites lignes à modifier dans le fichier de configuration /etc/mpd.conf.
Tout d’abord, il faut définir le répertoire du serveur qui contient la musique :

music_directory                "/home/rom/Musique"

Il vaut mieux commenter la ligne bind_to_address (pour éviter pas mal de problèmes) :

#bind_to_address               "localhost"

Pour que MPD ne monopolise pas le son de tout le système, commenter la ligne :

#	device		"hw:0,0"	# optional

Enfin, pour pouvoir changer le volume, décommenter la ligne :

mixer_type                     "software"

Mise à jour de la base de données

La première fois, et à chaque fois que de nouveaux fichiers sont ajoutés au répertoire de musique, la base de données doit être mise à jour :

sudo mpd --create-db

(le serveur doit être stoppé pour mettre à jour la base de cette manière)

Des logiciels clients permettent également de mettre à jour la base d’un simple clic.

Vérifiez bien que les fichiers contenus dans ce répertoire sont bien lisibles par tous (en particulier par l’utilisateur mpd). Si ce n’est pas le cas, modifiez les droits avec :

chmod +r -R /home/rom/Musique

Démarrage et arrêt

Pour démarrer le serveur :

sudo service mpd start

Pour le stopper :

sudo service mpd stop

Il démarrera automatiquement à chaque démarrage du système.

Clients

Les clients permettent de gérer la lecture à distance. Il est possible d’ouvrir plusieurs clients à la fois (un sur l’ordinateur et un sur le téléphone par exemple) qui resteront synchronisés avec le serveur. La lecture ne s’arrête pas lors de la fermeture du client. Chaque client a juste besoin de l’IP du serveur et du port (par défaut 6600).

Il en existe de nombreux pour toutes les plateformes. Malheureusement, beaucoup ne sont pas stables et souffrent de problèmes d’ergonomie. Globalement, ils sont moins agréables à utiliser qu’un vrai lecteur de musique installé localement (mais les contraintes ne sont pas les mêmes).

Je vais en présenter deux, un pour Gnome et un pour Android.

Ario

Après avoir testé de nombreux clients pour PC, mon choix s’est porté sur Ario :

Quelques avantages qui m’ont convaincu :

• il est très bien intégré à Gnome (y compris avec le système de notifications utilisé par Ubuntu) ;
• il ressemble beaucoup à Rhythmbox dans son utilisation ;
• le double-clic sur un album peut être configuré pour remplacer la liste de lecture (plutôt que d’ajouter son contenu à la fin, sans le lire immédiatement), contrairement à de nombreux clients ;
• l’interface ne reste pas figée systématiquement lors d’une communication avec le serveur ;
• la base de données du serveur peut être mise à jour en un clic…

DMix/MPDroid

Du côté d’Android, il y a beaucoup moins de clients. J’ai choisi DMix/MPDroid (qui est un fork de PMix) :

C’est un simple fichier apk à installer.

Dans la bibliothèque, lors de la navigation dans la liste des albums, une pression longue ajoute l’album sélectionné à la liste de lecture alors qu’une pression courte permet de naviguer vers les titres de l’album (pour les ajouter un par un). Le fonctionnement est similaire pour la liste des artistes. C’est bon à savoir

Aller plus loin

Je me suis contenté ici de décrire les fonctionnalités de base de MPD qui me sont utiles. Mais il est également possible de le configurer en serveur de streaming, pour lire la musique du serveur sur un ordinateur ou un téléphone. OpenSyd en parle à la fin d’un récent billet.

Conclusion

Ce lecteur est vraiment très pratique pour une gestion centralisée de la musique chez soi, et permet de toujours lire la musique sur le système son du salon (plutôt que sur la sortie audio de l’ordinateur).

Un problème survient cependant dès qu’on veut y accéder sur HTTPS plutôt qu’HTTP : on ne peut pas seeker dans la vidéo (c’est-à-dire qu’on ne peut pas déplacer le curseur pour se positionner à n’importe quel endroit), et on ne connaît pas sa durée totale.

Quelle différence entre l’accès en HTTP et HTTPS?

En HTTP, on reçoit la taille du fichier vidéo :

$ curl --compressed -I http://.../video.ogv
HTTP/1.1 200 OK
Server: Apache
…
Content-Length: 26959501
Content-Type: video/ogg

En HTTPS, on ne la reçoit pas, car le flux est compressé en gzip.

$ curl --compressed -k -I https://.../video.ogv
HTTP/1.1 200 OK
Server: Apache
…
Content-Encoding: gzip
Content-Type: video/ogg

(-k permet d’autoriser l’utilisation d’un certificat SSL non reconnu)

C’est la source du problème. Pourquoi ce comportement différent par défaut entre HTTP et HTTPS, je n’en sais rien (si quelqu’un peut m’éclairer…).

Par contre, il est très facile de désactiver la compression pour certains types de fichiers, comme les images ou les vidéos (compression qui n’a de toute façon aucun intérêt ces fichiers sont déjà compressés).

Pour cela, il suffit de rajouter une ligne dans /etc/apache2/mods-available/deflate.conf :

SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png|ogg|oga|ogv)$ no-gzip dont-vary

et de recharger Apache :

sudo service apache reload

Et maintenant, ça fonctionne correctement sur HTTPS :

$ curl --compressed -k -I https://.../video.ogv
HTTP/1.1 200 OK
Server: Apache
…
Content-Length: 26959501
Content-Type: video/ogg

Pour mon serveur mail (et plus généralement pour les outils que j’utilise), j’essaie de mettre en place uniquement ce dont j’ai besoin. Et jusqu’ici, je n’avais pas l’utilité d’un anti-spams, ne recevant aucun courrier indésirable. Mais depuis peu, j’en reçois un de temps en temps… C’est donc l’occasion de m’y mettre.

Installation et configuration

Il existe plusieurs méthodes, j’ai choisi la plus simple : c’est procmail qui fournit les mails à SpamAssassin.

Il faut tout d’abord installer et configurer procmail, puis installer le paquet spamassassin :

sudo apt-get install spamassassin

Ensuite, rajouter dans ~/.procmailrc la règle suivante (copiée de la doc) :

# Pipe the mail through spamassassin (replace 'spamassassin' with 'spamc'
# if you use the spamc/spamd combination)
#
# The condition line ensures that only messages smaller than 250 kB
# (250 * 1024 = 256000 bytes) are processed by SpamAssassin. Most spam
# isn't bigger than a few k and working with big messages can bring
# SpamAssassin to its knees.
#
# The lock file ensures that only 1 spamassassin invocation happens
# at 1 time, to keep the load down.
#
:0fw: spamassassin.lock
* < 256000
| spamassassin

Enfin, éditer /etc/spamassassin/local.cf.

Pour uniquement ajouter les en-têtes de spam (ce qui est suffisant pour filtrer), il faut changer la valeur de report_safe :

report_safe 0

Pour ajouter un tag dans le sujet d’un mail considéré comme un spam :

rewrite_header Subject *****SPAM*****

Il est également possible de configurer le score requis pour qu’un mail soit considéré comme un spam. Plus cette valeur est faible, plus le filtre est agressif.
La valeur par défaut (5.0) est un peu faible, je vous conseille d’augmenter un peu si vous voulez limiter les faux-positifs :

required_score 6.0

Rajouter éventuellement les lignes suivantes :

# Langues attendues (les autres auront un score plus élevé)
ok_languages fr

# Rapports en français
lang fr

Pour ajouter un expéditeur en liste blanche, rajouter :

whitelist_from any@mail.com

Test

Pour tester, le plus simple est de mettre un filtre très sévère, par exemple avec un score négatif :

required_score -2

En m’envoyant un mail à moi-même qui contient comme sujet test, je constate à la réception que les en-têtes ont été modifiés :

Subject: *****SPAM***** test
Date: Thu, 25 Mar 2010 21:19:52 +0100
Message-Id: <1269548392.9798.9.camel@rom-laptop>
X-Spam-Flag: YES
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rom-eeebox
X-Spam-Level: ***
X-Spam-Status: Yes, score=3.9 required=-2.0 tests=ALL_TRUSTED,

Le mail a bien été détecté comme un spam. Ça fonctionne.

Filtrage

Maintenant que les spams sont détectés, il faut les traiter (les déplacer dans un dossier prévu à cet effet).

Il suffit pour cela de créer un dossier sur le serveur :

maildirmake.dovecot ~/Maildir/.Spams

et d’ajouter la règle suivante dans ~/.procmailrc (plus d’infos) :

:0
* ^X-Spam-Status: Yes
.Spams/

Conclusion

Les spams auront maintenant un peu plus de mal à se glisser dans ma boîte mail.

La configuration présentée ici est vraiment minimale. Selon son efficacité il faudra peut-être l’affiner.

Voir aussi

Mes précédents billets sur l’auto-hébergement des mails :
Hébergez vos mails sur Ubuntu Server (et libérez-vous)
Installer un webmail (RoundCube) sur Ubuntu Server
Ajouter l’authentification SMTP sur un serveur mail
Trier ses mails directement sur le serveur (procmail)

Dans la continuité des articles consacrés à l’auto-hébergement des mails, je vais présenter quelque chose que je voulais mettre en place depuis un moment : le tri du courrier directement sur le serveur.

Introduction

Lorsqu’on est abonné à des mailing-lists ou qu’on reçoit des notifications de forums ou de blogs, il est inconcevable de garder tous ses mails dans un seul et même dossier, et impensable de les déplacer manuellement (à moins de passer 30 minutes par jour à les trier). Un tri doit être mis en place automatiquement, en se basant sur les en-têtes des mails reçus.

J’utilisais jusqu’à maintenant les filtres de messages de mon client mail, Evolution, mais ça n’était pas forcément approprié :

• d’une part c’est très long avec un compte IMAP (les dossiers étant gérés côté serveur), car le client doit récupérer localement les nouveaux messages du serveur et les analyser ; s’il faut en déplacer un, il doit demander au serveur de le copier de la boîte de réception vers le dossier destination adéquat, puis demander de le supprimer de la boîte de réception, et enfin récupérer le messages déplacé… Rien que ça !
• d’autre part, lorsqu’on accède à ses mails à partir de plusieurs endroits (par exemple le client mail, le webmail et le téléphone portable), il devient évident que ce ne peut pas être le rôle des clients de trier les messages…

C’est donc au serveur de placer les mails dans le bon dossier dès la réception. C’est ce que procmail permet de faire.

Les dossiers IMAP

Les dossiers IMAP sont des dossiers physiques contenus dans ~/Maildir (le répertoire des mails) qui respectent une structure particulière :

• leur nom commence par « . » (ce sont des dossiers cachés) et les sous-dossiers « logiques » sont séparés par des « . » (par exemple, si je veux un dossier a contenant un sous-dossier b, le répertoire physique sera ~/Maildir/.a.b) ;
• ils contiennent 3 sous-dossiers physiques : cur, new et tmp.

Pour les créer, il suffit d’utiliser maildirmake ou maildirmake.dovecot, à partir du répertoire ~/Maildir :

maildirmake.dovecot .forums.ubuntu-fr
maildirmake.dovecot .forums.developpez

pour obtenir l’arborescence suivante :

|-- .forums.developpez
|   |-- cur
|   |-- new
|   `-- tmp
`-- .forums.ubuntu-fr
    |-- cur
    |-- new
    `-- tmp

Il est également possible de les créer graphiquement grâce à un client mail.

Configuration de postfix

Il faut indiquer à postfix que procmail va s’occuper de trier les mails, en lui précisant dans /etc/postfix/main.cf :

mailbox_command = /usr/bin/procmail

Il faudra ensuite recharger la configuration :

sudo /etc/init.d/postfix reload

Définir les règles de tri

Tout se passe dans le fichier (à créer) ~/.procmailrc, qui contient deux parties : la définition des variables et la définition des « recettes » (les règles de tri).

Les variables

Pour les variables, copiez simplement ceci (en décommentant les 2 premières lignes si vous voulez des logs).

#VERBOSE=yes
#LOGFILE=.procmail.log
SHELL=/bin/sh
PATH=/bin:/usr/bin:/usr/local/bin
MAILDIR=Maildir/
DEFAULT=./

Les recettes

Les recettes sont écrites sous la forme suivante :

:0 [drapeaux] [ : [verrou_local] ]
<zéro ou plusieurs conditions (une par ligne)>
<exactement une ligne d'action>

Les conditions commencent toutes par « * », suivie d’une expression régulière. Pour qu’une recette exécute l’action définie, il faut que le mail en question valide toutes les conditions.

Pour faire simple, nous allons simplement créer des règles qui déplacent des mails dans des dossiers. Pour définir une telle action, il suffit d’écrire le nom du dossier, en terminant la ligne par / (très important, cette convention indique à procmail que le dossier est au format maildir).

Un exemple étant plus parlant, voici une règle qui déplace toutes mes notifications de blog dans un dossier blog :

:0
* ^From: .*<wordpress@blog\.rom1v\.com>$
.blog/

Cet autre exemple permet d’envoyer une copie des mails validant les conditions à des adresses e-mails spécifiées (je m’en sers pour transférer les messages vocaux de mon répondeur téléphonique sur plusieurs adresses) :

:0c
* ^From: telephonie\.freebox@freetelecom\.com$
! autre@email.com

Résultat

Au final, voici un extrait de mon fichier ~/.procmailrc (je n’ai pas mis toutes les règles, c’est juste pour donner quelques exemples) :

#VERBOSE=yes
#LOGFILE=.procmail.log
SHELL=/bin/sh
PATH=/bin:/usr/bin:/usr/local/bin
MAILDIR=Maildir/
DEFAULT=./

:0
* ^From: .*<wordpress@blog\.rom1v\.com>$
.blog/

:0
* ^Reply-To: .*<[0-9]+@bugs\.launchpad\.net>$
.bugs.launchpad/

:0
* ^From: .*<dev\.null@ubuntu-fr\.org>$
.forums.ubuntu-fr/

:0
* ^List-Id: <april\.april\.org>$
.ml.april/

Objectif

La configuration de postfix présentée dans mon premier billet limitait (dans un but de sécurité) l’envoi d’un mail à une personne distante qu’à partir du réseau local (ou une liste de réseaux prédéfinis). Cela est parfait lorsqu’on envoie toujours les mails de chez soi, avec au besoin la possibilité d’envoyer un mail de n’importe où grâce au webmail.

Mais l’utilisation du SMTP à distance devient utile lorsqu’on veut envoyer un mail à partir de chez un ami avec son client mail (plus pratique pour les pièces jointes par exemple), et cela devient carrément indispensable lorsqu’on veut écrire des mails à partir de son téléphone de n’importe où (sans IP fixe).

Ne plus restreindre l’utilisation du SMTP au réseau local implique évidemment de rajouter une couche d’authentification…

Je vais donc décrire comment mettre en place une authentification SMTP-AUTH « en clair » (bien sûr encapsulée dans une connexion chiffrée TLS, déjà configurée si vous avez suivi le premier tuto) qui correspond au login et mot de passe de l’utilisateur système. Il a été écrit pour une installation sur Ubuntu Server 9.10, il faudra donc peut-être l’adapter légèrement si vous utilisez autre chose.

Configuration de SASL

Il faut installer le paquet sasl2-bin :

sudo apt-get install sasl2-bin

et ajouter l’utilisateur postfix au groupe sasl :

sudo adduser postfix sasl

Ouvrez ensuite /etc/default/saslauthd, remplacez :

START=no

par :

START=yes

et remplacez la dernière ligne par :

OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd"

Démarrez le service :

sudo /etc/init.d/saslauthd start

Configuration de postfix

À la fin de /etc/postfix/main.cf, rajoutez :

# SASL
smtpd_sasl_auth_enable = yes
smtpd_recipient_restrictions = permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination

Dans ce même fichier, vous pouvez également supprimer le réseau 192.168.0.0/24 de la variable mynetworks (si vous l’aviez rajouté).

Créez le fichier /etc/postfix/sasl/smtpd.conf contenant :

pwcheck_method: saslauthd
mech_list: plain login

Rechargez la configuration de postfix :

sudo /etc/init.d/postfix reload

Voilà, tout est prêt.

Configuration du client mail

Dans votre client mail, indiquez que le serveur SMTP requiert une authentification, de type CLAIR (ou PLAIN), et précisez votre compte utilisateur à utiliser.

Il suffit d’aller dans le répertoire à partager et d’exécuter :

$ python -m SimpleHTTPServer
Serving HTTP on 0.0.0.0 port 8000 ...

Le répertoire sera chrooté et accessible sur http://localhost:8000.

Par défaut, le port 8000 est utilisé, mais on peut le changer :

$ python -m SimpleHTTPServer 1234
Serving HTTP on 0.0.0.0 port 1234 ...

Pour les ports inférieurs à 1024, il faut être root :

$ sudo python -m SimpleHTTPServer 80
Serving HTTP on 0.0.0.0 port 80 ...

Si le port correspondant est ouvert sur le routeur, il sera également accessible de l’extérieur. Pratique pour partager rapidement du contenu…

Il peut-être pratique, en plus de cela, d’accéder à ses mails par un webmail de n’importe où (notamment au travail, où il ne sera pas filtré comme celui de gmail ou de yahoo, puisque c’est un webmail perso).

Je profite de la réinstallation à neuf de mon serveur pour présenter l’installation de RoundCube, un webmail assez moderne, à installer sur LAMP (avec accès HTTPS) sur Ubuntu Server.

Voici ce que ça donne une fois installé :

Je partirai du principe que le webmail est sur la même machine que le serveur SMTP et que le répertoire ~/Maildir (contenant les mails), et qu’il sera le seul site hébergé en HTTPS sur le serveur.

Téléchargement

Tout d’abord, il faut télécharger l’archive sur le site de RoundCube (la version complète), et l’extraire dans un répertoire :

tar xzf roundcubemail-0.3.1.tar.gz

Il est plus pratique de le renommer :

mv roundcubemail-0.3.1 mail

Ensuite, il faut donner les droits au serveur d’écrire dans les répertoires temp et logs :

sudo chmod -R 777 mail/temp mail/logs

Enfin, faire un lien du répertoire d’installation de RoundCube (par exemple ~/mail) dans /var/www.

sudo ln -s ~/mail/ /var/www

Préparation de la base de données

Il faut créer une base de données qui sera utilisée par RoundCube, avec son propre utilisateur. Pour cela, démarrer mysql en tant qu’administrateur (le login et le mot de passe choisi lors de la configuration de mysql) :

$ mysql -uroot -p
Enter password:

Ensuite, créer une base de données :

mysql> CREATE DATABASE mail;
Query OK, 1 row affected (0,00 sec)

Puis un utilisateur mysql (par exemple mailuser/unmotdepasse) :

mysql> GRANT ALL PRIVILEGES ON mail.* TO mailuser@localhost IDENTIFIED BY 'unmotdepasse';
Query OK, 0 rows affected (0,00 sec)

Voilà, la base de données est prête à accueillir RoundCube.

Configuration d’Apache

Tout d’abord, il faut activer le mod ssl d’apache :

sudo a2enmod ssl

Et renseigner le champ date.timezone de php.ini :

sudo nano /etc/php5/apache2/php.ini

Remplacer la ligne :

;date.timezone =

par :

date.timezone = 'Europe/Paris'

Ensuite, il faut créer un VirtualHost qui décrit à Apache le site qu’il doit héberger (le nom du site sur lequel il répond en http, quels répertoires doivent être accessibles, etc.).

Voici un modèle (qui correspond à mon VirtualHost), qui permet :

• d’afficher le site contenu dans /var/www/mail lorsqu’une requête arrive sur le port 443 (https), c’est-à-dire quand je tape https://mail.rom1v.com dans un navigateur ;
• d’interdire l’accès aux répertoires config, temp et logs ;
• de rediriger automatiquement http://mail.rom1v.com vers https://mail.rom1v.com.

NameVirtualHost *:443

<VirtualHost *:80>
	ServerName	mail.rom1v.com
	Redirect	/ https://mail.rom1v.com/
</VirtualHost>

<VirtualHost *:443>
	DocumentRoot	/var/www/mail
	ServerName	mail.rom1v.com
	SSLEngine on
	SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem
	SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key

	<Directory /var/www/mail/>
		Options FollowSymLinks MultiViews
		AllowOverride All
		Order allow,deny
		allow from all
	</Directory>

	<Directory /var/www/mail/config>
		Options -FollowSymLinks
		AllowOverride None
	</Directory>

	<Directory /var/www/mail/temp>
		Options -FollowSymLinks
		AllowOverride None
	</Directory>

	<Directory /var/www/mail/logs>
		Options -FollowSymLinks
		AllowOverride None
		Order allow,deny
		Deny from all
	</Directory>

	ErrorLog	/var/log/apache2/mail_error.log
	CustomLog	/var/log/apache2/mail_access.log combined

</VirtualHost>

Ce fichier, une fois adapté à votre serveur, est à écrire dans /etc/apache2/sites-available/ (dans un fichier nommé comme votre site par exemple, mail.rom1v.com pour moi).

Il faut ensuite l’activer :

sudo a2ensite mail.rom1v.com

Et recharger Apache :

sudo /etc/init.d/apache2 reload

Configuration de RoundCube

Il ne reste plus qu’à aller sur http://votreserveur/installer avec un navigateur pour configurer RoundCube.

Bien sûr, lors de la première connexion, Firefox vous alerte car il ne connaît pas votre certificat SSL (qui est auto-signé), il suffit de lui indiquer que vous faites confiance à ce site (puisque c’est le vôtre) en ajoutant une exception.

L’étape 1 (Check environment) doit bien se passer (à part quelques modules optionnels que vous n’avez pas, ce n’est pas grave).

Pour l’étape 2 (Create config) :

• Choisir un product_name : le titre des pages souhaité ;
• Activer ip_check ;
• Désactiver enable_spellcheck (sinon tous vos mails seront envoyés à Google) ;
• Renseigner les données pour l’accès à la base de données (que nous avons créée tout à l’heure) ;
• Dans la partie IMAP, renseigner uniquement default_host à la valeur localhost ;
• Laissez par défaut le reste de la partie IMAP et la partie SMTP (vu que les mails sont sur la même machine).

Lors de la validation, deux fichiers sont générés. Il faut les télécharger et les placer dans le répertoire config/ (ce n’est pas très pratique d’ailleurs, lorsqu’on accède au serveur par ssh, devoir télécharger les fichiers localement pour les renvoyer au serveur est un peu tordu).

L’étape 3 (Test config) permet de tester que tout est OK. Il faut cliquer sur Initialize database.

Une fois ces étapes effectuées, rendez-vous sur l’adresse du webmail, vérifiez que ça fonctionne (avec votre login système et votre mot de passe). Si tout est ok, supprimez le répertoire installer/ :

rm -rf /var/www/mail/installer

Modifier les préférences

Une fois connecté, il est possible de changer les préférences utilisateur. Je vous laisse découvrir les options par vous-même, mais certaines sont importantes.

Tout d’abord, dans l’onglet identités, renseignez votre adresse mail (par défaut c’est login@localhost, ce qui posera des problèmes à ceux qui voudront vous répondre).

Ensuite, activez les options qui concernent la suppression d’un message sur un compte IMAP dans Préférences du serveur de l’onglet Préférences :

• Mettre le drapeau de suppression au lieu de supprimer (sinon vous ne pourrez pas supprimer de messages) ;
• Ne pas montrer les messages supprimés (sinon vous les verrez encore en barré)

Conclusion

Bravo. Vous avez maintenant un serveur mail perso avec un accès webmail sur HTTPS en plus de votre accès IMAP/TLS. Vous gagnez 1 point de liberté et 1 point de confort.

Après avoir acheté un petit serveur pour y héberger ce dont j’avais besoin, mon objectif est d’héberger TOUT ce qui n’a rien à faire ailleurs. Et comme l’explique Benjamin Bayart dans sa désormais célèbre conférence Internet libre ou Minitel 2.0, toutes nos données personnelles entrent dans cette catégorie.

Mon blog est un bon exemple d’un contenu qui ne doit pas être hébergé ailleurs. La liste des flux RSS que je consulte aussi (c’est pourquoi j’ai installé tt-rss). Mon album photos à partager avec la famille également (j’ai installé gallery). Mais il restait le plus important : les mails.

Et c’est bien moins compliqué à installer que je ne l’imaginais !

Je vais donc présenter comment installer son propre serveur de mails sur Ubuntu Server (si vous utilisez autre chose, ça ne devrait pas être bien dur à adapter). Ainsi, vous pourrez avoir une jolie adresse login@mondomaine.

Prérequis

Je supposerai que vous avez déjà un nom de domaine et que vous savez ajouter des enregistrements A et MX (généralement dans l’interface fournie par votre registrar).

Présentation

Pour mettre en place un serveur mail complet, nous avons besoin de deux choses : un serveur SMTP (qui gère le transport du courrier) et un serveur IMAP ou POP3 (permettant de se connecter à sa boîte aux lettres).

J’ai choisi respectivement postfix et dovecot (ceux par défaut dans Ubuntu Server).

Il est possible de faire tout un tas de choses compliquées, ici je vais aller au plus simple. Au final on obtiendra donc un compte mail par utilisateur système (avec son mot de passe système), un serveur SMTP et un accès IMAP, le tout sécurisé sur TLS. Le serveur SMTP ne pourra relayer les mails envoyés qu’à partir du réseau local.

Configuration DNS

Rajoutez deux records de type A à votre fichier de zones DNS (smtp et imap – histoire de faire comme tout le monde, mais vous mettez ce que vous voulez –), et ajoutez un record de type MX qui pointe vers votre enregistrement smtp (smtp.rom1v.com. – n’oubliez pas le . à la fin –).

Il faut bien sûr ouvrir les ports sur le routeur et dans le pare-feu…
Pour rappel :

• SMTP = 25
• POP = 110
• POP3S = 995
• IMAP = 143
• IMAPS = 993

Serveur

postfix

Si vous n’avez pas déjà les paquets installés :

sudo apt-get install postfix dovecot-imapd

Si vous aviez déjà postfix :

sudo dpkg-reconfigure postfix

Vous obtenez un écran de configuration debconf qui va vous prendre par la main pour la configuration :

1. Configuration type du serveur de messagerie : Site Internet
2. Nom de courrier : votre nom de domaine (rom1v.com pour moi)
3. Destinataire des courriels de « root » et de « postmaster » : votre login sur le serveur (rom pour moi)
4. Autres destinations pour lesquelles le courrier sera accepté : rajoutez votre nom de domaine dans la liste (rom1v.com)
5. Forcer des mises à jour synchronisées de la file d’attente des courriels : non (laisser par défaut)
6. Réseaux internes : 127.0.0.0/8, 192.168.0.0/24 si votre réseau local est 192.168.0.x
7. Utiliser procmail pour la distribution locale : non (allons au plus simple)
8. Taille maximale des boîtes aux lettres (en octets) : à vous de choisir, moi j’ai mis 5Gio (5368709120) (les créateurs de logiciels qui proposent 50Mio ne doivent pas recevoir des mails de gens n’y connaissant rien qui envoient en triple des photos en 10 mégapixels)
9. Caractère d’extension pour les adresse locales : + (laisser par défaut)
10. Protocoles internet à utiliser : all

Vous avez alors un fichier /etc/postfix/main.cf qui ressemble à ceci (sauf la dernière ligne) :

myhostname = rom1v.com
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
mydestination = rom1v.com, rom-eeebox, localhost.localdomain, localhost
relayhost =
mynetworks = 127.0.0.0/8, 192.168.0.0/24
mailbox_size_limit = 5368709120
recipient_delimiter = +
inet_interfaces = all
myorigin = /etc/mailname
inet_protocols = all
home_mailbox = Maildir/

Ajoutez donc la dernière ligne (c’est très important pour faire fonctionner IMAP).

Par défaut, les mails sont limités à 10Mio (ce qui paraît normal). Cependant, il arrive toujours que quelqu’un dans votre entourage vous envoie 10 photos de 3Mio chacune. Pour cela il faut ajouter dans /etc/postfix/main.cf la ligne suivante (pour 50Mio) :

message_size_limit = 52428800

Voilà, le serveur SMTP est prêt :

sudo /etc/init.d/postfix restart

Il ne sera possible d’envoyer un mail qu’à partir des réseaux définis dans mynetworks (c’est pour cela qu’il n’y a pas d’authentification par défaut).

Pour mettre en place une authentification plutôt que de limiter l’accès à une liste de réseaux, lisez ce billet.

dovecot

Il y a deux choses à changer dans le fichier /etc/dovecot/dovecot.conf, tout d’abord pour activer le protocole IMAP :

protocols = imap

Ensuite pour choisir le répertoire de stockage des mails pour les utilisateurs (forcément ~/Maildir) :

mail_location = maildir:~/Maildir

Enfin, il faut préparer ce répertoire en exécutant la commande :

maildirmake.dovecot ~/Maildir

Voilà, c’est fini :

sudo /etc/init.d/dovecot restart

Client

Le serveur est configuré, nous pouvons maintenant l’utiliser.

mailtutils

Commençons par le tester grâce au paquet mailutils qui permet d’envoyer des mails en ligne de commande :

sudo apt-get install mailutils

Directement sur le serveur :

$ mail login@mondomaine
Cc:
Subject: Mon premier serveur
Ça y'est, j'ai configuré mon premier serveur !

(terminer avec une nouvelle ligne suivi de Ctrl+D)
Le mail a dû arriver dans ~/Maildir/new.

Un vrai client

Comme pour n’importe quelle adresse e-mail, il suffit de configurer le client (Evolution par exemple) en renseignant les champs demandés.

Réception

Type de serveur : IMAP
Serveur : imap.rom1v.com (à adapter avec votre nom de domaine)
Nom d’utilisateur : votre login sur le serveur
Sécurité : Chiffrement TLS
Type d’authentification : Mot de passe

Envoi

Type de serveur : SMTP
Serveur : smtp.rom1v.com (à adapter avec votre nom de domaine)
Nom d’utilisateur : votre login sur le serveur
Sécurité : Chiffrement TLS
Pas d’authentification.

Sauvegardes

Bien entendu, maintenant que vous hébergez vos mails, vous êtes responsables de leur stockage, et donc des backups. Mais j’imagine que cela ne vous posera pas de problèmes, car vous avez bien évidemment déjà mis en place un système (au moins rsync) qui sauvegarde vos données sur une autre machine : il suffira donc de rajouter le répertoire ~/Mailbox à la liste des répertoires sauvegardés.

Disponibilité

Si le serveur est déconnecté moins de 48 heures, ce n’est pas catastrophique, les mails ne seront probablement pas perdus, la majorité des serveurs SMTP tentent de renvoyer le courrier après un échec. Évidemment, si le serveur est éteint durant un mois, il n’y a pas de magie : pas de serveur, pas de mails…

Conclusion

Cette étape est pour moi un pas de plus vers un internet libre…

J’ai présenté le minimum vital, mais vous pouvez trouver des fonctionnalités à mettre en place (un webmail tel que RoundCube, un anti-spam, le tri des mails sur le serveur, une authentification SMTP…).

Amusez-vous bien !

Ce nouveau blog est 100% libre :

• il ne parle que de logiciels libres ;
• la machine qui l’héberge est une eee-box avec ubuntu server ;
• le serveur est lamp (apache, mysql, php) ;
• le moteur de blog est wordpress ;
• j’accède au serveur par open-ssh à partir d’une machine ubuntu ;
• vous le lisez dans firefox…

Les avantages :

• accès total (ssh, …) ;
• pas de restriction d’espace disque ;
• pas de problèmes de droits comme sur certains hébergeurs ;
• les hébergeurs de blogs « connus » sont bloqués par les entreprises ;
• wordpress est plus sympa à utiliser et plus complet que blogger…

Les inconvénients :

• c’est plus long à mettre en place qu’un blog sur blogger, et ça demande un peu plus de connaissances ;
• il faut avoir un serveur (j’ai acheté mon eee-box 229€) allumé 24h/24 ;
• il faut acheter un nom de domaine (j’ai acheté le mien 15€/an chez gandi) ;
• il faut gérer les mises à jour et les backups soi-même…

Pour les backups, si ça peut vous servir, voici mon petit script que je lance à partir de mon pc fixe :

#!/bin/sh
now=$(date +'%Y%m%d-%H%M%S')
target="/tmp/wordpress_$now.sql.gz"
echo "Connecting to database..."
ssh -t rom-eeebox "mysqldump -u root -p wordpress | gzip > $target"
scp rom-eeebox:"$target" /media/gnu/backup/rom-eeebox
rdiff-backup rom-eeebox::/home/rom/blog /media/gnu/backup/rom-eeebox/blog

Il met le contenu de la base dans une archive, la transfert sur le pc fixe, puis fait un backup incrémental de tout le répertoire /var/www/blog (tout en gardant les anciennes versions, c’est l’intérêt de rdiff-backup sur rsync).