пятница, 26 декабря 2008 г.

deb-пакет: тема arctic для dokuwiki

Воспользовавшись краткой статьёй по ссылке Как мне сделать собственный .deb пакет? и информацией из man deb-control собрал deb-пакет с темой arctic для dokuwiki. Возможно криво. Можно взять здесь: dokuwiki-arctic-theme_0.0.20081104_all.deb

вторник, 16 декабря 2008 г.

DNAT и Policy Based Routing (portmapping и два канала)

На системе с OpenVZ столкнулся с любопытной проблемой. Вообще-то OpenVZ здесь не при чём, эта проблема заключалась в архитектуре сети.

Итак, имеется маршрутизатор с двумя внешними соединениями на интерфейсах ppp0 и ppp1. На обоих интерфейсах настроен MASQUERADE. На этом же маршрутизаторе есть внутренний интерфейс eth0, смотрящий в локальную сеть 10.16.7.0/24. В локальной сети находится несколько серверов и другие компьютеры.
 ppp0 .--------.           .-----> web (10.16.7.2)
<-----O        | eth0      |
      | router |-----------|-----> proxy (10.16.7.3)
<-----O        | 10.16.7.1 |
 ppp1 `--------'           `-----> samba (10.16.7.4)
Правила MASQUERADE добавляются в таблицы таким образом:
# iptables -t nat -A POSTROUTING -o ppp0 -s 10.16.7.0/24 -j MASQUERADE
# iptables -t nat -A POSTROUTING -o ppp1 -s 10.16.7.0/24 -j MASQUERADE
Не буду вдаваться в подробности тарифов и таблиц маршрутизации, намеренно упрощу изложение. Допустим что сеть 172.16.0.0/16 является внешней и принадлежит провайдеру. Обращаться к этой подсети, за исключением адреса 172.16.0.1, выгодно через интерфейс ppp1. Ко всем остальным адресам, включая 172.16.0.1, выгодно обращаться через интерфейс ppp0.

Таким образом команды для создания этой таблицы маршрутизации должны быть такими:
# ip route add 172.16.0.1 dev ppp0
# ip route add 172.16.0.0/16 dev ppp1
# ip route add default dev ppp0
С трафиком из подсети 10.16.7.0/16 всё просто - он в любом случае будет замаскирован под IP-адрес того интерфейса, через который он пойдёт.

С трафиком с самого маршрутизатора во внешнюю сеть дела обстоят чуть сложнее. Маршрутизатор обладает двумя внешними IP-адресами и потому для исходящих соединений может выбирать адрес совершенно произвольно. Поэтому может случиться так, что соединение выберет в качестве исходного IP-адреса адрес на интерфейсе ppp0, а трафик в соответствии с таблицей маршрутизации будет уходить через интерфейс ppp1. Любой провайдер фильтрует трафик от клиентов, запрещая отправлять пакеты с того IP-адреса, который не принадлежит конкретно этому клиенту. Поэтому такие неправильные соединения будут автоматически блокированы.

Чтобы этого не случилось, к маршрутам можно добавлять предпочитаемые исходные IP-адреса. Это можно сделать такими командами:
# ip route add 172.16.0.1 dev ppp0 src ppp0_IP
# ip route add 172.16.0.0/16 dev ppp1 src ppp1_IP
# ip route add default dev ppp0 src ppp0_IP
Где ppp0_IP и ppp1_IP - IP-адреса на соответствующих интерфейсах.

Идём далее. На маршрутизаторе может быть запущен некий сервис, допустим ssh. К нему может быть необходимо подключаться как через интерфейс ppp0, так и через интерфейс ppp1. При этом возвратные пакеты к клиенту будут опять-таки отправляться в соответствии с таблицей маршрутизации, то есть может повториться вышеописанная ситуация.

Чтобы этого не произошло, нужно создать две таблицы маршрутизации, которые будут применяться для маршрутизации пакетов от сервиса ssh к клиентам.

Для этого в файле /etc/iproute2/rt_tables пропишем две новые таблицы маршрутизации:
201     table_ppp0
202     table_ppp1
В каждую из таблиц добавим по единственному маршруту по-умолчанию в соответствующие направления следующими командами:
# ip route add default dev ppp0 table table_ppp0
# ip route add default dev ppp1 table table_ppp1
Теперь нужно указать в каких случаях какой таблицей пользоваться. Нужно чтобы пакеты с исходным адресом ppp0_IP уходили по маршрутам в таблице table_ppp0, а пакеты с исходным адресом ppp1_IP уходили по маршрутам в таблице table_ppp1. Это мы сделаем с помощью следующих команд:
# ip rule add from ppp0_IP table table_ppp0
# ip rule add from ppp1_IP table table_ppp1
Общий список всех команд для настройки Policy Based Routing в нашем примере будет таким (в первой группе команд на всякий случай явно укажем таблицу маршрутизации main):
# ip route add 172.16.0.1 dev ppp0 src ppp0_IP table main
# ip route add 172.16.0.0/16 dev ppp1 src ppp1_IP table main
# ip route add default dev ppp0 src ppp0_IP table main
# ip route add default dev ppp0 table table_ppp0
# ip route add default dev ppp1 table table_ppp1
# ip rule add from ppp0_IP table table_ppp0
# ip rule add from ppp1_IP table table_ppp1
После этого не будет проблем с трафиком с самого маршрутизатора, с трафиком из локальной сети 10.16.7.0/24, трафиком, адресованным самому маршрутизатору.

Теперь нужно сделать так, чтобы при обращении к порту 80 на внешних адресах маршрутизатора трафик перенаправлялся на локальный web-сервер, имеющий адрес 10.16.7.2.

После всего проделанного это кажется довольно простым, нужно всего лишь добавить пару правил в iptables:
# iptables -t nat PREROUTING -i ppp0 -d ppp0_IP -p tcp --dport 80 -j DNAT --to 10.16.7.2:80
# iptables -t nat PREROUTING -i ppp1 -d ppp1_IP -p tcp --dport 80 -j DNAT --to 10.16.7.2:80
Однако не стоит так торопиться, на самом деле всё чуть сложнее. Возвратный трафик от web-сервера к маршрутизатору будет обрабатываться в соответствии с правилами в таблице main и пакеты могут уйти на тот интерфейс, с которого это соединение инициировано не было.

Уже к этому этапу я достаточно намучился с большим количеством динамически изменяемых таблиц: таблицами маршрутизации, таблицами NAT и таблицами фильтрации трафика. Кроме того, при перезапуске виртуальных сред обновлялся и список интерфейсов объединённых сетевыми мостом (рассматриваемый в примере интерфейс eth0 в действительности был интерфейсом br0). Поэтому я решил: "С меня хватит!" и не стал разбираться с этой проблемой, перенеся веб-сервер на маршрутизатор.

Однако для себя я отметил, что в этом случае можно было бы назначить web-серверу ещё один локальный IP-адрес, например 10.16.7.5 и направлять на него соединения с одного из интерфейсов. То есть это выглядело бы таким образом:
# iptables -t nat PREROUTING -i ppp0 -d ppp0_IP -p tcp --dport 80 -j DNAT --to 10.16.7.2:80
# iptables -t nat PREROUTING -i ppp1 -d ppp1_IP -p tcp --dport 80 -j DNAT --to 10.16.7.5:80
А для того, чтобы пакеты от веб-сервера попадали на нужный интерфейс, на маршрутизаторе можно было бы добавить ещё два правила выбора таблиц:
# ip add rule from 10.16.7.2 table table_ppp0
# ip add rule from 10.16.7.5 table table_ppp1
Правда в этом случае весь трафик с web-сервера подчинялся бы этим правилам. Приходит на ум ещё одно решение: добавить web-серверу ещё один адрес и использовать все три таблицы маршрутизации. Для этого изменим правила DNAT таким образом:
# iptables -t nat PREROUTING -i ppp0 -d ppp0_IP -p tcp --dport 80 -j DNAT --to 10.16.7.5:80
# iptables -t nat PREROUTING -i ppp1 -d ppp1_IP -p tcp --dport 80 -j DNAT --to 10.16.7.6:80
Правила выбора таблицы маршрутизации для web-сервера будут такими:
# ip add rule from 10.16.7.5 table table_ppp0
# ip add rule from 10.16.7.6 table table_ppp1
Можно, конечно, сделать ещё более тонкую настройку - ужесточить два последних правила выбора таблицы маршрутизации использовав для отбора пакетов правила iptables:
# iptables -t nat PREROUTING -i ppp0 -d ppp0_IP -p tcp --dport 80 -j DNAT --to 10.16.7.5:80
# iptables -t nat PREROUTING -i ppp1 -d ppp1_IP -p tcp --dport 80 -j DNAT --to 10.16.7.6:80
# iptables -t mangle -A PREROUTING -s 10.16.7.5 -p tcp --sport 80 -j MARK --set-mark 1
# iptables -t mangle -A PREROUTING -s 10.16.7.6 -p tcp --sport 80 -j MARK --set-mark 2
# ip add rule fwmark 1 table table_ppp0
# ip add rule fwmark 2 table table_ppp1
Можно не назначать дополнительные адреса web-серверу, а заставить web-сервер принимать соединения на двух портах: 80 и 81.
# iptables -t nat PREROUTING -i ppp0 -d ppp0_IP -p tcp --dport 80 -j DNAT --to 10.16.7.2:80
# iptables -t nat PREROUTING -i ppp1 -d ppp1_IP -p tcp --dport 81 -j DNAT --to 10.16.7.2:81
# iptables -t mangle -A PREROUTING -s 10.16.7.2 -p tcp --sport 80 -j MARK --set-mark 1
# iptables -t mangle -A PREROUTING -s 10.16.7.2 -p tcp --sport 81 -j MARK --set-mark 2
# ip add rule fwmark 1 table table_ppp0
# ip add rule fwmark 2 table table_ppp1
Итак, полностью рабочая и наиболее точная схема обработки трафика в целом будет выглядеть так:
# iptables -t nat -A POSTROUTING -o ppp0 -s 10.16.7.0/24 -j MASQUERADE
# iptables -t nat -A POSTROUTING -o ppp1 -s 10.16.7.0/24 -j MASQUERADE
# ip route add 172.16.0.1 dev ppp0 src ppp0_IP table main
# ip route add 172.16.0.0/16 dev ppp1 src ppp1_IP table main
# ip route add default dev ppp0 src ppp0_IP table main
# ip route add default dev ppp0 table table_ppp0
# ip route add default dev ppp1 table table_ppp1
# ip rule add from ppp0_IP table table_ppp0
# ip rule add from ppp1_IP table table_ppp1
# iptables -t nat PREROUTING -i ppp0 -d ppp0_IP -p tcp --dport 80 -j DNAT --to 10.16.7.2:80
# iptables -t nat PREROUTING -i ppp1 -d ppp1_IP -p tcp --dport 80 -j DNAT --to 10.16.7.2:81
# iptables -t mangle -A PREROUTING -s 10.16.7.2 -p tcp --sport 80 -j MARK --set-mark 1
# iptables -t mangle -A PREROUTING -s 10.16.7.2 -p tcp --sport 81 -j MARK --set-mark 2
# ip add rule fwmark 1 table table_ppp0
# ip add rule fwmark 2 table table_ppp1
Теперь представьте что у вас во внутренней сети работает не один сервис. А теперь представьте, что и соединений с провайдерами больше. А теперь представьте, что всё это хозяйство должно динамически изменяться при установке и падении связи с определённым провайдером. Не думаю, что вы будете в восторге от такой головной боли.

Написать статью решил потому что сегодня случайно наткнулся на статью с немного другим подходом к решению этой проблемы: http://xgu.ru/wiki/Default_gateway

В этой статье предлагается использовать дополнительный промежуточный маршрутизатор. На всякий случай приведу предлагаемую в статье схему здесь:
        GW1   GW2
         ^     ^
         |     | 
     IP1 |     | IP2
  [eth1] |     | [eth2]
        .o-----o.
        |       |
        |  gw   |
        |       |
        `-------'
10.0.3.250  |  10.0.3.254
    [eth0]  |  [eth0:1]
            | 
            |
10.0.3.249  |  10.0.3.253
    [eth1]  |  [eth1:1]
        .-------.
        |       |
        |  pgw  |
        |       |
        `-------'
            | 10.0.3.6
            | [eth0]
            |
В примечании к схеме указано:
  • на шлюзе gw выполняется проброска на один из внутренних адресов, в зависимости от того, куда пришёл запрос;
  • на шлюзе pgw выполняется дальнейшая проброска внутрь сети.
Жаль, что предлагаемое решение не разложено по полочкам с приведением конкретных команд. Нужно будет подумать на досуге, а можно ли сделать это не прибегая к использованию дополнительной физической машины? Ведь сила множественных таблиц маршрутизации Linux именно в том, что на одной Linux-машине можно уместить два и более маршрутизаторов с собственными таблицами маршрутизации.

А вообще, вас не пугает такая сложность настройки довольно простой идеи разруливания трафика всего лишь двух провайдеров? После всего написанного выше среди вас ещё остались сторонники использования NAT?

Как ни крути, но NAT - это костыль. Временное решение постоянных проблем. Постоянное решение - это 128-битные адреса IPv6 и 32-битные номера автономных систем. Во всяком случае этих решений должно хватить на обозримое будущее (просто не хочу уподобляться одному человеку, однажды сказавшему "640 килобайт оперативной памяти хватит всем.") Смотрите сюда и трепещите! :)

Даёшь каждому по номеру автономной системы и по блоку IP-адресов!

воскресенье, 14 декабря 2008 г.

CD-рипперы в Linux

В репозитории Debian нашёл несколько CD-рипперов:

1. grip - CD-риппер для среды GNOME, имеет интеграцию с некоей базой данных DigitalDJ,

2. ripperx - лёгкий CD-риппер с GTK-интерфейсом,

3. sound-juicer - "Звуковыжиматель", довольно тяжёлый CD-риппер для среды GNOME. Интересен тем, что для сжатия использует аудиосистему gstreamer,

4. KAudioCreator - CD-риппер для среды KDE,

5. ripit - консольный CD-риппер, представляет собой Perl-скрипт.

Все программы, за исключением sound-juicer являются обёртками вокруг консольных программ вроде cdparanoia для снятия треков, и lame/oggenc для кодирования. При наличии доступа к Интернет программы подключаются к базе CDDB и автоматически проставляют теги, если диск был найден в базе. Можно отредактировать теги вручную, задать место расположения готовых файлов, задать способ их наименования с использованием содержимого тегов, выбрать и настроить энкодер на требуемое качество сжатия.

Ripper X не понравился тем, что не русифицирован. Английский интерфейс для меня проблемы не представляет, но зачем нарушать русскоязычную программную среду чужеродным элементом? :-)

В интерфейсе Grip не удалось найти настройки битрейта, зато они легко обнаружились в тектовом конфиге ~/.grip.

Sound Juicer вообще не богат настройками, можно выбрать только кодер и схему сжатия вроде "CD-качество", "Речь" и т.п. Нашёл XML-файл с настройками, правда нужных мне параметров там не обнаружилось. Вытягивать из программы необходимые настройки щипцами мне не очень интересно, поэтому мой выбор склонился в пользу других, лучше документированных программ. В общем чувствуется спорный подход среды GNOME к проектированию интерфейсов: прятать детали настройки с глаз долой в XML-файлы, которые плохо документированы - чем не реестр Windows? Для тех же кто не разбирается в настройках аудиокодеров вполне подойдёт.

KAudioCreator по свойствам в целом очень похож на Grip, только ориентирован на среду KDE. Из плюсов по сравнению с Grip можно отметить специальный мастер для формирования имён файлов по содержимому тегов, в Grip на этот счёт имеется страница в англоязычном файле справки.

Теперь о самой любопытной программе: ripit. Программа интересна прежде всего тем, что нисколько не уступая по возможностям и удобству остальным программам, обладает рядом довольно интересных возможностей. Во-первых она может работать в связке с довольно приличным набором рипперов и кодеров. Во-вторых, он позволяет указать количество ядер процессора, по которому будет определяться число одновременно работающих процессов-энкодеров. В-третьих, он позволяет использовать для энкодирования другие сетевые компьютеры доступные по ssh! Эта возможность мне лично кажется избыточной, поскольку современные компьютеры сжимают звук настолько быстро, что больше времени уходит на собственно считывание дорожек с компакт-диска.

Что выбирать? Ответить однозначно затрудняюсь.

Если вы простой пользователь, ничего не понимающий в тегах, кодерах, битрейтах, смело выбирайте Sound Juicer.

Если вы предпочитаете графический интерфейс, выбирайте Ripper X если вы пользуетесь каким либо Window Manager'ом, выбирайте Grip если вы пользователь GNOME, выбирайте KAudioCreator если вы используете KDE.

Если вы предпочитаете командную строку и текстовый интерфейс вас нисколько не пугает - смело выбирайте ripit. Несмотря на отсутствие графического или ncurses-интерфейса, пользоваться ею пожалуй даже удобнее, чем остальными программами.

вторник, 2 декабря 2008 г.

Разводка розетки RJ-45 на компьютер и телефон

На работе практически состоялся переезд в новый офис. Переехало около 80 рабочих мест телефон+компьютер, 7 серверов, 2 маршрутизатора, телефонная станция, 5 IP-линий связи, два телефонных потока по 7 и 10 номеров. Коммутация выполнялась на 110 панели, компьютеров - двупарными и четырёхпарными патчкордами RJ45-110, телефонов - кроссировочным кабелем.

СКС не была расчитана на такое количество народа, поэтому практически в каждой второй розетке разводили 8-парные UTP-кабели на компьютер и телефон.

На 110 панели пары идут в таком порядке: синяя, оранжевая, зелёная, коричневая.

1. Два компьютера можно развести на двойную розетку так:
на панель 110       на розетки (схема B)

синяя     -------\  оранжевая (1 разъём)
оранжевая -------/  зелёная   (1 разъём)
зелёная   -------\  оранжевая (2 разъём)
коричневая-------/  зелёная   (2 разъём)
2. Если в розетку можно задействовать под компьютер целиком, то разводка будет такой:
на панель 110       на розетку (схема B)

синяя     -------\  синяя
оранжевая --------\ оранжевая
зелёная   --------/ зелёная
коричневая-------/  коричневая
3. Если розетку можно задействовать под телефон целиком, то разводка будет такой:
на панель 110       на розетку (схема B)

синяя     ------->  синяя
оранжевая
зелёная
коричневая
Однако при этом развести розетку для телефона лучше точно так же, как и для компьютера, чтобы розетка была универсальной и её легко можно было перекоммутировать на панели для подключения компьютера.
на панель 110       на розетку (схема B)

синяя     ------->  синяя
оранжевая - - - - \ оранжевая
зелёная   - - - - / зелёная
коричневая- - - -/  коричневая
4. Теперь самый интересный вариант. Разводим телефон и компьютер. Тут есть два варианта.

4.1. Первый:
на панель 110       на розетку (схема B)

синяя     - - - ->  синяя     (1 разъём)
оранжевая --------\ оранжевая (1 разъём)
зелёная   --------/ зелёная   (1 разъём)
коричневая------->  синяя     (2 разъём)
4.2. И второй:
на панель 110       на розетку (схема B)

синяя     ------->  синяя     (1 разъём)
оранжевая --------\ оранжевая (2 разъём)
зелёная   --------/ зелёная   (2 разъём)
коричневая- - - ->  синяя     (2 разъём)
На фотографиях ниже наглядно представлена схема разводки розетки.




Я без задней мысли разводил двойные розетки по первому варианту.

Сегодня с утра начальник был очень разгневан моим безответственным поведением. Если при разводке по всем схемам 1 - 3 телефон на панели всегда оказывался на синей паре, то при разводке на двойную розетку компьютер-телефон по схеме 4.1, на панель телефон приходил коричневой парой. Это приводило к путанице и необходимости поиска телефонной пары на таких розетках.

Так вот, если кто не знает как лучше развести UTP-кабель на двойную розетку компьютер-телефон, знайте - лучше обжимать по схеме 4.2. Возможно это общепринятая практика, но мы научились на собственных шишках.

Говорят что дураки учатся на своих ошибках, а умные - на чужих. Желаю вам быть умными людьми.

Обновлено 13 марта 2010.

пятница, 17 октября 2008 г.

Скачивание образов дисков Debian с использованием jigdo-lite

Кратко о сути jigdo. jigdo состоит из двух взаимно дополняющих друг друга утилит - jigdo-file и jigdo-lite.

Первая утилита, jigdo-file сканирует образ диска и находит там файлы. Для каждого файла утилита рассчитывает хэш md5 - контрольную сумму. В результате сканирования образа утилита создаёт два файла - шаблон диска (*.template), содержащий всю информацию из образа за исключением файлов, и сжатый список файлов с контрольными суммами (*.jigdo).

Вторая утилита, jigdo-lite на основании файлов *.jigdo и *.template может воссоздать образ диска. Недостающие файлы она может найти в произвольном указанном ей каталоге на локальном диске или скачать с указанного ей Интернет-зеркала Debian.

Таким образом jigdo - это умный вариант rsync или torrent, предназначенный для скачивания iso-образов, который умеет собирать часть образа диска из имеющихся уже скачанных файлов.

Установим пакет jigdo:
# aptitude install jigdo-file
Создаём текстовый файл jigdo-list.txt, содержащий в каждой строке по одной ссылке на файлы *.jigdo и *.template для скачивания, ссылки берём на странице http://cdimage.debian.org/debian-cd/4.0_r4a/i386/jigdo-dvd/:
http://cdimage.debian.org/debian-cd/4.0_r4a/i386/jigdo-dvd/debian-40r4a-i386-DVD-1.jigdo
http://cdimage.debian.org/debian-cd/4.0_r4a/i386/jigdo-dvd/debian-40r4a-i386-DVD-1.template
http://cdimage.debian.org/debian-cd/4.0_r4a/i386/jigdo-dvd/debian-40r4a-i386-DVD-2.jigdo
http://cdimage.debian.org/debian-cd/4.0_r4a/i386/jigdo-dvd/debian-40r4a-i386-DVD-2.template
http://cdimage.debian.org/debian-cd/4.0_r4a/i386/jigdo-dvd/debian-40r4a-i386-DVD-3.jigdo
http://cdimage.debian.org/debian-cd/4.0_r4a/i386/jigdo-dvd/debian-40r4a-i386-DVD-3.template
http://cdimage.debian.org/debian-cd/4.0_r4a/i386/jigdo-dvd/debian-update-4.0r4a-i386-DVD-1.jigdo
http://cdimage.debian.org/debian-cd/4.0_r4a/i386/jigdo-dvd/debian-update-4.0r4a-i386-DVD-1.template
Запускаем скачивание файлов из списка:
$ wget -i jigdo-list.txt
В файле /etc/fstab прописываем монтирование имеющихся образов:
/home/iso/debian-40r4-i386-DVD-1.iso /mnt/debian1 udf,iso9660 user,loop=/dev/loop0 0 0
/home/iso/debian-40r4-i386-DVD-2.iso /mnt/debian2 udf,iso9660 user,loop=/dev/loop1 0 0
/home/iso/debian-40r3-i386-DVD-3.iso /mnt/debian3 udf,iso9660 user,loop=/dev/loop2 0 0
/home/iso/debian-update-40r3-i386-DVD-1.iso /mnt/debian4 udf,iso9660 user,loop=/dev/loop3 0 0
Смонтируем все ISO-образы:
# mount -a
Запустим jidgo-lite для первого образа, в диалоге укажем путь до первого смонтрованного диска:
$ jigdo-lite jigdo/debian-40r4a-i386-DVD-1.jigdo
Программа выдаст запрос, где можно поискать уже скачанные файлы, укажем ей смонтированный диск:
Files to scan: /mnt/debian1/
После сканирования файлов в каталоге, подсчёта и сопоставления контрольных сумм, программа определит количество найденных файлов:
Found 4627 of the 4627 files required by the template
После чего создаст образ диска и выдаст соответствующее сообщение:
Successfully created `debian-40r4a-i386-DVD-1.iso'
Затем программа проверит контрольную сумму полученного образа, чтобы убедиться что полученный диск абсолютно идентичен находящемуся на официальном сайте debian:
OK: Checksums match, image is good!
Отлично, первый диск готов!

Переходим ко второму:
$ jigdo-lite jigdo/debian-40r4a-i386-DVD-2.jigdo
И этот диск тоже не пришлось качать, я в восторге!
Следующие два образа у меня более старые, поэтому кое-что всё-таки пришлось качать.
$ jigdo-lite jigdo/debian-40r4a-i386-DVD-3.jigdo
Программа запоминает использованные источники файлов и предлагает указать один из них их цифрой, можно ввести новый источник файлов.
1: /mnt/debian2/
2: /mnt/debian1/
Files to scan: /mnt/debian3/
На этот раз программа нашла лишь часть файлов:
Found 5121 of the 8309 files required by the template

Copied input files to temporary file `debian-40r4a-i386-DVD-3.iso.tmp' - repeat command and supply more files to continue
Пока программа не нашла все подходящие файлы, она будет выводить предложение указать дополнительные источники снова и снова, если у Вас больше нет источников, можно нажать Enter:
Files to scan:
После этого программа предложит указать зеркало в сети, с которого можно скачать недостающие пакеты. У меня установлен apt-cacher, который указан в файле /etc/apt/sources.list. Программа сама предлагает мне использовать его, я соглашаюсь нажатием Enter:
Debian mirror [http://127.0.0.1:3142/debian/]:
После чего программа начнёт скачивание недостающих пакетов из сети. Для скачивания используется программа wget. Если Вы хотите скачивать недостающие файлы через прокси-сервер, можно настроить переменные окружения или конфигурацию wget, в которой указать адрес, порт имя и пароль используемого прокси-сервера.

Я таким образом закачал себе все три основных диска и диск с обновлениями. Насколько я понял, диск с обновлениями содержит только те пакеты, которые изменились с прошлого выпуска, потому что этот диск мне не пришлось скачивать - достаточно было указать три основных уже скачанных смонтированных диска. Имея этот диск можно обновить систему с предыдущего выпуска до текущего.

Итак, краткое описание использования программы.
1. Нужно установить в системе пакет jigdo-file.
2. Скачать файлы *.jigdo и *.template с официального сайта Debian.
3. Приготовить файлы с дисков Debian предыдущих версий, каталоги с deb-пакетами. Они могут пригодиться для того, чтобы не пришлось скачивать все диски целиком.
4. Запускать команду jigdo-lite для каждого jigdo-файла.
4а. На запрос программы "Files to scan:" можно ответить вводом пути до источника файлов, можно ввести цифру из меню для уже указанного однажды каталога, можно нажать Enter, если источников больше нет.
4б. На запрос "Debian mirror [http://127.0.0.1:3142/debian/]:" ввести URL зеркала или просто нажать Enter, чтобы использовать предложенное зеркало.
5. После завершения всех пунктов наслаждаться готовыми свежими образами системы.
Для скачивания через прокси можно соответствующим образом настроить wget, чтобы для скачивания не нужно было держать постоянно открытым отдельный терминал, можно воспользоваться программой screen.

понедельник, 13 октября 2008 г.

Игры в Linux

Недели две или три назад обновился до lenny, т.к. ждать официального выпуска не хватает терпения :) Linux-ядро осталось прежним - 2.26.18, но отлетел проприетарный модуль nvidia. Налаживать было совершенно лень, хоть и не требовало никаких усилий - просто обновить ядро и поставить к нему модуль. Я прописал в конфиге X-сервера использование свободного драйвера.

Из любопытства поставил пару игрушек - lxdoom и openarena.

Джон Кармак регулярно открывает движки всех своих игр под лицензией GPL, эти две игры основаны соответственно на движке Doom и движке Quake III. Однако, чтобы не остаться без штанов, контора не освобождает собственно сами игровые ресурсы - они по прежнему продаются за деньги. lxdoom и openarena используют доработанные движки оригинальных игр, но содержат разработанные с нуля игровые ресуры. В целом качество художественной работы, на мой взгляд, у обеих игр заметно ниже. Однако, не смотря на это, атмосфера и динамика игр абсолютно те же.

Первая игра нормально работает и без проприетарного модуля, а вот второй очень нужно 3D-ускорение. Рассмотрение openarena я отложил до того момента, когда я наконец обновлю ядро и поставлю проприетарный модуль nvidia.

Сегодня обновил ядро до версии 2.6.26-1-amd64 и поставил пакет с проприетарным модулем. Поиграл немного в openarena и понял, что прежнюю свою форму я потерял :) Играть на среднем уровне было тяжеловато, не смотря на то, что раньше я сравнительно легко играл даже на предпоследнем! Прошёл пару карт и почему-то интерес к игре немного стих.

Мне захотелось посмотреть - а что же ещё интересного из игр есть в Linux? Несколько раз встречал в интернете упоминания игр alien-arena, freeciv, какого-то аналога ufo x-com. За актуальной информацией я немедленно отправился на англоязычный ресурс www.linuxgames.com. После непродолжительного чтения нашёл ссылку на интересный проект: www.playdeb.net, где есть список доступных Linux-игр для Ubuntu. Пока что проект практически полностью дублирует страницу www.getdeb.net со списком игровых deb-пакетов для Ubuntu.

Что я там нарыл из интересного.

Шутеры от первого лица:
1. warsow,
2. urbanterror,
3. worldofpadman,
4. assaultcube.
Пошаговые стратегии:
5. freeciv - клон "Цивилизации",
6. freecol - клон "Колонизации",
7. ufoai - нечто среднее между RPG и пошаговой стратегией, клон "UFO".
RPG:
8. freedroidrpg - RPG про роботов.
Гонки:
9. tileracer.
2D:
10. slimevolley - 2D-воллейбол,
11. hedgewars - аналог "Червяков", но вместо червяков воюют ежи,
12. pipewalker - аналог KDE-шного Netwalk, отечественных "Ветка" для DOS и "IT" для Windows.

Это далеко не все доступные игры, это лишь то, что я отметил для себя на первое время. Конечно лучше всего сначала пробовать найти игру в репозитории, а уже потом, если в репозитории игры нет, качать её с указанных сайтов.

В общем работы теперь - непочатый край :) Можно качать, ставить, смотреть.

UPD 02-12-2008: Никита Рукавов на своём блоге выложил краткую статью со скриншотами заинтересовавших меня игр: Игры в Linux

суббота, 4 октября 2008 г.

Замена pure-ftpd-wrapper на pure-config в Debian

Продолжаю переносить статьи со старого блога. К статье могу добавить комментарий, что в принципе установка pure-ftpd из deb-src была сделана с одной лишь целью - ознакомиться с технологией. pure-ftpd можно просто поставить двоичным пакетом, а из тарболла с исходниками просто взять нужный нам wrapper и настроить скрипт в /etc/init.d на использование этого wrapper'а.

Перепробовал я под FreeBSD много разных FTP-серверов:
  1. родной bsdftpd, просто и со вкусом, ненужно заморачиваться с установкой, уже присутствует в самой системе;
  2. он-же, но споддержкой SSL и TSL - bsdftpd-ssl, после предыдущего практически не нужно ничего перенастраивать, но сразу добавляются шифрованные варианты протокола;
  3. proftpd с конфигурационным файлом, подобным оному в Apache, гибко, но тяжело. К тому же в своё время без сторонних патчей прикрутить русскую локаль было невозможно (только не кидайте камнями, типа это не по стандарту: оно бывает нужно, а добавить эту возможность в виде опции разработчики поленились);
  4. vsftpd, легко и безопасно, но почему-то тоже не прижился.
В поисках совершенства начал использовать Debian.

Человек я ленивый, а во FreeBSD тупо обновить систему с накатом обновлений безопасности сложновато:
  1. сама система - cvsup, make buildworld, make buildkernel, make installkernel, перезагрузка, смотрим как работает свежее ядро, затем make installworld;
  2. можно и проще freebsd_update, но если ядро собрано своё - опять-таки ядро придётся пересобирать;
  3. дерево портов cvsup или portsnap;
  4. проверка уязвимых установленных пакетов portaudit;
  5. установка свежих пакетов или установка из портов: portupgrade;
  6. исправление возможных глюков из-за обновлённых версий программ (конфиги поправить, запускные скрипты).
Некоторые пакеты не работают правильно, пока их не пересобирёшь из портов (бывало такое, бывало)! На это опять-таки нужно тратить время, ресурсы системы (а машинки бывают очень слабенькие - компиляция среднего размера пакетов может идти часами), или извращаться с монтированием удалённых каталогов, компилировать на более мощной системе.

В Debian тупо:
# apt-get update
# apt-get upgrade
И все обновления безопасности стоят в системе, конфигов править не нужно! Можно легко сопровождать таким способом десятки серверов, полезно лишь поставить на одну из машинок apt-cacher, чтобы не грузить почём зря официальные зеркала.

А учитывая, что в Debian есть достойная замена портам - deb-src, то жить становится значительно легче. И собственноручно собранные пакеты можно зафиксировать в системе, чтобы они не обновлялись вместе с остальными:
# dpkg --get-selections \* > selections.txt
Изменяем в selections.txt в строчке с названием пакета слово "install" на слово "hold".
# dpkg --set-selections < selections.txt
Захотелось мне поставить в качестве FTP-сервера pure-ftpd под Debian. Из достоинств: поддержка авторизации PAM (можно на свой вкус настроить на использование любых модулей), дедовский Unix (по файлам /etc/passwd, /etc/shadow, /etc/group), по собственной базе данных puredb, по базам данных в mysql и postgres, настройка дисковых квот, смена корня, ограничение пропускной способности и количества одновременных клиентов, поддержка различных кодовых страниц для конвертирования имён файлов и многое другое. Поставил, да вот незадача, у разработчиков Debian весьма нетрадиционное представление об удобстве его настройки. Поскольку pure-ftpd настраивается запуском с нужными опциями, а опций очень много, то хорошие люди придумали т.н. "wrapper", программу которая читает конфигурационный файл и запускает демон с нужными опциями. Так вот, в Debian кому-то очень понравилось хранить значения ключей настройки в отдельных файлах с соответствующими именами в каталоге /etc/pure-ftpd/conf/. Меня эта идея не вдохновила и я решил сменить перловый скрипт pure-ftpd-wrapper на стандартный pure-config.pl, идущий в комплекте с исходниками pure-ftpd. Устанавливаем пакеты, необходимые для установки из исходников (возможно я пропустил ещё какие-то нужные пакеты):
# apt-get install dpkg-dev
# apt-get install fakeroot
Скачиваем и распаковываем исходники pure-ftpd:
# apt-get source pure-ftpd
Переходим в каталог с исходниками:
# cd pure-ftpd-1.0.21
Устанавливаем пакеты, необходимые для построения пакета pure-ftpd из исходников:
# apt-get build-dep pure-ftpd
Строим пакет:
# dpkg-buildpackage -rfakeroot -us -uc
Как вариант, можно воспользоваться скриптами в каталоге с распакованным pure-ftpd:
# debian/rules build
# debian/rules binary
Выходим из каталога с исходниками:
# cd ..
И попадаем в каталог, где лежат свежепостроенные пакеты. Устанавливаем пакет pure-ftpd_1.0.21-8_i386.deb:
# dpkg -i pure-ftpd_1.0.21-8_i386.deb
Эта же технология применяется для установки любого пакета, если Вы хотите его настроить особым образом на этапе компиляции: наложить дополнительные патчи, изменить константы в исходных текстах, скомпилировать с дополнительными опциями или без ненужных. Далее, копируем новый скрипт в систему:
# cp pure-ftpd-1.0.21/configuration-file/pure-config.pl /usr/sbin/pure-ftpd-config
И устанавливаем права на выполнение:
# chmod a+x /usr/sbin/pure-ftpd-config
Теперь удаляем всё из каталога /etc/pure-ftpd/:
# rm -R /etc/pure-ftpd/*
И копируем сюда пример конфигурационного файла:
# cp pure-ftpd-1.0.21/configuration-file/pure-ftpd.conf /etc/pure-ftpd/
Исправляем скрипт запуска /etc/init.d/pure-ftpd, заменяем строчку:
WRAPPER=/usr/sbin/pure-ftpd-wrapper
На нашу:
WRAPPER=/usr/sbin/pure-ftpd-config
Добавляем после этого строчку:
CONFIG=/etc/pure-ftpd/pure-ftpd.conf
Заменяем в секциях case start и restart|force-reload:
--exec $WRAPPER -- $SUFFIX
на
--exec $WRAPPER $CONFIG -- $SUFFIX
Я собираюсь запускать pure-ftpd как самостоятельный сервер, поэтому меняю настройки запуска по-умолчанию в файле /etc/default/pure-ftpd-common: Заменяю
STANDALONE_OR_INETD=inetd
на
STANDALONE_OR_INETD=standalone
На этом пока что всё. К сожалению по этому серверу на русском языке очень мало информации, есть несколько how-to, но это не документация.

Настраиваем VPN-соединение с Уфанетом в Debian

Дома у меня есть интернет от уфимского провайдера "Уфанет", пользуюсь системой Debian GNU/Linux. Для того, чтобы получить доступ в интернет, нужно установить VPN-соединение, а точнее - PPTP.

Первый этап предполагает настройку Ethernet-соединения, а точнее настройку интерфейса на получение настроек по DHCP.

Делается это элементарно. В файле /etc/network/interfaces нужно добавить пару строчек:
auto eth0
iface eth0 inet dhcp
eth0 - это имя сетевого интерфейса, подключенного к сети Уфанет. Узнать список доступных интерфейсов можно с помощью команды:
$ ifconfig -a
Далее установим pptp-клиент и пакет resolvconf:
# aptitude install pptp-linux resolvconf
Пакет resolvconf добавляет к клиентам dhcp и pptp специальные сценарии, которые перехватывают информацию о DNS-серверах, полученную от dhcp- и pptp-серверов соответственно. Основываясь на перехваченной информации сценарии выполняют корректное обновление списка DNS-серверов в файле /etc/resolv.conf

Процесс настройки состоял из серии проб и ошибок, но в конце концов получилось удачно скомпилировать информацию из разных источников. В результате появился работоспособный набор конфигурационных файлов и скриптов.

Краткие пояснения по файлам конфигурации:

login - логин на соединение (именно логин, а не номер договора)
password - пароль на соединения (пароль на соединение, а не на просмотр баланса)
vpn.ufanet.ru - доменное имя VPN-сервера Уфанет

Теперь сами файлы:
/etc/ppp/peers/ufanet
pty "pptp vpn.ufanet.ru --nolaunchpppd"
name login
remotename vpn.ufanet.ru
file /etc/ppp/options.pptp
ipparam ufanet   # Этот параметр передаётся в скрипты настройки
                 # маршрутизации, о которых ниже
/etc/ppp/chap-secrets
# Secrets for authentication using CHAP
# client    server           secret      IP addresses
login       vpn.ufanet.ru    password    *
/etc/ppp/options
asyncmap 0
auth
crtscts
lock
hide-password
modem
proxyarp
lcp-echo-interval 30
lcp-echo-failure 4
noipx
/etc/ppp/options.pptp
lock
noauth
nobsdcomp
nodeflate
persist    # Восстанавливать соединение при обрыве
Теперь собственно скрипты для прописывания маршрутов при поднятии линка и для удаления маршрутов при падении линка. Скрипты были почерпнуты в одной из Интернет-конференций и доработаны под наш случай (в исходном виде скрипты, увы не работали).

/etc/ppp/ip-up.d/route
#!/bin/sh

case "$PPP_IPPARAM" in
  ufanet)
    SERVER=vpn.ufanet.ru
    GW=`route -n | grep ^0\.0\.0\.0 | awk '{print $2}'`
    route del $PPP_REMOTE dev $PPP_IFACE
    route add -host $SERVER gw $GW
    route add default dev $PPP_IFACE
    ;;
  *)
    echo "No PPP_IPPARAM defined"
    ;;
esac
/etc/ppp/ip-down.d/route
#!/bin/sh

case "$PPP_IPPARAM" in
  ufanet)
    SERVER=vpn.ufanet.ru
    route del -host $SERVER
    route del default dev $PPP_IFACE
    ;;
  *)
    echo "No PPP_IPPARAM defined"
    ;;
esac
Для того, чтобы сценарии заработали, нужно добавить им бит исполняемости:
# chmod +x /etc/ppp/ip-up.d/route /etc/ppp/ip-down.d/route
Подключение осуществляется с помощью команды:
# pon ufanet
Отключение осуществляется с помощью команды:
# poff ufanet
Команды pon и poff нужно выполнять от пользователя root.

Чтобы соединение устанавливалось при старте системы, можно прописать в файл /etc/network/interfaces следующие строки:
auto ufanet
iface ufanet inet ppp
  provider ufanet

Настройка принтера HP LaserJet 1018 в Debian

Решил перенести пару статей со старого блога, это одна из них.

Мне захотелось настроить в Linux систему печати, чтобы распечатать статью из браузера.

Сначала я установил пакет подсистемы печати cupsys:
# aptitude install cupsys
Пакет установился и автоматически запустил демона печати и даже нашёл подключенный к USB-порту принтер. Однако тест принтера не дал результатов:
# touch test.txt
# echo "Hello World" > test.txt
# cat test.txt > /dev/usb/lp0
Принтер упорно делал вид, что его вообще тут нет.

Я немного погуглил в инете на тему настройки принтеров HP LaserJet 1018 и нашёл несколько интересных текстов, о том как же его всё-таки заставить работать.

Всё дело оказалось в том, что перед тем, как начать печатать, на принтер нужно отправить так называемую прошивку.

Я критически рассмотрел все три источника и в итоге скомпилировал "своё авторитетное видение" процесса правильной настройки принтера HP LaserJet 1018 в системе Debian GNU/Linux.

Устанавливаем пакет foo2zjs:
# aptitude install foo2zjs
Скачиваем исходник его свежей версии с официального сайта разработчика:
# wget -O foo2zjs.tar.gz http://foo2zjs.rkkda.com/foo2zjs.tar.gz
Распакуем его:
# tar -xzvf foo2zjs.tar.gz
Перейдём в каталог с исходниками:
# cd foo2zjs
Скачаем образ прошивки для нашего принтера:
# ./getweb 1018
Тут особое внимание нужно обратить на символы "./" указывающие на то, что команда запускается из текущего каталога, а не из установленного в системе пакета. При этом будет скачана самая свежая версия прошивки.

Преобразуем прошивку в формат, пригодный для загрузки на принтер, сразу же поместив её в каталог прошивок:
# arm2hpdl aihp1018.img > /usr/share/foo2zjs/firmware/sihp1018.dl
Сменим владельца прошивки:
# chown root:root /usr/share/foo2zjs/firmware/sihp1018.dl
После чего выключим и включим принтер. Вуаля, новая прошивка должна быть загружена в принтер!

Теперь осталось лишь переконфигурировать принтер:
# printconf
К сожалению запускать эту команду необходимо каждый раз после подключения принтера.

В комплекте с подсистемой печати идёт веб-приложение для управления подсистемой печати. Оно доступно локально по адресу http://localhost:631/

В чём преимущества моего метода? В том, что в системе установлен пакет foo2zjs, идущий в комплекте с дистрибутивом. А это значит, что у нас не будет головной боли с обновлением этого пакета.

Список использованных материалов:
  1. Руководство по настройке системы печати
  2. Установка принтера HP1020 в Debian Еtch
  3. Установка принтера HP LaserJet 1018
  4. [GNU/Debian][HP 1018]Помогите

среда, 10 сентября 2008 г.

Кое-что об Ufanet

1. Диапазоны локальных и "белых" IP-адресов Ufanet:

192.168.0.0/16
172.16.0.0/12
10.0.0.0/8
46.191.128.0/17
81.30.176.0/20
81.30.192.0/19
89.189.128.0/19
77.79.128.0/18
79.140.16.0/20
92.50.128.0/18
94.41.0.0/16
95.105.0.0/17
136.169.128.0/17
145.255.0.0/19

Эта информация взята с сайта ufaman.ru, со страницы о локальных подсетях.

2. Cамое вкусное - сервис dyndns.

Раньше этот сервис подключался автоматически и работал всегда. Теперь его можно включить через страницу статистики, для каждого из подключенных тарифов отдельно.

Если сервис включен, то при установке VPN-подключения создаётся DNS-запись вида логин.dyn.ufanet.ru на сервере ns2.ufanet.ru.

TTL этой записи равен 10 минутам, поэтому может потребоваться 10 минут, прежде чем кеширующие DNS-серверы начнут возвращать актуальную информацию.

Подробнее.

3. DNS-серверы Ufanet имеют IP-адреса 81.30.199.5 и 81.30.199.94.

4. Локальные сети с "серыми" IP.

IP-адрес VPN-сервера vpn.ufanet.ru - 10.8.0.1.
IP-адрес локального DNS-сервера - 10.8.3.1.
IP-адрес веб-сервера ufaman.ru (или beta.ufanet.ru), доступного для просмотра без установки VPN-соединения: 81.30.199.65.

Скорее всего VPN-сервер не один, просто все VPN-серверы находятся в разных VLAN-ах.

Все "серые" сети изолированы. Внутри "серых" сетей шлюз постоянно отправляет широковещательный ARP-ответ, сообщая что широковещательный IP-адрес занят шлюзом. Из-за этого в "серых" сетях не работают все широковещательные протоколы - это безсерверные чаты, игры, сетевые папки SMB. Подключаться напрямую по IP-адресам можно, только ситуация осложняется тем, что эти адреса динамические и выдаются DHCP-сервером. Поэтому для подключения двух компьютеров нужно предварительно узнать "серый" IP-адрес сервера.

5. О локальных сервисах можно узнать на странице http://ufaman.ru/nashi-resursy/ и на сайте http://mir.ufanet.ru/.

6. В Уфе теперь можно подключаться не только по PPTP, но и по PPPoE. PPPoE лучше тем, что меньше нагружает компьютер и позволяет добиваться более высокой скорости передачи данных. А ещё - он проще настраивается, т.к. не нужно указывать адрес сервера. В Linux'ах настройка упрощается ещё больше, так как не нужно ещё и прописывать маршрут к серверу и не нужно настраивать DHCP-клиент так, чтобы он не принимал маршут по умолчанию.

Вот, пожалуй, и всё, что я хотел сказать.

Обновлено 18 декабря 2009 года.

Обновлено 30 августа 2013 года.

понедельник, 1 сентября 2008 г.

Опять о шрифтах в Linux (Debian)

Проблема шрифтов для многих линуксоидов стоит особо остро. Надо признать, шрифты в Linux не особо радуют глаз человека, привыкшего к шрифтам Windows. Windows-шрифты по сравнению со шрифтами Linux кажутся чёткими, контрастными.

Впрочем, справедливости ради, стоит сказать что у меня проблема эта остро встала лишь в Firefox2, который использует библиотеки GNOME.

Кратко опишу те действия, которые я предпринял для настройки шрифтов.

1. В разных статьях советуют первым делом выставить в xorg.conf DPI в 96x96. Все мои попытки сделать это различными способами не удались. X-сервер попросту ложил на эти настройки и всё-равно использовал привычные ему 100x100. Возможно это связано с тем, что я использую фирменный драйвер nvidia и этот драйвер не воспринимает настройки DPI.

Посмотреть DPI запущенного X-сервера можно так:
$ xdpyinfo | grep resolutions
resolution:    100x100 dots per inch
2. Советуют пересобрать библиотеку freefonts2 с поддержкой опции TT_CONFIG_OPTION_BYTECODE_INTERPRETER.

Как я выяснил, эта опция в Debian уже включена специальным патчем! (Это действительно так, я видел этот патч своими глазами!)

3. Советуют поиграться с настройками пакета fontconfig-config примерно таким образом.
# dpkg-reconfigure fontconfig-config
Первый экран: выбираем "Native" для шрифтов, которые установлены в Debian по-умолчанию, или Autohinter, если используются шрифты от Microsoft.

На втором экране выбираем: "Всегда" - если у Вас LCD-монитор (жидкокристаллический дисплей), и "Никогда" - если у вас CRT-монитор (электронно-лучевая трубка).

На третьем выбираем вариант "Нет" в любом случае, поскольку масштабирование матричных шрифтов всегда выглядит плохо.

Затем применяем сделанные изменения командой:
# dpkg-reconfigure fontconfig
И перезапускаем X'ы.

4. Выбрать каталоги со шрифтами в xorg.conf. Я у себя оставил лишь две строчки - fixed-шрифты, без которых X-сервер просто не запустится, и TTF-шрифты, которые хорошо масштабируются.

В секции Files остались две строчки:
FontPath        "/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType"
FontPath        "/usr/share/fonts/X11/misc"
5. Обычно советуют установить шрифты от Microsoft (разработанные фирмой Monotype), которые находятся в виртуальном пакете msttcorefonts. На самом деле это скрипт, который скачивает шрифты из официальных публичных источников и с помощью утилиты cabextract извлекает их из самораспаковывающихся cab-архивов, дополненных exe-декомпрессором :)

Сразу скажу, что шрифты эти я пробовал ставить, но они мне не понравились. В большинстве случаев шрифты выглядели вполне нормально, но в окне Firefox на некоторых сайтах они всё-таки выглядели ужасно.

Я поискал статьи о текущем положении со шрифтами в Linux. И к моему счастью, Алексей Федорчук, в своей статье (см. №2) меня обрадовал. Как оказалось, в Linux вполне хватает качественных шрифтов.

Шрифты Microsoft (они же Monotype) были мной снесены. Взамен я установил шрифты, имеющиеся в Linux:
# aptitude install ttf-bitstream-vera
# aptitude install ttf-dejavu
# aptitude install ttf-freefont
# aptitude install ttf-linux-libertine
# aptitude install xfonts-terminus
6. Советуют прописать в домашнем каталоге специально настроенный файл .gtkrc-2.0, но и его изменение не оказывало заметных на глаз изменений в шрифтах Firefox.

Чтобы добиться более-менее божеского вида шрифтов в Firefox, в его настройках я прописал использование следующих шрифтов родственных микрософтовским:
  1. Пропорциональный - без засечек, размер - 16,
  2. С засечками - DejaVu Serif,
  3. Без засечек - DejaVu Sans,
  4. Моноширинный - DejaVu Sans Mono, размер - 13,
  5. Наименьший размер шрифта - 10,
и запретил использовать веб-сайтам свои шрифты вместо установленных.
  1. Википедия - Шрифт
  2. Алексей Федорчук. И снова про шрифты в Иксах
  3. Владимир Попов. Рендеринг шрифтов в X Window: как в MS Windows и даже лучше
  4. LOR-FAQ: X-сервер
  5. LOR-FAQ: Desktop
  6. В качестве шутки, в которой есть доля правды, тема на LORе: Ужасные шрифты в Linux (как можно терпеть такое?)
Результат, в принципе, меня удовлетворил (до этого было гораздо страшнее):

Как всегда, буду рад выслушать Ваши наблюдения и наработки по настройке шрифтов в Linux.

вторник, 19 августа 2008 г.

Настройка DynDNS на Debian

Давно хотел застолбить себе домен, пусть даже и третьего уровня, чтобы можно было без лишних проблем легко попадать на свой домашний Linux-сервер.

Проблемы состоят во-первых в том, что у этого сервера не постоянный IP-адрес, он выдаётся при подключении по PPTP. А во-вторых, на безлимитном тарифе провайдер не предоставляет услугу постоянного IP-адреса.

До сих пор обходился самописным скриптом, который автоматически при поднятии линка заливает текстовый файл с IP-адресом по FTP на бесплатный веб-хостинг.

1. Регистрация на сервисе DynDNS

После непродолжительного гугления на тему динамических DNS, был найден сервис http://www.dyndns.com/. Долго откладывал настройку, но сейчас решил настроить и описать процесс.

На этом сайте можно заказать за деньги DNS-хостинг, мониторинг серверов и многие другие услуги. Есть также бесплатный DNS-сервис, ограниченный 864000 запросами к DNS в месяц и бесплатный домен третьего уровня, позволяющий производить динамические обновления зоны.

Для начала регистрируемся на сайте и подтверждаем регистрацию по почте.

Выбираем доменное имя второго уровня, где будем размещать свою зону. Полный список доменов второго уровня, в которых Вы можете застолбить свой домен третьего уровня, можно посмотреть здесь: http://www.dyndns.com/services/dns/dyndns/domains.html Я выбрал домен homelinux.org.

Затем подписываемся на услугу Dynamic DNS, где выбираем тип узла - custom.

На этом сайт можно покинуть, больше он нам не понадобится.

2. Настройка ddclient с помощью мастера настройки

Устанавливаем ddclient:
# aptitude install ddclient
Сразу во время установки запускается мастер настройки ddclient с ncurses-интерфейсом:
1. Выбираем сервис, на котором зарегистрировали учётную запись. Я выбрал www.dyndns.com

2. Вводим имя домена, который выбрали при регистрации на DynDNS:

3. Вводим имя пользователя, с которым регистрировались на сервисе DynDNS:

4. Пароль для этой учётной записи:

5. Указываем имя интерфейса, к IP-адресу которого будет привязываться выбранное доменное имя. Можно оставить это поле пустым, тогда IP-адрес будет определяться автоматически, исходя из того, какой IP-адрес был использован клиентом при подключении к сервису.

6. Здесь можно указать, будет ли запускаться ddclient при запуске PPP-соединений и отключаться при закрытии PPP-соединений.

7. Если выбрать запуск ddclient в режиме демона, он будет автоматически запускаться при загрузке системы и работать постоянно. Если вы выбрали этот режим, то в предыдущем пункте можно отключить запуск демона при поднятии PPP-канала связи.

Если вы ошиблись в настройках, запустить мастер настройки ddclient снова можно в любое время, для этого можно воспользоваться следующей командой:
# dpkg-reconfigure ddclient
3. Конфигурационные файлы и настройка без мастера

Все указанные мной настройки уместились в двух файлах. /etc/ddclient.conf:
# Configuration file for ddclient generated by debconf
#
# /etc/ddclient.conf

pid=/var/run/ddclient.pid
protocol=dyndns2
use=if, if=
server=members.dyndns.org
login=www2
password='password'
ufadeb.homelinux.org
В этом файле можно указать имя интерфейса, имя и пароль учётной записи на DynDNS и доменное имя, которые вы выбрали при регистрации.

И второй файл - /etc/default/ddclient:
# Configuration for ddclient scripts
# generated from debconf on Срд Фев 25 20:17:16 YEKT 2009
#
# /etc/default/ddclient

# Set to "true" if ddclient should be run every time a new ppp connection is
# established. This might be useful, if you are using dial-on-demand
run_ipup="true"

# Set to "true" if ddclient should run in daemon mode
run_daemon="false"

# Set the time interval between the updates of the dynamic DNS name in seconds.
# This option only takes effect if the ddclient runs in daemon mode.
daemon_interval="300"
В нём можно указать режимы запуска и период обновления информации:
  1. run_ipup соответствует запуску демона при установлении PPP-подключения и его остановке при разрыве PPP-подключения, принимает два значения - true (запускать) и false (не запускать),
  2. run_daemon - запускать ddclient в режиме демона (true) или нет (false),
  3. daemon_interval - интервал обновления привязки доменного имени и IP-адреса в секундах (300 - 5 минут).
4. Более сложный случай настройки

Мне понадобился несколько более экзотический случай настройки: мне нужно обновлять две доменные записи и привязывать их к двум интерфейсам. С помощью мастера настройки и обычных режимов работы ddclient, предусмотренных скриптами в /etc/init.d/ddclient это настроить нельзя. Поэтому я настроил немного по-другому.

Нужно прописать в файле конфигурации обычные настройки для одного домена, но указать их два. Для каждого домена обновлять записи следует из командной строки, указывая название интерфейса и доменное имя, для которых производится обновление. Теоретически можно было бы вызывать эти скрипты единожды при поднятии PPP-интерфейсов, однако на практике такая схема обновления записей себя не оправдала: если ddclient не срабатывал сразу при поднятии интерфейса, то новых попыток обновить адрес не предпринималось до тех пор, пока PPP-соединение не будет переподключено вновь. Если каждое обновление записей в DynDNS требует личного контроля, автоматизацией это не назовёшь. Поэтому был выбран другой вариант - обновление записей по cron'у.

Сначала я отключил режим демона и режим запуска для PPP-соединений:
run_ipup="false"
run_daemon="false"
daemon_interval="1m"
Настроил в файле /etc/ddclient.conf два доменных имени:
pid=/var/run/ddclient.pid
protocol=dyndns2
server=members.dyndns.org
login=www2
password='password'
ufadeb.homelinux.org
stupin.homelinux.org
И настроил запуск ddclient по cron'у каждую минуту:
# crontab -e
Добавив в таблицу две строчки:
*   *  *   *   *     /usr/sbin/ddclient -file /etc/ddclient.conf -host stupin.homelinux.org -use if -if ppp0
*   *  *   *   *     /usr/sbin/ddclient -file /etc/ddclient.conf -host ufadeb.homelinux.org -use if -if ppp1
Интерфейсы ppp0 и ppp1 всегда привязаны к определённым соединениям с помощью опции unit демона pppd.

Теперь можно перезапустить демон cron, чтобы он заново считал свои настройки (хотя вроде бы и так он перечитывает их каждую минуту):
# /etc/init.d/cron restart
ddclient хранит текущие настройки в файле /var/cache/ddclient/ddclient.cache, иногда для того, чтобы принудительно обновить настройки на DynDNS-сервере может потребоваться удалить этот файл (ddclient не отправляет запрос на обновление, если текущие настройки интерфейсов совпадают с сохранёнными в этом файле).

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

понедельник, 11 августа 2008 г.

Конвертируем FLAC в MP3 под Debian

Неоднократно от разных аудиофилов с хорошей аудиоаппаратурой слышал, что mp3 сжатие сильно ухудшает качество звука.

Однажды я решил попробовать скачать музыку в современном свободном формате со сжатием без потерь, чтобы попробовать оценить разницу между mp3 и flac на моей аппаратуре и моим слухом.

Накачал для примера несколько компакт-дисков, сжатых в этом формате. На слух разницы не услышал. Скачал ещё один компакт-диск, чтобы сравнить с альбомом в формате mp3 с битрейтом 192 килобита, который у меня уже был. Можно было поступить проще - просто пересжать один из компакт-дисков в mp3 и сравнить.

В итоге я опять не услышал никакой разницы. В мою голову закрались смутные сомнения:
  1. возможно скачанный диск был получен из треков mp3,
  2. у меня плохая аудиосистема,
  3. у меня плохая звуковая карта,
  4. у меня плохой слух.
Так или иначе, но если я не заметил разницы, смысла в хранении альбомов размером с пол-гигабайта я не увидел, а потому решил пересжать flac в mp3.

Из подручных средств под виндой у меня не оказалось перекодировщика, который бы умел декодировать flac (проигрыватель foobar2000 не в счёт). Кроме того, на домашнем компьютере почти не было места для пересжатия, потому я решил пересжать треки прямо на домашнем сервачке под Debian.

Для этого я использовал пакеты flac, lame и немножко shell-скриптинга.

Для начала установим пакет flac:
# aptitude install flac
Теперь нужно установить пакет lame. Этот пакет не включен в основную поставку Debian по лицензионным соображениям, поэтому воспользуемся сторонним сервером.

Для начала добавим новые источники в файл /etc/apt/sources.list:
# deb http://ftp.debian-unofficial.org/debian etch main contrib non-free restricted
# deb-src http://ftp.debian-unofficial.org/debian etch main contrib non-free restricted
Теперь добавим GPG-ключи:
# wget http://ftp-master.debian-unofficial.org/other/openpgp/archive-key-2006.asc -O - | apt-key add -
wget http://ftp-master.debian-unofficial.org/other/openpgp/archive-key-2007.asc -O - | apt-key add -
Теперь обновим список пакетов:
# aptitude update
И установим пакет lame:
# aptitude install lame
Для потоковой обработки всех файлов с расширением .flac в текущем каталоге я наваял следующий shell-скрипт mlame.sh:
#!/bin/sh

for flac in *.flac;
do
  mpeg=`echo $flac | cut -f1 -d.`.mp3
  flac -d -c "$flac" | lame --cbr -b 192 - "$mpeg"
done
Этот скрипт находит в текущем каталоге файлы с расширением flac. В цикле для каждого такого файла создаёт имя целевого файла mp3, затем настраивает команды flac и lame для совместной работы в конвейере.

Сжатие осуществляется в mp3-файл с постоянным битрейтом 192 килобита.

Если есть предложения по оптимизации скрипта, буду рад выслушать. К сожалению мне не удалось обойтись без cat, поскольку в именах файлов были пробелы, поэтому скрипты воспринимали имя файла как несколько не связанных между собой аргументов.

Ссылки по теме:
Установка lame на Debian

четверг, 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

понедельник, 23 июня 2008 г.

DNAT с помощью ipfw и natd

Коротко о сути того, что нужно было сделать.

Один корпоративный сайт, находящийся вне нашего филиала, доступен через интернет и по корпоративной сети. В интернете этот сайт имеет белый IP, а в корпоративной сети - серый. Соответственно трафик по интернет-сети оплачивается помегабайтно, а по корпоративной сети бесплатен.

Пользователи, подключающиеся по VPN к нашей сети имеют два DNS, один - провайдера, второй выдаётся VPN-сервером. Провайдерский DNS возвращает белый IP этого сайта, поэтому VPN-клиенты пытаются обращаться к сайту именно по белому IP. Нужно, чтобы они обращались по серому IP.

Отказаться от провайдерского DNS сложновато: он выдаётся автоматом и используется для установки соединения с VPN-сервером по его имени.

Был придуман костыль: на VPN-сервере настроить DNAT, чтобы заменять белый IP на серый.

Под Linux и iptables это настраивается элементарно, однако с FreeBSD, ipfw и natd пришлось немного попариться.

В итоге получились следующие правила, с дополнительным экземпляром natd:
${fwcmd} add divert 7667 tcp from VPN_сеть to белый_IP 443
${fwcmd} add divert 7667 tcp from серый_IP 443 to VPN_сеть
${natd} -p 7667 -n интерфейс_серый -redirect_port tcp серый_IP:443 белый_IP:443
  • VPN_сеть - диапазон IP-адресов, выдающийся VPN-клиентам,
  • белый_IP - белый IP корпоративного сайта,
  • серый_IP - серый IP корпоративного сайта,
  • интерфейс_серый - интерфейс VPN-сервера, обращённый в сеть с серым IP корпоративного сервера.
Суть правил в следующем:

В первом правиле отбираются пакеты, идущие от VPN-клиентов к белому IP корпоративного сервера и отправляются в специально обученный natd.

Во втором правиле отбираются ответные пакеты, то есть идущие от серого IP корпоративного сервера к VPN-клиентам и тоже направляются в специально обученный экземпляр natd.

В третьей строчке запускается специально обученный экземпляр natd. Он заменяет адрес назначения с белого на серый IP у пакетов, идущих от VPN-клиентов к корпоративному сайту. Для возвратных пакетов, идущих от корпоративного сайта к VPN-клиентам, осуществляется обратное преобразование, адрес корпоративного сайта с серым IP заменяется на адрес с белым IP.