Synchroniser simplement ses documents

Bonjour à tous,

Je suis en train de rédiger mon rapport de stage (fin de DUT, on ne se moque pas de la jeunesse :smiley: ) et j’ai cherché à mettre en place un environnement ergonomique (pour avoir envie de me jeter dans la rédaction) et sécurisé du point de vue de la sauvegarde de fichiers (pour ne pas avoir à tout réécrire bien sûr).

À titre indicatif j’utilise Debian Testing (Wheezy lors de l’écriture de ce post)

[size=130]La solution mise en place[/size]
[size=115]Une solution libre…[/size]
Je ne fais pas confiance aux Dropbox et autres SkyDrive et j’ai donc voulu mettre en place une solution indépendante de ces logiciels (et libre, mais libre comme l’air, pas comme la bière :018 ). Ainsi, pour ce qui est de la gestion de l’espace de stockage je m’appuie sur WebDAV (et son pendant pour le monter en userspace: davfs2).

[size=115]… mais pas (forcément) gratuite[/size]
Je bénéficie de cet espace de stockage chez un hébergeur Roubaisien bien connu, moyennant bien sûr quelque paiement (rien d’indécent dans les tarifications cependant).

[size=115]Des outils simples et efficaces[/size]
Pour rédiger mon rapport je me suis tourné spontanément vers LaTeX. Puisqu’il s’agit de fichiers texte (pour les sources .tex du moins) j’ai eu l’idée de synchroniser ma sauvegarde avec… Mercurial, n’en déplaise aux aficionados de rsync (et pourtant je viens du monde des Gentooïstes !)

[size=115]Le principe[/size]
Le principe est relativement simple: il s’agit de monter l’espace de stockage dans l’espace utilisateur à l’aide de davfs, et de synchroniser un répertoire local (~/Documents chez moi) et le répertoire distant via son montage et à l’aide de Mercurial.

[size=130]En pratique[/size]
[size=115]Davfs[/size]
Pour ce qui est de la mise en place du montage de l’espace de stockage à l’aide de davfs je dois avouer m’être grandement inspiré de la documentation Ubuntu (malgré mon aversion pour la distribution, pas taper :smiley: )
Ainsi, j’ai installé le paquet davfs2 disponible dans les dépôts Debian et l’ai “dpkg-reconfiguré”

$ aptitude install davfs2 $ dpkg-reconfigure davfs2

J’ai ensuite créé l’emplacement destiné au montage et ai modifié mon /etc/fstab en conséquence

[code]$ mkdir ~/TBox

echo “https://serveur.qui.heberge.net /home/thibault/TBox davfs rw,user,noauto 0 0” >> /etc/fstab

adduser thibault davfs2[/code]

J’ai utilisé également la méthode (pas très sécurisée) décrite dans la documentation ubuntu pour pouvoir monter l’espace de stockage sans devoir rentrer identifiant et mot de passe à chaque tentative de montage (et permettre à Nautilus de le monter comme un grand).

Ainsi j’ai créé mon propre répertoire ~/.davfs2 et l’ai rempli comme il se doit

[code]$ mkdir ~/.davfs2
$ cp /etc/davfs2/davfs2.conf ~/.davfs2

cp /etc/davfs2/secrets ~/.davfs2

chown thibault:thibault ~/.davfs2/secrets[/code]

Avant de le remplir j’ai vérifié que j’étais bien le seul à pouvoir le lire:

$ ls -l ~/.davfs2/secrets -rw------- 1 thibault thibault 2692 mai 27 12:04 /home/thibault/.davfs2/secrets

Ensuite un petit coup de vim dans le fichier secrets pour le remplir (histoire d’éviter qu’un echo “/home/thibault/TBox identifiant motDePasse” >> ~/.davfs2/secrets ne se retrouve dans mon .bash_history :smiley: ) selon la syntaxe suivante:

Ça y est, on a déjà notre espace WebDAV accessible simplement ! On note que le contenu n’est pas crypté et qu’un employé peu scrupuleux pourrait avoir accès au contenu. Si vous n’avez pas de fichier sensible tout peut être laissé en l’état, sinon la solution détaillée dans la documentation ubuntu me paraît satisfaisante.

[size=115]Mercurial[/size]
Le comportement attendu est de garder un répertoire local (~/Documents) synchronisé avec le répertoire distant.

[size=110]La solution inefficace[/size]
Il pourrait être tentant d’exécuter les commandes suivantes après montage de l’espace WebDAV afin de respecter la synchronisation du répertoire local envers le répertoire distant (ie pouvoir faire un cd ~/Documents && touch a && hg commit && hg push au lieu de touch ~/Documents/a && cd ~/TBox/Documents && hg pull)

$ cp ~/Documents ~/TBox/ $ hg init ~/TBox/Documents && hg add && hg commit $ mv ~/Documents ~/Documents.bak $ cd ~ && hg pull ~/TBox/Documents

Si il est louable de respecter la prépondérance du serveur vis à vis du client, cette solution est brouillon et très consommatrice en bande passante (l’espace WebDAV est certes monté localement, mais il communique avec le serveur derrière) puisqu’il y a des allers retours incessants entre le client et le serveur.

[size=110]La solution kivamieux[/size]
Voyons comment contourner le problème, c’est à dire garder l’autorité du serveur (c’est le client qui push et pas le serveur qui pull) sans consommer autant de bande passante qu’il faudrait pour télécharger les intégrales du seigneur des anneaux et de star wars en version longue et dans toutes les langues.

Pour faire les choses proprement, commençons par créer le répertoire Mercurial localement, sans rien envoyer au serveur:

$ hg init ~/Documents $ hg add $ hg commit

Ensuite, “exportons” notre répertoire vers le serveur (ceci peut prendre du temps au vu de la quantité de données qui peut transiter. À ce sujet, il est certainement intéressant pour vous de mettre en place un .hgignore qui ne synchronisera pas certains documents lourds et peu importants)

Nous avons donc maintenant nos deux répertoires synchronisés ! Cependant, nous avons un comportement assez peu élégant puisque pour effectuer une synchronisation il faut que ce soit le serveur qui pull les changements.

Cela se résoud de manière très simple ! En effet il suffit de déplacer le fichier ~/TBox/Documents/.hg/hgrc vers ~/Documents/.hg/hgrc et le comportement s’inversera

[size=130]Conclusion[/size]
J’aimerais beaucoup avoir vos retours sur cette méthode et des moyens de l’améliorer ! Je rappelle qu’elle s’applique dans mon cas à des fichiers texte (ou des pdf immuables).

Bonjour,

pourquoi ne pas utiliser ssh ? il est sécurisé, simple à monter et tout comme davfs tu peux monter le dossier avec sshfs

Sinon, il y a un projet qui me semble très porteur : Syncany.
Il n’y a pas d’activité à proprement parler depuis 1 an. Mais ce projet à pour but d’être une véritable alternative Libre à Dropbox (enfin !).
Le developpeurs n’ayant plus le temps, ce sont des étudiants qui ont repris le projet, pour leur projet de thèse.
Tu peux jeter un coup d’oeil dessus pour avoir quelques infos en plus.

En attendant, j’approuve pour ssh. Simple et sécurisé.
et si tu remplacait mercurial par rsync+cron ?

Une solution personnel, après des essais peu convaincants de owncloud entre autres (qui semble prometteur toutefois).

Cela nécessite
Un serveur ssh
et sur chaque machine cliente:
Un client ssh avec un accès au serveur par clef, nommé «maison» ci dessous et rsync

Tout d’abord il faut modifié rc.local en rajoutant

if [ -d /etc/scripts.d ] ; then for f in $(ls /etc/scripts.d | grep -v "~$") ; do /etc/scripts.d/$f done fi
juste avant le «exit 0». Cela exécute tous les scripts dans /etc/scripts.d au démarrage.

Un script /etc/scripts.d/synchro contenant

[code]#!/bin/sh
SELF=/etc/scripts.d/synchro
DELAI=20
LOG=/dev/null
USER=francois
if [ -z $1 ] ; then

export > /tmp/phase1

su $USER -c "$SELF init"

else
if [ $1 = init ] ; then
PGM=$SELF

echo $PGM > /tmp/phase2

    cd ~

#Liste des fichiers et serveur SSH correspondant
LISTE=$(cat .liste_sync) SERVEUR=$(cat .serveur_sync) $PGM go > $LOG 2>&1 &
else

touch /tmp/phase3

    for dir in $LISTE ; do
        echo $dir
        rsync -aqvuzb --del --backup --backup-dir=BackupOrg~ --exclude '*~' ${SERVEUR}:${dir}/ ~/$dir
    done
    sleep $DELAI
    while /bin/true ; do
        for dir in $LISTE ; do
            echo $dir 
            rsync -qavuzb --del --backup --backup-dir=BackupDes~  --exclude '*~' ~/$dir/ ${SERVEUR}:${dir}
            rsync -aqvuzb  --del --backup --backup-dir=BackupsOrg~ --exclude '*~' ${SERVEUR}:${dir}/ ~/$dir
        done
        sleep $DELAI
    done
fi

fi
[/code]
Les paramètres sont USER= utilisateur courant, DELAI=nombre de secondes entre chaque synchro (20 est un peu petit je pense mais bon).

Il suffit de faire deux fichiers, un fichier .liste_sync contenant la liste des répertoires à synchroniser et .serveur_sync contenant le compte ssh configuré avec accès clefs,

[la suite tout à l’heure les invités arrivent]

Avec hg, je ne m’y prend pas pareil en local. D’abord, je pull les modifications, et sur le serveur, je lance hg update pour les recevoir, et ça marche plutôt bien jusqu’à présent. Cela dit, je ne suis pas sûr que ce soit la meilleure méthode…

Suite; Lorsqu’un fichier est détruit, un backup est fait soit suite «repertoire>/Backuporg~ soit sur «repertoire>Backupdest~ ce qui permet de rattraper un souci lors d’un conflit entre deux machines sur lesquelles on travaille.

Le tout est parfait pour mes besoins: un dropbox perso.

Bon, amélioration finale

[code]#!/bin/sh
SELF=/etc/scripts.d/synchro
LOG=/dev/null
if [ -z $1 ] ; then

export > /tmp/phase1

su francois -c "$SELF init"

else
if [ $1 = init ] ; then
PGM=$SELF

echo $PGM > /tmp/phase2

    cd ~
    DELAI=$(cat .delai_sync)

#Liste des fichiers et serveur SSH correspondant
LISTE=$(cat .liste_sync) SERVEUR=$(cat .serveur_sync) $PGM go > $LOG 2>&1 &
else

touch /tmp/phase3

    for dir in $LISTE ; do
        echo $dir
        rsync -aqvuzb --del --backup --backup-dir=BackupOrg~ --exclude '*~' ${SERVEUR}:${dir}/ ~/$dir
    done
    sleep $DELAI
    while /bin/true ; do
        cd ~
        LISTE=$(cat .liste_sync)
        SERVEUR=$(cat .serveur_sync) $PGM go > $LOG 2>&1 &
        DELAI=$(cat .delai_sync)
        for dir in $LISTE ; do
            echo $dir
            rsync -qavuzb --del --backup --backup-dir=BackupsDes~  --exclude '*~' ~/$dir/ ${SERVEUR}:${dir}
            rsync -aqvuzb  --del --backup --backup-dir=BackupsOrg~ --exclude '*~' ${SERVEUR}:${dir}/ ~/$dir
        done
        sleep $DELAI &
        PID=$!
        echo $PID > /tmp/.pid_synchro
        wait $PID
    done
fi

fi
[/code]
et un fichier /usr/local/bin/synchro

#!/bin/sh if [ -f /tmp/.pid_synchro ] ; then kill $(cat /tmp/.pid_synchro) fi

  • Il y a 3 fichiers modifiables à la volée. .liste_sync contient la liste des répertoires à synchroniser, .serveur_list la machine ssh (ça peut contenir toto@pouet.labas.fr ou machine suis le fichier .ssh/config) et .delai_sync le délai entre chaque synchronisation automatique.
    Les fichiers/répertoires finissant par ~ ne sont pas synchronisés.

  • Si on synchronise le répertoire Toto,
    lors du lancement une synchronisation est faite. Si un fichier est détruit ou mis à jour, l’ancienne version est mise dans Toto/BackupsOrg~ ce qui permet de le récupérer éventuellement. Par la suite si on détruit un fichier (ou un répertoire) dans Toto, il est détruit sur le répertoire de sauvegarde mais une copie est conservé dans Toto/BackupsDes~ ce qui permet de le récupérer.

  • Pour forcer une synchonisation, il suffit de taper «synchro».

Cela permet de travailler sur plusieurs machines en même temps de manière automatique et ne consomme pas (ou très peu) de ressources. Je préfère finalement ce système à owncloud ou à dropbox (pour des raisons évidentes dans ce derniers cas).

Merci a vous pour votre partage.
Cela sera t’il mis en tuto dans votre site ?

Bientôt, il faut que j’ai le temps de le faire. Je viens d’améliorer en mettant une attente du réseau au cas où il ne démarre pas tout de suite…

[code]#!/bin/sh
SELF=/etc/scripts.d/synchro
LOG=/dev/null
if [ -z $1 ] ; then

export > /tmp/phase1

su francois -c "$SELF init"

else
if [ $1 = init ] ; then
PGM=$SELF

echo $PGM > /tmp/phase2

cd ~
DELAI=$(cat .delai_sync)

#Liste des fichiers et serveur SSH correspondant
LISTE=$(cat .liste_sync) SERVEUR=$(cat .serveur_sync) $PGM go > $LOG 2>&1 &
else

touch /tmp/phase3

TEST=1
while [ $TEST  -gt 0 ] ; do 
    TEST=$(ssh $SERVEUR /bin/true 2> /dev/null )
    TEST=$?
    sleep 5
done
for dir in $LISTE ; do
    echo $dir
    rsync -aqvuzb --del --backup --backup-dir=BackupOrg~ --exclude '*~' ${SERVEUR}:${dir}/ ~/$dir
done
sleep $DELAI
while /bin/true ; do
    cd ~
    LISTE=$(cat .liste_sync)
    SERVEUR=$(cat .serveur_sync) $PGM go > $LOG 2>&1 &
    DELAI=$(cat .delai_sync)
    for dir in $LISTE ; do
	echo $dir
	rsync -qavuzb --del --backup --backup-dir=BackupDes~  --exclude '*~' ~/$dir/ ${SERVEUR}:${dir}
	rsync -aqvuzb  --del --backup --backup-dir=BackupsOrg~ --exclude '*~' ${SERVEUR}:${dir}/ ~/$dir
    done
    sleep $DELAI &
    PID=$!
    echo $PID > /tmp/.pid_synchro
    wait $PID
done
fi

fi
[/code]

Pourquoi ne pas utiliser cron pour une tâche régulière comme ça ? Personnellement j’aurais bien fais une partie initialisation dans un script d’init standard (vérifier l’accès au serveur distant et modifier un fichier dès qu’il est accessible) et un script lancé par cron qui fait la syncro dans les deux sens.

Pour changer le délai à la volée… La synchronisation doit se faire d’abord serveur vers machine, puis par couple (machine vers serveur puis serveur vers machine). Un cron ne me paraissait pas assez souple. Enfin, je voulais pouvoir forcer une synchro avant de quitter (kill sleep).

La nouvezlle version de /usr/local/bin/synchro qui suit et un

[code]# cd /etc/pm/sleep.d

ln -s /usr/local/bin/synchro[/code]

permet de gérer correctement l’hibernation ou la veille de l’ordinateur#!/bin/sh PGM=/usr/local/bin/synchro PGMBIS=/etc/scripts.d/synchro QUI=francois if [ -z $1 ] ; then if [ -f /tmp/.pid_synchro ] ; then kill $(cat /tmp/.pid_synchro) fi else if [ -z $USER ] ; then su $QUI -c "$PGM $1" else case "$1" in suspend|hibernate) if [ ! -f /tmp/.hib ] ; then touch /tmp/.hib PID=$(ps x | grep "/etc/scripts.d/synchro" | grep -v grep | awk '{print $1}') if [ ! -z "$PID" ] ; then kill $PID fi cd ~ LISTE=$(cat .liste_sync) SERVEUR=$(cat .serveur_sync) for dir in $LISTE ; do rsync -qavuzb --del --backup --backup-dir=BackupDes~ --exclude '*~' ~/$dir/ ${SERVEUR}:${dir} rsync -aqvuzb --del --backup --backup-dir=BackupsOrg~ --exclude '*~' ${SERVEUR}:${dir}/ ~/$dir done fi sleep 1 ;; thaw|resume) if [ -f /tmp/.hib ] ; then rm /tmp/.hib cd ~ $PGMBIS init (ps x | grep synchro) >> /tmp/toto fi ;; esac fi fi

Si un ordinateur rajoute un fichier sur le dépot ou fait des modifs pendant que cet ordinateur est en veille, au réveil il actualisera son répertoire.

Désormais le seul souci est le travail en même temps entre deux ordinateurs, il faudrait une priorité…