Je veux parler de ma tentative de créer un client Dropbox simple ligne pour Linux en utilisant uniquement des composants open source gratuits, y compris
rclone ,
entr et
systemd .
Contexte
Récemment, le client propriétaire Dropbox pour Linux a supprimé la prise en charge de tous les systèmes de fichiers Linux sauf
ext4 non chiffré . Et mon répertoire personnel est malheureusement crypté.
Début décembre, le client propriétaire a cessé de fonctionner. Il s'est déconnecté et a suggéré de choisir un autre dossier de synchronisation dans le «système de fichiers pris en charge».
Soit dit en passant, j'utilise Ubuntu Bionic sur le Thinkpad t460s de deux ans.
Pourquoi ai-je besoin de Dropbox
J'utilise activement le
mode Org : je prends des notes en texte brut et Dropbox crée continuellement des copies de sauvegarde des notes tout en tapant.
Si vous travaillez également dans le domaine des infrastructures de stockage, mon cas d'utilisation est très similaire à la «réplication asynchrone à maître unique», c'est-à-dire avec un maître. Toutes les entrées passent par mon Thinkpad, c'est le maître. Le dossier distant Dropbox n'est qu'une réplique en lecture seule, que j'émets parfois des demandes en lecture seule ou que j'utilise comme sauvegarde pour créer un nouvel assistant lorsque l'actuel échoue ou est volé.
Cependant, cette configuration de réplication m'a sauvé la vie plusieurs fois. J'ai encore sous les yeux comment le Thinkpad a refusé de démarrer lors de la session de deuxième année. Comme j'ai constamment répliqué toutes les notes dans Dropbox, je n'ai perdu aucune donnée et j'ai pu voir les dernières notes sur le Macbook de ma mère. Merci maman!
Tentatives infructueuses
Lorsque le client Dropbox a cessé de fonctionner, je me suis concentré sur la recherche d'un autre client distant multifonctionnel similaire pour Linux. En principe, cela ne me dérange pas de passer à un autre service, tel que Google Drive ou AWS S3. Certaines des options sont
overGrive et
insync .
Cependant, je suis arrivé à la conclusion que ces solutions sont trop fonctionnelles et
peu adaptées à mon cas .
Par exemple, les clients essaient de
connecter un système de fichiers distant à votre PC . Ils essaient très fort d'abstraire les systèmes de fichiers distants, les faisant ressembler à des systèmes locaux. En règle générale, ils implémentent la synchronisation bidirectionnelle, le mappage automatique des types de fichiers distants vers les types de fichiers Linux, etc.
Je n'ai pas besoin de ce niveau d'abstraction. Quelque chose de simple est nécessaire pour sauvegarder constamment des notes dans le cloud pendant que je tape. De plus, les abstractions rendent difficile le réglage et le débogage. Sans oublier que la plupart de ces clients multifonctionnels sont propriétaires.
rclone
Je suis tombé
rclone utilitaire
rclone , et j'ai immédiatement réalisé: c'est exactement ce que je cherchais. Un programme simple mais puissant. Très similaire à l'outil
rsync , uniquement pour le stockage dans le cloud.
Par exemple,
rclone prend en charge la tolérance aux pannes (vérification d'intégrité), dispose d'algorithmes de synchronisation efficaces, etc., tout en fournissant une
interface CRUD simple pour interagir avec les services de stockage cloud populaires, notamment Amazon S3, Google Drive et Dropbox.
La commande suivante synchronise le répertoire de l'
org distante avec le répertoire local
/home/lpan/org .
ORG_DIR=/home/lpan/org REMOTE=dropbox rclone sync $ORG_DIR $REMOTE:org
entr
L'utilitaire pour exécuter les commandes
entr utilise l'API
inotify . Essentiellement, il exécute des commandes lors de la modification de fichiers sans
interroger le système de fichiers.
Un cas d'utilisation courant consiste à
reconstruire un projet si l'un des fichiers source a changé .
entr prend une liste de chemins absolus depuis
stdin puis exécute la commande passée en argument si l'un des fichiers observés a changé.
WORKDIR=/path/to/myproject find $WORKDIR | grep "\.cpp$" | entr make
Script sur une seule ligne
Maintenant, nous avons
rclone et
entr . Le script résultant est très simple. Permettez-moi de vous rappeler que mon cas d'utilisation pour Dropbox est très simple: il vous suffit de répliquer en permanence les fichiers Org locaux lorsqu'ils changent. Par conséquent, vous pouvez utiliser
entr pour surveiller les fichiers et
rclone pour «synchroniser» avec le stockage distant.
Le script résultant (
/home/lpan/sync_dropbox.sh ) est le suivant:
Exécutez le démon
Un démon n'est qu'un programme informatique qui s'exécute en arrière-plan. Nous faisons de notre script un processus d'arrière-plan afin qu'il synchronise constamment les changements de fichiers locaux en arrière-plan avec le système de fichiers distant.
systemd fournit une interface pour contrôler les processus démon.
J'ai créé le
service Dropbox dans
~/.config/systemd/user/dropbox.service .
[Unit] Description=Dropbox Daemon [Service] ExecStart=/home/lpan/sync_dropbox.sh Restart=always [Install] WantedBy=default.target
Vous pouvez ensuite contrôler le démon à l'aide des commandes suivantes:
Conclusion
Dans cet article, nous avons expliqué comment appliquer la philosophie UNIX et utiliser un ensemble d'outils open source gratuits pour remplacer le client Dropbox propriétaire et hérité. Nous avons utilisé
rclone et
entr . J'ai également montré comment faire de ce processus un démon et le gérer avec
systemd .
Je veux vous rappeler que l'idée clé est la simplicité. Nous voulons des solutions simples pour des tâches simples. Mon cas d'utilisation pour Dropbox est très simple. Et c'est pourquoi un script sur une ligne est préférable à l'utilisation d'un client cloud trop fonctionnel et propriétaire.
Merci beaucoup d'avoir lu! J'espère vraiment que vous apprécierez ce post. Si vous connaissez la meilleure façon de faire de même ou d'étendre le script pour un autre cas d'utilisation - faites le moi savoir dans les commentaires!