Краеугольный камень пакетной системы Debian — это deb-пакет (см. deb(5)), представляющий из себя архив формата ar, внутри которого содержится три файла:
1. debian-binary — текстовый файл, содержащий версию формата deb-пакета, в данный момент это 2.0. Программы, работающие с deb-пакетами, должны читать только первую строку этого файла и не падать, если минорная версия вдруг поменяется (например, станет 2.1).
2. control.tar.gz — служебная информация о пакете, скрипты, вспомогательные файлы (см deb-control(5)). Должен содержать только файлы, единственная папка, которая может присутствовать — «.» (текущая директория). В этот архив обязательно должен входить файл control, его минимальное содержимое рассмотрим чуть ниже.
3. data.tar — собственно файлы, устанавливаемые в систему. Чаще всего этот файл сжат каким-нибудь архиватором (поддерживаются расширения .gz, .xz, .bz2, .lzma), чаще всего в архивах встречается data.tar.gz.

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

Файл control в архиве control.tar.gz описывает назначение, версию и зависимости пакета, его формат более-менее подробно описан в deb-control(5). Пересказывать всю справку сейчас не буду, опишу лишь минимальное содержимое, необходимое для взаимодействия с инфраструктурой dpkg:

Package: имя пакета
Version: строка версии (при выборе политики назначения версий следует придерживаться deb-version(5))
Maintainer: John Doe <johndoe@foo.com> (человек, поддерживающий пакет, а не автор программы)
Description: короткое описание пакета
 Длинное описание,  на несколько строк. Каждая строка, входящая в
 длинное описание,  должна начинаться с пробела

Работа с пакетами средствами ar

Теоретически данной информации должно быть достаточно, чтобы собрать простейший пакет «на коленке» и установить его в систему. Пусть наш пакет (назовем его test) просто добавляет в систему файл /usr/share/example-content/test со строчкой «test». Сделаем архив data.tar.gz со структурой папок и единственным файлом, а также файлик debian-binary:

$ mkdir -p usr/share/example-content/
$ echo test > usr/share/example-content/test
$ tar czf data.tar.gz usr
$ echo 2.0 > debian-binary

Создадим файл control со следующим содержанием:

$ cat control
Package: test
Version: 1.0
Maintainer: Dummy Maint <dummy@example.org>
Description: test package
 Test package created on my own knees.
$ tar czf control.tar.gz control

Теперь соберем все воедино:

$ ar -qS test-1.0.deb debian-binary control.tar.gz data.tar.gz

В текущем каталоге должен появиться файл test-1.0.deb. Его «физическое» содержимое можно просмотреть с помощью следующей команды:

$ ar t test-1.0.deb
debian-binary
control.tar.gz
data.tar.gz

Посмотреть файл debian-binary:

$ ar p test-1.0.deb debian-binary
2.0

Посмотреть список файлов в пакете:

$ ar p test-1.0.deb data.tar.gz|tar -tzf -
usr/
usr/share/
usr/share/example-content/
usr/share/example-content/test

Посмотреть содержимое файла control:

$ ar p test-1.0.deb control.tar.gz |tar -O -xzf - control
Package: test
Version: 1.0
Maintainer: Dummy Maint <dummy@example.org>
Description: test package
 Test package created on my own knees.

Можно установить этот пакет и убедиться, что файл /usr/share/example-content/test успешно создан, но лучше этого не делать, поскольку из-за недостатка информации в control в пакетной системе может появиться мусор:

$ sudo dpkg -i test-1.0.deb
Selecting previously deselected package test.
(Reading database ... 97631 files and directories currently installed.)
Unpacking test (from test-1.0.deb) ...
Setting up test (1.0) ...

Работа с пакетами средствами dpkg-deb

Все вышеописанное позволяет управляться с deb-пакетами на самом низком уровне, не имея под рукой ничего, кроме стандартных средств Unix (доподлинно известно, что программа ar входила в состав первых Unix 1970х годов). Однако, как несложно догадаться, есть и более высокоуровневые способы создания пакетов и изучения их содержимого. В частности, если уж так необходимо поковыряться с пакетом на низком уровне, все вышеописанные действия настоятельно рекомендуется выполнять с помощью утилиты dpkg-deb(1).

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

Минимальный формат вызова команды dpkg-deb для построения пакета следующий:

dpkg-deb -b исходная_папка

Все, что находится в исходной папке, кроме директории DEBIAN, помещается в data.tar.gz. Содержимое DEBIAN будет использовано для создания control.tar.gz, в частности, будет прочитан и проанализирован файл control и в случае каких-либо ошибок (отсутствует одно из необходимых полей или эти поля имеют неправильные значения) пакет просто не будет создан. Процесс создания нашего тестового пакета с нуля теперь выглядит так (в последней команде предполагается, что в текущей папке остался файл control от сборки пакета средствами ar):

Подготовка структуры:

$ mkdir -p test-1.1/usr/share/example-content/ test-1.1/DEBIAN
$ echo test 1.1 > test-1.1/usr/share/example-content/test
$ sed 's/Version: 1.0/Version: 1.1/g' control > test-1.1/DEBIAN/control

Попытаемся собрать пакет:

$ dpkg-deb -b test-1.1
warning, in file 'test-1.1/DEBIAN/control' near line 5 package 'test':
 missing architecture
dpkg-deb: building package `test' in `test-1.1.deb'.
dpkg-deb: warning: ignoring 1 warnings about the control file(s)

Несмотря на отсутствие важного, но не необходимого поля Architecture, был создан пакет test-1.1.deb. Добавим поле и пересоздадим пакет:

$ sed -i "1a \
Architecture: all" test-1.1/DEBIAN/control
$ dpkg-deb -b test-1.1
dpkg-deb: building package `test' in `test-1.1.deb'

Еще одна немаловажная деталь. Как правило, в названии файла пакета указывается его архитектура, а команда dpkg-deb -b назвала файл по имени папки, из которой он был создан. Если бы папка называлась ololo, то мы получили бы ololo.deb. Чтобы файл пакета автоматически именовался в формате имя-версия-архитектура, при вызове dpkg -b необходимо указывать папку, куда будет положен итоговый архив, например, текущую. Тогда все компоненты имени файла будут извлечены из control:

$ cp -R test-1.1 ololo
$ dpkg -b ololo
dpkg-deb: building package `test' in `ololo.deb'.
$ dpkg -b ololo .
dpkg-deb: building package `test' in `./test_1.1_all.deb'.

Теперь всё относительно нормально, продолжаем изучение возможностей dpkg-deb на примере нового пакета.

Получение информации о пакете

Узнать версию формата deb, размер пакета и содержимое файла control:

$ dpkg -I test_1.1_all.deb
 new debian package, version 2.0.
 size 644 bytes: control archive= 259 bytes.
     160 bytes,     6 lines      control
 Package: test
 Architecture: all
 Version: 1.1
 Maintainer: Dummy Maint <dummy@example.org>
 Description: test package
  Test package created on my own knees.

Список файлов, устанавливаемых в систему (кроме служебных):

$ dpkg -c test_1.1_all.deb
drwxr-xr-x bvk/bvk           0 2010-10-22 13:21 ./
drwxr-xr-x bvk/bvk           0 2010-10-22 13:21 ./usr/
drwxr-xr-x bvk/bvk           0 2010-10-22 13:21 ./usr/share/
drwxr-xr-x bvk/bvk           0 2010-10-22 13:21 ./usr/share/example-content/
-rw-r--r-- bvk/bvk           9 2010-10-22 13:21 ./usr/share/example-content/test

Обратите внимание на владельца устанавливаемых файлов и каталогов: это не root, а некий пользователь. Чтобы исправить эту проблему, можно собирать пакеты из-под root’а, либо воспользоваться специальной утилитой fakeroot из одноименного пакета. Она перехватывает системные вызовы chmod(2) и stat(2) для файлов, и возвращает значения, как если бы файл принадлежал пользователю root. Небольшой пример:

$ id
uid=1000(bvk) gid=1000(bvk) ...
$ touch trololo
$ ls -l trololo
-rw-r--r-- 1 bvk bvk 0 2010-10-22 13:23 trololo
$ fakeroot ls -l trololo 
-rw-r--r-- 1 root root 0 2010-10-22 13:23 trololo

Думаю, принцип понятен. Пересоберем пакет еще более правильно:

$ fakeroot dpkg -b test-1.1 .
dpkg-deb: building package `test' in `test_1.1_all.deb'.
$ dpkg -c test_1.1_all.deb
drwxr-xr-x root/root         0 2010-10-22 13:25 ./
drwxr-xr-x root/root         0 2010-10-22 13:25 ./usr/
drwxr-xr-x root/root         0 2010-10-22 13:25 ./usr/share/
drwxr-xr-x root/root         0 2010-10-22 13:25 ./usr/share/example-content/
-rw-r--r-- root/root         9 2010-10-22 13:25 ./usr/share/example-content/test

Теперь наконец ок.

Можно получаить информацию о пакете в заданном формате:

$ dpkg-deb -W --showformat='${Package}-${Version}-${Architecture} (${Maintainer})\n' test_1.1_all.deb
test-1.1-all (Dummy Maint <dummy@example.org>)

Список полей, которые можно указать в –showformat, можно узнать из вывода команды dpkg-deb -I

Подать на STDOUT архив data.tar.gz из пакета (уже «разжатый»), может быть полезно для извлечения только некоторых файлов:

$ dpkg-deb --fsys-tarfile test-1.0.deb |tar -Ox usr/share/example-content/test
test

Перепаковка пакета

Пожалуй, теперь наступил момент применить свежеполученные знания на практике :) Часто возникает следующая проблема: из некоего источника поступил пакет с некорректными зависимостями, например, требуется устаревший пакет, отсутствующий в системе и всех репозиториях, но доподлинно известно, что другой, уже установленный пакет предоставляет нужную функциональность. В скачанном пакете требуется изменить файл control, убрав или исправив зависимость. Правильно было бы скачать и распаковать исходник пакета (apt-get source), произвести необходимые изменения в скриптах сборки, установить все необходимые для пересборки библиотеки и окружение и т.д. и т.п., но для частного использования (т.е. без распространения по репозиториям) достаточно просто распаковать пакет, изменить необходимые файлы и запаковать обратно. Проиллюстрирую последовательность действий на примере невинного пакета hello:

$ aptitude download hello
Get:1 http://yum.fireground.ru/ubuntu/mirror/ maverick/main hello i386 2.5-1 [34.4kB]
Fetched 34.4kB in 0s (824kB/s)
# да-да, я сижу под убунтой и описываю debian
# распаковать содержимое пакета в папку hello (если не существует, будет создана):
$ dpkg-deb -x hello_2.5-1_i386.deb hello
# распаковать содержимое control.tar.gz в hello/DEBIAN
$ dpkg-deb -e hello_2.5-1_i386.deb hello/DEBIAN
# что-нибудь поменять в control, например, версию пакета:
$ sed -i 's/Version: .*$/Version: 2.5-1test/' hello/DEBIAN/control 
# собрать новый пакет:
$ fakeroot dpkg -b hello/ .
dpkg-deb: warning: 'hello//DEBIAN/control' contains user-defined field 'Original-Maintainer'
dpkg-deb: building package `hello' in `./hello_2.5-1test_i386.deb'.
dpkg-deb: warning: ignoring 1 warnings about the control file(s)

Пакет собран. Убедиться, в том, что в нем нет ошибок из-за немного нетрадиционного способа сборки, можно с помощью программы lintian:

$ sudo aptitude install lintian
...
$ lintian hello_2.5-1test_i386.deb
$ echo $?
0

Всё в порядке!

Об установке пакетов в систему, механизме зависимостей, структуре репозиториев и еще более правильных способах сборки пакетов читайте в следующих статьях :)

В базовой системе (lenny) оставляем только функционал, необходимый для управления всем хозяйством, лично мне необходимы mc, openssh, vim, bash_completion и иногда svn. Также неплохо поиметь где-нибудь (да хоть на этой же машине) кэширующий прокси для репозиториев debian, типа apt-proxy или apt-cacher, чтобы не создавать излишнюю нагрузку на региональные зеркала. У нас используется apt-cacher, работающий по адресу http://apt:3142.

Debootstrap ­— основная рабочая лошадка:

apt-get install debootstrap

debootstrap --include=mc,ssh,vim lenny /systems/lenny http://apt:3142/ftp.debian.org/debian/

Первый аргумент — название релиза, второй — путь, куда устанавливается система, третий — адрес репозитория. В опции –include через запятую указываются пакеты, которые необходимы, но не входят в минимальную базовую систему. Debootstrap выкачивает из репозитория и устанавливает минимальный набор пакетов, теоретически сразу после этого можно делать chroot /systems/lenny и переходить к работе, но осталась еще несколько немаловажных доделок:

Добавляем идентификатор системы, который будет отображаться в скобках в приглашении шелла (читай — bash), выполняемом в chroot-окружении:

echo lenny > /systems/lenny/etc/debian_chroot

Но работа в основном ведется от имени root, а в squeeze и sid у root’а в .bashrc переменная окружения PS1 переопределяется и этот идентификатор пропадает. Поэтому если делаем виртуалку squeeze, то строчку с PS1 в /root/.bashrc лучше закомментировать:

sed -i 's/^\(export PS1.*\)$/#\1/g' /systems/squeeze/root/.bashrc

Монтируем /dev/pts — виртуальную файловую систему, которая динамически создаёт файлы терминалов /dev/pts/X для каждого нового подключения; это необходимо для нормального функционирования многих программ, работающих с терминалом, в т.ч. скриптов postinst и config пакета mysql-server:

mount -t devpts devpts /systems/lenny/dev/pts

Монтируем /proc (реально proc в новом месте будет содержать ту же информацию, что и общесистемный /proc):

mount -t proc proc /systems/lenny/proc

Чтобы apt-get не ругался на неподписанные пакеты при установке, необходимо обновить файл Release.gpg, т.к. по умолчанию debootstrap его не устанавливает. Это проще всего сделать обновлением индексных файлов репозитория:

chroot /systems/lenny apt-get update

После этого уже можно делать chroot /systems/lenny, устанавливать и настраивать пакеты, запускать/останавливать сервисы и т.д. Главная проблема при этом ­— следить за тем, чтобы сервисы в разных chroot’ах не конфликтовали, пытаясь занять порт на одном IP-адресе. Обычно добавляются виртуальные сетевые интерфейсы и им назначаются виртуальные же IP-адреса, которые и указываются в настройках сервисов.

Disclaimer: данная заметка описывает мой персональный опыт и не претендует на полноту. Комментарии и дополнения приветствуются.

У нашего подразделения есть специальная сеть для тестовых серверов и виртуальных машин: 192.168.20.0/24, и очень часто приходится набирать команды типа ssh user@192.168.20.xx, причем в командах различается только последняя цифра. У ограниченного числа серверов нужно указывать другой username. Реже приходится ходить на сервера в других подсетях (в пределах 192.168.0.0/16); также иногда клиенты открывают нам доступ к своим системам, чтобы мы смогли продиагностировать их проблему и решить ее на месте.

Как следует из предыдущего абзаца, очень часто набираются команды вида:

ssh ordinary_user@192.168.20.xx
ssh special_user@192.168.xx.yy
ssh third_user@ww.xx.yy.zz

Возникает естественное желание этот процесс сократить и оптимизировать. Когда серверов было немного, я насоздавал множество хитрых алиасов вроде следующего:

alias 123='ssh user@192.168.20.123'

Однако вскоре я понял, что поддерживать список из полусотни alias’ов — не true unix way, и задумался об альтернативах. Вспомнил об опытах вебмастеров эпохи web 1.0 по использованию 404 ошибки для отображения страницы с нужным содержанием, задумался о том, каким образом bash перехватывает вызов неизвестной команды и подменяет её командой поиска нужного пакета… В результате беглого изучения состава пакета command-not-found было выяснено, что используется функция command_not_found_handle. Она принимает в качестве аргумента введённую пользователем команду, выполняет некие действия и возвращает 127, если ничего нельзя сделать (в таком случае bash выводит стандартное сообщение об ошибке), или любое другое число, если что-то получилось.

Остальное оказалось делом техники. В ~/.bashrc была добавлена функция:

command_not_found_handle () {
    if [[ ! "$1" ]] ; then
        return 127
    fi

    n="$1"

    if echo $n| perl -ne 'exit(/^([1-9]|[1-9]\d|1\d{2}|2[0-4]\d|25[0-5])$/ ? 0:1)' ; then
        ip=192.168.20.$n
    elif echo $n| perl -ne 'exit (/^([1-9]|[1-9]\d|1\d{2}|2[0-4]\d|25[0-5])\.([1-9]|[1-9]\d|1\d{2}|2[0-4]\d|25[0-5])$/ ? 0:1)' ; then
        ip=192.168.$n
    elif echo $n| perl -ne 'exit (/^([1-9]|[1-9]\d|1\d{2}|2[0-4]\d|25[0-5])\.([1-9]|[1-9]\d|1\d{2}|2[0-4]\d|25[0-5])\.([1-9]|[1-9]\d|1\d{2}|2[0-4]\d|25[0-5])\.([1-9]|[1-9]\d|1\d{2}|2[0-4]\d|25[0-5])$/ ? 0:1)' ; then
        ip=$n
    else
        return 127
    fi

    ssh $ip
}

Любое введённое число от 1 до 255 преобразуется в команду ssh 192.168.20.число; два числа — в ssh 192.168.число.число; любой введённый IP-адрес превращается в ssh IP-адрес. Во всех остальных случаях просто выводится сообщение "command not found".

Поскольку используется довольно сложное регулярное выражение, то для его обработки пришлось использовать perl. Ещё был вариант с grep -qP, но эксперименальная опция -P (расширенная поддержка perl-овых регулярных выражений) включена в grep не во всех дистрибутивах (например, в Ubuntu 8.04 её нет, а в 8.10 уже есть).

Чтобы для всех хостов в 20 сети подставлялось общее имя пользователя ordinary_user, а для избранных хостов — специальные имена, в ~/.ssh/config я добавил строчки (общие параметры для всех хостов, предваряемые конструкцией Host *, должны находиться в конце списка):

Host 192.168.20.251
User special_user1

Host 192.168.20.252
User special_user2

Host 192.168.20.254
User special_user3

Host *
User ordinary_user

К сожалению, мне не удалось заставить эту функцию обрабатывать также и параметры командной строки: функции command_not_found_handle передаётся только первый позиционный параметр, остальные недоступны. Поэтому для каждого нестандартного хоста придётся либо писать полный вариант команды со всеми параметрами, либо указывать настройки сервера в ~/.ssh/config, подобно указанным выше. Имеются и прочие недостатки в реализации, обсуждаемые, в частности, на сайте smylers hates software.

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

P.S. бонус для дочитавших до этого места: библиотека регулярных выражений perl, где я нашел регэксп для проверки строки на соответствие IP-адресу.