Хочу рассказать о своей попытке создать простой однострочный клиент Dropbox под Linux, используя только бесплатные компоненты с открытым исходным кодом, в том числе rclone, entr и systemd.
Недавно проприетарный клиент Dropbox под Linux отказался от поддержки всех файловых систем Linux, кроме незашифрованной ext4. А мой домашний каталог, «к сожалению», зашифрован.
В начале декабря проприетарный клиент перестал работать. Он вышел из системы и предложил выбрать другую папку синхронизации в «поддерживаемой файловой системе».
Кстати, я запускаю Ubuntu Bionic на двухлетнем Thinkpad t460s.
Я активно использую Org mode: делаю заметки обычным текстом, а Dropbox непрерывно создаёт резервные копии заметок во время набора.
Если вы тоже работаете в области инфраструктуры хранения данных, мой вариант использования очень похож на «асинхронную репликацию single-master», то есть с одним мастером. Все записи проходят через мой Thinkpad, это и есть мастер. Удалённая папка Dropbox — просто реплика только для чтения, которой я иногда «выдаю запросы только для чтения» или использую в качестве резервной копии для создания нового мастера, когда текущий терпит неудачу или украден.
Тем не менее, такая настройка репликации несколько раз спасала мне жизнь. У меня до сих пор перед глазами, как Thinkpad отказался загружаться во время сессии на втором курсе. Поскольку я постоянно реплицировал все заметки в Dropbox, то не потерял никаких данных и смог просмотреть последние заметки на Macbook моей мамы. Спасибо, мам!
Когда клиент Dropbox перестал работать, я сосредоточился на поиске другого аналогичного многофункционального удалённого клиента под Linux. В принципе, я не против перейти и на другой сервис, такой как Google Drive или AWS S3. Некоторые из возможных вариантов — overGrive и insync.
Однако я пришёл к выводу, что эти решения излишне функциональны и не очень подходят для моего случая.
Например, клиенты пытаются подключить удалённую файловую систему к вашему ПК. Они очень стараются абстрагировать удалённые файловые системы, делая их похожими на локальные. Как правило, они реализуют двустороннюю синхронизацию, автоматическое сопоставление удалённых типов файлов с типами файлов Linux и т. д.
Мне не нужен такой уровень абстракции. Требуется что-то простое, позволяющее постоянно создавать резервные копии заметок в облаке, пока я набираю текст. Кроме того, абстракции затрудняют настройку и отладку. Не говоря уже о том, что большинство этих многофункциональных клиентов проприетарные.
Мне попалась утилита
Например,
Следующая команда синхронизирует удалённый каталог
Утилита для выполнения команд entr использует API inotify. По сути, она запускает команды при изменении файлов без опроса файловой системы.
Один из распространённых способов использования — пересборка проекта, если изменился какой-то из исходных файлов.
Теперь у нас есть
Итоговый скрипт (
Демон — это просто компьютерная программа, которая работает в фоновом режиме. Сделаем наш скрипт фоновым процессом, чтобы он постоянно синхронизировал с удалённой файловой системой локальные изменения файлов в фоновом режиме.
systemd обеспечивает интерфейс для управления процессами демона.
Я создал Dropbox Service в
Затем можно управлять демоном с помощью следующих команд:
В этой статье мы обсудили, как применить философию UNIX и использовать набор бесплатных инструментов с открытым исходным кодом для замены проприетарного и устаревшего клиента Dropbox. Мы применили
Хочу напомнить, что ключевая идея — простота. Мы хотим простые решения для простых задач. Мой вариант использования Dropbox очень простой. И вот почему однострочный скрипт лучше, чем использование излишне функционального и проприетарного облачного клиента.
Большое спасибо за чтение! Очень надеюсь, что вам понравится этот пост. Если знаете лучший способ сделать то же самое или расширить скрипт для другого варианта использования — дайте знать в комментариях!
Контекст
Недавно проприетарный клиент Dropbox под Linux отказался от поддержки всех файловых систем Linux, кроме незашифрованной ext4. А мой домашний каталог, «к сожалению», зашифрован.
В начале декабря проприетарный клиент перестал работать. Он вышел из системы и предложил выбрать другую папку синхронизации в «поддерживаемой файловой системе».
Кстати, я запускаю Ubuntu Bionic на двухлетнем Thinkpad t460s.
Зачем мне Dropbox
Я активно использую Org mode: делаю заметки обычным текстом, а Dropbox непрерывно создаёт резервные копии заметок во время набора.
Если вы тоже работаете в области инфраструктуры хранения данных, мой вариант использования очень похож на «асинхронную репликацию single-master», то есть с одним мастером. Все записи проходят через мой Thinkpad, это и есть мастер. Удалённая папка Dropbox — просто реплика только для чтения, которой я иногда «выдаю запросы только для чтения» или использую в качестве резервной копии для создания нового мастера, когда текущий терпит неудачу или украден.
Тем не менее, такая настройка репликации несколько раз спасала мне жизнь. У меня до сих пор перед глазами, как Thinkpad отказался загружаться во время сессии на втором курсе. Поскольку я постоянно реплицировал все заметки в Dropbox, то не потерял никаких данных и смог просмотреть последние заметки на Macbook моей мамы. Спасибо, мам!
Неудачные попытки
Когда клиент Dropbox перестал работать, я сосредоточился на поиске другого аналогичного многофункционального удалённого клиента под Linux. В принципе, я не против перейти и на другой сервис, такой как Google Drive или AWS S3. Некоторые из возможных вариантов — overGrive и insync.
Однако я пришёл к выводу, что эти решения излишне функциональны и не очень подходят для моего случая.
Например, клиенты пытаются подключить удалённую файловую систему к вашему ПК. Они очень стараются абстрагировать удалённые файловые системы, делая их похожими на локальные. Как правило, они реализуют двустороннюю синхронизацию, автоматическое сопоставление удалённых типов файлов с типами файлов Linux и т. д.
Мне не нужен такой уровень абстракции. Требуется что-то простое, позволяющее постоянно создавать резервные копии заметок в облаке, пока я набираю текст. Кроме того, абстракции затрудняют настройку и отладку. Не говоря уже о том, что большинство этих многофункциональных клиентов проприетарные.
rclone
Мне попалась утилита
rclone
, и я сразу понял: это именно то, что я искал. Простая, но мощная программа. Очень похожа на инструмент rsync
, только для облачного хранилища.Например,
rclone
заботится об отказоустойчивости (проверка целостности), имеет эффективные алгоритмы синхронизации и так далее, при этом предоставляет простой CRUD-интерфейс для взаимодействия с популярными сервисами облачного хранения, включая Amazon S3, Google Drive и Dropbox.Следующая команда синхронизирует удалённый каталог
org
с локальным каталогом /home/lpan/org
.ORG_DIR=/home/lpan/org
REMOTE=dropbox
rclone sync $ORG_DIR $REMOTE:org
entr
Утилита для выполнения команд entr использует API inotify. По сути, она запускает команды при изменении файлов без опроса файловой системы.
Один из распространённых способов использования — пересборка проекта, если изменился какой-то из исходных файлов.
entr
берёт список абсолютных путей из stdin
, а затем выполняет команду, переданную в качестве аргумента, если изменился любой из наблюдаемых файлов.WORKDIR=/path/to/myproject
find $WORKDIR | grep "\.cpp$" | entr make
Однострочный скрипт
Теперь у нас есть
rclone
и entr
. Итоговый скрипт получился очень простым. Напомню, что мой вариант использования Dropbox очень простой: требуется лишь постоянно реплицировать локальные файлы Org при их изменении. Поэтому можно использовать entr
для мониторинга файлов и rclone
для «синхронизации» с удалённым хранилищем.Итоговый скрипт (
/home/lpan/sync_dropbox.sh
) выглядит следующим образом:#!/bin/bash
ORG_DIR=/home/lpan/org
REMOTE=dropbox
find $ORG_DIR | entr -r rclone sync -v $ORG_DIR $REMOTE:org
Запускаем демон
Демон — это просто компьютерная программа, которая работает в фоновом режиме. Сделаем наш скрипт фоновым процессом, чтобы он постоянно синхронизировал с удалённой файловой системой локальные изменения файлов в фоновом режиме.
systemd обеспечивает интерфейс для управления процессами демона.
Я создал Dropbox Service в
~/.config/systemd/user/dropbox.service
.[Unit]
Description=Dropbox Daemon
[Service]
ExecStart=/home/lpan/sync_dropbox.sh
Restart=always
[Install]
WantedBy=default.target
Затем можно управлять демоном с помощью следующих команд:
# reload the service file
systemctl --user daemon-reload
# start the daemon
systemctl --user start dropbox.service
# start the daemon on login
systemctl --user enable dropbox.service
# inspect the status of the daemon
systemctl --user status dropbox.service
Вывод
В этой статье мы обсудили, как применить философию UNIX и использовать набор бесплатных инструментов с открытым исходным кодом для замены проприетарного и устаревшего клиента Dropbox. Мы применили
rclone
и entr
. Я также показал, как сделать этот процесс демоном и управлять им с помощью systemd
.Хочу напомнить, что ключевая идея — простота. Мы хотим простые решения для простых задач. Мой вариант использования Dropbox очень простой. И вот почему однострочный скрипт лучше, чем использование излишне функционального и проприетарного облачного клиента.
Большое спасибо за чтение! Очень надеюсь, что вам понравится этот пост. Если знаете лучший способ сделать то же самое или расширить скрипт для другого варианта использования — дайте знать в комментариях!