Мой Мир. Мой Unix.

Asterisk запись звонков / call recording

2011-10-12T01:56:00.000-07:00

Заметка на 99% основана на http://nixadm.ru/archives/605 , но с некоторыми корректировками.

Все изменения вносятся в extentions.ael (про AEL написано тут http://habrahabr.ru/blogs/voip/122974/ ).
Разница в том, что я оформил в виде отдельного макроса, который можно подставлять в любые контексты и довел до рабочего состояния.

macro record( EXT , UNQ ) {
if ("${RECORDING}" = "1") {
Set(monopt=/bin/nice -n 19 /usr/local/bin/lame -b 16 --silent "${WAV}/${UNQ}.wav" "${MP3}/${UNQ}.mp3" && rm -f "${WAV}/${UNQ}.wav");
MixMonitor(${WAV}/${UNQ}.wav,b,${monopt});
};
return;
};

globals {
WAV=/var/log/asterisk/wav;
RECORDING=1;
MP3=/var/www/valinor.fabit.ru/asterisk;
};

context ael-sip {
s => {
Wait(1);
Answer();
Set(TIMEOUT(digit)=5);
Set(TIMEOUT(response)=10);
&record(${EXTEN},${UNIQUEID});
Dial(SIP/ael-user2);
Hangup();
};
};

Обязательно проверяем права в ${MP3} на запись у пользователя, от котого запущен asterisk (обычно asterisk).

В макросе переменная ${UNQ} планировалась для добавления ее в имя итогового файла для большей наглядности, так можете и поступить, добавив другие переменные.

Про удобную вебморду для прослушивания записей написано тут http://nixadm.ru/archives/659 .

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

OpenVPN: Отзыв и восстановление отозванных сертификатов

2011-08-30T00:29:00.000-07:00

Отзыв сертификата

Находясь в директории с easy-rsa, в которой происходит генерация сертификатов, устанавливаем переменные серды и выполняем скрипт revoke-fullSD/Unix:

./vars

./revoke-full hmmboy

hmmboy - имя сертификата. Имя можно посмотерть либо по названию сертификата, либо в файле keys/index.txt.

Восстановление отозванного сертификата

OpenSSL хранит статус каждого сертификата в ${CATOP}/index.txt, для OpenVPN это easy-rsa/keys/index.txt. На основе этого файла генерируется CRL (certificate revocation list).

Так выгялядят рабочий и отозванный сертификаты:

V       201120070444Z           22      unknown /C=RU/ST=Ru/L=Belgorod/O=FIT/CN=goodboy/emailAddress=admin@fabit.ru

R       201217190136Z   110830061053Z   23      unknown /C=RU/ST=Ru/L=Belgorod/O=FIT/CN=hmmboy/emailAddress=admin@fabit.ru

Для восстановления отозванного сертификата нужно отредактировать это файл. Заменить в строке соответствующей отозванному сетификату R на V и удалить третий столбец (это дата отзыва). Колонки разеделены табуляций, если нарушить это разделение, то можно похерить CA. Поэтому никаких пробелов и MS Word'ов.

После сохранения изменений нужно перегенерировать CRL. Возможно есть более гуманные способы, но приведенный ниже занял меньше всего времени по его поиску и возможности повторого использования. Скрипт revoke-full перегененрирует CRL, скопируем его в crl-regen и закомментируем строки ответственные за отзыв сертификата.

#!/bin/bash

CRL="crl.pem"

RT="revoke-test.pem"



#if [ $# -ne 1 ]; then

#    echo "usage: revoke-full <cert-name-base>";

#    exit 1

#fi



if [ "$KEY_DIR" ]; then

    cd "$KEY_DIR"

    rm -f "$RT" 



    # set defaults

    export KEY_CN=""

    export KEY_OU=""

    export KEY_NAME=""

  

#    # revoke key and generate a new CRL

#    $OPENSSL ca -revoke "$1.crt" -config "$KEY_CONFIG" 

 

    # generate a new CRL -- try to be compatible with

    # intermediate PKIs

    $OPENSSL ca -gencrl -out "$CRL" -config "$KEY_CONFIG"

    if [ -e export-ca.crt ]; then

        cat export-ca.crt "$CRL" >"$RT"

    else

        cat ca.crt "$CRL" >"$RT"

    fi

    

#    # verify the revocation

#    $OPENSSL verify -CAfile "$RT" -crl_check "$1.crt"

else

    echo 'Please source the vars script first (i.e. "source ./vars")'

    echo 'Make sure you have edited it to reflect your configuration.'

fi

Далее через скрипт list-crl можно поглядеть на отсутствие сертификата в списке отозванных. Так же помним о необходимости установить переменные среды через vars.

Bash. Batch

2011-08-14T09:04:00.000-07:00

Search, match & rename:

for i in *;
do
if echo $i | grep -q aniDuB
then
mv $i `echo $i | sed 's/aniDuB/AniDub/g'`
fi
done

Find content in files & replace

find . -name "*.conf" -print | xargs sed -i 's/listen$.*$91.194.207.148:80/listen\180/g'

Linux-шлюз. Объединение двух сетей с одинаковым адресами подсетей.

2011-04-11T03:52:00.000-07:00

Статья расчитана на людей, имеющих смутное представление о хождении трафика внутри ядра Linux. Мастера Дзен, постигшие природу netfilter, не найдут такие учения достойными их внимания, так как текст содержит много пояснительной информации. Это не готовое решение, но задает вектор для поиска правильного пути в преодолении подобной проблемы.

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

При создании локальной сети не каждый администратор подходит с ответственностью к выбору диапазона адресов. А может и не каждый догадывается о наличии частных диапазонов кроме 192.168.0.0/24. И со временем такая бомба замедленного действия может дать о себе знать. Локальные сети объединяются, возникает потребность в коммуникации между хостами разных сетей. И тут выясняется, что адреса подсетей совпадают. И менять их по каким либо причинам проблематично или невозможно.
В таком случае, серверу, маршрутизирующему пакеты между сетями, остается сделать вид, что подсети различны и выдавать желаемое за действительное. В богатом арсенале Linux есть средства для таких манипуляций: iptables с NETMAP и утилита ip.

1. Цель.
Из сети LAN1 мы хотим послать пакет в сеть LAN2. Но мы не можем послать его в подсеть, адрес которой одинаков с нашим. В самом частом случае 192.168.0.0/24. Если такой пакет появится в LAN1, он не будет знать, что есть LAN2, он будет искать такую машину в LAN1. Таковы правила маршрутизации по умолчанию.
Значит, надо посылать пакеты с другими адресами, которые уйдут в роутер.

Как это должно вглядеть для внешнего наблюдателя из LAN1.
Например, пользователь сети LAN1 будет видеть сеть LAN2 как 10.8.1.0/24. Тут уже никакого пересечения адресов. LAN1 доволен.

Как это выглядит с обеих сторон.
Из LAN1 приходит пакет с адресом отправителя 192.168.0.100 и адресом назначения 10.8.1.200. Из роутера с интерфейса LAN2 выходит тот же пакет с адресом отправителя 10.8.1.100 и с адресом назначения 192.168.0.200. Пакет проходит до адреса назначения и тот шлет в ответ на адрес отправителя со своим адресом. Пакет уходит в роутер. В нем происходит обратное преобразование и пользователь LAN1 получает ответ с того адреса, на который отправил пакет.

2. Теория. Путь пакета в ядре роутера: netfilter.
Здесь я попытаюсь рассказать о путешествии транзитного трафика через наш Linux-роутер. Для полного понимания процесса путешествия пакета лучше видеть схему его прохождения по цепочкам netfilter.

Pic 1: wikipedia.org

Наш пакет с [источником|назначением] [192.168.0.100|10.8.1.200] попадает на сетевой интерфейс роутера и первой его цепочкой будет PREROUTING.

PREROUTING
Проходя по цепочке он попадает в таблицу PREROUTING mangle. В которой посредством iptables мы определяем интерфейс, с которого он пришел, и адрес источника. Если это наш пациент, мы его помечаем действием MARK (для каждой манипуляции с пакетом есть своя таблица и цепочка).
После чего пакет [192.168.0.100|10.8.1.200|(marked)] попадает в таблицу nat. Эта таблица предназначена для трансляции адресов. Поскольку не существует реального адреса 10.8.1.200, то на последующем этапе маршрутизации пакет будет отброшен или уйдет в неизвестном направлении. Поэтому заменяем ему адрес назначения на тот, на который он действительно должен пойти именно тут: [192.168.0.100|192.168.0.200|(marked)]. Делается это действием NETMAP, которое заменяет подсеть по маске.

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

Пакет успешно проходит цепочку FORWARDING. Попадает опять на этап маршрутизации. Если в FORWARDING с ним ничего не случилось, а по идее не должно было. Он идет тем же путем. После чего попадает в POSTROUTING.

POSTROUTING
Без изменений доходя до таблицы nat. Мы должны изменить адрес источника. Ведь ответ на пакет [192.168.0.100|192.168.0.200] будет отправлен в локальную сеть, а не в роутер. Чтоб он попал обратно в роутер, меняем адрес источника на несуществующий [10.8.1.100|192.168.0.200]. Опять же NETMAP. После этого пакет выходит в LAN2.
С ответным пакетом проделываем обратную процедуру, чтоб он дошел до первоначального источника.

3. Реализация.

iptables -t mangle -A PREROUTING -i tun0 -d 10.8.1.0/24 -j MARK --set-mark 8

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

iptables -t nat -A PREROUTING -m mark --mark 8 -j NETMAP --to 192.168.0.0/24

Узнаем пакет по метке и действием NETMAP в таблице PREROUTING подменяет адрес назначения.

iptables -t nat -A POSTROUTING -m mark --mark 8 -j NETMAP --to 10.8.2.0/24

В POSTROUTING NETMAP подменяет адрес источника.
После этого все обращения на подсеть 10.8.1.0/24 будут выглядеть внутри LAN2, как обращения из подсети 10.8.2.0/24.

ROUTING
Чтобы маршрутизировать пакеты по метке необходимо создать свою таблицу маршрутизации.Редактируем /etc/iproute2/rt_tables, добавляя уникальное число и название новой таблицы.

256 netmap

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

ip ru add fwmark 0x8 lookup netmap

Теперь помеченные пакеты будут уходить на маршрутизацию в таблицу netmap.

И последним шагом нужно определить маршруты в таблице netmap.

ip route add default dev eth1 table netmap

Или можно указать в отдельном случае отдельный шлюз, если в эту сеть трафик от роутера идет через него. Что-то в духе:

ip route via 192.168.1.254 dev eth1 table netmap

Пока рано радоваться, к нам придет ответ из LAN2 [192.168.0.100|10.8.2.200].
Надо сделать все тоже самое, но только преобразовать обратно, увы, netfilter сам этого не делает. Все действия уже описаны, приведу только последовательность команд для преобразования адресов в одну и в обратную сторону. (В первой таблице маршрутизации необходимости в данном случае нет, но при иных обстоятельствах может понадобиться.)

ip rule add fwmark 8 lookup netmap
ip route add 192.168.0.0/24 dev eth1 table netmap

iptables -t mangle -A PREROUTING -i tun0 -d 10.8.1.0/24 -j MARK --set-mark 8
iptables -t nat -A PREROUTING -m mark --mark 8 -j NETMAP --to 192.168.0.0/24
iptables -t nat -A POSTROUTING -m mark --mark 8 -j NETMAP --to 10.8.2.0/24

ip rule add fwmark 9 lookup netmap2
ip route add 192.168.0.0/24 dev tun0 table netmap2

iptables -t mangle -A PREROUTING -i eth1 -d 10.8.2.0/24 -j MARK --set-mark 9
iptables -t nat -A PREROUTING -m mark --mark 9 -j NETMAP --to 192.168.0.0/24
iptables -t nat -A POSTROUTING -m mark --mark 9 -j NETMAP --to 10.8.1.0/24

Результаты.
Вот что пишет tcpdump (первый пример с vnc, второй с пингом):

# tcpdump -i any port 5900

12:46:46.358969 IP 192.168.0.100.41930 > 10.8.1.200.5900: Flags [P.], seq 647:657, ack 261127, win 1213, options [nop,nop,TS val 460624 ecr 171318], length 10

12:46:46.358978 IP 10.8.2.100.41930 > 192.168.0.200.5900: Flags [P.], seq 647:657, ack 261127, win 1213, options [nop,nop,TS val 460624 ecr 171318], length 10

12:46:46.505847 IP 192.168.0.200.5900 > 10.8.2.100.41930: Flags [.], ack 657, win 64879, options [nop,nop,TS val 171320 ecr 460624], length 0

12:46:46.505861 IP 10.8.1.200.5900 > 192.168.0.100.41930: Flags [.], ack 657, win 64879, options [nop,nop,TS val 171320 ecr 460624], length 0

# tcpdump -i any icmp

12:47:46.363905 IP 192.168.0.100 > 10.8.1.200: ICMP echo request, id 2111, seq 1, length 64

12:47:46.363922 IP 10.8.2.100 > 192.168.0.200: ICMP echo request, id 2111, seq 1, length 64

12:47:46.364049 IP 192.168.0.200 > 10.8.2.100: ICMP echo reply, id 2111, seq 1, length 64

12:47:46.364054 IP 10.8.1.200 > 192.168.0.100: ICMP echo reply, id 2111, seq 1, length 64

Tcpdump отлично демонстрирует, как происходит преобразование адресов на входе в один интерфейс и на выходе в другой и в обратную сторону.

Так же отлично работают остальные сервисы, типа Samba и ее аналог на Windows.

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

push "route 10.8.1.0 255.255.255.0"

Warning!
При отладке конфигурации не пытайтесь законнектиться к серверу, на котором шлюз. Соединяйтесь с машинами за ним в LAN2.
И вот почему. Правила расчитаны, что пакет будет проходить через шлюз, i. e.
PREROUTING -> Маршрутизация -> FORWARD -> Маршрутизация -> POSTROUTING
Если пакеты будут адресованы 10.8.1.1 (серверу), то они в результате маршрутизации пойдут в цепочку INPUT и преобразование адреса назначения в POSTROUTING не будет выполнено.
PREROUTING -> Маршрутизация -> INPUT -> Приложение
Соответственно, адрес источника не будет измненен и ответ будет послан не на 10.8.2.xy, а на 192.168.0.xy на маршрут по умолчанию для этого диапазона, т. е. в LAN2, а не в LAN1.

Заключение.
Рекомендую всем, занимающимся настройкой маршрутизации и фильтрации трафика в Linux, и особенно тем, кто этого еще не сделал, обратиться к документам Linux Advanced Routing & Traffic Control и Iptables tutorial. Любые другие статьи, советы, etc не дадут полного представления о сабже. Документы объемные и за один присест врядли получится их полностью понять, но они того стоят и в будущем могут служить хорошим справочником по командам и опциям iptables и iproute2. На просторах OpenNet'а есть их русскоязычные переводы, хоть и немного устаревшие. У оригиналов более свежие версии и соответственно описано больше опций, который отсутствовали на момент перевода.

P. S.
В процессе написания этого мануала нашел пару подобных статей, в которых описывается похожая ситуация.
Первая http://sudouser.com/nastrojka-nat-po-principu-set-v-set-pri-pomoshhi-iptables-netmap.html (Долго плевался, читая это.)
Вторая (англ.) http://nimlabs.org/~nim/dirtynat.html
Ситуация идентичная моей, с той лишь разницей, что у меня openvpn туннелирует ip трафик L3, в статье же ethernet L2. Немного другие адреса без отдельной маршрутизации по меткам. И применяется arp-proxy.

DHCPD: раздача адресов на 2 подсети. (ISC-DHCPD)

2011-04-01T14:57:00.000-07:00

Когда подсетей более чем 1, а сервер раздающий адреса - один на всех, то корректная раздача адресов одним демоном dhcpd может вызвать вопросы, которые я попытаюсь разобрать.

1. Как на два интерфейса раздавать одним демоном адреса разных подсетей?

2. Как на одном интерфейсе при нехватке одной подсети выдавать адреса из 2 подсетей?

1. Некоторые господа предлагают два экземпляра демона на два интерфейса с уникальными конфигами. Такой функциональный подход вызвает снисходительную улыбку.

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

То есть, если подсеть 192.168.1.0, то будет задействован только интерфейс с адресом 192.168.1.x, если второй интерфейс 192.168.2.x, то и диапазон разадачи будет 192.168.2.0. Главное - указать это в конфиге.

Пример конфига:


ddns-update-style ad-hoc

subnet 192.168.2.0 netmask 255.255.255.0 {
range 192.168.2.XX 192.168.2.XX;
default-lease-time 7200;
max-lease-time 21600;
option routers 192.168.2.XX;
option ip-forwarding off;
option broadcast-address 192.168.2.255;
option subnet-mask 255.255.255.0;
option domain-name-servers XX.XX.XX.XX, XX.XX.XX.XX;
}

subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.XX 192.168.1.XX;
min-secs 3;
default-lease-time 7200;
max-lease-time 21600;
option routers 192.168.1.XX;
option ip-forwarding off;
option broadcast-address 192.168.1.255;
option subnet-mask 255.255.255.0;
option domain-name-servers XX.XX.XX.XX, XX.XX.XX.XX;
}

2. Цитата по мотивам OpenNet'а.

Иногда случается, что в одном физическом сегменте сосуществуют несколько IP подсетей. Например в организации существует требование использовать 8-битные маски подсетей, но сеть разрослась до размеров превышающих 254 хоста, в этом случае необходимо использовать две подсети с 8-битными масками до тех пор пока новый ethernet сегмент не будет добавлен. В этом случае секции subnet описывающие две эти подсети могут быть заключены в секцию shared-network.

Для решения проблемы надо заключить обе подсети в shared-network, при этом interface eth1; необходимо объявить только в одной подсети группы.
Примерно так:

shared-network subnet10-1-1 {
    subnet 10.1.1.0 netmask 255.255.255.0 {
        interface eth1;
        option routers 10.1.1.1;
        option subnet-mask 255.255.255.0;
        range 10.1.1.2 10.1.1.254;
        allow unknown-clients;
    }
    subnet 10.1.2.0 netmask 255.255.255.0 {
        option routers 10.1.2.1;
        option subnet-mask 255.255.255.0;
        range 10.1.2.2 10.1.2.254;
        allow unknown-clients;
    }
}

Не редки более сложные случаи, но для них требуется более сложная магия с другими хитростями и инструментами.

Debian + PPA (Firefox 4 в Debian)

2011-03-24T16:37:00.000-07:00

[Зависть] Вот ведь несправедливость, какой-то дериват Debian Unstable пользуется всеми достижениями великого дистрибутива, так еще и к этому имеет всякие "человечные" фишки, которые довольно вкусны, но доступны только пользователям дистрибутива с африканским лицом. И один из примеров - PPA (Personal Package Archive) на базе Launchpad, на котором хостят свои проекты многие разработчики и самая свежатина появляется именно там. Восстановим справедливость! Землю - рабочим, заводы - крестьянам, deb'ы - дебианщикам!

Для начала немного информации о жертве. Launchpad - веб-проект хостящий у себя разработчиков с репозиториями исходников их программ, с кучей фич, упрощающих разработку и сопровождение софта. А так же содержит репы для Ubuntu с программами этих самых разработчиков, которые доставляются ленивым убунтоидам посредством PPA.
Как работает PPA?

1. Ленивый убунтоид хватает мышь рукой/ногой/хвостом. Запускает Ubuntu Software Center, тыкает Edit > Software Source, клик по Other Software. Клик по Add. Paste загадочный ppa:mozilla-team/firefox-stable. Клик!.. Клик!!. Клик!!!!1 Программа стоит, #@%$*!

2. Убунтоид умелый запускает консоль:
$ sudo add-apt-repository ppa:mozillateam/firefox-stable
$ sudo apt-get update && sudo apt-get upgrade

Срываем покровы! (Пытая теркой убунтоида)
PPA - это обычный дебиановский репозиторий, который регулярно обновляется самими разработчиками и их приспешниками.
Че за ppa:mozillateam/firefox-stable, спросите Вы?
На самом деле все просто. Добавляя это в свою уютненькую Ubuntu, ленивый убунтоид и не подозревает, что всего лишь добавил еще один репозиторий в sources.list.

deb http://ppa.launchpad.net/mozillateam/firefox-stable/ubuntu lucid main

Вот она и вся магия:

deb http://ppa.launchpad.net/<некий ppa>/ubuntu <версия Ubuntu> main

Так вот и очеловечил Марк sources.list, только версий для дебиана на PPA нет. Печально.
Но ничто не мешает добавить эти репы самим. Можно ручками в sources.list все прописать. Но можно применить запрещенный прием самих же убунтоидов. Добавим в систему add-apt-repository.
Это простой скрипт, найденный на просторах интернета, который также просто добавляется в систему одной командой:

# wget http://blog.anantshri.info/wp-content/uploads/2010/09/add-apt-repository.sh.txt -O /usr/sbin/add-apt-repository && chown root:root /usr/sbin/add-apt-repository && chmod u+x /usr/sbin/add-apt-repository

Теперь все просто как в Ubuntu.

# add-apt-repository ppa:mozillateam/firefox-stable
# apt-get install firefox

Если после выполнения команды add-apt-repository вылазят непонятные ошибки, то советую проверить содержимое add-apt-repository. Возможно там просто лог ушибок неудачного скачивания.

Содержимое add-apt-repository:

#!/bin/bash
if [ $# -eq 1 ]
then
 ppa_name=`echo "$1" | cut -d":" -f2 -s`
 if [ -z "$ppa_name" ]
 then
  echo "PPA name not found"
  echo "Utility to add PPA repositories in your debian machine"
  echo "$0 ppa:user/ppa-name"
 else
  echo "$ppa_name"
  echo "deb http://ppa.launchpad.net/$ppa_name/ubuntu lucid main" >> /etc/apt/sources.list
  apt-get update >> /dev/null 2> /tmp/apt_add_key.txt
  key=`cat /tmp/apt_add_key.txt | cut -d":" -f6 | cut -d" " -f3`
  apt-key adv --keyserver keyserver.ubuntu.com --recv-keys $key
  rm -rf /tmp/apt_add_key.txt
 fi
else
 echo "Utility to add PPA repositories in your debian machine"
 echo "$0 ppa:user/ppa-name"
fi

Строки в этом скрипте создают непонятную переменную и временный файл.

apt-get update >> /dev/null 2> /tmp/apt_add_key.txt
  key=`cat /tmp/apt_add_key.txt | cut -d":" -f6 | cut -d" " -f3`
  apt-key adv --keyserver keyserver.ubuntu.com --recv-keys $key
  rm -rf /tmp/apt_add_key.txt

Видимо, автор не освоил стандартные юниксовые пайпы.
Можем немного переписать эти непотребства в одну строку:

apt-get update >> /dev/null | cut -d":" -f6 | cut -" " -f3 | \

apt-key adv --keyserver keyserver.ubuntu.com --recv-keys -

Небольшое замечание по скрипту. Скрипт парсит stderr от apt-get update, т. е. если будут другие ошибки от apt-get update, то они ему тоже попадут под нож.

И замечание по поводу версии Ubuntu. На мой взгляд, лучше использовать текущую версию LTS (на момент написания - lucid) по двум причинам:
1. Debian в силу своей стабильности не так свеж, как самые новые Ubuntu.
2. LTS гарантирует 3 года жизни дистрибутива, т.е. меньше переживаний и бессоных ночей по поводу прекращения выпуска новых пакетов для старой Ubuntu.
Это всего лишь my humble opinion.

Да, как нетрудно заментить, с версии 6.06 названия дистрибутивов Ubuntu идут в алфавитном порядке латинского алфавита. Это позволяет проще ориентироваться в порядке версий. Natty Narwhal (Изящный Нарвал) идет перед Oneiric Ocelot (Сновещательный Оцелот). Дальше придумают что-нибудь вроде Pooper Peacock.

[/Зависть] P. S. Адептов Ubuntu и сочувствующих прошу воспринимать упоминания самой Ubuntu и ее пользователей в строках, приведенных выше, как шутку. Ни один убунтоид не пострадал. Peace. Love. Linux.

BIND. Собственная зона.

2011-03-20T18:51:00.000-07:00

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

[Tips & Tricks] (Адекватные люди могут пропустить следующие 4 абзаца.)
Свое доменное имя в чужой локалке. Ничего не мешает указать на внешних DNS-серверах в интеренете адрес из частного диапазона своей локальной сети, т.е. свой ip в локалке. Даже без ведома администратора этой сети. DNS-серверу без разницы на какой ip-адрес будет указывать имя. Конечно, за пределелами этой локалки смысла не будет в этом имени. Why so serious? Многочисленные любители держать локальные ресурсы, типа dc-хабов, игровых серверов, торрентов, радио и прочей мути, могут себя почувствовать полноценными хостерами. It's serious business.
Есть множество бесплатных доменных регистраторов вполне терпимых зон. Типа co.cc. Любой школяр будет рад держать игровой сервер имени себя. Вроде maximka-pro-gamer.co.cc. Врядли кто будет разоряться на домен второго уровня для такого ответственного дела, типа .org, .ru или .com. Бессмысленный перевод имен. But some people makes great deals.
Если же ip серый, то можно использовать всем известный dyndns.com, на имя которого через тип CNAME может ссылаться любое более приятное глазу имя. coolmegaserver.ru -> vasingameserver.dyndns.com -> Серый IP.
Более адекватное применение таких свободных и бесплатных серверов доменных имен - дополнительная анонимность для back-connect'а или любого другого коннекта, на что фантазии хватит. Допустим на сервере, от коротого мы ну ни как не можем вспомнить пароль, а возможности открыть порт нету, можно сделать коннест каким-либо образом netcat'ом к нашему хосту, и чтоб лишний раз не светить ip в логах или истории команд шела, присваиваем ему имя, которое можно потом с такой же легкостью удалить. Хотя это полумера и серьезной скрытности не предаст.
[END]

Переопределение адреса для конкретного домена. Или создание личного домена. Или управление зоной.

Для локальных зон в директории с конфигами /etc/bind/ есть специальный файл на такой случай named.conf.local. В нем-то и надо производить подобные манипуляции. (Конечно это все условности, и он посредством инклуда включен в основной конфиг, но для сохранения порядка лучше модифицировать его.)

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

Для примера будем перенаправлять microsoft.com. Вносим следующие строки:

zone "microsoft.com"{
type master;
file "/etc/bind/db.microsoft.com";
};

где тип зоны "мастер" говорит бинду, что мы управляем доменом;
file - наш файл, в котором хранятся записи о домене.
Он может выглядеть так:

$TTL 604800
@ IN SOA microsoft.com. hostmaster.example.com. (
; после ";" - идут комментарии, hostmaster.example.com = hostmaster@example.com
; почтовый адрес админа зоны, первая точка вместо @
20110317 ; Порядковый номер - при его увеличении подчиненные серверы
; обновляют данные, если таковые есть.
7200 ; Период обновления - периодичность обновления данных подчиненным серверами.
1800 ; Интервал между попытками - если в первый раз не получилось обновить данные.
604800 ; Интервал устаревания - время обслуживания зоны подчиненными серверами
; в отсутствии главных серверов.
7200 ) ; Минимальное время жизни (Negative cache TTL) - время жизни отрицательных ответов.
; Если нет подчиненных сервереров, то эти данные менять не обязательно.
;
@ IN A xx.xx.xx.xx ; @ - псевдоним текущей зоны, т.е. microsoft.com, xx.xx.xx.xx - ее ip-адрес
@ IN NS localhost. ; NS - DNS зоны, необходимо указать сервер имен зоны, чтоб у него
; клиент резолвил имена в этой зоне, в данном случае это этот же сервер
; если имя указано в конце без ".", то он воспринимается как префикс к текущей зоне
; т.е. localhost = localhost.microsoft.com.
; если указать ip адрес вместо имени, то он будет воспринят как имя, xx.xx.xx.xx.microsoft.com
; поэтому лучше сделать следующую запись в таком случае
@ IN NS ns ; указываем сервер имен вместо предыдущего или вместе,
; если он в нашей зоне, если нет, то указываем полное имя и не забываем про точку
ns IN A yy.yy.yy.yy ; пишем адрес, если все же в нашей зоне,
; этот же тип записи характерен для всех поддоменов нашей зоны
; вместо ns - любое имя, * - будет перенаправлять все поддомены на указанный ip-адрес
google IN CNAME google.com. ; CNAME - каноническое имя, псевдоним для другого хоста.

Эра IPv6 уже не загорами и вместо A будут использоваться записи AAAA. И BIND 9 к этому готов. Ничего не мешает получать у сервера имен адреса IPv6, даже если он имеет адрес IPv4.
IPv6 запись в том же конфиге может выглядеть так:

google IN AAAA 2a00:1450:800

Как-то так. Материал ни в коей мере не претендует на адекватность и раскрытие темы. Все названия и имена вымышлены. А любые совпадения - случайны.

[Tips & Tricks] SSH множественное перенаправление портов

2011-01-29T08:03:00.000-08:00

Бывалых пользователей этот метод не удивит. Иногда возникает необходимость подлючиться к сети и сделать forwarding удаленных портов на локальную машину. Есть вариант использовать SOCKS5 (параметр -D), возможности которого предоставляются openssh, но можно сделать проще - перенаправить несколько удаленных портов на локальные. Зачем это? Не особо большое удовольствие прописывать в браузере SOCKS5 каждый раз. Или делать несколько подключений. VPN? Для таких мелких задач он не нужен. Куда проще открыть страницу в браузере что-то вроде: http://127.0.0.1:3130, или подключиться к машине в локалке за сервером -L 5900:192.168.0.10:5900
Как оказалось, ssh может переваривать несколько параметров -L:

# ssh user@82.151.114.123 -L 3129:localhost:80 -L 3130:www.google.com:80 -L 3131:localhost:3128
Семантика параметра -L для перенаправления на локальную машину такова: -L <local port>:<remote host>:<remote port>

# lsof -i -P | grep ssh
ssh 4105 root 5u IPv4 177511 0t0 TCP localhost:3129 (LISTEN)
ssh 4105 root 7u IPv4 177515 0t0 TCP localhost:3130 (LISTEN)
ssh 4105 root 9u IPv4 177519 0t0 TCP localhost:3131 (LISTEN)

Возможно будет выскакивать ошибка такого рода:
channel 7: open failed: connect failed: Connection refused

Решилась проблема добавление параметра в конфиг ssh-сервера /etc/ssh/sshd_config:
AllowTcpForwarding yes

Все манипуляции производились c использованием OpenSSH 5.7

Домолинк. Статический IP. Модем Zyxel P660RU2 EE. NAT. ADSL

2011-01-24T03:13:00.000-08:00

[Заметка на полях] Некоторое время назад пришлось настраивать сабж в организации. Сама процедура настройки совсем нехитрая. Но почему-то в интернете описания не нашлось. Она отличается от настройки домашнего пользователя с динамическим IP. Может еще кому пригодится, чтобы не перебирать все варианты. ТП Домолинка может только рассказывать заученные шаблоны для динамического IP.
Как подключить модем, зайти по дефолтному паролю и сменить его - рассказывать не буду.
Заходим в веб-интерфейс по адресу модема: 192.168.1.1. Во вкладке Network -> WAN выставляем следующие параметры (в квадратных скобках):

P660RU2
|
+-Network
| |
| +-WAN
~~~~~~~~

--------------------
Line
--------------------

Modulation [Multi Mode]
Annex [Annex B] (Сигнализации ради, если ее нет, то можно Annex A)

--------------------
General
--------------------

Name [любое]
Mode [Routing]
Encapsulation [ENET ENCAP]
Multiplexing [LLC]
Virutal Circuit ID (2 параметра зависят от региона)
VPI [0]
VCI [35]

--------------------
IP Address
--------------------

( ) Obtain an IP Address Automatically
(o) Static IP Address
IP Address [xx.xx.xx.xx] (Ваш статический IP)
Subnet Mask [xx.xx.xx.xx] (Выданная Вам маска подсети - MS)
Gateway IP address [xx.xx.xx.xx] (Ваш GW)

После настройки перезапускаем модем, почему-то сразу принимать новые параметры без перезагрузки отказывался. Таки все.

Gnome 3 in Debian. Experimental. Сага.

2011-01-19T09:45:00.000-08:00

Ставим gnome-shell от Gnome 3 в Debian Squeeze.
Википедия говорит:
GNOME Shell — одна из компонент GNOME 3, следующего поколения свободной среды рабочего стола GNOME. GNOME Shell управляет рабочим столом и отвечает за такие базовые функции, как запуск приложений и переключение между окнами. GNOME Shell тесно интегрирован с Mutter, который является следующим поколением оконного менеджера Metacity.

Хватит слов, приступим к делу!

Добавляем в репозитории /etc/apt/sources.list

deb http://ftp.debian.org/debian experimental main non-free contrib

# apt-get update
# apt-get install gnome-shell -t experimental

За этим безобразием тянутся QT.

Видим, как в процессе установки гном дохнет и возраждается.

Далее запускаем команду:

$ gnome-shell --replace

Наблюдаем за чудесами исчезновения старых панелей и пояления новой с подозрительной кнопкой Activities, через которую и должна протекать вся основная деятельность.

Пропала возможность переключать раскладку средствами гнома. Скорее всего причина тому то, что не все пакеты среды доступны, это всего лишь gnome-shell. Исправляем через Иксы:

$ setxkbmap -layout "us,ru" -option "grp:alt_shift_toggle,grp_led:scroll"

Рабочий стол остался только один.
Workspace'ы обнаружились в меню Activities, где добавлялись плюсиком, переключение между всеми окнами осуществляется традиционнім Alt-Tab, даже если окна на разных столах. Или традиционными Ctrl+Alt+стрелки. Увы, не видно, что находится на столах при переключении. Еще можно мышой хватать фон и таскать столы.
Количество столов динамично, могучие + и - правят их количеством. Жаль, что только в одном измерении переключаются - вправо и влево, хотя может я просто плохо искал.
Не смотря на эти неудобства, видны красотульки.

Конки завелись, хоть и не сразу.

Позрачность теперь реальна, т.е. видно не только фоновый рисунок на прозрачном окне, но окна между фоном и прозрачным окном.
Не увидел трея с программами, только настройки.
Уже посещают мысли, как приделать сенсорную панель к нетбуку, п.ч. новый гноме расчитан на возюканье пальцем ноги. Судя по тенденции, близится єра компьютеров с сєнсорніми экранами. Вспомнился Unity, чем-то схож. Думаю, на каком-нибудь xPad'е, когда допилят, будет удобно.

Общее впечатление: слава богам, оно не такое тяжелое, как KDE 4, но требует основательного допила, ибо глючно, но шустро, если ничего не сломают.
Приговор: не трогать до релиза! Пусть зреет.
Нужно ли оно? Увы, всем гномерам рано или поздно придется сменить Gnome 2 на что-либо.
Посижу на этом добре, вроде юзабельно.
А теперь картинки! Все любят картинки!

Ну и в заврешение телка с моими конками.

Девка не моя! Я просто поставил на фон картинку из инета!

Потрошим чужие deb'ы или взмах катаной

2011-01-03T03:18:00.000-08:00

Это продолжение заметки о сборке deb'ов, только уже наоборот.
Для чего это может понадобиться?
В первую очередь, если мы хотим собрать истинно канонiчный и рассово верный пакет, но не собираемся записывать мэйнтейнеры Debian, то проще всего взять готовый deb-пакет (если таковой есть), разобрать его, обновить бинарники, подправить метаданные и собрать обратно. Зачем делать то, что сделали до нас? Go! Go! Go! Fire in the hole! (пер.: Пойти! Пойти! Пойти! Огонь в дыре!)

Для операции - распаковки .deb пакета можно сделать так (этот метод извлечет только инсталируемые файлы):
# dpkg -x somepackage.deb ~/target_directory/

Или быстрый самурайский метод:
# ar p somepackage.deb data.tar.gz | tar zx

Тот же самурайский метод по шагам (наша катана вскроет внутренности пакета и вывалит их наружу). На самом деле deb-пакет всего лишь юниксовый ar-архив, который можно разобрать (а так же собрать) стандартными средствами любого *никса:
# ar vx somepackage.deb

x - debian-binary
x - control.tar.gz
x - data.tar.gz

где debian-binary - файл, содержащий версию deb-пакета (не имеет отношения к версии программы);
control.tar.gz - содержимое DEBIAN, директория, которую мы создавали для метаданных в заметке про создание пакетов (тут больше файлов и назначение их можно понять по названию);
data.tar.gz - инсталлируемые в систему файлы (доки, бинарники, конфиги).

Распаковка архивов стандартным методом:
# tar -xzvf data.tar.gz

Просмотр их содержимого без распаковки:
# tar -tzvf data.tar.gz

На этом все, спрячем катану в ножны и насладимся цветением сакуры весенним днем у подножья Фудзи, обдуваемой легким ветерком с востока.

Lenny in the Sky with Daemons. Стартовые скрипты Debian

2010-12-30T00:28:00.000-08:00

Обращаем программы в демонов и ставим их на службу добру ]:-)>.

Инициализация системы в Debian подобна Unix System V или, проще говоря, Sys-V like init system.
После того, как загрузчик передал управление ядру, а ядро запускает init, тут-то и начинается вся настройка пользовательского окружения. И в зависимости от уровня выполнения, который можно посмотреть в /etc/inittab:
id:2:initdefault:
или командой runlevel, запускаются скрипты различных системных демонов в /etc/rc#.d/, где # - уровень выполнения, по умолчанию он 2.
В директории /etc/rc2.d/ расположены символические ссылки на директорию /etc/init.d/, где сами скрипты и лежат. Симлинки только те, которые нужны для уровня выполнения, а не все подряд.
Симлинки начинающиеся c K - неактивны (disable), с S - эти выполняются (enable). Дальше после первой буквы идет номер, это порядок запуска. Порядок важен некоторым зависимым от других демонам.

Таким образом, для соответсвия канонам наш демонизирующий скрипт должен лежать в /etc/init.d/, а потом его уже специальными инструментами добавим в нужные уровни запуска.

Вот пример минимального скрипта:

#! /bin/sh

# /etc/init.d/blah
#

# Some things that run always
touch /var/lock/blah

# Carry out specific functions when asked to by the system
case "$1" in
start)
echo "Starting script blah "
echo "Could do more here"
;;
stop)
echo "Stopping script blah"
echo "Could do more here"
;;
*)
echo "Usage: /etc/init.d/blah {start|stop}"
exit 1
;;
esac

exit 0

Обязательно должны быть два принимаемых параметра start и stop.
Инструмент для помещения нашего демона в уровни выполнения - update-rc.d
Добавляем наш скрипт:
# update-rc.d blah defaults
Убираем из загрузки:
# update-rc.d -f blah remove
Запускаем, останавливаем:
либо
# /etc/init.d/blah start
либо
# service blah start
тоже самое со stop и другими принимаемыми параметрами, если они есть. Иногда бывает restart, status или специфичные для каких-либо программ.

На самом деле скрипты бывают очень сложные с кучей проверок, условий, параметров. Но это уже для более глубокого ковыряния.

Разбор более сложного примера из арча. Казалось бы, при чем тут арч?
Не при чем, просто наткнулся на пример, в котором есть полезные конструкции и невозбранно скопировал.

#!/bin/bash
. /etc/rc.conf
. /etc/rc.d/functions
TFTPD_ARGS=
[ -f /etc/conf.d/tftpd ] && . /etc/conf.d/tftpd
# конструкция [ -f "file name" ] возвращает true, если файл существует
PID=`pidof -o %PPID /usr/sbin/in.tftpd`
# pidof -9 %PPID <программа> возвращает идентификатор желаемого процесса, пропуская %PPID, т.е. родительскои pid породившего pidof процесса
case "$1" in
start) # обработка аргумента start
stat_busy "Starting TFTPD" # Вывод
[ -z "$PID" ] && /usr/sbin/in.tftpd {TFTPD_ARGS}
# -z пустая строка, т.е. нулевая длина, проверка есть ли такой пид
# если программа не запущена, pidof возвращает пустую строку
# т.е. если программа еще не запущена, то она запускается после &&
# если же она запущена, то [ -z $PID ] возвращает false
# и до выполнения && не доходит
if [ $? -gt 0 ]; then
# код заверешния последней команды, если 0 - успешно;
# -gt - проверка на условие больше

stat_fail
else
add_daemon in.tftpd
stat_done
fi
;;
stop)
stat_busy "Stopping TFTPD"
[ ! -z "$PID" ] && kill $PID &> /dev/null
if [ $? -gt 0 ]; then
stat_fail
else
rm_daemon in.tftpd
stat_done
fi
;;
restart)
$0 stop
$0 start
;;
*)
echo "usage: $0 {start|stop|restart}"
esac
exit 0

Как образец в Дебиане есть /etc/init.d/skeleton
Подробности в /etc/init.d/README

На его основе с немалыми правками сделал канонiчний загрузочный скрипт.

#! /bin/sh
### BEGIN INIT INFO
# Provides: ompd
# Required-Start: $remote_fs $syslog
# Required-Stop: $remote_fs $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Starts Opera Mini Proxy Daemon
# Description: Starts Opera Mini Proxy Daemon
#
### END INIT INFO

# Author: anonymous
#

# Do NOT "set -e"

# PATH should only include /usr/* if it runs after the mountnfs.sh script
PATH=/sbin:/usr/sbin:/bin:/usr/bin
DESC="OMPD - Opera Mini Proxy Daemon"
NAME=ompd
DAEMON="/usr/bin/python /opt/ompd/$NAME.pyc"
DAEMON_ARGS="-d"
PIDFILE=/var/run/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME
PID=`pidof -o %PPID /usr/bin/python /opt/ompd/mopd.pyc`
# Exit if the package is not installed
#[ -x "$DAEMON" ] || exit 0

# Read configuration variable file if it is present
#[ -r /opt/ompd/ompd.conf ] && . /opt/ompd/ompd.conf

# Load the VERBOSE setting and other rcS variables
. /lib/init/vars.sh

VERBOSE="yes"

# Define LSB log_* functions.
# Depend on lsb-base (>= 3.2-14) to ensure that this file is present
# and status_of_proc is working.
. /lib/lsb/init-functions

#
# Function that starts the daemon/service
#
do_start()
{
# Return
# 0 if daemon has been started
# 1 if daemon was already running
# 2 if daemon could not be started
#start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON --test > /dev/null || return 1
#start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON --$DAEMON_ARGS || return 2
if [ -z $PID ]; then
$DAEMON $DAEMON_ARGS > /dev/null 2>> /var/log/faillog &
if [ $? -gt 0 ]; then
return 2
else
return 0
fi
else
return 1
fi
# Add code here, if necessary, that waits for the process to be ready
# to handle requests from services started subsequently which depend
# on this one. As a last resort, sleep for some time.
}

#
# Function that stops the daemon/service
#
do_stop()
{
# Return
# 0 if daemon has been stopped
# 1 if daemon was already stopped
# 2 if daemon could not be stopped
# other if a failure occurred
if [ -n "$PID" ]; then
kill $PID
if [ $? -eq 0 ]; then
return 0
else
return 2
fi
else
return 1
fi
#start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile $PIDFILE --name $NAME
#RETVAL="$?"
#[ "$RETVAL" = 2 ] && return 2
# Wait for children to finish too if this is a daemon that forks
# and if the daemon is only ever run from this initscript.
# If the above conditions are not satisfied then add some other code
# that waits for the process to drop all resources that could be
# needed by services started subsequently. A last resort is to
# sleep for some time.
#start-stop-daemon --stop --quiet --oknodo --retry=0/30/KILL/5 --exec $DAEMON
#[ "$?" = 2 ] && return 2
# Many daemons don't delete their pidfiles when they exit.
#rm -f $PIDFILE
#return "$RETVAL"
}

#
# Function that sends a SIGHUP to the daemon/service
#
do_reload() {
#
# If the daemon can reload its configuration without
# restarting (for example, when it is sent a SIGHUP),
# then implement that here.
#
start-stop-daemon --stop --signal 1 --quiet --pidfile $PIDFILE --name $NAME
return 0
}

case "$1" in
start)
[ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
do_start
case "$?" in
0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
;;
stop)
[ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME"
do_stop
case "$?" in
0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
;;
status)
status_of_proc "$DAEMON" "$NAME" && exit 0 || exit $?
;;
#reload|force-reload)
#
# If do_reload() is not implemented then leave this commented out
# and leave 'force-reload' as an alias for 'restart'.
#
#log_daemon_msg "Reloading $DESC" "$NAME"
#do_reload
#log_end_msg $?
#;;
restart|force-reload)
#
# If the "reload" option is implemented then remove the
# 'force-reload' alias
#
log_daemon_msg "Restarting $DESC" "$NAME"
do_stop
case "$?" in
0|1)
do_start
case "$?" in
0) log_end_msg 0 ;;
1) log_end_msg 1 ;; # Old process is still running
*) log_end_msg 1 ;; # Failed to start
esac
;;
*)
# Failed to stop
log_end_msg 1
;;
esac
;;
*)
#echo "Usage: $SCRIPTNAME {start|stop|restart|reload|force-reload}" >&2
echo "Usage: $SCRIPTNAME {start|stop|status|restart}" >&2
exit 3
;;
esac

:

Выше был пример редкого случая, когда необходимо запустить программу на питоне. В обычных случаях достаточно поправить переменные в skeleton'е.

Cint. Интерпретатор C/C++ или жестокий скриптинг

2010-12-29T03:31:00.000-08:00

Все в языке должно быть прекрасно. У С++ немало плюсов, но возможно это просто минусы, расположенные перпендикулярно.
- Надоели компиляторы... Неинтересно.
- No sir! Больше никаких компиляторов. Только интерпретаторы!
Тезисы, модели и подсистемы описаны тут http://habrahabr.ru/blogs/cpp/109898/ .
Наша задача: пришел, увидел, запустил.

Пришел: http://root.cern.ch/drupal/content/cint тут хомяк синта.

Увидел: # svn co http://root.cern.ch/svn/root/trunk/cint cint
# cd cint
# sh ./setenv.sh
# ./configure --with-prefix=/usr/local/cint/
доставил зависимостей
снова configure
# make -j2

параллельно с компиляцией запустил процесс распития пива:

bool compiled = false;
if(fork()) { compiled = compile(cint); }
else { while(!compiled) drink(beer); }
// ладно, знаю, что поток не прочитает измененную переменную в другом потоке. Это иллюстрация просто.

# checkinstall -D --pkgname cint --pkgversion 5.18.00 --pkgrelease 1 --arch i386 --strip --stripso --gzman

Запустил: $ cint test.cpp

Хочу заметить, что интерпретатор на 100% не поддерживает C/C++, и скорее всего программы-монстры не запустятся (однако, безумству храбрых поем мы песню).
Ну, а для образовательных, отладочных или извращенско-скриптовых целей - в самый раз. Теперь осталось найти безумца, готового переписать все скрипты в системе на истинно верном языке ;)

Создание deb-пакета из бинарников на примере OMPD

2010-12-28T21:57:00.000-08:00

- Мой мастер, я уже научился мастерски владеть checkinstall'ом. Когда я смогу превзойти тебя и тоже стать мастером?
- Мой юный падаван, когда сможешь собирать и компилировать пакеты в уме, тогда ты и станешь настоящим мастером. А для начала научись собирать пакеты, как делали это наши предки.

~ Сага о пакетах

Есть замечательная утилита checkinstall, которой для бытовых нужд хватает с головой. Но не всегда можно сделать так:
# checkinstall -D make install
Хотя оговорюсь, можно обойтись checkinstall. Этот самурайский метод рассмотрим поверхностно.

OMPD - компрессор веб-траффика, использующий сервера OperaMini для обработки страниц.

Программа реализована как локальный прокси-сервер.

Благодаря использованию протокола/формата OM v 1.2x-3.xx достигается очень высокая степень сжатия за счёт потерь в форматировании страницы. http://ompd-proxy.narod.ru/

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

Задача:

Канонично собрать пакет для Debian стандартными средствами.

Акт созидания:

1.Определяемся с православным именованием нашей жертвы:
<project>_<major version>.<minor version>-<package revision>
<название>_<версия>-<версия пакета>
В нашем случае:
ompd_0.3.2-1

2. Далее создаем директорию с этим названием:
# mkdir ompd_0.3.2-1

3. Переходим в директорию и начинаем думать. А думать начинаем, п.ч. наша программа и все ее файлы расположены в одной директории. Менять саму программу лень. В директории типа /usr/bin/ ставить ее - кощунство, сколько там будет мусора. Единственный вариант на такой случай директория /opt/. Увы, конфиг в /etc/ лежать не будет и шелл не будет знать, где лежит исполняемый файл (если мы сами ему не подскажем). Придется чем-то жертвовать или можно сварганить симлинк в /usr/bin/, это уже дело вкуса и остается на домашнее задание.

# cd ompd_0.3.2-1/
# mkdir opt
# mkdir opt/ompd
# cd opt/ompd/
# cp -fr ../../../ompd/* .

где последний путь - директория с разархивированной программой.

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

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

4. Дебовский пакет - это не только ценный мех^W^W свалка файлов, инсталируемых в систему, но еще и информация о том, что оно из себя представляет, откуда и для чего нужно. На эти непростые вопросы отвечают мета-данные в директории DEBIAN.
Возвращаемся в наш корень:

# cd ../..
# mkdir DEBIAN
# vim DEBIAN/control #ну или nano, дело вкуса и уровня джедайства (nano - для падаванов, vim - для мастеров, а для илиты - gedit)

Как должно выглядеть содержимое:

Package: ompdVersion: 0.3.2-1
Section: base
Priority: optional
Architecture: i386
Depends: python (>= 2.6.0), здесь могла быть еще одна зависимость, а потом через запятую еще и еще, это писать не надо (>= 6.6.6)
Maintainer: Your Name <you@email.com>
Description: OMPD
Web traffic comressor based on free Opera Mini servers
It works as local proxy server.
Very high compression rate has achieved due to usage of OM 1.2x..3.xx protocol/data format.

В описании перед каждой строкой должен быть пробел.

5. А теперь замутим свой пакет с шахматами и куртизанками:
# dpkg-deb --build ompd_0.3.2-1

где ompd_0.3.2-1 - наша директория с кишками и прочими потрохами программы, естественно, из которой мы предварительно вышли.
Пакет будет валяться в том месте, откуда вызвали dpkg-deb.

Вот так мы и наполнили нашу жизнь шалостями с Debian.

Как сделать тоже самое, но пойдя по пути самурая?
Просто!
Есть способы сборки из исходников deb-пакетов.
Делаем свой особенный Makefile с правилами установки, которые копируют файлы программы в нужные места. И установка должна осуществляться make install'ом.
А потом checkinstall в руки или световой меч^W^W предусмотренные для этого средства. Подробности о последнем можно прочитать тут: http://takeworld.blogspot.com/2009/05/deb.html

P.S. Еще можно наколдовать init-скрипт для запуска с системой, но это колдунство для совсем другой сказки.

Блог.

2010-12-28T18:55:00.000-08:00

Цель создания - сохранение информации, которая не умещается в памяти. Если кто-либо найдет полезным содержание (если вообще кто-нибудь его найдет на просторах сети), буду рад.
Ну, и возможно еще какой-нибудь бред, рожденный воспаленным разумом.