По результату обсуждения о развитии коробочных решений, было решено подготовить расширение сервера ALT Linux Ковчег с применением сервиса settingsd. Задача: дать возможность пользователю после установки системы настроить удалённый торрент клиент, запускаемый через web-interface. В качестве Web-сервиса решено использовать rutorrent. Для торрент клиента настраивается samba-шара. В настройках rutorrent можно указать отслеживаемый каталог для торрент файлов. В качестве бекенда rutorrent использует rtorent, который обычно запускается в screen'е. Это нужно оформить в виде init.d сервиса.
Изучал программу: http://code.google.com/p/rutorrent Посмотрел еще transmission, тоже довольно популярное решение, но у rutorrent возможностей побольше.
Сервер я поставил и разобрал некоторые его особенности "из коробки". Далее требуются: - модуль для Samba. В P5 его нет, а на текущем Сизифе он мне пишет: Backend: Unable to find workflow form - модуль настройки торрент клиента. Видимо, для каждого клиента (rutorrent, transmission, etc.), отдельного. - упаковать web-интерфейс торрент-клиента в пакет (для rutorrent нужно добавить сервис rtorrent'а в screen'е, для transmission web-интерфейс тоже не упакован); - механизм добавления наших репозиториев и установки наших расширений. Тут, во-первых, не предусмотрено возможностей для расширения пакетной базы из web-интерфейса, во-вторых установки дополнительного ПО. Так что консоль и apt-get в помощь, для чего нужно после установки сервера: + задать, через web-интерфейс, через руту пароль; + создать, через web-интерфейс, нового пользователя и задать ему пароль (за раз, как можно подумать, эта операция не проходит, чему я был удивлён); + добавить, через web-интерфейс, нового пользователя в группу wheel (иначе не работает su); + далее войти по ssh на сервер и войти через su- в рута. - продумать механизм обновления наших базовых пакетов для обновлений (apt-conf-etersoft-p5 и etersoft-gpgkeys, которые нужно бекпортировать на P5) - продумать функционал и ограничения, а затем добавить модули альтератора, чтобы увидеть самбу и торрент-клиент в web-интерфейсе альтератора.
Думаю, что пока обойдемся rutorrent`ом, у него возможностей более чем достаточно.
Запаковал rutorrent в пакет. Инит-скрипты и пример конфига для lighttpd будут лежать отдельно.
У rutorrent есть два режима установки: многопользовательский и монопольный. В случае многопользовательского режима, он может работать интерфейсом к нескольким клиентам rtorrent: -------------- http://code.google.com/p/rutorrent/wiki/Config#%D0%9F%D1%80%D0%BE%D1%87%D0%B5%D0%B5 http://code.google.com/p/rutorrent/wiki/WebSERVER#Lighttpd http://code.google.com/p/rutorrent/wiki/Config#%D0%9C%D0%BD%D0%BE%D0%B3%D0%BE%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D1%82%D0%B5%D0%BB%D1%8C%D1%81%D0%BA%D0%B0%D1%8F_%D0%B8_%D0%BE%D0%B4%D0%BD%D0%BE%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7 -------------- Вопрос заключается в том, будем ли мы поддерживать этот режим работы. Я считаю, что клиент должен быть многопользовательским, таким образом, мы сможем разграничить данные каждого из пользователей. В монопольном же режиме, у нас будет одна общая шара для всех пользователей. Давайте решать, как это будет выглядеть в конечном итоге.
как то слабо себе представляю на домашнем сервере необходимость скачивать под разными пользоватлелями... как возможность это конечно может быть, но не думаю, что это может быть реально восстребовано. ПОэтому если это не сущетсвенно по доп затратам и не усложняет интерфейс (а мне кажется усложняет), то можно с ним.
Думаю двигаться стоит последовательно. Сейчас нам нужна "одна общая шара для всех пользователей". Вообще я не совсем понимаю откуда пользователи возьмутся? В самом первом приближении, причём это то, что нужно большинству. Нужна одна общая шара для всех для просмотра/прослушивания/скачивания и один web-ресурс для управления. Torrent файлы можно держать в отдельном каталоге общей шары, а можно в отдельной шаре. Копирование торрент-файла в каталог может автоматически запускать закачку.
Мне тоже кажется, что с одним пока надо сделать. Отлично, так и поступим.
Собрал пакет с сервисом для rtorrent, лежит у нас в репозитории под названием rtorrentd. Настраивается через файл /etc/sysconfig/rtorrent. Там можно задать пользователя, от имени которого будет работать сервис и несколько других параметров. Так же можно передать опции командной строки ля rtorrent, вместо использования файла .rtorrent.rc. Поправил кривые зависимости в rutorrent. Настроил lighttpd, однако дальше выяснилась неприятная проблема: ------------------- [mdevaev@testing ~]$ rtorrent -o scgi_port=localhost:5000 Caught Segmentation fault, dumping stack: Stack dump not enabled. Аварийный останов ------------------- То есть, программа не хочет работать через scgi. Опция локального сокета sock_local выдает такой же результат. В Федоре работает нормально. В Сизифе используется unstable-вариант rtorrent`а, 0.8.7, в то время, как стабильная версия - 0.8.6. http://libtorrent.rakshasa.no/ http://forums.rutorrent.org/index.php?topic=540.0 http://code.google.com/p/rutorrent/issues/detail?id=43 Судя по багам, проблема так же может быть в некорректных либах xmlrpc. Нужно попробовать использовать предыдущие версии из Альта 5.0. Кроме того, я думаю, что для большей безопасности, работать нужно через unix socket с соответствующими правами, чтобы кто попало не мог подсоединиться к серверу rtorrent, даже локально.
rtorrent заработал из 5.1 с соответствующими библиотеками из xmlrpc. Настроил права доступа, добился работоспособности rutorrent через порт scgi localhost:5000, потом добавил новые параметры в конфигурацию rtorrent, чтобы он мог работать через локальный сокет. Исправил в стартовом скрипте несколько багов. Пересобрал пакеты для сизифа и для 5.1. Теперь настройка сводится к установке пакета rutorrent (остальное подтянется зависимостями), выполнению команд: ------------------ chown lighttpd /var/www/rutorrent/share/{settings,torrents} sed -i -e 's/rtorrent:rtorrent/rtorrent:lighttpd/g' /etc/sysconfig/rtorrent sed -i -e 's/$scgi_port = 5000;/$scgi_port = 0;/g /var/www/rutorrent/conf/config.php sed -i -e 's/$scgi_host = "127.0.0.1";/$scgi_host = "unix:///tmp/rtorrentd.sock";/g' /var/www/rutorrent/conf/config.php ------------------ Так же требуется настроить lighttpd. В конфиге последнего замечено несколько багов, в Альте его неправильно составили, нужно сообщить им в багзиллу. Протестировал закачку и раздачу на большом и маленьком файлах. Все работает корректно. Посмотреть можно здесь: http://testing/rutorrent/ Единственное, что после остановки сидирования, файлы попадают в категорию "Ошибка". Видимо, это бага старого rtorrent.
Изменил пакет для соответствия политике веб-приложений: http://www.altlinux.org/Web_Policy Пропатчил пакет, чтобы по умолчнанию использовались параметры работы через локальный сокет, а не 5000`ный порт. Собрал пакет rutorrent-lighttpd, предоставляющий конфиг /etc/lighttpd/conf.d/rutorrent.conf, содержащий в себе записи для rutorrent и fastcgi, нужного для него. Отписался в багзилле Альтлинукса на тему некорректности конфигурации по-умолчанию: https://bugzilla.altlinux.org/show_bug.cgi?id=24775 Настройка сейчас водится к: -------------- apt-get install rutorrent-lighttpd chown lighttpd /var/www/rutorrent/share/{settings,torrents} sed -i -e 's/rtorrent:rtorrent/rtorrent:lighttpd/g' /etc/sysconfig/rtorrent service rtorrentd start service lighttpd start -------------- Нынешняя конфигурация в достаточной степени безопасна. Для того, чтобы пользователь мог получить доступ к загрузкам и торрент-файлам, его необходимо добавить в группу rtorrent. Веб-сервер соединяется с rtorrent через локальный сокет с ограниченными правами.
(In reply to comment #11) [...] > chown lighttpd /var/www/rutorrent/share/{settings,torrents} > sed -i -e 's/rtorrent:rtorrent/rtorrent:lighttpd/g' /etc/sysconfig/rtorrent [...] > Не совсем понятно, зачем так делать. Получается, что для кажлого вида http-сервера нужно отдельно менять права группы. Логичнее добавить пользователя lighttpd в группу rtorrent или специальную группу rtorrentd, чтобы разделить права пользователей от прав сервисов. Тогда любой http-сервис потребуется добавлять в группу rtorrentd и это будет единственный необходимый механизм, не требующий указания всех файлов, к которым нужно предоставить доступ для работы web-интерфейса. В альтах, для всех псевдопользователей веб-сервисов, сейчас предусмотрена специальная группа _webserver. В сочетании с модулем ролей, установка нужных прав сводится к добавлению группы rotorrentd в группу _webserver, что означает предоставление привилегии rotorrentd роли _webserver. > Нынешняя конфигурация в достаточной степени безопасна. Для того, чтобы > пользователь мог получить доступ к загрузкам и торрент-файлам, его необходимо > добавить в группу rtorrent. Веб-сервер соединяется с rtorrent через локальный > сокет с ограниченными правами. При варианте использования через Samba-шару остаётся сделать саму шару с правами на запись в каталог /var/lib/rttorrent/downloads. Для этого нужно, чтоб модуль настройки samba умел выставлять force user. Ещё один вариант использования предполагает локальный доступ к закачанным файлам. Для этого, чтобы иметь права на удаление или переименование, нужно не только в группу входить, но права на запись для этой группы держать выставленными. Здесь нужны umask=0022 и setgid на группу rtorrent для каталога закачки. Из настроек rutorrent хотелось бы выделить: - возможность установки каталога для закачки. rutracker это сам умеет через web-интерфейс, но там нужно точно указать полный путь. Кроме того права пользователя rtorrent должны быть тоже выставлены. - возможность указания отслеживаемого каталога с torrent-файлами, для автоматического подхвата (опция schedule) Отмечу ещё, что как-то не очень красиво держать локальный сокет в /tmp/rtorrentd.sock. Ему место где-то в /var/run - там же, где и dbus держит свой сокет. Кстати, в сизифе rtorrent сломан и я не понимаю в чём там дело. Не стабильная версия 0.8.7 падает при доступе через scgi_port. Через scgi_local - у меня вообще ничего не запустилость - rutorrent не может достучаться до rtorrent: [20.12.2010 05:12:45] WebUI started. [20.12.2010 05:12:46] Bad response from server: (403 [error,getplugins]) <?xml version="1.0" encoding="iso-8859-1"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head> <title>403 - Forbidden</title> </head> <body> <h1>403 - Forbidden</h1> </body> </html> [20.12.2010 05:12:47] Bad response from server: (403 [error,getuisettings]) <?xml version="1.0" encoding="iso-8859-1"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head> <title>403 - Forbidden</title> </head> <body> <h1>403 - Forbidden</h1> </body> </html> Я откатил rtorrent до 0.8.6, чтобы он зарботал через 127.0.0.1:5000. В общем с ходу на сизифе не работает.
> Не совсем понятно, зачем так делать. Получается, что для кажлого вида > http-сервера нужно отдельно менять права группы. Логичнее добавить пользователя > lighttpd в группу rtorrent или специальную группу rtorrentd, чтобы разделить > права пользователей от прав сервисов. Веб-сервер должен иметь доступ на запись только к изменяемым данным веб-приложения. Включив lighttpd в группу rtorrent, мы автоматически выдаем доступ на запись в каталоги rtorrent. Зачем это? С другой стороны, можно применить схему, в которой у нас есть две группы, rtorrentd и rtorrent. В первую входят пользователи плюс вебсервер, во вторую - только пользователи. Права выставить соответствующие. Но это какой-то огород. У нас есть замечательное поле для владельца файла, которое можно использовать. Я не вижу причин от этого отказываться, учитывая, что это удобно. На коробочке у нас не будет использоваться десять веб-серверов и включить в сценарий настройки установку правильной группы - не проблема. Если сейчас начать мутить что-то с группами, то мы получим такую же глупость с правами, как в Альтовском веб-полиси: http://www.altlinux.org/Web_Policy . Исходя из него получилось, что у файлов должно быть две группы: _webserver и webmasters. И владелец root. Проблема нерешаема. В контексте Альта, я бы предложил все сервера (lightpd, apache, nginx) запускать из-под специального пользователя webserver и группы webserver. Пересечений между серверами почти никогда не бывает, а даже если и будет, то это не критично. Пока так не сделали, я предлагаю ставить владельцем именно веб-сервер. Еще раз, проблем вставить эту строчку в настройку системы нет никаких. Что касается группы сокета - то тут без разницы, lighttpd это или _webserver. > Ещё один вариант использования предполагает локальный доступ к закачанным > файлам. Для этого, чтобы иметь права на удаление или переименование, нужно не > только в группу входить, но права на запись для этой группы держать > выставленными. Здесь нужны umask=0022 и setgid на группу rtorrent для каталога > закачки. Хорошая мысль. > Из настроек rutorrent хотелось бы выделить: > - возможность установки каталога для закачки. rutracker это сам умеет через > web-интерфейс, но там нужно точно указать полный путь. Кроме того права > пользователя rtorrent должны быть тоже выставлены. Не понял, закачки куда? Или имя для _подкаталога_, в который нужно выкачать торрент? > - возможность указания отслеживаемого каталога с torrent-файлами, для > автоматического подхвата (опция schedule). Ok. > Отмечу ещё, что как-то не очень красиво держать локальный сокет в > /tmp/rtorrentd.sock. Ему место где-то в /var/run - там же, где и dbus держит > свой сокет. Ok. > Кстати, в сизифе rtorrent сломан и я не понимаю в чём там дело. Не стабильная > версия 0.8.7 падает при доступе через scgi_port. Через scgi_local - у меня > вообще ничего не запустилость - rutorrent не может достучаться до rtorrent: > ... > Я откатил rtorrent до 0.8.6, чтобы он зарботал через 127.0.0.1:5000. В общем с > ходу на сизифе не работает. Да, есть такое, я еще в http://bugs.etersoft.ru/show_bug.cgi?id=6608#c9 об этом написал.
> > Ещё один вариант использования предполагает локальный доступ к закачанным > > файлам. Для этого, чтобы иметь права на удаление или переименование, нужно не > > только в группу входить, но права на запись для этой группы держать > > выставленными. Здесь нужны umask=0022 и setgid на группу rtorrent для каталога > > закачки. > Хорошая мысль. Реализовано патчем Жени > > - возможность указания отслеживаемого каталога с torrent-файлами, для > > автоматического подхвата (опция schedule). > Ok. То же самое > > Отмечу ещё, что как-то не очень красиво держать локальный сокет в > > /tmp/rtorrentd.sock. Ему место где-то в /var/run - там же, где и dbus держит > > свой сокет. > Ok. Переместил во всех пакетах в /var/run/rtorrentd.sock
Добавил в settingsd поддержку редактирования опций RTORRENT_CONFIG и raw-содержимого этого файла. Багу считаю решенной.
Для тех, кто не пользуется багзиллой или не умеет пользоваться групповым редактированием при поиске, закрываем задачи, которые они должны были принять.
