Administration système

Installer un serveur Firefox Sync

Michael V.

• 6 min read
Installer un serveur Firefox Sync

Vous aimez utiliser les systèmes de synchronisation entre appareils de vos navigateurs préférés mais vous vous demandez où vont vos données ? Aujourd’hui, je vous propose d’installer votre propre serveur Firefox Sync.

L’avantage d’installer son propre serveur de synchronisation Firefox est d’avoir la certitude que vos données sont au chaud chez vous ou sur votre serveur et qu’ils ne sont pas dans les mains d’un géant du Web qui utilisera vos données pour X raison. De plus l’installation est très simple et sa mise en production ne demande que quelques minutes.

Installation

Dans un premier temps, on va installer tous les paquets nécessaires au bon fonctionnement de Firefox. Pour cela, on va installer cette suite de paquets :

apt-get install -y git git-core python-dev python-virtualenv build-essential sqlite3 nginx`

Si vous souhaitez utiliser une base de données MySQL à la place de SQLite, je vous invite à remplacer le paquet sqlite3 par mariadb-server ou mysql-server.

Vous aurez aussi besoin d’un serveur Web. Dans mon cas, j’utilise Nginx qui est excellent. A vous de choisir quel serveur Web vous souhaitez utiliser parmi apache2 ou nginx.

Ensuite, on va cloner le dépôt Git du serveur de synchronisation en tapant la commande suivante puis entrer dans le dossier :

git clone https://github.com/mozilla-services/syncserver
cd syncserver

On envoi la commande make qui va télécharger les dépendances et compiler le code.

Configuration du serveur de synchronisation

La configuration du serveur de synchronisation est très simple, quelques paramètres à changer dans le fichier de configuration, une petite configuration sur Nginx puis une ligne à modifier sur son navigateur et c’est terminé ! Sans plus tarder, commençons !

Le fichier de configuration de base ressemble à ça :

[server:main]
use = egg:gunicorn
host = 0.0.0.0
port = 5000
workers = 1
timeout = 30

[app:main]
use = egg:syncserver

[syncserver]
# This must be edited to point to the public URL of your server,
# i.e. the URL as seen by Firefox.
public_url = http://localhost:5000/

# This defines the database in which to store all server data.
#sqluri = sqlite:////tmp/syncserver.db

# This is a secret key used for signing authentication tokens.
# It should be long and randomly-generated.
# The following command will give a suitable value on *nix systems:
#
#    head -c 20 /dev/urandom | sha1sum
#
# If not specified then the server will generate a temporary one at startup.
#secret = INSERT_SECRET_KEY_HERE

# Set this to "false" to disable new-user signups on the server.
# Only request by existing accounts will be honoured.
# allow_new_users = false

# Set this to "true" to work around a mismatch between public_url and
# the application URL as seen by python, which can happen in certain reverse-
# proxy hosting setups.  It will overwrite the WSGI environ dict with the
# details from public_url.  This could have security implications if e.g.
# you tell the app that it's on HTTPS but it's really on HTTP, so it should
# only be used as a last resort and after careful checking of server config.
force_wsgi_environ = false

# Uncomment and edit the following to use a local BrowserID verifier
# rather than posting assertions to the mozilla-hosted verifier.
# Audiences should be set to your public_url without a trailing slash.
#[browserid]
#backend = tokenserver.verifiers.LocalVerifier
#audiences = https://localhost:5000

Nous allons modifier les paramètres public_url, sqluri, secret, allow_new_users, audiences et ajouter un dernier paramètre.

Dans public_url, on va mettre l’URI final. Par exemple : https://fsync.themimitoof.fr.
Dans sqluri, on va dé-commenter et mettre l’emplacement ou l’URI qui va permettre au serveur de se connecter la base de données et stocker les informations :

  • Si vous souhaitez utiliser une base de données SQLite, la syntaxe est la suivante : sqlite:////var/opt/fsync/fsync.db (Vous pouvez bien entendu changer le dossier ou se situe le fichier SQLite)
  • Si vous souhaitez utiliser un autre type de BDD (compatible avec SQLAlchemy) : engine://username:password@IP_or_hostname/database

Pour le paramètre secret, on va devoir générer une clé secrète pour les tokens d’authentification. Pour cela, on va entrer la commande suivante, on dé-commente la ligne puis on copie le contenu pour le mettre dans le paramètre secret :

head -c 20 /dev/urandom | sha1sum

Note : Si vous ne mettez pas rien dans ce paramètre, le serveur va vous en générer un mais il sera différent à chaque redémarrage du serveur.

Pour le paramètre allow_new_users, on va simplement le dé-commenter et mettre comme paramètre **true **pour autoriser notre compte à ce connecter pour la première fois à notre serveur (pensez à mettre false une fois que tous les comptes que vous souhaitez héberger ce sont connecter au moins une fois sur votre serveur).

On va ensuite modifier le paramètre audiences et mettre la même chose que le paramètre **public_uri **sans oublier de dé-commenter la ligne. (Normalement ce paramètre n’est pas obligatoire mais je vous recommande fortement de l’utiliser car j’ai eu beaucoup de soucis comme quoi mon utilisateur était rejeté car l’URI et l’application_URI (je sais pas qui c’est celui-ci :D) était différent).

Pour finir, il suffira d’ajouter la ligne suivante à la fin de votre fichier :

forwarded_allow_ips = *

Cette ligne vous permettra d’éviter les messages d’erreurs et problèmes d’autorisation comme j’ai cité dans l’explication de l’utilité du paramètre audiences.

Configuration du serveur Web

Maintenant, on va configurer le serveur Web. Pour ma part, j’utilise Nginx mais je respecte les afficionados d’Apache 😉

Pour Nginx, pas bien compliqué, il vous suffit d’utiliser le proxy intégré d’Nginx comme ci-dessous :

server {
        listen  80;
        server_name sync.example.com;

        location / {
                proxy_set_header Host $http_host;
                proxy_set_header X-Forwarded-Proto $scheme;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_redirect off;
                proxy_read_timeout 120;
                proxy_connect_timeout 10;
                proxy_pass http://127.0.0.1:5000/;
        }
}

Pour Apache, la configuration est totalement différente car on aura besoin d’utiliser un socket WSGI :

<VirtualHost *:80>
  ServerName sync.example.com
  DocumentRoot /path/to/syncserver
  WSGIProcessGroup sync
  WSGIDaemonProcess sync user=sync group=sync processes=2 threads=25 python-path=/path/to/syncserver/local/lib/python2.7/site-packages/
  WSGIPassAuthorization On
  WSGIScriptAlias / /path/to/syncserver/syncserver.wsgi
  CustomLog /var/log/apache2/sync.example.com-access.log combined
  ErrorLog  /var/log/apache2/sync.example.com-error.log
</VirtualHost>

Note : Il est possible pour les utilisateurs d’Nginx d’utiliser le socket WSGI seulement c’est un peu plus compliqué. Si cela vous tient à cœur, je vous invite à lire le petit paragraphe à cette adresse : https://docs.services.mozilla.com/howtos/run-sync-1.5.html#nginx-uwsgi

Pour finir avec la configuration des serveurs Web, je recommande à tous l’utilisation d’un certificat SSL (avec Let's Encrypt ou délivré par une authorité de certification reconnue) ce qui permettra de sécuriser les échanges entre vos postes et le serveur (Safety first !).

Démarrage du serveur de synchronisation

Une multitude de moyens s’offrent à vous pour démarrer le serveur de synchronisation comme le lancement au démarrage du système, la tâche Cron, le lancement manuel ou encore via systemctl. Dans cet article je vais simplement vous présenter les deux techniques pour démarrer le serveur de synchronisation et une petite ligne à mettre dans son fichier crontab.

Pour démarrer le serveur de synchronisation, vous pouvez soit lancer la commande suivante :

./path/to/syncserver/local/bin/gunicorn --paste /path/to/syncserver/syncserver.ini &

ou bien

make serve &

J’ai ma préférence pour la première car elle permet de choisir l’emplacement du fichier de configuration mais aussi de mettre l’argument --threads 4 qui permet d’attribuer plus de puissance au serveur de synchronisation.

Pour démarrer le serveur à chaque démarrage du serveur, vous pouvez ajouter la ligne suivante dans votre crontab en tapant la commande crontab -e :

@reboot ./path/to/syncserver/local/bin/gunicorn --paste /path/to/syncserver/syncserver.ini &

Configurer le poste client

Avant de commencer, si vous êtes déjà connecté aux serveurs de Firefox Sync, je vais vous demander de vous déconnecter autrement, la connexion au nouveau serveur peut ne pas fonctionner (surtout sur les clients mobiles).

Ouvrez un nouvel onglet et entrer dans la barre d’adresse about:config puis, cliquez sur le bouton « Je prends le risque » :

Capture-du-2016-10-02-17-49-06-1024x363

Dans la barre de recherche, entrez sync. :

Capture-du-2016-10-02-17-52-26

Puis modifier le paramètre identity.sync.tokenserver.uri en mettant :

http(s)://sync.exemple.com/token/1.0/sync/1.5

Note : Remplacez le protocole HTTP/HTTPS et l’URI en fonction de votre configuration précédente

Il ne vous reste plus qu’à essayer avec deux appareils et voir si votre historique/favoris se retrouve sur tous vos appareils, si ce n’est pas le cas, revérifiez votre configuration et vérifiez si le serveur est actif. Un moyen simple de savoir si votre serveur est actif est d’ouvrir un onglet et essayer le public_URI. Le serveur doit vous ressortir « it works! »

Conclusion

Vous êtes maintenant le propriétaire de votre propre serveur de synchronisation ! Félicitations !

Dans un prochain article, je parlerai de la mise en place d’un serveur d’authentification qui vous permettra d’être totalement dépendant des serveurs de Firefox.

Sources : Documentation Firefox