RPM Server
Last updated
Was this helpful?
Last updated
Was this helpful?
Все уже порядком устали от импортозамещения, однако до заветных показателей отечественных ОС на десктопах ещё далековато. Пришло время обсудить схему распространения обновлений/дополнений и прочего софта.
И нет, я не буду смотреть на вас как дядька на КДПВ, да и парой минут тут явно не обойтись. Будем неспешно продвигаться от локальной машины к захвату вселенной корпоративной сети.
Как обычно, возимся с отечественными RedHat-based дистрибутивами — RedOS, Rosa. Сборки на базе Debian — не моё направление, но уверен, что и там всё отлично.
Для тех, кто раньше с линуксами особо дела не имел, немного поясню: rpm (RedHat Package Manager) — это программа для управления установочными пакетами в дистрибутивах производных от RedHat Linux. Установочные пакеты имеют расширение .rpm.
Программа позволяет установить пакет, удалить, показать содержимое/метаданные, показать установленные пакеты и т.д. В самом пакете, помимо исполняемых файлов, библиотек, конфигов, документации и прочих данных, содержится достаточное количество скриптов, самостоятельно подстраивающих конфигурацию пакета под конкретную систему и наоборот. Они также подчищают всё за собой в случае удаления софта. Кроме того, в формате rpm прописано, какие пакеты (зависимости) должны присутствовать в системе (requires) и какие зависимости данный пакет предоставляет (provides). Для того чтобы избавиться от непроизводительных трудозатрат по поиску пакетов, удовлетворяющих зависимости устанавливаемой программы (а также зависимостей-зависимостей), был создан замечательный инструмент yum (yellowdog updater, modified) который делает это за нас и устанавливает всё недостающее вместе с требуемым пакетом. Собственно dnf это уже дальнейшее развитие yum (вернее, форк), при этом сохранивший совместимость с yum на уровне команд.
По идее, она уже обновляется, т.к. в графической оболочке вам будет надоедать значок dnfdragora или yumex. Лично я считаю, что эти «товарищи» недостойны жить на корпоративных десктопах — логика их работы неочевидна, юзерские интерфейсы ужасны, сами они подвисают по любому поводу и без повода, требуют избыточных прав, жрут ресурсы, да и отдавать пользователям такое важное мероприятие не есть хорошо. Безответственные они (пользователи).
Если ваш дистрибутив уже начал перебираться на dnf, то необходимо доустановить пакет dnf-automatic и прописать необходимый таймер в systemd:
При этом необходимо выбрать любой из возможных таймеров:
dnf-automatic-notifyonly
dnf-automatic-download
dnf-automatic-install
Что они делают, попытайтесь отгадать самостоятельно, либо можно подсмотреть в man dnf-automatic
Для yum необходимо поставить пакет yum-cron и организовать его запуск при загрузке
Все настройки в файлах /etc/yum/yum-cron.conf и /etc/yum.conf.
Обновления теперь приходят регулярно и бесшумно.
Если хочется всё контролировать
Вроде всё необходимое написал выше и можно расходиться. Однако, постойте :)
Так как наша корпоративная сетка изолирована от внешнего мира десятью фаерволами, то, если просто накатить с пластинки/флешки операционку, всё вышеописанное банально не сработает. Даже пакеты dnf-automatic или yum-cron без дополнительных телодвижений не установить. Первым делом надо запретить нашей машинке лезть за обновлениями в интернет, а затем приучить к пользованию внутренними ресурсами.
И dnf и yum используют одно место для хранения конфигурации репозиториев — каталог /etc/yum.repos.d. Заходим туда и редактируем по очереди все файлы любимым текстовым редактором: nano, mcedit, vi, ed, sed. Наша задача: в каждой секции строчку enabled=1 заменить на enabled=0. Таким образом мы отключили находящиеся в интернете стандартные репозитории.
Следующий этап — подключить внутренние репозитории. Копируем сюда заранее заготовленный файл с конфигурацией, полученный от системного администратора. Совсем забыл, что сисадмин — это мы, а значит, файлик придётся делать самостоятельно, взяв за основу любой из данного каталога. В нём перебиваем baseurl на адрес нашего сервера и ставим enabled=1 для необходимых секций. Также и на начальном этапе отключим gpgcheck — когда наберёмся опыта/знаний, тогда и решим, что с ним дальше делать.
Как убавить интерактивности
Вроде клиента настроили, однако расслабляться рано — помните baseurl из предыдущего абзаца? Он сейчас указывает «в никуда». Значит, перемещаемся на консоль сервера (или просто выделенной машины) и начинаем поднимать собственный сервер обновлений. Некорректный термин «обновлений», т.к. это, по сути, дистрибутивный сервер, где хранятся всё программное обеспечение, а обновления — это всего лишь свежие версии пакетов.
В дистрибутивном образе (с которого делали установочный носитель) обычно находится самодостаточный и довольно большой набор пакетов, однако на сервере производителя их значительно больше. А если взять, к примеру, образ Centos Netinstall, то там пакетов вообще практически нет — всё вытягивается из сети.
На нашем сервере конфигурацию репозиториев yum не трогаем — ведь нам реально придётся тащить данные из интернета.
Также для нашего сервера необходимо открыть доступ к серверам производителя по протоколу https. Необходимые адреса берём из baseurl которые прописаны в оригинальных конфигах.
Почти всё готово, однако, запуск yum или dnf с параметром update не сделает нашу машину дистрибутивным сервером, мы просто обновим установленные пакеты.
Для «зеркалирования» репозитория имеется утилита reposync из пакета yum-utils (или dnf-utils). Запускаем её и наблюдаем процесс скачивания репозиториев в текущий каталог. Далее настраиваем запуск этой команды на регулярной основе, по крону, либо через таймер systemd, и поднимаем с необходимыми настройками локальный http-сервер, чтобы клиенты могли скачать себе метаданные репозитория и входящие в него пакеты.
Плюсы данного решения — у вас появляется полная копия репозитория 47k+ пакетов.
Минусы данного решения — у вас появляется полная копия репозитория 75+ Гб.
Есть второй вариант.
На нашей машинке исправляем параметр keepcache в файле yum.conf и/или dnf.conf. Соответственно, всё, что мы будем ставить на наш компьютер — будет оседать в кэше /var/cache/yum (/var/cache/dnf) и эти пакеты можно брать и раздавать всем страждущим.
Также можно с помощью опции --downloadonly пропускать стадию установки пакетов, только скачивать.
Более того, в данном случае можно иметь дополнительную машинку вне пределов корпоративной сети и таскать оттуда пакеты на внутренний сервер посредством «флоппинета».
Плюсы — объёмы небольшие. Только то, что реально нужно
Минусы — некий костыль, однако работает.
Третий и последующие варианты придумывайте самостоятельно — wget, curl, rsync и т.д. зазеркалить и синхронизировать папку с http-сервера проблем не представляет.
Пакеты мы вроде скачали, сложили в доступное для клиентов место, однако этого недостаточно — нужно проиндексировать содержимое репозитория и подготовить необходимые метаданные.
Превращение файлопомойки с пакетами в репозиторий производится утилитой createrepo из пакета createrepo. Запускаем, и в параметрах указываем имя каталога с пакетами. После обработки в нём появляется каталог repodata, содержащий метаданные, которые клиент вытаскивает в свой кэш, что позволяет его пакетному менеджеру мгновенно разрешать зависимости и находить необходимые пакеты. Если что-нибудь добавили в уже имеющийся репозиторий, то можно ускорить процесс индексирования опцией --update
Движемся дальше. Схема с одним сервером в корпоративной сети — не сказать чтобы очень хорошая. Даже с учётом низких требований к скорости, а точнее — оперативности обновлений, хочется чтобы была определённая отказоустойчивость и меньшая нагрузка на каналы передачи данных. Как обычно, это решается установкой вторичных и/или каскадных серверов обновлений на удалённых площадках — поближе к потребителям.
Настройка серверов — как описано выше, только они тянут пакеты не напрямую из интернета, а с нашего центрального сервера. А вот настройка клиентов будет специфичная. «Энтерпрайз» любит и приветствует унификацию, посему я предлагаю не делать уникальные файлы описаний репозиториев для каждой площадки. Как тогда указать клиенту, чтобы он обращался к серверу обслуживающим данную локацию?
Вариант A — в baseurl перечислить все имеющиеся серверы. Клиента обламывать либо на выходе из площадки с помощью фаервола, либо через списки доступа на сервере. Вариант так-себе — потери времени при переборе серверов плюс паразитный трафик.
Вариант B — шалости с dns, например, посредством view в ISC BIND или через Lua Records в PowerDNS. Традиционно это считается очень нехорошим решением и не приветствуется. Но если работает, pourquoi pas?
Вариант C — в строке baseurl использовать переменные, как сказано в самом конце man yum.conf. Помимо стандартных $releasever, $basearch, $uuid можно использовать внешние переменные $YUM0-$YUM9 или содержимое файлов в каталоге /etc/yum/vars. Что и как туда сложить придумывайте самостоятельно.
Вариант D — на центральном сервере организовать редирект на вторичные, в зависимости от адреса обратившегося. Реализуется настройками или специально обученными скриптами http-сервера, хостящего наши пакеты. Тут, конечно, надо дополнительно порешать, что делать в плане отказоустойчивости и доступности центрального сервера.
Какой из вариантов реализовать также решайте сами и исходя из своих возможностей и топологии сети.
Что делать с «левыми» пакетами, взятыми не из официального репозитория производителя ОС или с пакетами, которые мы сгенерировали сами?
Правильно — размещать в собственных репозиториях. На веб-сервере делаем необходимые настройки/каталоги и складируем туда пакеты. Далее утилитой createrepo генерируем необходимые метаданные. Для клиентов делаем файл с описанием репозитория. Всё должно работать.
Хочу ещё один нюанс упомянуть. Все эти манипуляции с установкой софта, мгновенным предоставлением информации о доступных пакетах и их зависимостях, низкая нагрузка на каналы — всё это достигается предварительной индексацией и кэшированием данных.
Поэтому если вы не видите свой пакет, только что уложенный в репозиторий, то необходимо запускать dnf/yum с опцией --refresh. Таким образом, вы заставляете его скачать свежайшие метаданные репозитория и получите требуемые пакеты.
Как видите, ничего сложного. Развернув собственную инфраструктуру дистрибутивных серверов для RPM-based дистрибутивов, мы можем уже полноценно управлять нашими линуксовыми рабочими станциями, давая задания нашей SCM (ansible, chef, puppet и т.д.) на обновление, установку или удаление программного обеспечения. Причём всё это производится абсолютно незаметно для пользователя.
