Серия «Кудахтеры: Ansible»

Изначальное движение «кто-то пишет код, кто-то проверяет код» постепенно закончилось лет 10-15 назад. Критическими точками стали:
18 апреля 2016, с выходом статьи The Linux scheduler: a decade of wasted cores. Полный текст тут
9 декабря 2021, когда в Log4j выявили CVE-2021-44228. Не замеченную ни корпоративным миром, ни Apache Software Foundation с 2013 года. И это еще ничего, сейчас пошла волна вайб кодинга, там просто караул.

Причины "исхода" понятны – повсеместное внедрение тайм трекеров, систем управления, рост сложности кода, etc, не дают возможности массово заниматься «чем-то еще», и вклад в сообщество не монетизируется. Разработчики и команды забрасывают проекты, достаточно вспомнить RatticDB и Ralph, и последние движения везде.
В том числе поэтому страдает не только сам код, но и документация и сценарии к нему. Особенно статьи, написанные исключительно в стиле «как надо» и «как у меня получилось». Сценарии «как у меня не получилось и почему» оседают в глубинах форумов или (запрещенная в РФ социальная сеть) групп. Поэтому, иногда проще сделать самому «как не надо», сломать раз 10, написать «так точно не работает», и написать «как работает у меня и почему».
Мне почему-то проще так, через «сломай сам и напиши что сломал».

Теперь к теме

Важно: Вышло обновление 2.19, и вышло давно! :

Ansible Core 2.19 was officially released on July 21, 2025.

Important: The ansible-core 2.19/Ansible 12 release has made significant templating changes that might require you to update playbooks and roles. The templating changes enable reporting of numerous problematic behaviors that went undetected in previous releases, with wide-ranging positive effects on security, performance, and user experience. You should validate your content to ensure compatibility with these templating changes before upgrading to ansible-core 2.19 or Ansible 12. See the porting guide to understand where you may need to update your playbooks and roles. ROADMAP.

Теоретическая часть

В чем плюс Microsoft Active Directory Domain Services (MS AD DS) ? Он просто работает. Я про это уже писал вот тут (SSSD или приключения Linux в домене Windows (MS AD)) и повторяться не нужно. И он документирован сотнями примеров и миллионами пользователей.

В чем минусы Ansible? Точнее, в чем минусы, если его не настраивать.

Первый минус.
Можно сказать, что очевидный минус в том, что это не pull система.
Хотя в документации и есть раздел Ansible-Pull, цитата:

You can invert the Ansible architecture so that nodes check in to a central location instead of you pushing configuration out to them. Ansible-Pull

То есть, каждый включенный в MS AD сервер «сам» ходит за новыми настройками, и «сам» их обновляет.
Для Ansible можно при первом проходе добавить в CRON
git pull && ansible-playbook
Но это не наш метод. И все равно, нужна система типа Netbox или хотя бы php ipam или хотя бы, если вы совсем немощный, GLPI - Gestionnaire libre de parc informatique.
GLPI, как оказалось, неплохой проект. Для целей именно ИТ в серверному сегменте, и управлению конфигурациями пригоден меньше, чем Netbox, но коллеги из РФ прикручивали к GLPI костыли, и кое как это ездило. Даже какое-то русское сообщество есть. Ralph, говорят, тоже неплох. Был.
Ralph 3 - Asset Management / CMDB
Github allegro /ralph

Цитата

Discontinued

"Effective January 1, 2024, all development and maintenance activities associated with the Ralph project on Allegro's GitHub will be discontinued. This means that no further updates or modifications will be applied to the codebase. However, the current version of the code available in the repository will remain the property of the community, allowing individuals to continue contributing to and developing Ralph as they deem appropriate."

As Allegro, we continue to publish Ralph's source code and will maintain its development under a "Sources only" model, without guarantees. We believe this approach will be beneficial, allowing everyone to use and build upon the software. Our current goal is to modernize the software and ensure its long-term maintainability, and we're investing into it in 2025.

However, we are not operating under a contribution-based model. While we welcome discussions, we do not guarantee responses to issues or support for pull requests. If you require commercial support, please visit http://ralph.discourse.group.

We sincerely appreciate all past contributions that have shaped Ralph into the powerful tool it is today, and encourage the community to continue using it.
README.md

IT Asset Management нужен, но это система управления, а не система настройки. Хотя, может и к ней есть какой-то готовый модуль выгрузок, или его можно написать, именно как модуль.

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

Второй с половиной минус, это ограничения по исполнению для разных типов учетных записей и прочего sudoers .

Вопрос использования Ansible, скорее, относится к координации отделов. Если отдел ИТ един, и при создании очередной виртуальной машины, в облаке или на земле, VM или сервис добавляется в Ansible, или изначально VM и физика добавлены, или есть автоматическое обновление, то проблемы нет.
Но ситуация «забыли добавить» и бесконтрольных Windows машин касается. Если Windows машину в домен не добавить, то волшебным образом она там не появится, и на локальном WSUS отмечаться не будет.

Отсутствие контроля плохо что так, что эдак.

Что дает еще одно направление для инвентаризации, про которое я как-то раньше не думал, но про это напишу статью - Инвентаризация инфраструктуры и сети. Пометки для начинающих. Черновик заведен, дальше как время будет получится.

Развертывание Ansible

Про это я уже писал в статьях:
Переход на Proxmox Часть 3. Ansible и
Переход на Proxmox Часть 6. Возвращаемся к запуску Ansible.

После всех тестов у меня остался:
Кое-как настроенный Ansible
Никак толком не настроенный Linux с SSSD
Git, просто Git. Причем в контейнере

Ansible AWX у меня не заработал. Не очень и хотелось. Можно было поиграть в семафор.

В репозитории  AWX Project написано, цитата:

The last release of this repository was released on Jul 2, 2024. Releases of this project are now paused during a large scale refactoring.

Event-Driven Ansible has been a huge success, but we’ve noticed the same limitations with our existing architecture when trying to combine it with this new system. We need Jobs to be able to report their status in different ways and in different places. We need credentials and projects to be usable in a secure way by this system. Inventory management for Ansible today isn’t just about Servers or Containers, they are about Cloud and Service APIs as well as Embedded and Edge capabilities.
Upcoming Changes to the AWX Project

Размер VM для тестов

Судя по тестовой VM, для связки Nexus + Gitlab + Ansible – 4 Гб на одной VM не достаточно.
30% памяти забирает Java, 20% - Ruby, остальное расходится туда-сюда.
5 Гб минимум для тестов в моей конфигурации. Это не самая большая сложность, когда на нормальном ноутбуке уже 64 Гб памяти (на топовых уже по 96 Гб оперативной памяти).

Проверяем легаси конфиг Ansible
Делаем: ansible --version
Получаем:
ansible --version == ansible [core 2.18.7]; config file = /etc/ansible/ansible.cfg

Делаем: ansible-inventory --list -y
Получаем, цитата:

all:
children:
proxmox:
hosts:
192.168.1111.1111:
ansible_python_interpreter: /usr/bin/python3

servers:
hosts:
server1:
ansible_host: 192.168.1111.2222
ansible_port: 2424
ansible_python_interpreter: /usr/bin/python3

(я в курсе, что IP 192.168.1111.1111 принципиально неправильный, но мне лень как-то иначе переписывать данные реального стенда)

Посмотрим что там:
nano /srv/ansible/hosts.ini
Как оказалось, /srv/ansible/hosts.ini – это какой-то недоделанный файл из какой-то старой инструкции. Не нужен
nano /etc/ansible/hosts

Получаем тот же конфиг, что выше, но в формате конфига:

[servers]
server1 ansible_host=192.168.1111.1111

[servers:vars]
ansible_port=2424

[proxmox]
192.168.1111.2222

[all:vars]
ansible_python_interpreter=/usr/bin/python3

Не знаю, можно ли назвать это вообще конфигом, или минимальным конфигом для работ, но мне хватает. Точно так же, я не уверен, что надо записывать сервера по IP, а не по DNS имени, или не как-то иначе. Точнее, уверен что лучше по имени, но можно и так.

2424 – это у меня SSH переставлен, в /etc/ssh/sshd_config. Потому что на 22 порту этой VM живет gitlab в docker. Можно было наоборот.

В интернетах пишут то, что мне нравится, то есть: используйте FQDN. цитата:

I tend to disregard the commonly accepted best practice of using short names for hosts, and use FQDNs instead. In my opinion, it has many advantages.
It makes it impossible for host names and group names to collide.
Creating an additional variable to carry the host's expected FQDN becomes unnecessary.
It is immediately obvious which (actual) host caused some failure.
Ansible naming conventions

В Ansible docs пишут то же самое: Inventory basics: formats, hosts, and groups

Но можно использовать и алиасы: раздел Inventory aliases в документации.

Что имеем перед началом движения:
не обновленный Ansible с простейшей конфигурацией.
Еще раз напоминаю, что в 2.19 (у меня ansible [core 2.18.7] поведение поменялось.

Обновиться в лабе просто так можно, но нельзя, через:
pip install --upgrade ansible-core
Можно выстрелить себе в ногу, потому что:
ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts.

ansible 11.8.0 requires ansible-core~=2.18.7, but you have ansible-core 2.19.2 which is incompatible.
Successfully installed ansible-core-2.19.2

Придется обновлять целиком:
python3 -m pip install --upgrade --user ansible

Found existing installation: ansible 11.8.0 ; Successfully installed ansible-12.0.0

Такое, конечно, только в лабе и можно делать, без бекапа, без плана отката, вообще без ничего.

Переходим к фактам, просто потому что они мне были нужны
Самая простая команда для сбора фактов -
ansible all -m setup
Читается просто.
Ansible – понятно.
All – группа по умолчанию

Дальше интересно, потому что «-m» описан в Ansible ad hoc commands, как
$ ansible [pattern] -m [module] -a "[module options]"

Там же описана параллельное исполнение команд, цитата:

By default, Ansible uses only five simultaneous processes. If you have more hosts than the value set for the fork count, it can increase the time it takes for Ansible to communicate with the hosts. To reboot the [atlanta] servers with 10 parallel forks

Кто подскажет, почему я тупой, и нашел перечень в выводе man ansible
и не нашел какой-то подробной статьи в интернетах?

-m == module; в том числе -m ansible.builtin.setup , что равно -m setup
-a == command
-u username == user
--ask-become-pass ; -K; --ask-pass – запрос пароля;
--check == Running playbooks in check mode
-i; --inventory == файл с перечнем хостов
-e; ‐‐extra-vars
-l; ‐‐limit

man ansible

usage: ansible [-h] [--version] [-v] [-b] [--become-method BECOME_METHOD] [--become-user BECOME_USER] [-K | --become-password-file BECOME_PASSWORD_FILE]
[-i INVENTORY] [--list-hosts] [-l SUBSET] [--flush-cache] [-P POLL_INTERVAL] [-B SECONDS] [-o] [-t TREE] [--private-key PRIVATE_KEY_FILE]
[-u REMOTE_USER] [-c CONNECTION] [-T TIMEOUT] [--ssh-common-args SSH_COMMON_ARGS] [--sftp-extra-args SFTP_EXTRA_ARGS]
[--scp-extra-args SCP_EXTRA_ARGS] [--ssh-extra-args SSH_EXTRA_ARGS] [-k | --connection-password-file CONNECTION_PASSWORD_FILE] [-C] [-D]
[-e EXTRA_VARS] [--vault-id VAULT_IDS] [-J | --vault-password-file VAULT_PASSWORD_FILES] [-f FORKS] [-M MODULE_PATH]
[--playbook-dir BASEDIR] [--task-timeout TASK_TIMEOUT] [-a MODULE_ARGS] [-m MODULE_NAME]

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

server1 | UNREACHABLE! => {
"changed": false,
"msg": "Failed to connect to the host via ssh

И еще, для моего сценария «ничего не настроено», нужно делать не
ansible all -m setup
а
ansible all -m setup --ask-pass

Или индивидуально для группы серверов:
ansible proxmox -m setup --ask-pass
не говоря про остальное написанное в прошлых текстах:
ansible proxmox -m command -a "uptime" --ask-pass
ansible proxmox -m command -a "pveversion" --ask-pass
ansible proxmox -m command -a "echo ' Hello World '" --ask-pass

И тогда, в ответ на
ansible all -m setup --ask-pass
вы получите не только
(IP) | SUCCESS => {
"ansible_facts": {
"ansible_all_ipv4_addresses": [

Но и огромную xml выгрузку по массе параметров.

Дальше нужно переходить к использованию фильтров
вместо ansible all -m setup --ask-pass
запросить ansible all -m setup -a "filter=ansible_cmdline" --ask-pass

и, кроме использования фильтров, переходить на использование групп, где proxmox – это группа, описанная в /etc/ansible/hosts, и строка будет выглядеть как:

ansible proxmox -m setup --ask-pass -a "filter=ansible_cmdline" --ask-pass

Или придется вспоминать базовейший баш, и выгрузить все полученное в файл,
ansible proxmox -m setup --ask-pass > ansible_out_01.txt

Внутри выгруженного файла посмотреть список того, что можно получать в фильтрах, например:
ansible_all_ipv4_addresses
ansible_default_ipv4
ansible_uptime_seconds
ansible_kernel

И получать именно их:
ansible proxmox -m setup -a "filter=ansible_uptime_seconds" --ask-pass

С выводом:
"ansible_facts": {
"ansible_uptime_seconds": 3416

Переходим к первому плейбуку
nano /home/user/uptime_report.yml

Плейбук целиком утащен из интернета или даже написан AI: цитата:

---

- name: Get and display system uptimes
hosts: all
gather_facts: true # Ensure facts are gathered to get ansible_uptime_seconds
tasks:
- name: Display uptime for each host
ansible.builtin.debug:
msg:
Hostname: {{ inventory_hostname }}
Uptime: {{ (ansible_uptime_seconds / 86400) | int }} days,
{{ ((ansible_uptime_seconds % 86400) / 3600) | int }} hours,
{{ (((ansible_uptime_seconds % 86400) % 3600) / 60) | int }} minutes,
{{ (((ansible_uptime_seconds % 86400) % 3600) % 60) | int }} seconds
when: ansible_uptime_seconds is defined

Выполним что получилось. Без всякой фильтрации хостов и без ничего.

ansible-playbook uptime_report.yml --ask-pass --user root

Получим 1 [ERROR]: Task failed: Failed to connect to the host via ssh:, и  получим 1 ОК.

Ansible playbook для первой группы хостов
На следующем этапе первым делом надо разобраться вот с чем.
Команда:
ansible-playbook -i /path/to/your/hosts_file.ini your_playbook.yml
позволяет работать со списком хостов и групп хостов в hosts_file.ini
по умолчанию это /etc/ansible/hosts

Очень хочется сделать по образцу:
Вместо: ansible proxmox -m setup -a "filter=ansible_uptime_seconds" --ask-pass
сделать:
ansible-playbook proxmox uptime_report.yml --ask-pass --user root

Так работать не будет!

man ansible-playbook

NAME
ansible-playbook - Runs Ansible playbooks, executing the defined tasks on the targeted hosts.
SYNOPSIS
usage: ansible-playbook [-h] [--version] [-v] [--private-key PRIVATE_KEY_FILE]
[-u  REMOTE_USER]  [-c  CONNECTION]  [-T TIMEOUT] [--ssh-common-args SSH_COMMON_ARGS] [--sftp-extra-args SFTP_EXTRA_ARGS] [--scp-extra-args
SCP_EXTRA_ARGS]  [--ssh-extra-args  SSH_EXTRA_ARGS]  [-k  |  --connection-password-file  CONNECTION_PASSWORD_FILE]  [--force-handlers]
[--flush-cache]  [-b]  [--become-method  BECOME_METHOD]  [--become-user BECOME_USER] [-K | --become-password-file BECOME_PASSWORD_FILE] [-t TAGS] [--skip-tags SKIP_TAGS] [-C] [-D] [-i INVENTORY] [--list-hosts] [-l SUBSET] [-e EXTRA_VARS] [--vault-id VAULT_IDS] [--ask-vault-pass‐

word  |  --vault-password-file  VAULT_PASSWORD_FILES]  [-f  FORKS]  [-M MODULE_PATH] [--syntax-check] [--list-tasks] [--list-tags] [--step]

[--start-at-task START_AT_TASK] playbook [playbook ...]

Значит, что остаётся делать?
Остается читать: Ioannis Moustakis Ansible Inventory (есть русский перевод от slurm: Изучаем Ansible Inventory: основы и примеры использования)

Делаем: ansible-playbook uptime_report.yml --ask-pass --user root --inventory proxmox
И ничего подобного, ТАК НЕ РАБОТАЕТ

казалось бы, очевидный лично для меня вариант, когда команда исполняется для какой-то выборки из группы хостов в файле «по умолчанию».
Ничего подобного. Будьте добры делать, как положено:
ansible-playbook uptime_report.yml --ask-pass --user root --inventory  /etc/ansible/hosts  --limit “proxmox”

То есть, конечно, можно и покороче:
ansible-playbook uptime_report.yml --ask-pass --user root --limit “proxmox”

но через limit, если вы хотите «чтобы бралось по умолчанию, но не все».
Лично мне вот это было совершенно не очевидным моментом, что это делается именно так.
Проблема роста – когда ты имеешь развитую инфраструктуру, где все это давно используется, и закопано в наслоениях легаси, можно сделать по образцу и, скорее всего, будет работать. Когда ты пытаешься разобраться, как и почему сделано вот так, это уже совсем другое.

Ну да ладно.
Скопирую конфиг себе и буду пробовать
cp /etc/ansible/hosts /home/user/1st_hosts.ini

Удалю лишнее, оставлю только

[proxmox]
192.168.1111.2222

[all:vars]
ansible_python_interpreter=/usr/bin/python3

И сделаю
ansible-playbook uptime_report.yml --ask-pass --user root --inventory  /home/user/1st_hosts.ini

И все отлично, и все работает.

Заключение.

Система как система, ничем не хуже другой. Первый час сложно, ничего не понятно. Потом попроще.

Литература
Переход от SDLC к SSDLC
GLPi
Ansible AWX
Upcoming Changes to the AWX Project
Classic SysAdmin: Configuring the Linux Sudoers File

Ansible docs Discovering variables: facts and magic variables
Ansible docs Run Your First Command and Playbook
Redhat An introduction to Ansible facts
Specify hosts in ansible-playbook command line
stackoverflow  How to list all currently targeted hosts in an Ansible play

Ioannis Moustakis Ansible Inventory (есть русский перевод от slurm: Изучаем Ansible Inventory: основы и примеры использования)

@editors, мне бы теги Ansible и CMDB, пожалуйста! Не работает их добавление у меня, ничего не могу с этим сделать!

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 ?