Avant de commencer cette petite revue, je vais présenter ce que j’attend d’une solution de synchronisation pour mes petits besoins personnels.

• Synchronisation de N clients sur un serveur
• Accès hors ligne des données (et modification), synchro à la prochaine connexion
• Automatisation des synchro (dès qu’il y a quelque chose à synchroniser et que la connexion existe, on y va)
• Utilisation en ligne de commande possible (et GUI pour qui veut)
• En bonus, historique des fichiers

Revue

Cette revue est sans doute incomplète mais elle est le résultat tout de même de nombreuses heures (par dizaines) à fouiner un peu partout et à tester. J’espère qu’elle sera utile à celles et ceux qui se posent la même question et peut être à éclaircir (en vue de développements futurs ?) les points forts et faibles de l’existant. Je parle ici uniquement des solutions libres pour lesquelles les données peuvent être mises sur un serveur maitrisé par l’utilisateur final (auto-hébergement…). J’avoue ne pas avoir tout testé. Aux personnes qui pensent dropbox, je les renvoie là et là.

Rsync

Unison

Un vieux software performant. C’est le rsync bidirectionnel. Il peut être utilisé en local ou à travers du SSH et peut être automatisé (option batch). Le seul hic est qu’il n’a pas le moyen de vérifier qu’une nouvelle synchro est nécessaire, autrement dit, ce n’est pas un démon. Il faut le coupler à autre chose comme inotify. Inotify permet d’envoyer des signaux lorsqu’il y a des modifications sur le système de fichier (création, accès, destruction…)

Unison étant pour moi une des solutions les plus à même de répondre aux besoins, je ferai un paragraphe dédié en fin d’article (bidouilles possibles). Cependant, elle ne l’est pas en l’état. Certains ont essayé de faire des adaptations avec le logiciel suivant.

Lsyncd

Lsyncd est conçu pour palier l’absence d’inotify dans rsync. Le projet semble avoir déjà une petite maturité. Le problème est qu’avec rsync, on tombe à nouveau dans une solution unidirectionnelle. Une solution utilisant Unison à la place de rsync semble prometteuse. L’idée est de synchroniser via ssh en utilisant le puissance de unison lorsque le système de fichier est changé (lsyncd). L’auteur procède même à du reverse ssh afin de déclencher une synchronisation dû à un changement de l’autre coté (je peux presque m’éviter ça… j’y reviendrai). En lisant les commentaires, on remarque qu’une personne a remonté un problème : les tâches unison sont lancées en série. L’écueil est que la synchronisation démarre sur un fichier spécifique mais que la synchro est globale. On voit vite qu’on peut créer un grand nombre de processus unison parce que plein de petits fichiers son modifiés successivement. On a vu mieux.  Le hack n’est pas parfait.

SSHfs/webdav

Je n’ai pas essayé sshfs mais webdav via owncloud. J’imagine que le premier souffre des mêmes critiques que le second qui sont que le travail hors ligne est impossible. Je n’ai trouvé aucune solution logicielle permettant de travailler sur du webdav hors ligne. Attention aussi à la moindre déconnexion internet. Si vous continuer à utiliser votre logiciel parce que vous ne faites pas attention et qu’il accède aux données, les surprises vont arriver rapidement (j’ai testé…).

Le hack que je vois ici est :

1. de monter le webdav si connexion active
2. synchroniser avec la copie locale
3. démonter

Sparkleshare

Certains ont crié victoire à l’arrivé de ce logiciel (tout au moins dans le titre ). Le problème est qu’à l’heure actuelle, le projet est jeune et que le client est en mono. Je ne suis pas emballé pour l’instant par ce logiciel, mais bien plus par l’idée. Concept concurrent à Unison, Sparkleshare utilise la puissance de gestionnaires de version tel que Git. C’est pour moi la condition sine qua none d’une bonne qualité : reposer sur un système éprouvé. Ce système est avant tout utile pour des fichiers non binaires, en effet, les performances chuteront dès qu’il s’agira de renvoyer le fichier en intégralité. Mon avis est que c’est un faux problème, car je ne cherche pas à synchroniser Zim comme des photos. Pour des photos, j’utiliserais bien plus webdav qu’une solution de synchronisation comme sparkleshare.

Git permet d’avoir l’historique, un bon point mais certains disent que le dépôt risque de prendre du poids rapidement. Git permet de modifier l’histoire, je ne suis pas un gourou mais je pense qu’en se penchant dans la doc, on doit pouvoir trouver le moyen d’alléger le dépôt régulièrement.

dvcs-autosync

Passons maintenant à celui-ci. Ce logiciel utilise Git, inotify et Jabber (XMPP). Le substitut à sparkleshare par excellence. J’ai été un peu surpris de l’utilisation de jabber, celui-ci sert visiblement à communiquer entre les divers instances. C’est pour moi la révélation de cette revue, simple, efficace, mes pré-tests sont tout à fait concluant. Ce logiciel est une perle qui devrait être bien plus largement connue. Une discussion a eu lieu sur le forum d’archlinux.

Syncany

Voici un logiciel en java. Il semble très prometteur aussi puisqu’il a pour ambition d’être chiffré et peu dépendant du support de stockage : FTP, IMAP, Webdav, SSH et bien d’autres… La version que j’ai testé ne fonctionnait pas (FTP ou webdav ou SSH, commit initial impossible). Difficile de donner un avis, mais la première version n’est pas encore sortie. C’est pour moi un logiciel à surveiller de très près. Il faudra voir la robustesse en gestion de conflits etc.

Lipsync

Suite à cet article, j’ai aussi trouvé ce logiciel que je n’ai pas réussi à faire fonctionner. J’ai commencé à modifier le code pour résoudre divers bugs et puis j’ai rapidement lâché. La qualité n’est pas à la hauteur de mes espérances. D’après ce que j’ai vu, il n’utilise que rsync… (?)

Csync

Je mentionne aussi l’existence de ce projet csync qui semble mort. Pas testé de ce fait.

Rubydrop

Rubydrop est un projet plus à l’échelle du projet personnel. La dernière activité remonte à décembre 2010 et la licence est exotique. Par manque de conviction, je n’ai pas testé non plus.

Conclusion de la revue

De nombreuses solutions et très peu qui fonctionnent out of the box pour moi. Il y a deux concepts qui sortent du lot : le bon vieux Unison et des gestionnaires de version comme Git. L’utilisation de inotify est selon moi un atout, mais limite l’interopérabilité avec les systèmes windows notamment (comme ça ne m’importe pas…). Les autres systèmes de type webdav ne répondent pas à nos besoins, ils sont par contre bien plus utiles pour des dépôts de documents, photos, vidéos, sons… Là où une synchronisation manuelle à un sens (on ne synchronise pas des photos tous les quatre matins). Pour les données d’un logiciel utilisé au quotidien, c’est inadapté.

Parmis les solutions à surveiller, je dirais :

• Syncany
• Sparkleshare (principalement la recherche d’amélioration concernant mono)
• dvcs-autosync : peu connu et qui mériterait de l’être plus. Actuellement, c’est la seule solution viable à mes yeux.

Addendum : Bidouilles possibles

Si on s’ennuie, on peut envisager des petites bidouilles (hacks). Ce sont de petites pensées, le coeur de l’article n’est pas là

Webdav

Je vois assez bien un hack très rapide avec webdav. Comme expliqué plus haut, ne pas travailler directement dans le répertoire monté, mais synchroniser dedans avec unison. Synchroniser par cron me semble peut intelligent. Par contre, incron devrait être facile à utiliser (ou un script perl/python avec une lib inotify).

Unison

A l’image de lsyncd + unison, je pense qu’on peut écrire un petit code (perl ou python par ex) avec la lib inotify qui lancerait des synchro avec unison. J’éviterai l’erreur ci-dessus en groupant les synchros. Autrement dit, je ne lance pas une synchro dès qu’il y a un signal lancé par inotify. Je limite par ex la fréquence des synchro et j’attends toujours que la précédente soit finie pour lancer la nouvelle. C’est l’absence de cette deuxième condition qui selon moi pose problème.

J’ai parfois des soucis avec le reverse ssh (erreur du type  ssh_exchange_identification: Connection closed by remote host) objets de longues discussions sans solution sur les forums alors que je suis déjà parvenu à le faire fonctionner. Néanmoins, je pense que synchroniser au démarrage de la machine et après des temps d’inactivité long suffirait (à titre personnel). En effet, je ne travaille que sur une machine à la fois et un long moment se passe lorsque je change de machine (temps de trajet d’au moins 10 minutes). On devrait dans ce cas pouvoir se passer d’une communication serveur vers clients.