DropBox в Funtoo Linux
-
Внимание! Описанные здесь подходы и решения не являются руководством к буквальному следованию. Большая часть приведенных команд выполняются с привилегиями суперпользователя, а потому требуют внимания и четкого понимания. Если Вы не понимаете, что произойдет при выполнении той или иной из приведенных здесь команд - не выполняйте их! Часть, посвященная init-скрипту, предназначена только для для системы Gentoo/Funtoo и, возможно, подходит для некоторых Gentoo-based дистрибутивов. Не забывайте о бэкапе важных данных, в частности о данных хранящихся на Dropbox-аккаунте. В общем, я Вас предупредил и претензии вида: "Я сделал как здесь написано и у меня все поломалось!" - я не принимаю.
Вдохновившись хвалебными отзывами в интернетах вообще и на этом сайте в частности о сервисе DropBox (https://www.dropbox.com/), я решил тоже попользоваться этим замечательным сервисом.
Небольшое отступление о моей системе: у меня установлена Funtoo GNU/Linux (http://www.funtoo.org), unstable-ветка, это на 98% та же самая Gentoo, от того же Daniel Robbins, просто с небольшими доработками (Portage на основе git, а не rsync, GBUB2 вместо GRUB-Legacy и еще чуть-чуть). Но в целом, это все та же Gentoo. Ядро я использую 2.6.37-r2, графическое окружение - GNOME-2.32.
Вернемся к DropBox. В репозитории обнаружилось два с виду подходящих пакета: net-misc/dropbox и gnome-extra/nautilus-dropbox.
Установка gnome-extra/nautilus-dropbox не увенчалась успехом - одна из зависимостей не собралась из-за проблем с Unicode-ом - да ну и ладно.
Пробую net-misc/dropbox - вуаля, установка выполнена, но... это просто прекомпилированный пакет, без GUI, без man-page, с одним единственным README, в котором 99% - это текст лицензии. Есть только кучка библиотек, исполняемый файл dropbox, скрипт dropbox-launhcer, который запускает dropbox с пониженным приоритетом и dropdoxd - симлинк на dropbox-launcher. Все это легло в /opt/dropbox. А ну и еще симлинк на dropbox в /opt/bin. Вот и все.
Запускаю:
dropbox пытается соединиться, не знает куда и дает ссылку в интернеты. Иду по ссылке, попадаю на сайт DropBox, логин, пароль - ура, "The computer slims-pc was linked to your account". Ну да, сперва я, конечно, создал аккаунт на сервере :)slims@slims-pc ~ $ dropbox <Enter>
Процесс в фон сам не уходит, блокирует терминал, для завершения ждет Ctrl+C (вот это уже настораживает, надо будет добавлять & ).
Смотрю в домашний каталог - есть dot-папка .dropbox:
Пара сокетов, pid-файл с номером процесса, базы данных SQLite, сплошная бинарщина, ручной правке не подлежит.slims@slims-pc ~ $ ls -l .dropbox srw------- 1 slims users 0 Апр 4 09:17 command_socket -rw-r--r-- 1 slims users 5120 Апр 4 09:17 config.db -rw-r--r-- 1 slims users 4 Апр 4 09:17 dropbox.pid -rw-r--r-- 1 slims users 22528 Апр 4 09:17 filecache.db -rw-r--r-- 1 slims users 69 Апр 4 09:17 host.db srw------- 1 slims users 0 Апр 4 09:17 iface_socket drwxr-xr-x 2 slims users 6 Апр 4 09:17 l -rw-r--r-- 1 slims users 14336 Апр 4 09:17 sigstore.db -rw-r--r-- 1 slims users 168 Апр 4 09:17 unlink.db
Еще есть папка Dropbox:
Ага, вот это и есть синхронизированная папочка. Проверяю: что-то положить, что-то удалить. попробовать восстановить - работает.slims@slims-pc ~ $ ls -l Dropbox -rw-r--r-- 1 slims users 268860 Апр 2 17:18 Getting Started.pdf drwxr-xr-x 3 slims users 4096 Апр 2 17:18 Photos drwxr-xr-x 2 slims users 4096 Апр 2 17:18 Public
Но что-то все равно напрягает... Запускаю из-под рута - ну, точно: снова ссылка, привязка и у рута в домашней папке своя копия Dropbox и .dropbox. Напрашивается вопрос - зачем мне одному две копии одного и того же? -
Зачем мне одному две копии одного и того же?
А и правда зачем? Ведь root - это я, но, естесственно, я под рутом не сижу; slims - тоже я; больше никто на моей машине под "линуксом" не сидит. Делаем ход конем:
Если dropbox запущен - останавливаем (у всех пользователей), для одного из тех, кого линкуем копируем всё из ~/Dropbox в /home/Dropbox, а затем всем пользователям, которых мы хотим привязать к общей папке, выполняем:# Создадим отдельную директорию root@slims-pc ~ # mkdir -v /home/Dropbox root@slims-pc ~ # chown -v root:users /home/Dropbox root@slims-pc ~ # chmod -v 775 /home/Dropbox
Теперь у всех пользователей, у которых был создан такой симлинк, dropbox на самом деле будет использовать одну и ту же папку /home/Dropbox.root@slims-pc ~ # cd root@slims-pc ~ # rm -r ~/Dropbox root@slims-pc ~ # ln -sv /home/Dropbox
Внимание! Следует иметь ввиду, что эти пользователи должны использовать и один на всех аккаунт на сервере Dropbox. Если какой-либо пользователь имеет свой собственный аккаунт - ему симлинк создавать нельзя! Так что, возможно, есть смысл назвать общую папку не /home/Dropbox, а к примеру, /home/Dropbox-slims, или использовать бОльшую вложенность. Опять же, группу и права доступа надо устанавливать согласно своей ситуации и политике безопасности. Например, я мог сделать "chown -v root:slims /home/Dropbox" вместо "chown -v root:users /home/Dropbox". Владельца, наоборот, менять нельзя.
Можно вообще, для каждого Dropbox-аккаунта создать группу и соответственно им устанавливать права. Короче, думайте :)
Что же дает такой подход?
Достоинства:
- только одна копия синхронизированных файлов для разных профилей пользователя при условии использования ими одного аккаунта Dropbox (пока там лежит десяток фоток - не критично, а когда там 100+ ГБ? );
- процесс dropbox может (и должен, вообще говоря) быть запущен только из-под одной учетки, все остальные будут синхронизироваться автоматически.
Недостатки:
- относительная сложность настройки. Но это же Unix-way, не так ли: все есть файл, у файла есть права, правами управляет root и он знает, что делает ;)
P.S. В целях сохранности и доступности данных root-у симлинк тоже можно не создавать, т.к. у многих /home смонтирован отдельным разделом, а в однопользовательском режиме (recovery-mode) часто бывает доступен только корневой, а вот данные с Dropbox-а могут и понадобится (особенно, когда сам Dropbox запустить нет возможности). -
Как настроить Dropbox на автоматический запуск?
Рассмотрим пути запуска dropbox в Funtoo.
1. Ручной запуск:
Процесс стартует, синхронизация выполняется, но терминал блокирован, ждет Ctrl+C. Вывод - плохо, совсем не то, хотя мы точно знаем, что делаем, как и когда.slims@slims-pc ~ $ dropbox <Enter>
2. Ручной фоновый запуск:
Процесс стартует, синхронизирует, терминал не блокирован - процесс в фоне, убивать через kill или системный монитор графической оболочки. Вывод - уже лучше, но главное - не забыть запустить.slims@slims-pc ~ $ dropbox & <Enter>
3. Ручной запуск из графической оболочки:
Alt+F2, ввести команду "dropbox", галочку "Запустить в терминале" не ставить. Полностью аналогчно п.2.
4. Автоматический запуск в графической оболочке.
Для GNOME: Система -> Параметры -> Запускаемые приложения -> Добавить -> "Имя: Dropbox Service Команда: dropbox Описание: ну сами что-нибудь напишите" -> поставить галочку в списке.
Вывод: гораздо лучше, сервис стартует вместе с "гномом". Минусы: 1) в случае одновременного графического логина нескольких пользователей с одним Dropbox-аккаунтом возможны конфликты самого "дропбокса" из-за общей папки синхронизации; 2) автозапуск, вероятно, придется настраивать отдельно для каждой графической среды (GNOME, KDE и т.д.); 3) и самое неприятное - в случае невозможности/нежелания графического входа, в голом терминале все равно придется запускать вручную.
5. Автоматический запуск на уровне инициализации системы.
В Gentoo/Funtoo (а также Calculate, Sabayon) можно:
a) использовать файл /etc/conf.d/local
b) можно написать скрипт, скажем /etc/init.d/dropbox-service, а затем использовать его как любой другой rc-скрипт:# rc-update add dropbox-service default
Вот вариант 5b я использую у себя, о чем и хочу рассказать.
Начальные условия: у меня есть аккаунт Dropbox и рабочая учетная запись slims, под рутом тоже иногда приходится работать. Поэтому у меня создана общая папка /home/Dropbox, а домашних папках рута и юзера симлинки ~/Dropbox указывают на неё (см. предыдущий пост)
Итак, из-под рута:# Пишем скрипт root@slims-pc ~ # echo > /etc/init.d/dropbox-service << EOF #!/sbin/runscript # Copyright (c) 2011 Sergej Naidjonov <slims.ua@gmail.com> # All rights reserved. Released under the 2-clause BSD-license. depend() { need net localmount } start() { ebegin "Starting Dropbox service" start-stop-daemon --start --quiet --exec /opt/dropdox/dropbox-launcher & eend ${?} } stop() { ebegin "Stopping DropBox service" start-stop-daemon --stop --quiet --pidfile /root/.dropbox/dropbox.pid eend ${?} } EOF # Разрешаем исполнение скрипта root@slims-pc ~ # chmod +x /etc/init.d/dropbox-service # Проверяем root@slims-pc ~ # /etc/init.d/dropbox-service start * Starting DropBox service [ ok ] # Если увидели OK, добавляем в автозапуск root@slims-pc ~ # rc-update add dropbox-service default
Несколько пояснений.
1. need net - сервис dropbox должен запускаться только после сетевых интерфейсов.
2. need localmount - поскольку у меня /home находится на отдельном разделе и монтируеися через /etc/fstab, то сервис dropbox должен запускаться только после монтирования /home.
3. start-stop-daemon --stop --quiet --pidfile /root/.dropbox/dropbox.pid - сервис стартует с правами рута, поэтому и pid-файл находится в /root/.dropbox
Поскольку и /root/Dropbox и /home/slims/Dropbox являются симлинками на одну и ту же папку, то slims может управлять содержимым своей /home/slims/Dropbox, а синхронизироваться она будет процессом рута.
4. В данном случае юзеры slims можно вообще не запускать dropbox самому и тогда можно ~/.dropbox удалить. После удаления dropbox запускать можно только привязывая его к тому же самому аккаунту.
5. Пользователям, имеющим другие аккаунты, используя пути запуска 1-4. -
Надеюсь, эта информация кому-нибудь покажется полезной. С радостью жду комментариев, критики и просто отзывов. Если есть необходимость, то могу попробовать в таком же ключе описать подход к запуску популярного Bittorrent-клиента uTorrent, Linux-версия которого пока существует только в виде прекомпилированного бинарника, да к тому же без GUI, а только сервер+Web-интерфейс.
С уважением, ваш SlimsUA. -
Интересное решение. Только вот малость запутанное и непонятно в принципе зачем это может понадобиться.
Оставив в стороне подключение нескольких пользователей (именно пользователей, не администраторов, вроде root) на один аккаунт в сервисе, хочется уточнить почему бы просто не заменить директорию Dropbox с файлами в /home/user на симлинк, ведущий на /root/Dropbox?
При таком варианте мы имеем и доступ рута к файлам в однопользовательском режиме и не плодим дубликаты. Права на просмотр и редактирование вложенных директорий в /root/Dropbox - это не проблема.
Такой вариант несоизмеримо проще и элегантнее, чем то, что вы предложили.
Или я что-то упускаю? -
Например, запустить таким образом настроенный клиент Dropbox на домашней "безголовой" файлопомойке, а с рабочего "настольника"/ноутбука получать доступ к синхронизированной папке по NFS/Samba не имея на них клиента Dropbox вообще. Тем самым экономя не только место, но и траффик. Я думаю, сервера Amazon-а будут благодарны.Alizeo:...непонятно в принципе зачем это может понадобиться...
Отвечу вопросом на вопрос. А как Вы относитесь к пользователям "той самой ОС", которые хранят свои фильмы на рабочем столе? Или ставят многогигабайтные игры в "C:\Program Files"? И как быть, если на одной машине установлены 2 ОС с разными root-разделами, но общим /home-разделом?Alizeo:почему бы просто не заменить директорию Dropbox с файлами в /home/user на симлинк, ведущий на /root/Dropbox?.. Такой вариант несоизмеримо проще и элегантнее, чем то, что вы предложили.
Или я что-то упускаю? -
Вообще, конечно, надо еще разбираться. В частности, сегодня вот увидел проблему: процесс клиента работает с EUID root-а, а потому файлы, полученные с сервера, получают права 644 и владельцем является рут (согласно стандартной маске umask 022), т.е. обычному пользователю доступны только для чтения.
Но я ведь предупреждал, что это не "руководство к действию", а "руководство к размышлению" -
Как раз о правах доступа я сразу и подумал. Но это решается одной строкой. Так что пропустим.
С доступом через Samba все просто и понятно. Или есть принципиальная разница куда самбой коннектиться?
А вот в примере с "той самой ОС" неясно ничего: При чем тут их рабочий стол или Program Files? Не станете же вы Program Files синхронизировать через сервис. Да и Рабочий стол суть у каждого свой должен быть.
В случае с общим /home: ну сделайте там основную директорию, а в /root симлинк поставьте.
Изначально мы рассматривали вариант когда и root, и пользователь одно лицо, в одной ОС пусть и на разных разделах. И мой вариант с симлинком тут предпочтительнее. В случае с 2 /root и общим /home мы просто переставим местами слагаемые, сумма-то не изменится. -
Да не принципиально. Я просто описал один из возможных способов использования такого изолирования клиента Dropbox, когда синхронизируется только лишь одна машина (локальная файлопомойка/прокси-сервер), а остальные домашние машины прозрачно синхронизированы с ней (используя локальные коммуникации).Alizeo:С доступом через Samba все просто и понятно. Или есть принципиальная разница куда самбой коннектиться?
В "C:\Program Files" акцент делался на на "Program Files", а на "C:\". Рабочий стол (за редкими исключениями) тоже на Це-диске. А использование системного раздела для хранения информации, не относящейся к функционированию этой системы - плохая практика. У меня, например, корневой раздел - всего 2ГБ, т.к. /boot, /home, /usr, /tmp и /var/tmp - вынесены на отдельные разделы, причем все они (кроме /usr) монтируются и в Funtoo, и в LFS.Alizeo:А вот в примере с "той самой ОС" неясно ничего: При чем тут их рабочий стол или Program Files? ... Да и Рабочий стол суть у каждого свой должен быть.
