Patchman (Linux Patch Status Monitoring System) представляет собой систему отчётности о состоянии актуальности пакетной базы компьютеров на базе ОС Linux. Patchman имеет клиент-серверную архитектуру. Серверная часть представляет собой фронтэнд в виде веб-сервера на базе фреймворка Django с бакендом в виде базы данных SQLite/MySQL/PostgreSQL. Клиентская часть является по сути легковесным скриптом, работающим с такими пакетными менеджерами как YUM, APT и Zypper.
Клиенты Patchman при каждом запуске отправляют список установленных пакетов и включенных репозиториев на сервер Patchman. Сервер Patchman по полученным от клиентам репозиториям формирует собственную базу метаданных о доступных в этих репозиториях пакетах. После этого сервер сопоставляет версии пакетов в метаданных репозиториев и на клиентах и в наглядном виде показывает то, какие хосты требуют обновлений, и являются ли эти обновления обычными или обновлениями безопасности. Кроме этого веб-интерфейс Patchman предоставляет дополнительную информацию о потенциальных проблемах, таких как пакеты, не имеющие привязки к репозиториям или включенные на клиентах репозитории, имеющие проблемы с онлайн-доступностью.
При работе с веб-интерфейсом информация о хостах, пакетах, репозиториях и операционных системах может быть отфильтрована. Это позволяет, например, быстро получить информацию о том, на каких хостах установлена определенная версия пакета и с каким репозиторием она сопоставима.
С точки зрения взаимодействия клиента Patchman с пакетным менеджером работа выполняется в режиме "только чтение", то есть клиент не занимается обновлением кеша пакетного менеджера и не устанавливает пакеты обновлений на хосты. Плагины yum, apt и zypper отправляют отчеты на сервер Patchman каждый раз, когда выполняются стандартные процедуры установки/обновления/удаления пакетов на хосте.
Установка сервера Patchman
Базовые инструкции по установке Patchman на разные ОС Linux можно найти здесь: INSTALL.md
Мы рассмотрим пример установки и настройки сервера Patchman на базе ОС Debian GNU/Linux 12 (Bookworm), которая будет запущена на выделенной виртуальной машине.
Добавляем в менеджер пакетов APT информацию о репозитории Patchman:
# wget https://repo.openbytes.ie/openbytes.gpg -P /usr/share/keyrings/
# echo "deb [signed-by=/usr/share/keyrings/openbytes.gpg] https://repo.openbytes.ie/patchman/debian bookworm main" > /etc/apt/sources.list.d/patchman.list
Обновляем кеш менеджера пакетов и выполняем установку пакетов серверной и клиентской части Patchman:
# apt-get update
# apt-get install python3-patchman patchman-client
В ходе установки в качестве зависимостей в систему будет установлен ряд дополнительных пакетов, в том числе веб-сервер Apache, Memcached и другие.
После установки основная конфигурация сервера Patchman находится в файле:
/etc/patchman/local_settings.py
Конфигурация каталогов Patchman сайта для веб-сервера Apache находится в файле:
/etc/apache2/conf-available/patchman.conf
Конфигурация клиентской части Patchman находится в файле:
/etc/patchman/patchman-client.conf
По умолчанию в качестве бакенда для хранения данных Patchman использует хранилище формата SQLite3 в файле /var/lib/patchman/db/patchman.db. Такую конфигурацию не рекомендуется использовать для продуктивных сред, тем более для сред с большим количеством клиентов. Предлагается заменить этот бакенд на MySQL или PostgreSQL. В нашем примере будет использоваться вариант с PostgreSQL.
Из стандартных репозиториев Debian 12 установим пакеты, которые потребуются для работы с PostgreSQL:
# apt-get install postgresql python3-psycopg2
Создадим пользовательскую сессию Linux-пользователя postgres и запустим в этой сессии оболочку psql:
# su - postgres
postgres@SERVER:~$ psql
psql (15.8 (Debian 15.8-0+deb12u1))
Type "help" for help.
postgres=#
Создадим новую пустую БД, например, с именем "patchman":
postgres=# CREATE DATABASE patchman;
CREATE DATABASE
Создадим пользователя СУБД, например, с именем "patchmanusr" и настроим некоторые опции его роли:
postgres=# CREATE USER patchmanusr WITH PASSWORD 'MyPwD!lO';
CREATE ROLE
postgres=# ALTER ROLE patchmanusr SET client_encoding TO 'utf8';
ALTER ROLE
postgres=# ALTER ROLE patchmanusr SET default_transaction_isolation TO 'read committed';
ALTER ROLE
postgres=# ALTER ROLE patchmanusr SET timezone TO 'UTC';
ALTER ROLE
Выдадим пользователю доступ на подключение к СУБД и полный доступ на уровне БД:
postgres=# GRANT ALL ON SCHEMA public TO patchmanusr;
GRANT
postgres=# GRANT ALL PRIVILEGES ON DATABASE patchman to patchmanusr;
GRANT
В отличие от того, что сейчас описано в документе INSTALL.md, нам потребуется дополнительно выполнить запрос на присвоение роли владельца базы данных "patchman" для пользователя "patchmanusr". Это особенность PostgreSQL версии 15 и выше, которую следует учесть, чтобы избежать последующей проблемы с нехваткой прав доступа.
postgres=# ALTER DATABASE patchman OWNER TO patchmanusr;
ALTER DATABASE
Выйдем из оболочки psql и завершим сессию пользователя postgres:
postgres=# \q
postgres@SERVER:~$ exit
logout
Переходим в конфигурационный файл сервера Patchman и корректируем параметр DATABASES, указав в атрибуте default новые данные для подключения к БД.
# nano /etc/patchman/local_settings.py
То есть, заменяем фрагмент конфигурации по умолчанию:
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.sqlite3',
'NAME': '/var/lib/patchman/db/patchman.db',
}
}
на следующий вид:
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.postgresql_psycopg2',
'NAME': 'patchman',
'USER': 'patchmanusr',
'PASSWORD': 'MyPwD!lO',
'HOST': '127.0.0.1',
'PORT': '',
'CHARSET' : 'utf8'
}
}
После настройки бэкэнда базы данных необходимо синхронизировать базу данных Django (инициализация и миграция базы данных):
# patchman-manage makemigrations
# patchman-manage migrate --run-syncdb --fake-initial
Обе команды должны отработать без явных ошибок.
Запустим утилиту создания административного пользователя, где укажем имя пользователя и пароль для доступа к веб-консоли сервера Patchman:
# patchman-manage createsuperuser
Username (leave blank to use 'root'): pmadmin
Email address: Pathcman-Monitoring@holding.com
Password: **********
Password (again): **********
Superuser created successfully.
Далее, согласно документации, нам потребуется выполнить команду обновления статического содержимого веб-фреймворка:
# patchman-manage collectstatic
You have requested to collect static files at the destination
location as specified in your settings:
/var/lib/patchman/static
This will overwrite existing files!
Are you sure you want to do this?
Type 'yes' to continue, or 'no' to cancel: yes
0 static files copied to '/var/lib/patchman/static', 167 unmodified.
В конфигурационном файле веб-сайта Patchman нам потребуется прописать IP-подсети, из которых разрешено отправлять на сервер клиентские отчёты (по умолчанию разрешён доступ только с локальных адресов 127.0.0.0 и ::1).
# nano /etc/apache2/conf-available/patchman.conf
В секцию описания каталога /patchman/reports/upload добавим необходимые подсети:
<Location /patchman/reports/upload>
# Add the IP addresses of your client networks/hosts here
# to allow uploading of reports
Require ip 192.168.1.0/255.255.255.0
Require ip 127.0.0.0/255.0.0.0
Require ip ::1/128
</Location>
Не забываем также прописать разрешающее правила доступа к порту веб-сервера Patchman для соответствующей клиентской подсети в конфигурации nftables.
Перезапустим службу веб-сервера:
# systemctl restart apache2.service
Теперь мы можем попробовать перейти на веб-интерфейс Patchman по ссылке http://server/patchman и в веб-форме аутентификации ввести логин/пароль ранее созданного административного пользователя для Patchman.
После входа главная страница "Dashboard" будет пустой, так как у сервера Patchman нет информации ещё ни об одном клиенте. Поэтому давайте попробуем получить в веб-консоли данные хотя бы по самому серверу Patchman. Для этого нам потребуется настроить конфигурационный файл клиента Patchman:
# nano /etc/patchman/patchman-client.conf
В этом файле, как минимум, нам потребуется корректно указать URL сервера Patchman, на который клиент будет отсылать отчёты. В нашем примере к опциям curl, указанным по умолчанию, добавлена опция игнорирования системных/пользовательских настроек прокси, чтобы клиент не пытался использовать прокси-сервер и напрямую подключался к серверу Patchman:
# Patchman server
server=http://server.holding.com/patchman
# Options to curl
curl_options="--noproxy '*' --insecure --connect-timeout 60 --max-time 300"
# Space delimited tags to send
tags="Server"
# Does the client output a report of the upload (e.g. for cronjob output)
report=false
Выполним команду отправки клиентского отчёта на сервер с подробным выводом информации:
# patchman-client -v
Клиентские данные отправлены на сервер, но в веб-интерфейсе Patchman они не появятся до тех пор, пока не будет выполнена обработка этих данных самим сервером. Чтобы немедленно инициировать такую обработку, выполним на сервере команду:
# patchman -a
В ходе выполнения этой команды в базу данных сервера попадёт информация о всех установленных на клиенте пакетах и всех подключённых репозиториях. Кроме этого для обнаруженных репозиториев будет предпринята попытка загрузки из этих репозиториев актуальной информации о последних версиях пакетов, размещённых в этих репозиториях.
Настройка клиентов Patchman
В этом разделе мы отдельно рассмотрим пример настройки только клиентской части. В качестве клиентской системы используем также компьютер на базе ОС Debian GNU/Linux 12 (Bookworm),
Также, как и в случае с сервером, на клиентской системе для начала добавляем в менеджер пакетов APT информацию о репозитории Patchman:
# wget https://repo.openbytes.ie/openbytes.gpg -P /usr/share/keyrings/
# echo "deb [signed-by=/usr/share/keyrings/openbytes.gpg] https://repo.openbytes.ie/patchman/debian bookworm main" > /etc/apt/sources.list.d/patchman.list
Обновляем кеш менеджера пакетов и выполняем установку только клиентской части Patchman:
# apt-get update && apt-get install patchman-client
Как было отмечено ранее, клиентская часть Patchman не имеет зависимостей и не требует установки каких-либо дополнительных пакетов.
Настраиваем основной конфигурационный файл клиента по аналогии с тем, как было описано выше.
# nano /etc/patchman/patchman-client.conf
Мы можем вручную запустить клиента с подробным выводом, чтобы убедиться в том, что между клиентом и сервером на сетевом уровне нет проблем взаимодействия (не мешают брандмауэры, нет ненужных заворотов на прокси и т.п.):
# patchman-client -v
Стоит отметить то, что параметры, указываемые в конфигурационном файле patchman-client.conf являются по сути параметрами по умолчанию, которые клиент использует при запуске без явного указания опций. И если есть желание иметь в инфраструктуре несколько серверов Patchman, то можно заставить клиента при запуске отсылать отчёт на разные серверы, передав исполняемому файлу patchman-client адрес сервера:
# patchman-client -s http://server2.holding.com/patchman
Ещё одной особенностью клиентской части Patchman является то, что в ходе установки клиента в пакетный менеджер подключается механизм, который инициирует команду отправки отчёта на сервер Patchman после выполнения команд установки новых пакетов типа apt-get install или команд удаления пакетов типа apt-get remove. Это можно заметить, например, и при выполнении команды apt-get upgrade, где в самом конце вывода появляется сообщение, говорящее об отправке отчёта на сервер Patchman:
Найти эту дополнительную конфигурацию пакетного менеджера apt, включающего этот механизм, можно в файле /etc/apt/apt.conf.d/05patchman.
Автоматизация выполнения задач Patchman
Процесс автоматизации выполнения сервером обработки клиентских данных может быть реализован разными путями. В небольших инфраструктурах можно обойтись периодическим запуском вышеуказанной команды через планировщик Сron. В крупных инфраструктурах, где помимо большого количества клиентов Patchman имеется множество администраторов, возможно, имеет смысл дополнительной настройки таких опциональных компонент, как Memcached и Celery, о чём упомянуто в инструкциях INSTALL.md. В рамках данной статьи мы не будем рассматривать эти компоненты, а пойдём по несколько иному сценарию и решим вопрос автоматизации общения клиентов и сервера Patchman посредствам создания специальных юнитов Systemd – службы, описывающей команду запуска клиента/сервера, и таймера, описывающего время периодического запуска службы. Настраиваемая конфигурация будет предполагать то, что все клиенты Patchman раз в сутки с утра будут отсылать на сервер свои отчёты, после чего сервер Patchman будет обрабатывать эти клиентские данные, подтягивать свежие метаданные о последних обновлениях в онлайн-репозиториях и формировать в своей БД сведения о необходимых для клиентов обновлениях пакетной базы.
Настройка на стороне клиента Patchman
Данная настройка выполняется на стороне каждого клиента Patchman.
Создадим юнит systemd, описывающий службу, например, с именем patchman-client-report.service, в конфигурации которой указана команда запуска клиентской утилиты patchman-client:
# nano /etc/systemd/system/patchman-client-report.service
Наполним файл содержимым:
[Unit]
Description=Sending patchman-client report to patchman server
[Service]
Type=oneshot
ExecStart=/usr/sbin/patchman-client
[Install]
WantedBy=multi-user.target
Перезагрузим конфигурацию systemd, запустим службу и проверим её статус:
# systemctl daemon-reload
# systemctl start patchman-client-report.service
# systemctl status patchman-client-report.service
Служба должна запуститься, выполнится и сразу завершить свою работу, так как она настроена по типу "oneshot". То есть эта служба не будет находиться в запущенном состоянии всё время, а будет запускаться лишь тогда, когда будет срабатывать специальный таймер, который мы настроим далее.
Здесь, как минимум, мы должны убедиться в том, что запуск службы происходит без ошибок. В случае проблем с запуском службы, можем исследовать её лог:
# journalctl -u patchman-client-report.service
Создадим ещё один юнит systemd, описывающий таймер, с тем же именем, что и ранее созданная служба, но с расширением .timer, то есть в нашем примере это будет таймер с именем patchman-client-report.timer.
# nano /etc/systemd/system/patchman-client-report.timer
В конфигурации этого юнита укажем периодичность запуска созданной выше службы patchman-client-report.service:
[Unit]
Description=Timer for periodic launch of patchman-client-report.service
[Timer]
OnCalendar=*-*-* 06:30
RandomizedDelaySec=30m
Persistent=true
[Install]
WantedBy=timers.target
В данном примере мы настраиваем ежедневный запуск в 06:30 утра с рандомизацией запуска в течение следующих 30 минут. То есть, фактически запуск будет произведён в случайное время в интервале от 06:30 до 07:00. При большом количестве клиентов такой подход будет полезен для исключения ситуации с пиковой нагрузкой на сервер в определённое время.
При планировании и определении показателя в параметре OnCalendar, можем воспользоваться диагностической командой следующего вида:
# systemd-analyze calendar "*-*-* 06:30"
Вывод этой команды покажет нам расчётные дату и время следующего выполнения по заданному нами шаблону и даст понять правильно ли мы указали формат даты и времени в этом шаблоне.
Для того, чтобы активизировать созданный таймер, перезагрузим конфигурацию systemd, запустим таймер и включим автозапуск таймера при запуске системы:
# systemctl daemon-reload
# systemctl start patchman-client-report.timer
# systemctl enable patchman-client-report.timer
# systemctl status patchman-client-report.timer
Созданный нами юнит таймера при запуске не должен выдавать никаких ошибок и этот юнит всегда должен находиться в запущенном состоянии. В случае возникновения проблем при запуске таймера, исследуем его лог командой:
# journalctl -u patchman-client-report.timer
На этом настройку автоматизации регулярной отсылки клиентских отчётов Patchman можем считать законченной.
Настройка на стороне сервера Patchman
Данная настройка выполняется один раз только на стороне сервера Patchman.
Создадим юнит systemd, описывающий службу, например, с именем patchman-server-reports.service, в конфигурации которой указана команда запуска серверного процесса patchman:
# nano /etc/systemd/system/patchman-server-reports.service
Наполним файл содержимым:
[Unit]
Description=Processing reports for all clients on patchman server
[Service]
Type=oneshot
Environment="https_proxy=http://squid.holding.com:3128/"
Environment="http_proxy=http://squid.holding.com:3128/"
Environment="ftp_proxy=http://squid.holding.com:3128/"
Environment="no_proxy=sub.local.holding.com,my.holding.com"
ExecStart=/usr/bin/patchman --all --quiet
[Install]
WantedBy=multi-user.target
В показанном примере в секции Service используются параметры Environment для заполнения переменных окружения https_proxy/http_proxy/ftp_proxy при запуске процесса, который указан в параметре ExecStart. В нашем случае это необходимо для того, чтобы процесс patchman мог выйти за периметр локальной сети для скачивания метаданных из разных репозиториев в интернете. А параметр no_proxy используется для описания локальных доменов, которые должны использовать не проход через прокси, а прямое подключение для репозиториев внутри локальной сети.
Перезагрузим конфигурацию systemd, запустим службу и проверим её статус:
# systemctl daemon-reload
# systemctl start patchman-server-reports.service
Служба должна запуститься, выполнится и сразу завершить свою работу, так как она настроена по типу "oneshot". То есть эта служба не будет находиться в запущенном состоянии всё время, а будет запускаться лишь тогда, когда будет срабатывать специальный таймер, который мы настроим далее.
Здесь, как минимум, мы должны убедиться в том, что запуск службы происходит без ошибок. В случае проблем с запуском службы, смотрим её лог:
# journalctl -u patchman-server-reports.service
Создадим ещё один юнит systemd, описывающий таймер, с именем patchman-server-reports.timer. В конфигурации этого юнита укажем периодичность запуска для созданной ранее службы patchman-server-reports.service:
# nano /etc/systemd/system/patchman-server-reports.timer
Наполним файл содержимым:
[Unit]
Description=Timer for periodic launch of patchman-server-reports.service
[Timer]
OnCalendar=*-*-* 07:15
Persistent=true
[Install]
WantedBy=timers.target
В данном примере мы настраиваем ежедневный запуск в 07:15 утра, то есть после того, как все наши клиенты в период с 06:30 до 07:00 уже отослали свои отчёты на сервер Patchman.
Для того, чтобы активизировать созданный таймер, перезагрузим конфигурацию systemd, запустим таймер и включим автозапуск таймера при включении системы:
# systemctl daemon-reload
# systemctl start patchman-server-reports.timer
# systemctl enable patchman-server-reports.timer
Созданный нами юнит таймера при запуске не должен выдавать никаких ошибок и этот юнит всегда должен находиться в запущенном состоянии. В случае возникновения проблем при запуске таймера, исследуем его лог командой:
# journalctl -u patchman-server-reports.timer
На этом настройку автоматизации регулярной обработки клиентских отчётов и обновления метаданных из онлайн-репозиториев на сервере Patchman можем считать законченной.
Настройка SSL для защиты соединений к серверу Patchman
Данный блок настройки является опциональным, но он полезен с точки зрения защиты сетевых соединений к веб-серверу на стороне сервера Patchman. Это может быть особенно важным, если в дальнейшем мы планируем настраивать интеграцию веб-интерфейса Patchman с доменной аутентификацией.
Активируем модули веб-сервера Apache, которые потребуются нам для поддержки SSL и перезапустим службу веб-сервера:
# a2enmod ssl socache_shmcb rewrite headers
# systemctl restart apache2
Убедимся в том, что нужные модули отображаются в списке активированных модулей:
# apache2ctl -M | grep -e "ssl" -e "socache_shmcb" -e "rewrite" -e "headers"
headers_module (shared)
rewrite_module (shared)
socache_shmcb_module (shared)
ssl_module (shared)
Теперь нам потребуется создать файлы сертификата и соответствующего ему закрытого ключа. Пример генерации этих файлов для веб-сервера Apache рассматривался ранее в заметке
"Установка сертификата от Windows Server CA на веб-сервер Apache".
Предполагая, что у нас уже есть на руках готовые файлы ключа и сертификата в формате PEM, размещаем их на нашем сервере Patchman в каталогах /etc/ssl/private/ и /etc/ssl/certs/ соответственно. Ограничиваем доступ к файлу ключа, чтобы его мог читать пользователь, от имени которого работает процесс веб-сервера Apache:
# mv ~/patchman.key /etc/ssl/private/
# mv ~/patchman.pem /etc/ssl/certs/
# chmod 640 /etc/ssl/private/patchman.key
# chown root:www-data /etc/ssl/private/patchman.key
Создадим новую конфигурацию сайта Patchman, которая подразумевает обязательное использование SSL:
# nano /etc/apache2/sites-available/patchman-ssl.conf
Наполним файл содержимым:
<VirtualHost *:80>
RewriteEngine On
RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [R=301,L]
</VirtualHost>
<VirtualHost *:443>
SSLEngine on
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.2
SSLHonorCipherOrder off
SSLSessionTickets off
SSLCertificateFile "/etc/ssl/certs/patchman.pem"
SSLCertificateKeyFile "/etc/ssl/private/patchman.key"
DocumentRoot "/var/www/html"
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
Файл не содержит информации о конфигурации виртуального каталога "/patchman", так как он эта конфигурация настроена нами ранее в подключаемом модуле /etc/apache2/conf-available/patchman.conf.
Выключим настроенную по умолчанию конфигурацию сайта Apache (/etc/apache2/sites-available/000-default.conf):
# a2dissite 000-default
Site 000-default disabled.
To activate the new configuration, you need to run:
systemctl reload apache2
Включим сайт созданной нами конфигурации (/etc/apache2/sites-available/patchman-ssl.conf):
# a2ensite patchman-ssl
Enabling site patchman-ssl.
To activate the new configuration, you need to run:
systemctl reload apache2
Перезагрузим службу веб-сервера Apache:
# systemctl restart apache2
На этом этапе мы должны получить работающий сайт, защищённый SSL.
Разумеется, теперь при настройке клиентов в конфигурационном файле /etc/patchman/patchman-client.conf URL сервера Patchman следует указывать в формате https://patchman.holding.com/patchman.
Ознакомление с базовыми функциями веб-интерфейса Patchman
На главной странице "Dashboard" получаем сводный статус по вопросам, которые требуют внимания. Здесь мы увидим перечень систем, требующих установки обновлений и отдельно выделен блок систем, где к установке предлагаются обновления безопасности. Здесь же увидим проблемы с доступностью зеркал репозиториев, а также пакеты, версии которых не обнаружены ни в одном из доступных репозиториев и некоторую другую информацию.
На вкладке "Hosts" отображается полный перечень систем, подключенных к Patchman и при переходе в свойства любого хоста можно получить базовую информацию об этом хосте: версия ОС и архитектура, версия ядра, ссылки на 3 последних отчёта, отправленных клиентским приложением patchman-client. С помощью тегов, назначаемых хосту, как через параметр "tags" ранее рассмотренного конфигурационного файла patchman-client.conf, так и непосредственно здесь, в свойствах хоста, через веб-интерфейс, в последствии можно более гибко строить отборы при работе с общим списком хостов.
А если в свойствах хоста перейти на вкладку "Updates Available", то здесь мы увидим перечень пакетов, для которых в репозиториях имеются более новые версии. Красным будут подсвечены версии пакетов, включающие исправления проблем безопасности.
На вкладке "Repos" можно увидеть все публичные и локальные репозитории, которые подключены на хосте. 
Теперь в главном меню заглянем во вкладку "Repositories". В этой вкладке после каждой обработки клиентских отчётов будет обновляться информация о всех репозиториях, найденных на всех клиентах. То есть новые записи о репозиториях появляются здесь автоматически, но при необходимости они могут быть изменены (можно менять отображаемое имя репозитория, менять перечень его зеркал т.п.) или удалены.
Перейдя в главном меню на вкладку "Operating Systems" мы получим возможность управления группировками операционных систем. Группы ОС могут назначаться, например, в свойствах репозиториев или хостов. Использование группировок ОС необязательно, но такие группировки могут послужить в качестве вспомогательного рычага в механизме фильтрации при работе со списками хостов или репозиториев.
На представленных выше скриншотах не видно блоков фильтров для быстрого отбора, так как я пытаюсь сконцентрировать внимание на ключевом контенте и не показываю весь экран. Но на самом деле в разных местах веб-интерфейса в правой области экрана имеется ряд таких фильтров, среди которых и присутствует фильтр по группе ОС:
Перейдя в главном меню на вкладку "Packages", мы получим доступ к механизму поиска любого пакета, который поможет быстро определить то, какие версии пакета в каких репозиториях присутствуют и на каких хостах установлены.
Подобная аналитика позволяет оперативно оценить масштаб проблемы и фронт необходимой работы, когда, например, появляется информация об уязвимостях определённой версии какого-то пакета.
На вкладке главного меню "Reports" можно увидеть отсортированные по дате устаревания отчёты, поступившие ото всех клиентов Patchman. По картинке в столбце "Processed" мы можем понять какие из отчётов обработаны сервером Patchman, а какие ещё не обработаны.
Например, если на каком-то из клиентов только что была проведена установка обновлений, то ранее описанный плагин пакетного менеджера сразу отчитается о новом перечне установленных пакетов. И в списке отчётов появится новая запись со статусом необработанного отчёта. Открыв свойства этой записи по гиперссылке в колонке "ID", мы можем инициировать срочную обработку отчёта сервером, нажав на кнопку "Process this Report".
Процесс фоновой обработки отчёта занимает некоторое время, поэтому обновлённая информация в веб-интерфейсе появится не сразу, а через несколько минут. Разумеется, дергать постоянно руками такую обработку смысла нет никакого, так как настроенный ранее таймер patchman-server-reports.timer на стороне сервера Patchman выполнит всю нужную работу по заданному нами расписанию.
Заключение
Данное решение представляется как полезный и наглядный инструмент для администраторов Linux систем в инфраструктурах разного масштаба, а также может рассматриваться, как вспомогательное средство визуальной оценки уровня актуальности пакетной базы для специалистов в области информационной безопасности и аудита.
Из очевидных плюсов решения можно отметить "деликатность" и легковесность клиентской части Patchman. Из очевидных минусов можно отметить отсутствие взаимной аутентификации между клиентом и сервером Patchman, что теоретически позволяет посылать на сервер недостоверную информацию с любого компьютера, входящего в диапазоны разрешённых подсетей в конфигурации веб-сервера Apache.
Серверная часть Patchman, построенная на базе фреймворка Django, открывает некоторые дополнительные возможности, как, например, использование REST API для дальнейшей интеграции с другими системами мониторинга и контроля.
История релизов говорит нам о том, что проект развивается, а To-Do List обнадёживает планами на дальнейшее улучшение. И это хорошо.
RSS - Записи
Спасибо, весьма полезно действительно.