Ansible для детского сада в скольки то частях. Часть 2. Костылируем жалкое подобие WSUS⁠⁠

Почему я вообще пишу эту статью? Почему нет готового решения «делайте хорошо, плохо не делайте»?
Как жесток и несправедлив этот мир!

Ansible для детского сада в скольки то частях. Часть 1.Про все сразу
Ansible для детского сада в скольки то частях. Часть 2. Костылируем жалкое подобие WSUS - Linux Server Update Services (LSUS)
Ansible для детского сада в скольки то частях. Часть 3. Настраиваем подобие безопасности и все остальное
Ansible для детского сада в скольки то частях. Часть 4. Приделываем костыли

Рассуждения про LSUS - Linux Server Update Services

Я вообще очень удивлен не тому, что в опенсорс инсталляциях творится бардак похуже, чем в  Windows среде. Больше меня удивляет то, что комьюнити с момента появления Linux, а это 17 сентября 1991 года, не сделало какого-то документа «делать так точно хорошо».
У Microsoft был Baseline Security Analyzer
У Microsoft есть Security Compliance Toolkit (SCT)
У Microsoft есть Azure Update Manager operation(AUM).

В опенсорсе был Spacewalk. Последний релиз - 2.10 / March 18, 2020
У RH был Satellite. Это Foreman + katello+ support. Foreman 3.16 and Katello 4.18
Ivanti Patch for Endpoint Manager ? Ага, цитата

Release DateSeptember 18, 2025  The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has published an analysis of the malware deployed in attacks exploiting vulnerabilities affecting Ivanti Endpoint Manager Mobile (EPMM). The Cybersecurity and Infrastructure Security Agency (CISA) obtained two sets of malware from an organization compromised by cyber threat actors exploiting CVE-2025-4427 and CVE-2025-4428 in Ivanti Endpoint Manager Mobile (Ivanti EPMM). Each set contains loaders for malicious listeners that enable cyber threat actors to run arbitrary code on the compromised server. Malicious Listener for Ivanti Endpoint Mobile Management Systems

Rudder ? Ничего про него не знаю.

По беглому обзору, Katello и его функции Lifecycle Ennvironments Content View, выглядят достаточно интересно.

Но единственная «быстро» найденная статья на русском по недоразумению лежит на портале Минцифры, и не содержит описания работы Katello-agent. Который должен был быть, цитата:

Katello-agent is deprecated and will be removed in the next release. Transition your workloads to use the remote execution feature. Red Hat Satellite 6.9

Есть статья на английском. Katello and Foreman in the process of patch management. Картинок достаточно, перевод сейчас в браузере есть.

Проект (Foreman 3.16 and Katello 4.18) выглядит интересным, поскольку содержит интеграцию с Ansible, Configuring hosts by using Ansible, и это позволяет не тащить туда-сюда агенты. Но его установка и интеграция с Ansible и отзывы на него, в целом, неоднозначные.
На официальном сайте есть новость:
betadots GmbH joins the group of companies that provide professional services for Foreman!

Так что вопрос в сложности развертывания, это совсем не WSUS с его далее – далее - готово – пропишите WSUS в GPO.

Рассуждения про структуру LSUS - Linux Server Update Services

Какую задачу я решаю? Наверное, я пытаюсь доказать сам себе, что чего-то упускаю. Не может же быть такого, что нет инструмента для сбора нужной мне статистики в отрыве от системы управления или системы инвентаризации. Которая мне просто и легко сгенерирует таблицу сервер – ядро – версия основного приложения – аптайм и покажет «пока обновляться».
Самый простой вариант – сделать самому. Заодно питон вспомню.

LSUS Фаза 1. Тащим данные
LSUS Фаза 2. ?
LSUS Фаза 3. Profit

Забрать данные из Ansible facts проще всего в текстовый файл любой структуры. Хотите xml \ yaml, хотите что угодно.
Получить эталонные данные проще всего из эталонного образца нужного дистрибутива. У меня везде Debian разных версий, вот на них и буду опираться. Потому что в закрытом или частично (с прокси репозиториями) контуре внешние данные с какого-то сайта \ репозитория не получить.
Хотя и можно на проверяемом сервере делать apt get update и смотреть на счетчик пакетов для обновления.

Но на первой стадии, получения «хоть какого-то то прототипа» гораздо, гораздо проще взять данные из текстового файла \ xml \ любой другой структуры, даже бинарного формата, чем из внешнего источника. Есть же Python pickle, который и положит данные в любой удобный мне формат, и заберет их оттуда. Но, это все после, а пока

Добавление еще одного хоста Debian к Ansible

Вроде изян.
Редактируем 1st_hosts.ini, добавляем туда еще один IP, делаем как в первой части:
ansible-playbook uptime_report.yml --ask-pass --user root --inventory  /home/user/1st_hosts.ini

И, конечно, получаем на воротник, потому что в Debian по умолчанию в /etc/ssh/sshd_config запрещено root ssh – параметром PermitRootLogin. Что правильно.

Но в таком случае придется держать под руками скрипт -
sudo adduser ansible
sudo usermod -aG sudo ansible # If you want the ansible user to have sudo privileges
ssh-copy-id ansible@<debian_12_ip_address>

Или, скорее, положить этот скрипт в гит, и брать его из гит. Если вы разворачиваете VM с ноля, а не из шаблона.

Изян: stackoverflow
curl -s http://server/path/script.sh | bash -s arg1 arg2

LSUS Linux Server Update Services и структура данных

Если нужно что-то строить, то потребуется:
A Single Source of Truth (SSOT). То есть источник данных по требуемой версии. Можно сделать такой «автоматизированный для сразу всего». Это долго: планировать, напланировать, сделать. Это водопад. Можно сделать криво, руками, и так и оставить. Это Agile. Вот так и сделаю.
Похоже, это будет таблица, в виде:
Debain 10-11-12-13 и последних версий ядер к ним, а, значит, и Debian в контейнере или в VM, для того чтобы брать данные из него. Можно сделать и Debian VM, на тонком диске, без ПО. Такая VM займет 2-3 гигабайта.
Придется держать Ubuntu 18-20-22-24 и даже 25. С той же целью. Наверное, если чуть-чуть подумать, то можно «потом» сделать и автоматизацию, когда VM или контейнер запускаются, обновляются, и данные с них забирает система учета. Или в саму систему учета встроить десяток репозиториев и смотреть последние версии хотя бы ядер в репозиториях. С одной стороны это проще, с другой в тестовые виртуальные машины можно положить еще массу всякого софта, то есть соорудить еще одно dev окружение. Но это, скорее, даже не фаза 2 (?), и не фаза 3, а фаза 4 – развиваем то, что есть.
На фазе 1 хватит и простой таблицы.

С целевой структурой данных ситуация сложнее. Для своего предпоследнего пет проекта под похожие задачи я просто развернул базу данных (Postgre), и туда клал разное. Нужно ли на первом шаге такое решение? Не знаю, мне не нужно, мне и бинарной таблицы хватит. Но что туда класть? Очевидно, туда должны попасть: FQDN, IP, дистрибутив, версия дистрибутива, ядро сейчас, последние дата и время доступности, аптайм. Должно ли туда попадать предыдущее состояние объекта, и какие-то еще настройки? Не очень важно, всегда можно расширить схему данных, добавить к объекту еще пару свойств. Как, впрочем, можно и пересоздать и перезалить базу.

Заключение

Для построения LSUS Linux Server Update Services на фазе 1 вам понадобятся:
Git \ Gitlab. Можно в контейнере.
Ansible с настроенным доступом
Python. Почему не Rust и не Go? Потому что компилировать не хочется, а Python работает и так. И объемы небольшие.

Литература

SpaceWalk:Satellite
MS Azure Automatic Guest Patching for Azure Virtual Machines and Scale Sets
MS Azure Update Manager
MS Azure How Update Manager works
MS techcommunity Step-by-Step: How to update an Azure Linux VM using Update management
Ivanti Patch for Endpoint Manager
Katello и Foreman в процессе patch management
Katello and Foreman in the process of patch management
Katello (old)
Foreman 3.16 and Katello 4.18
Foreman Quickstart Guide for Foreman with Katello on RHEL/CentOS
RH Chapter 11. Host Management Without Goferd and Katello Agent
Github Katello
RedOS Настройка GLPI-сервера (для инвентаризации оборудования)

@editors, можно мне все же выдать тег Ansible ?