Bien que Mozilla soit sans doute respectueux de la vie privée, l’idée d’un serveur centralisé stockant mes données personnelles me dérange toujours. Puisque Mozilla permet d’utiliser un serveur Sync chez soi, profitant en pour garder nos marques pages à la maison. Tout en sécurisant les échanges via SSL.

Après 3 essais infructueux pour installer ce serveur « simple » d’installation, j’en ressors victorieux à la 4e tentative. Cette méthode d’installation, si elle n’est pas « simple », permet d’avoir un serveur Sync fonctionnel et sécurisé.

Tout d’abord, histoire de savoir de quoi on parle, rendons-nous chez Mozilla pour quelques explications sur le service.
Et, comme je n’ai rien inventé, voila la source principale de tout ce que je vais expliquer ici: le how-to de Mozilla.

A présent nous pouvons commencer.
Comme à l’habitude, nous allons supposer que nous disposons déjà d’un serveur apache fonctionnel exploitant SSL. (Sinon: Tutoriel apache.)

Je n’ai pas testé l’usage d’un certificat auto-signé, mais je pense que c’est possiblement problématique. Un retour serait utile.

Installation et compilation

Nous allons commencer par installer les paquets nécessaires:

sudo apt-get install python-virtualenv python-dev mercurial build-essential

Nous utiliseront ici mysql pour supporter la base de donnée, qui sera plus facile à manipuler lorsqu’il s’agira de gérer les utilisateurs.

sudo apt-get install libmysqlclient-dev mysql-server

En cas d’usage de sqlite (le choix par défaut), il faudra remplacer les paquets précédents par celui-ci. Toutefois, nous n’explorerons pas cette possibilité.

sudo apt-get install sqlite3

Les dépendances satisfaites, nous allons pouvoir commencer l’installation.
Il nous faut d’abord choisir le dossier dans lequel nous installerons le serveur Sync. Il est préférable à ce moment d’éviter d’utiliser un dossier situé après le .htaccess de votre site principal. Mieux vaut placer le serveur Sync à l’écart, afin d’éviter toute interférence.

Attention, après téléchargement, le dossier ne doit pas être déplacé sous peine de fausser les chemins enregistrés par mercurial.

On se place donc dans le dossier choisi, afin de télécharger les sources du serveur Sync à l’aide de mercurial.

hg clone https://hg.mozilla.org/services/server-full/ DOSSIER_SERVEUR_SYNC

hg clone créera lui-même le dossier DOSSIER_SERVEUR_SYNC.

Puis on se place dans le dossier, pour compiler le serveur.

cd DOSSIER_SERVEUR_SYNC
make build

Enfin, afin de permettre à python d’exploiter mysql, nous allons installer Mysql-Python.

bin/easy_install Mysql-Python

Sync utilisant un environnement python dédié, Mysql-Python sera installé à l’intérieur du dossier de Sync, dans DOSSIER_SERVEUR_SYNC/lib/python2.7/site-packages/
MySQL_python-1.2.4-py2.7-linux-i686.egg

Création de la base de donnée de Sync

Nous faisons le choix ici d’une base de donnée mysql. Mais il est possible également d’utiliser sqlite ou postgres.
Il est nettement préférable de créer un utilisateur avec un mot de passe généré aléatoirement qui aura accès uniquement à la base de donnée de Sync. Ceci afin d’éviter de corrompre d’autres bases de données si le mot de passe, inscrit en clair dans le fichier de config, venait à être connu.
Il y a 2 manière de créer la base de données et son utilisateur dédié.

En utilisant phpmyadmin:
Nous nous rendrons dans l’onglet Privilèges pour Ajouter un utilisateur. Après avoir nommé l’utilisateur et lui avoir donné un mot de passe, nous choisiront de Créer une base portant son nom et donner à cet utilisateur tous les privilèges sur cette base. Nous aurons ainsi une base de donnée au nom de son utilisateur.

En ligne de commande:

mysql -u root -p

mysql> CREATE DATABASE BDD_NAME;
mysql> GRANT ALL PRIVILEGES ON BDD_NAME.* TO USER@localhost  IDENTIFIED BY 'MOTDEPASSE';
mysql> quit

Configuration du serveur Sync

Le fichier de configuration de Sync est DOSSIER_SERVEUR_SYNC/etc/sync.conf
Nous allons modifier les lignes suivantes:

sqluri = mysql://USER:MOTDEPASSE@localhost/BDD_NAME

Cette ligne se présente à 3 reprises, qui doivent toute être modifiées et pointées sur la même base de données.
Celle-ci stockera les utilisateurs ainsi que les données synchronisées.

quota_size = 25120

Le quota par défaut est de seulement 5mo, ce qui pourrait être contraignant. Augmenter cette limite permettra de ne pas avoir de problèmes avec ça.

fallback_node = https://www.monsite.fr/sync/

C’est sans doute la principale source d’erreur de Sync, celle qui renvoi le plus souvent à l’erreur « URL invalide ».
Cette option indique au client à quelle adresse il doit se connecter. Il est important que cette adresse soit identique à celle utilisée pour contacter le serveur apache qui se placera devant Sync.

#allow_new_users = false

Cette ligne devra être décommentée dés lors que les utilisateurs désirés seront enregistrés. Sans quoi nous nous exposerons au risque de voir le serveur Sync squatté par n’importe qui.

use_ssl = false

Bien évidemment, on voit SSL, ça attire l’œil. Toutefois, ceci ne concerne que la connexion à reCaptcha. Dans notre cas, ça n’a pas d’importance.

Sync est à présent configuré.
Nous allons donc nous intéresser à la communication avec l’extérieur. Sync utilise un mini-serveur standalone écoutant sur le port 5000. Mais utiliser ce serveur tel quel nous obligerait à ouvrir le port 5000, ce qui nous couperait la possibilité de passer par SSL. Nous allons donc insérer apache entre Sync et l’extérieur.

Configuration d’apache en reverse-proxy

Bien qu’on pourrait se battre des heures sans succès avec wsgi pour substituer apache au serveur standalone de Sync, on va lui préférer un reverse-proxy efficace et rapide à mettre en place.

Nous allons donc préparer apache en lui ajoutant les 2 modules nécessaires, mod_proxy et mod_proxy_http.

sudo a2enmod proxy
sudo a2enmod proxy_http

Puis modifier le virtualhost du domaine en ajoutant, dans la section servant sous le port 443, les lignes suivantes:

#Reverse proxy pour le mini-server standalone de Firefox sync
        ProxyRequests Off
        <Proxy *monsite.fr/sync/*>
                Order deny,allow
                Allow from all
        </Proxy>
        ProxyPass /sync/ http://localhost:5000/
        ProxyPassReverse /sync/ http://localhost:5000/

Attention, si le proxy n’est pas servi sous SSL en 443 mais sur le port 80, il faut modifier en conséquence la ligne fallback_node du fichier DOSSIER_SERVEUR_SYNC/etc/sync.conf en retirant le s de https.

Voyons en détails les réglages du proxy:

ProxyRequests Off

Interdit l’usage du serveur en tant que proxy ouvert. Cela restera donc un proxy limité à l’usage fait ci-après.

<Proxy>

Limite la portée des commandes placées entres les balises au proxy.

ProxyPass

C’est LA fonction de reverse proxy, qui va rediriger la requête reçu par apache sur monsite.fr/sync/ vers le serveur sync, à localhost:5000.

ProxyPassReverse

Assure les redirections du serveur Sync placé derrière le proxy, en corrigeant les adresses renvoyés par ce dernier.

Ainsi configuré, apache renverra les connexions sur https://www.monsite.fr/sync/ vers http://localhost:5000/. Ainsi, les connexions entrantes seront contraintes au SSL sur 443 avant de contacter, en local, le serveur sync qui, lui, n’est pas sécurisé.

 

On peut dés à présent tester le fonctionnement du serveur Sync.
Nous allons commencer par redémarrer apache pour prendre en compte les modifications du virtualhost.

sudo /etc/init.d/apache2 restart

Et enfin démarrer le serveur Sync afin qu’il réponde aux requêtes renvoyées par apache.

bin/paster serve development.ini

A présent, il suffit de créer un compte à l’aide de Sync sur firefox, en choisissant ”Utiliser un serveur personnalisé” au lieu de ”serveur Mozilla Firefox Sync”. On indiquera alors https://www.monsite.fr/sync/

Si tout va bien, aucun message d’erreur n’est mentionné. Ce que l’ont peut également vérifier en se rendant sur about:sync-log.

Toutefois, le serveur Sync doit encore être démarré manuellement, ce qui est bien évidemment problématique pour un usage courant. Nous allons donc faire démarrer Sync comme un service afin qu’il soit automatiquement démarré avec la machine.

Démarrage automatique de Sync

L’ajout d’un programme au démarrage de la machine en tant que service passe par le programme upstart.
Nous allons donc commencer par écrire un script upstart pour Sync.
Cela se passe dans /etc/init.d/.

Pour simplifier, le script upstart peut-être téléchargé directement et copié à sa place. Script upstart fsync.

Nous allons copier le fichier skeleton avant de le modifier.

sudo cp /etc/init.d/skeleton /etc/init.d/fsync

Les lignes à éditer sont les suivantes:

# Short-Description: Serveur Sync de Firefox
# Description:       Serveur de synchronisation de marques-pages, etc, fourni par Mozilla,
#		     ayant pour but de remplacer le serveur centralisé de Mozilla.
[...]
# Author: Maniack Crudelis 
[...]
DESC="Serveur Sync de Firefox"
NAME=fsync
[...]
DAEMON_ARGS=""
[...]
start-stop-daemon --start --quiet --background --pidfile $PIDFILE --exec $DAEMON --test > /dev/null 
r
[...]
start-stop-daemon --start --quiet --background --pidfile $PIDFILE --exec $DAEMON -- 

Le script terminé, nous allons le rendre exécutable.

sudo chmod +x /etc/init.d/fsync

Cela fait, nous allons créer le raccourci fsync auquel nous faisons mention dans le script upstart.
Retour donc au dossier DOSSIER_SERVEUR_SYNC pour y créer un script bash qui se chargera de l’exécution du serveur Sync. Script nommé fsync.sh, contenant ces commandes:

#!/bin/sh
CHEMIN="/CHEMIN/DU/SERVEUR/SYNC/DOSSIER_SERVEUR_SYNC/"          
$CHEMIN/bin/paster serve $CHEMIN/development.ini

Script que nous allons rendre exécutable.

chmod +x fsync.sh

Cela étant, notre script upstart ne va pas chercher le script sh à sa place. Pour un résultat propre, nous allons créer un lien symbolique dans /usr/sbin pointant sur le script sh.

sudo ln -s /CHEMIN/DU/SERVEUR/SYNC/DOSSIER_SERVEUR_SYNC/fsync.sh /usr/sbin/fsync

Il suffit maintenant d’un
sudo /etc/init.d/fsync start pour lancer le serveur Sync. Pour qu’il soit démarré en tant que service, nous allons créer les raccourcis dans rcX.d

sudo update-rc.d fsync defaults 99

 

Il ne reste plus qu’à redémarrer la machine pour profiter du serveur de synchronisation Sync.
Sans oublier de décommenter allow_new_users = false afin d’interdire toute inscription à votre serveur Sync.

Lors d’un ajout ultérieur d’un nouvel utilisateur, le serveur sync (parfaitement bien codé…) répondra par un limpide « Erreur inconnue » si l’inscription de nouveaux utilisateurs n’est pas autorisé. De quoi s’arracher les cheveux pendant un moment, puisqu’aucun message ne l’indiquera dans les log. Il sera donc important de commenter allow_new_users = false ET de redémarrer le serveur sync.

Comments

  1. Noelle Joly on 07.31.2013

    Salut,

    Merci pour les infos, ça fonctionne. J’étais pas loin de la 10536ème tentative non plus 🙂

    Quelques remarques pour aider les suivants, ou bien pour mettre à jour le doc :

    >Il nous faut d’abord choisir le dossier dans lequel nous installerons
    >le serveur Sync. Il est préférable à ce moment d’éviter d’utiliser un
    >dossier situé après le .htaccess de votre site principal. Mieux vaut
    >placer le serveur Sync à l’écart, afin d’éviter toute interférence.

    Je ne trouve pas ça très clair : je dirai plutôt : « ne pas placer « server-full » dans un de vos DocumentRoot » – ceci dit, je peux me tromper.

    Il faudrait peut-être aussi préciser que l’action  »
    hg-clone » va créer un répertoire.

    Et qu’avant de faire le « make build », il faut aller dans le répertoire. D’ailleurs, une petite remarque du genre « make build va télécharger plein de choses mais c’est normal » ne ferait pas de tort.

    On peut aussi dire qu’il faut que la base de données soit créée avant. Logique, mais pas évident non plus 🙂

    Voilà, c’est superficiel, de toutes façons, puisqu’à la fin ça marche. Merci encore !

  2. Maniack Crudelis on 08.02.2013

    Merci de ton retour, c’est un plaisir de savoir que je ne suis pas devenu chauve uniquement pour que ça fonctionne chez moi.

    Tes remarques sont très judicieuses car à force de manipuler mon serveur j’en oublie que quand j’ai commencé, un tuto sans ces fameux détails que je n’ai pas indiqué m’aurait mené droit à un échec! Ça me semble aujourd’hui évident mais ça ne l’a pas toujours été, loin de là.

    Concernant le DocumentRoot, il me semble que c’est uniquement les règles d’URL rewriting du htaccess qui posent des problèmes. Si il n’y en a pas, ça ne devrait pas interférer avec le fonctionnement du serveur sync. D’où l’importance, à mon avis, de ne pas se focaliser sur le DocumentRoot mais bien sur les htaccess qui peuvent précéder l’emplacement de sync.

    En effet, hg-clone créer le répertoire, et je viens de voir qu’on pouvait aussi lui indiquer un autre nom de dossier directement. Intéressant, car il faut bien avouer que server-full n’est pas un nom très explicite…

    Je n’avais pas regardé ce que faisait make, je vérifie juste qu’il n’y ai pas d’erreur à la fin. Mais en effet il télécharge des scripts python en début de make. Mais, est-ce vraiment important de savoir qu’il télécharge des fichiers? (Ce n’est pas un reproche mais une véritable question.)

    Je vais corriger le tuto et y ajouter ces quelques informations.

Leave a Reply