четверг, 31 июля 2008 г.

Настройка веб-интерфейса Clutch

В предыдущей статье я описал настройку торрент-клиента transmission-daemon, в этой статье я опишу как я настраивал веб-интерфейс к transmission-daemon.

Первым делом устанавливаем веб-сервер lighttpd, php и php-расширение json.
# apt-get install lighttpd php5-cgi php5-json
Включаем модуль fastcgi веб-сервера lighttpd:
# lighty-enable-mod fastcgi
Заменяем в конфигурации модуля /etc/lighttpd/conf-enabled/10-fastcgi.conf
интерпретатор PHP4 на PHP5:
fastcgi.server = (
  ".php" => 
  (
    (
      "bin-path" => "/usr/bin/php5-cgi",
      "socket" => "/tmp/php.socket",
      "max-procs" => 2,
      "idle-timeout" => 20,
      "bin-environment" =>
      ( 
        "PHP_FCGI_CHILDREN" => "4",
        "PHP_FCGI_MAX_REQUESTS" => "10000"
      ),
      "bin-copy-environment" =>
      (
        "PATH",
        "SHELL",
        "USER"
      ),
      "broken-scriptfilename" => "enable",
      "check-local" => "disable"
    )
  )
)
Перезапускаем веб-сервер:
# /etc/init.d/lighttpd restart
При перезапуске сервер ругается, что расширение json уже загружено!

Комментируем строчку, отвечающую за загрузку расширения json в файле /etc/php5/cgi/php.ini:
;extensions=json.so
Снова перезапускаем веб-сервер:
# /etc/init.d/lighttpd restart
Переходим в каталог /root, качаем дистрибутив Clutch:
# cd /root/
# wget http://clutchbt.com/Files/Clutch-0.4.tar.gz
Распаковываем дистрибутив:
# tar xzvf Clutch-0.4.tar.gz
Меняем владельца и группу на пользователя и группу, под которыми работает веб-сервер:
# chown -R www-data:www-data Clutch-0.4
Переходим в каталог, где хранится файл настройки сокета для связи с transmission-daemon:
# cd Clutch-0.4/remote/data/
Прописываем в файле socket полный путь к сокету transmission-daemon:
/tmp/transmission.socket
Переходим в каталог веб-сервера:
# cd /var/www/
Делаем линк на веб-интерфейс:
# ln -s clutch /root/Clutch-0.4
Пробуем зайти в браузере по адресу: http://localhost/clutch/

Видим, что веб-интерфейс открывается, но java-скрипты не работают.

Я потратил довольно много времени на проверки, всё ли я сделал правильно. Сделал страницу phpinfo.php с содержимым "" Попробовал в браузере открыть эту страницу: расшинения json и sockets были включены. Попробовал прикинуться веб-сервером с помощью команды su - www-data и проверить, имею ли я доступ к сокету transmission-daemon, имею ли я доступ на запись в каталог /root/Clutch-0.4/remote/data/.

Потом я решил проверить работоспособность самого веб-интерфейса Clutch с помощью расширения Firebug для Firefox увидел, что Firebug ругается на ошибку в одном из java-скриптов.

Я решил скачать самую свежую версию Clutch прямо из svn-репозитория проекта. Установил subversion:
# apt-get install subversion
Перешёл в каталог /root/ и скачал репозиторий:
# cd /root/
# svn co http://svn.recurser.com/transmission/trunk clutch
Заглянул в каталог /root/clutch и увидел, что туда скачался интерфейс cocoa для MacOSX, исходники веб-сервера lighttpd, и нужный мне web-интерфейс.
Скопировал нужный мне раздел с web-интерфейсом
# cp clutch/branches/rpc/web/ clutch-web
Далее опять поменял владельца:
# chown -R www-data:www-data clutch-web
Отредактировал файл clutch-web/remote/data/socket:
/tmp/transmission.socket
В каталоге /var/www удалил прежнюю ссылку, добавил новую:
# rm clutch
# ln -d /root/clutch-web clutch
Попробовал зайти через веб-интерфейс по адресу http://localhost/clutch/ снова. И, о чудо, он наконец заработал.

Тарболл с веб-интерфейсом можно скачать здесь: clutch-web.tar.gz

Осталось защитить веб-интерфейс паролем, чтобы разные злобные буратины не хозяйничали на моём веб-интерфейсе.

Подключаем к веб-серверу модуль auth:
# lighty-enable-mod auth
В конфигурации модуля /etc/lighttpd/conf-enabled/10-auth.conf прописываем:
auth.backend = "htdigest"
auth.backend.htdigest.userfile = "/etc/lighttpd/htdigest" 

auth.require  = (
  "/clutch" => 
  ( 
    "method" => "digest",
    "realm" => "Clutch",
    "require" => "user=admin"
  )
)
И с помощью скрипта lightdigest.sh, взятого с сайта lighttpd, устанавливаем пароль для пользователя admin и рилма Clutch:
# lightdigest.sh -u admin -p password -r Clutch
Скрипт для генерирования файла htdigest можно взять здесь: lightdigest.sh

Ну вот, пожалуй, и всё!

Дополнение от 8 октября 2009 года:

Transmission всех версий выше 1.22 имеет новый способ управления. Теперь для управления демоном используется не сокет-файл, а HTTP-сервер, работающий по умолчанию на TCP-порту 9091. Сервер поддерживает digest-авторизацию, управление осуществляется с помощью какой-то разновидности протокола RPC. Также на этом HTTP-сервере имеется встроенный Web-клиент для управления Transission, старый знакомый Clutch, который доступен при подключении браузером к серверу. Никаких особых настроек не требуется, в squeeze демон снабжён init-сценарием для запуска.

воскресенье, 27 июля 2008 г.

Настройка торрент-клиента transmission-daemon в Debian

Торрентом я начал интересоваться несколько месяцев назад, как только у меня появился безлимитный интернет. Как ни печально это для других протоколов, но торрент показал себя как самое надёжное средство для скачивания объёмных данных, например, DVD-образов любимого мною Debian'а.

Захотелось мне выделить под торрент-клиент отдельную Linux-машинку под Debian, благо есть старый системный блок на котором это можно сделать.

Начал я с обзора торрент-клиентов под Linux:
Torrent клиенты в Linux

Я со своей идеей оказался не одинок, многим другим людям пришла в голову та же мысль. Вариантов программ без GUI оказалось немного - rtorrent c ncurses-интерфейсом, мультипротокольный p2p-демон mldonkey, transmission-daemon и btpd.

rtorrent можно запустить в screen-сессии, а можно, в добавок к этому, ещё и прикрутить к нему web-интерфейс:
В общем-то не самый плохой вариант, но мне запуск ncurses-программы в сессии screen не кажется кошерным.

В процессе дальнейших копаний материалов на эту тему решил, что mldonkey также мне не подходит, поскольку он, судя по отзывам, часто падает.

Есть ещё некий btpd, копать в направлении которого мне не захотелось, поскольку я уже подобрал подходящий вариант, о котором ниже. Если кому-то будет интересно узнать что-либо о btpd, прошу рассказать о результатах копания мне :)

Наконец был найден подходящий вариант, основанный на transmission-daemon и AJAX веб-интерфейсе Clutch:
Clutch

Вот, кстати, краткое описание консольного клиента, демона и утилиты управления демоном torrent:
Торрент-клиент Transmission

Этот вариант и был выбран в качестве наиболее перспективного, для дальнейшего изучения были скачаны руководства по установке связки transmission и Clutch:
В Debian Etch поставить transmission без GTK оказалось непросто, т.к. пакета без GTK-интерфейса в репозитарии не было. Я написал инструкцию по сборке пакета без GTK-клиента, но теперь она не нужна, т.к. в Lenny пакет transmission был разделён на три части:
  1. transmission-common - содержит различные README, информацию о лицензии и т.п.,
  2. transmission-cli - содержит демон, утилиту для правления демоном, прокси и простой консольный клиент, который может работать отдельно от демона,
  3. transmission-gtk - графическая утилита для управления демоном, использующая GTK.
Установим пакет transmission-cli:
# aptitude install transmission-cli
Однако, как и в Etch, в Lenny нет скрипта для запуска и остановки демона и нет конфигурационного файла для его настройки. Я написал, как мне кажется, довольно гибко настраиваемый скрипт для запуска transmission-daemon. Скачать его можно здесь: transmission.sh

Помещаем скрипт в каталог /etc/init.d/.

Для настройки опций запуска демона используется специальный конфигурационный файл, шаблон которого можно взять здесь: transmission.conf
По-умолчанию я выставил те настройки, которые, как мне показалось, будут подходящими большинству пользователей.

Для себя же я поменял настройки так:
TORRENT_DIR=/home/torrents/
PORT_MAPPING=disable
USER=www-data
GROUP=www-data
Запускаем демон вручную:
# /etc/init.d/transmission.sh start
Осталось добавить этот скрипт в автозагрузку и автовыгрузку.
# update-rc.d transmission.sh defaults
Всё, на этом первая статья завершена. В следующей статье расскажу, как я настраивал веб-интерфейс Clutch к transmission-daemon.

Последнее обновление 26 февраля 2009 года.

Дополнение от 8 октября 2009 года:

Transmission всех версий выше 1.22 имеет новый способ управления. Теперь для управления демоном используется не сокет-файл, а HTTP-сервер, работающий по умолчанию на TCP-порту 9091. Сервер поддерживает digest-авторизацию, управление осуществляется с помощью какой-то разновидности протокола RPC. Также на этом HTTP-сервере имеется встроенный Web-клиент для управления Transission, старый знакомый Clutch, который доступен при подключении браузером к серверу. Никаких особых настроек не требуется, в squeeze демон снабжён init-сценарием для запуска.

вторник, 1 июля 2008 г.

Настройка ADSL-моста, PPPoE во FreeBSD, два провайдера

Сегодня я долго и со смаком занимался любовью с ADSL-модемом ZyXEL Prestige 660.

У нашей компании имеется собственный VPN-сервер (PPTP), к которому подсоединяются через Интернет наши сотрудники в других городах для получения доступа к корпоративной сети. Причём VPN-сервер подключен к Ethernet-провайдеру, а большинство сотрудников ходят через ADSL-провайдера.

Недавно мы узнали, что у ADSL-провайдера внутренний трафик бесплатный и не имеет ограничения по скорости. Поскольку платить за каждый мегабайт Интернет-трафика сразу двум провайдерам довольно дорого, то имеет смысл разместить VPN-сервер в сети ADSL-провайдера.

Конечно качество ADSL-связи не сравнится с качеством Ethernet. ADSL имеет максимальную входящую скорость 8Mbit/s, а исходящую - максимум 1Mbit/s. Таким образом два модема на разных концах соединения ограничивают и входящую и исходящую скорость соединения до 1Mbit/s в каждую сторону.

Подключение к ADSL-провайдеру у нас уже имелось, но до этого модем использовался только в режиме роутера. При этом любой компьютер, выходящий в Интернет через такой модем, автоматически оказывается за NAT'ом. Естественно за NAT'ом бесполезно запускать какой-либо сервер, к нему никто не сможет подключиться. Да, конечно, у многих модемов есть функция проброса TCP-соединений вовнутрь, которая во многих случаях может выручить. Но у VPN-сервера кроме управляющего TCP-соединения на 1723 порту есть ещё двунаправленный поток GRE-пакетов, которые несут полезную нагрузку в виде PPP-пакетов. В этом случае простым пробросом TCP-портов уже не обойтись, поэтому ADSL-модем нужно было перенастроить в режим моста.

В режиме моста модем выполняет разбивку и упаковку кадров Ethernet, поступивших на его Ethernet-порт, внутрь ячеек ATM. Ячейки ATM передаются в направлении провайдера, где и обрабатываются. Для ячеек ATM, приходящих от провайдера, модем выполняет обратные действия: извлекает и собирает частей кадр Ethernet, который отправляет через свой Ethernet-порт.

Но это ещё не всё! Быть может вы подумали, что достаточно на сетевой карте компьютера настроить IP-адрес, маску, шлюз, прописать DNS, как сразу же всё заработает? Нет, компьютер должен установить с провайдером соединение PPPoE, то есть PPP over Ethernet.

Вот именно с этим пунктом у меня и возникли трудности, ни с сервера FreeBSD ни с компьютера Windows соединение установить не удавалось. Я перерыл все настройки модема, перерыл по-интернета, перечитал различные варианты настройки PPPoE-клиента. Перечитал кучу инструкций по настройке различных ADSL-модемов в режиме моста, пробовал поменять модем. Ничего не помогало.

Огромное спасибо одному из специалистов ADSL-провайдера, который действительно вник в суть проблемы, а не предложил в очередной раз сбросить модем на заводские настройки и перепроверить VPI/VCI. В течение около пяти-восьми минут с моих слов он понял, что модем не хочет работать в режиме моста и попросил прверить настройки инкапсуляции. В настройках инкапсуляции должен был значиться RFC1483, у меня же стоял PPPoE.

Я как чайник в технологиях телефонии и как человек, до этого никогда не настраивавший ADSL-модем в режиме моста, совершенно спокойно игнорировал этот пункт. Как только я его поменял, соединение сразу же установилось. Так же легко установилось заранее настроенное соединение на FreeBSD.

От себя добавлю следующее. Чтобы легко и без глюков можно было пользоваться обоими провайдерами, нужно в фаерволл ipfw прописать правила PBR (Policy Based Routing):
ipfw add fwd Gateway1 ip from IP1 to any
ipfw add fwd Gateway2 ip from IP2 to any
Чтобы не получилось так, что в сеть одного из провайдеров уходили пакеты с IP-адресом другого.

Если же машинка выполняет функции NAT-шлюза, то на каждом внешнем интерфейсе нужно запустить по одному экземпляру natd. Кошерно это делается через rc.conf так:
natd_program="/sbin/natd"
natd_enable="YES"
natd_interface="rl0"
natd_flags="-s -f /etc/natd.conf"

ppp_enable="YES"
ppp_mode="ddial"
ppp_nat="YES"
ppp_profile="provider"
Только одно соединение должно устанавливать маршрут по умолчанию. Поэтому через второго провайдера можно назначить специальные маршруты, которые будут указывать на подсети этого провайдера. Выяснить подсети, принадлежащие провайдеру, можно покопавшись на его официальном сайте либо через whois.

Приведу несколько полезных, на мой взгляд, ссылок.
  1. Страница хэндбука FreeBSD, посвященная настройкам PPPoE:
    Использование PPP через Ethernet (PPPoE)
  2. Довольно доходчивое описание протокола PPPoE, позволяющее как минимум понять общие принципы его работы:
    Метод передачи РРР через Ethernet (PPPoE)
  3. Продвинутая настройка PPPoE на FreeBSD:
    Настройка PPPoE на FreeBSD (нужна регистрация на сайте)
  4. Статья в журнале "Системный администратор" об использовании двух каналов:
    Два канала – роскошь? Резервирование и балансировка трафика во FreeBSD