RPM Server
Last updated
Was this helpful?
Last updated
Was this helpful?
https://habr.com/ru/companies/ruvds/articles/687048/
Все уже порядком устали от импортозамещения, однако до заветных показателей отечественных ОС на десктопах ещё далековато. Пришло время обсудить схему распространения обновлений/дополнений и прочего софта.
И нет, я не буду смотреть на вас как дядька на КДПВ, да и парой минут тут явно не обойтись. Будем неспешно продвигаться от локальной машины к захвату вселенной корпоративной сети.
Как обычно, возимся с отечественными 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 и т.д.) на обновление, установку или удаление программного обеспечения. Причём всё это производится абсолютно незаметно для пользователя.
