Используем APT Pinning для закрепления пакетов в Debian и Ubuntu

Достаточно часто при работе с Linux-системами возникает потребность в установке пакетов в версии отлично от той, что находится в репозиториях. Чаще всего для этих целей используется ручная установка нужной версии пакета с последующей заморозкой (при необходимости) или сборка пакета из исходников. В тоже время в основанных на Debian дистрибутивах существует штатная система закрепления пакетов APT Pinning, использование которой более предпочтительно, тем более что работать с ней совсем несложно.

Онлайн-курс по устройству компьютерных сетей
На углубленном курсе "Архитектура современных компьютерных сетей" вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.

Прежде всего давайте разберемся, почему использовать ручную установку пакетов нежелательно. Конечно, если речь идет о какой-то отдельной библиотеке для внутренних нужд, скажем для сборки PostgreSQL от 1С, то нет никакого смысла городить огород, можно смело поставить пакет вручную и благополучно про него забыть. Совсем другое дело если вы таким образом установите какую-либо публичную службу, скажем, веб-сервер Apache или интерпретатор PHP.

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

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

Чем же хорош APT Pinning? Эта технология основана выборе источника пакетов на основании заданных вами предпочтений. Т.е. вполне реально становиться подключить репозитории с нужными версиями пакетов, правильно настроить предпочтения и получать все обновления пакетов оттуда используя штатные механизмы. Это сразу снимает целый пласт проблем, связанных с поддержкой, если нужный пакет получает обновления ваша система тоже их получит.

С чего начать? С источников пакетов, чаще всего это репозитории других версий этого дистрибутива, но можно подключить любые иные: репозитории разработчиков ПО, PPА (для Ubuntu) и т.п. Для их подключения нужно добавить адреса источников пакетов в список репозиториев системы.

Список репозиториев хранится в /etc/apt/sources.list, если мы откроем это файл, например, в Debian 8, то увидим следующее:

По умолчанию подключено три репозитория: основной, обновления и обновления безопасности. Репозитории deb-src содержат исходные коды для сборки пакетов. Из типов репозиториев подключен только main - ПО, отвечающие критериям свободного ПО Debian. Также существуют репозитории contrib - ПО которое не соответствует критериям свободного ПО Debian и non-free - несвободное ПО. Поэтому полный набор репозиториев будет выглядеть так:

deb http://ftp.ru.debian.org/debian jessie main contrib non-free
deb http://ftp.ru.debian.org/debian jessie-updates main contrib non-free
deb http://security.debian.org/ jessie/updates main contrib non-free

Как несложно заметить данный набор принадлежит к актуальному на текущий момент дистрибутиву Debain 8 "Jessie", для других выпусков следует заменить jessie на кодовое имя другого дистрибутива.

Кроме кодовых имен Debian позволяет использовать класс релиза: stable, oldstable, testing, unstable. Текущий дистрибутив - это stable, предыдущий - oldstable, разрабатываемый - testing, нестабильный (sid) - unstable. Однако на практике такие обозначения не используются, так как если у вас вместо jessie указано stable, то с выходом следующего стабильного дистрибутива - stretch - произойдет автоматическое обновление на него, что на рабочих серверах может привести к неожиданным последствиям. Хотя если вы энтузиаст, то можете прописать везде testing и быть постоянно на переднем крае прогресса.

В Ubuntu набор репозиториев выглядит немного иначе:

На первый взгляд репозиториев больше и вообще все более запутано. Однако все на самом деле очень просто. Как и в Debian нас интересуют три репозитория основной, обновления и обновления безопасности. Которые в свою очередь делятся на main - свободное ПО и restricted - несвободное ПО, поддерживаемые Canonical, а также universe и multiverse - свободное и несвободное ПО поддерживаемое сообществом.

В итоге список основных репозиториев можно привести к виду:

deb http://ru.archive.ubuntu.com/ubuntu/ trusty main restricted universe multiverse
deb http://ru.archive.ubuntu.com/ubuntu/ trusty-updates  main restricted universe multiverse
deb http://security.ubuntu.com/ubuntu trusty-security main restricted universe multiverse

В Ubuntu версия дистрибутива задается только по кодовому имени, в нашем случае это trusty - Ubuntu 14.04 LTS (Trusty Tahr).

Добавить новые репозитории можно двумя способами: дописать их в основной файл /etc/apt/sources.list, либо создать новый файл с расширением .list в папке /etc/apt/sources.list.d, например, precise.list для репозиториев Ubuntu 12.04 и т.п., все файлы из этой папки с правильным расширением будут автоматически подключены к списку источников.

После того как вы добавили новые репозитории нужно обновить список пакетов:

apt-get update

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

apt-cache policy имя_пакета

Давайте внимательно рассмотрим скриншот ниже, где мы выполнили указанную команду для пакета Nginx:

В вывод команды попали все доступные пакеты, как из репозитория Debian, так и из репозитория Nginx. Но к установке предложен (и установлен) - 1.9.14, как наиболее новый. Еще обратите внимание на цифры перед именами источников. Это приоритет (вес) пакета. Пакеты в репозиториях имеют приоритет 500, установленные - 100. К установке всегда предлагается самый новый пакет с самым высоким приоритетом.

Значения веса приоритета могут быть следующими:

P >= 1000 - пакет будет установлен, даже если это приведет к понижению версии уже установленного пакета
990 <= P < 1000 - пакет будет установлен, если не установлена более новая версия
500 <= P < 990 - пакет будет установлен, если нет пакета принадлежащего к целевому выпуску или не установлена более новая версия
100 <= P < 500 - пакет будет установлен, если нет кандидатов из других источников или установленного пакета более новой версии
0 < P < 100 - пакет будет установлен, если нет других кандидатов и установленных пакетов любой версии
P < 0 - пакет не будет установлен ни при каких условиях
P = 0 - неопределенное состояние, не используется

Использовать вес выше 1000 следует с осторожностью, особенно если предпочтения включают отбор по маске, в этом случае вы можете без запроса провести понижение сразу целого набора пакетов (по зависимостям), что может привести к неожиданным результатам.

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

Отдельно остановимся на различиях между весом в диапазоне 500 - 990 и 990 - 1000.

Так при весе от 500 и выше новый пакет будет всегда установлен и заменит уже существующий пакет если действие будет явно задано пользователем. Таким образом команды:

apt-get install имя_пакета

или

apt-get upgrade

обновят пакет или набор пакетов до самых последних версий при весе от 500 и выше. Например, у нас на Debian 7 установлен apache 2.2, добавим репозитории от Debain 8 и посмотрим кандидата на установку:

При этом мы можем установить пакету apache2 любой вес от 500 до 1000, результат будет тот же самый. Так в чем же тогда разница между 500-990 и 990-1000?

Разница состоит в понятии целевого выпуска, который по умолчанию не задан, поэтому поведение системы с весами от 500 до 1000 будет одинаковым. Чтобы задать целевой выпуск создадим в папке /etc/apt/apt.conf.d пустой файл без расширения, скажем, default и внесем в него следующую строку:

APT::Default-Release "wheezy";

Это установит в качестве целевого установленный выпуск Debian 7. Проверим что будет теперь:

Даже несмотря на то, что мы присвоили apache2 из jessie вес 900, кандидатом на установку остается пакет из wheezy, так как принадлежит целевому выпуску. Чтобы изменить ситуацию, нужно присвоить пакету вес от 990 до 1000:

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

Разобравшись с тем, как действуют приоритеты, самое время научиться указывать их самостоятельно. Для указания приоритета следует создать файл без расширения в папке /etc/apt/preferences.d и поместить в него ряд директив. Мы рекомендуем называть файлы по имени закрепляемых пакетов и не писать все настройки в один файл. Это позволит более гибко управлять процессом закрепления пакетов.

В самом файле следует разместить один или несколько наборов следующих директив:

Package: имя_пакета
Pin: опции_прикрепления
Pin-Priority: приоритет

Имя пакета может быть задано как целиком, так и по маске, например, apache2*. Допускается также указание нескольких имен через пробел.

В качестве опций прикрепления могут выступать источник пакетов, версия и их происхождение. Например, следующий набор директив закрепит Perl на уровне линейки 5.10, а заданный вес пакета 1001 позволит понизить уже установленную версию (при необходимости).

Package: perl
Pin: version 5.10*
Pin-Priority: 1001

А эта конструкция указывает получать пакеты sqiud3 из репозитория example.com, например, если вам нужно использовать специальную сборку пакета и не допускать его замены штатным, даже если он будет новее.

Package: squid3
 Pin: origin "example.com"
 Pin-Priority: 999

И наконец привязка к определенному выпуску, например все пакеты по маске apache2* брать из репозиториев выпуска wheezy:

Package: apache2*
 Pin: release n=wheezy
 Pin-Priority: 900

Для Debian допустимо также использовать конструкцию:

Pin: release a=testing

Для Ubuntu значение обоих ключей n и a совпадает и должно содержать кодовое имя релиза.

Чтобы не быть голословными рассмотрим несколько практических сценариев.

Понижение версии пакетов

Наиболее часто требуется понизить версию Apache с 2.4 до 2.2, например, для нужд 1С предприятия. Поэтому прежде всего в систему следует добавить репозитории от предыдущего выпуска, который содержит нужную версию Apache, это wheezy для Debian или precise для Ubuntu. Дальше можно пойти двумя путями, например, задать вес 1001 и произвести замену нужных пакетов:

Package: apache2*
 Pin: release n=wheezy
 Pin-Priority: 1001

Это потенциально опасная операция, поэтому перед тем как производить установку следует выполнить ее тестирование:

apt-get install apache2 -s

Если вывод не помещается в экран, то его следует перенаправить утилите less:

apt-get install apache2 -s | less

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

Если все в порядке, то можно проводить установку. Однако мы не рекомендовали бы использовать вес больше 1000, так как остается опасность случайного понижения пакетов, скажем при обновлениях. Более безопасно установить вес от 990 до 1000 и предварительно удалить уже установленные пакеты.

Для того, чтобы удалить пакеты сначала нужно получить их список, для этого служит команда dpkg -l с последующим отбором по имени пакета.

dpkg -l | grep apache2

Установленные пакеты удаляем командой:

dpkg -r имя_пакета

Также можно удалить и все настройки пакетов, для этого снова выполните

dpkg -l | grep apache2

и затем

dpkg -P имя_пакета

Однако учтите, что данная операция уничтожит все настройки и данные относящиеся к пакету, в случае с MySQL или PostgreSQL это приведет к полной потере данных, поэтому предварительно сделайте копии нужного содержимого и настроек.

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

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

Повышение версии пакетов

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

Вообще правильным способом повышения пакета является его сборка в окружении текущего дистрибутива из исходных кодов репозитория deb-src от нового выпуска. Однако этот метод выходит за рамки данной статьи.

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

Package: *
 Pin: release n=stretch
 Pin-Priority: 300

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

Хорошо, дистрибутивы добавили, приоритеты выставили, кандидатов проверили, вроде бы все нормально. Попробуем установить пакет в тестовом режиме:

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

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

Ну вот, вроде бы все добавлено, как видим в список предпочтений попали самые неожиданные пакеты (а мы хотели только обновить Apache):

Тестируем установку и видим весьма неожиданный результат:

Да, если оставить все как есть, то новый Apache мы поставим, но при этом удалим часть системных утилит. Это произойдет по причине поломанных зависимостей. Какой выход? Обновить их до версий из нового выпуска, т.е. снова начинаем решать квест с зависимостями. В этом, несомненно увлекательном процессе, самое главное - вовремя остановиться, оценить степень изменения дистрибутива и подумать о полноценном переходе на новую версию, вместо того, чтобы сооружать некое чудовище Франкенштейна.

Выводы

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

Записки IT специалиста