OCS Inventory NG - система инвентаризации и деплоя ПО OCS умеет фиксировать дельту между инвентаризациями: изменения железа, ПО, значений реестра/файлов, кастомных параметров. Ниже — подробный гайд, как максимально эффективно настроить и использовать эти механизмы для отслеживания изменений конфигураций.

---

1. Что именно может отслеживать OCS Inventory

Тип изменения	Поддержка в OCS	Механизм
Аппаратное (CPU, RAM, диски, BIOS, сетевые адаптеры, периферия)	Да	Сравнение снапшотов инвентаризации
Программное (установка/удаление/обновление ПО)	Да	Таблица softwares, история изменений
Реестр / файлы / параметры ОС	Частично	Плагины агента [REGISTRY], [FILES]
Сетевые конфиги, GPO, службы, параметры ядра	Нет	Требуются внешние системы

2. Включение истории инвентаризации (основа для отслеживания изменений)

По умолчанию OCS хранит только последнее состояние устройства. Чтобы сравнивать конфигурации во времени, нужно включить ведение истории.

На сервере (Linux)

1. Откройте конфигурационный файл сервера:

   sudo nano /etc/ocsinventory-server/z-ocsinventory-server.conf

2. Найдите или добавьте параметры:

   OCS_OPT_ENABLE_HISTORY=1
   OCS_OPT_HISTORY_MAX_DAYS=180

3. Перезапустите Apache/PHP-FPM:

   sudo systemctl restart apache2 php-fpm

В веб-интерфейсе

1. Перейдите: Администрирование → Общие настройки → Инвентаризация
2. Убедитесь, что Включить историю инвентаризации = Да
3. Установите срок хранения снапшотов (рекомендуется 90–180 дней)

Внимание:

• Включение истории увеличивает нагрузку на БД и объём хранилища. Для крупных парков (>5000 хостов) рекомендуется настроить очистку через cron и мониторинг таблицы assets_history.

---

3. Как просматривать изменения конфигурации

Через веб-интерфейс

1. Компьютеры → Поиск устройства → Открыть карточку
2. Перейдите на вкладку История (History)
3. Выберите две даты инвентаризации → нажмите Сравнить

4. Система подсветит добавленные/удалённые/изменённые элементы:

• Новое оборудование/ПО
• Удалённое
• Изменённые параметры (версии, объёмы, пути)

Через API / SQL (для автоматизации)

Таблица истории: assets_history (в OCS 2.9+) или hardware + временные метки.

Пример запроса для поиска изменений ПО за период:

SELECT h.name, h.uuid, s.name AS software, s.version, h.lastdate AS last_inventory
FROM hardware h
JOIN softwares s ON h.id = s.hardware_id
WHERE h.lastdate BETWEEN '2025-01-01' AND '2025-12-31'
ORDER BY h.name, s.name;

Точная структура БД зависит от версии OCS. Рекомендуется использовать встроенные отчёты или REST API (/ocsreports/api.php).

4. Отслеживание специфичных конфигурационных параметров

OCS позволяет собирать кастомные данные через агента. Это основной способ мониторинга конфигов.

4.1. Мониторинг реестра (Windows)

В файле агента C:\ProgramData\OCS Inventory Agent\ocsinventory-agent.cfg:

[REGISTRY]
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\CurrentVersion
HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU

После следующей инвентаризации значения появятся во вкладке Реестр карточки устройства.

4.2. Мониторинг файлов/конфигов (Linux/Windows)

[FILES]
/etc/hostname
/etc/ssh/sshd_config
C:\Windows\System32\drivers\etc\hosts

Файлы читаются только в текстовом виде и хешируются. Для бинарных конфигов используйте [RUN] с внешним скриптом.

4.3. Кастомные поля через [RUN]

Пример для Linux (сбор текущей политики ядра):

[RUN]
cat /proc/sys/kernel/randomize_va_space | awk '{print "RANDOMIZE_VA_SPACE="$1}'
sysctl net.ipv4.ip_forward | awk '{print "IP_FORWARD="$3}'

Результат отобразится в разделе Пользовательские данные и будет участвовать в сравнении историй.

5. Автоматизация оповещений об изменениях

OCS не имеет встроенных уведомлений, но их легко реализовать:

Вариант 1: OCS Reports + Cron

1. Создайте SQL-отчёт, ищущий новые записи в assets_history за последние 24 часа
2. Настройте cron с mysql -e "SELECT ..." | mail -s "OCS: Изменения конфигурации" admin@domain.ru

Вариант 2: Внешний скрипт (Python/REST API)

import requests
url = "http://ocs-server/ocsreports/api.php"
params = {"mode": "history", "computer_id": 1234, "days": 1}
resp = requests.get(url, params=params, auth=("api_user", "password"))
changes = resp.json().get("deltas", [])
if changes:
    print("Обнаружены изменения:", changes)
    # Отправка в Telegram/Slack/Email

Вариант 3: Интеграция с GLPI

Установите плагин OCS Inventory NG для GLPI → включите Синхронизацию изменений → настройте Правила автоматических действий для создания тикетов при изменении критичных параметров.

6. Ограничения и рекомендации

Проблема	Решение
Нет трекинга изменений сетевых устройств, GPO, служб	Используйте Oxidized/RANCID, Ansible, Wazuh, SCCM/Intune
История хранит только снапшоты, не логи событий	Парсите журналы ОС (journalctl, EventLog) и отправляйте в SIEM
Высокая нагрузка при частой инвентаризации	Настройте PROLOG_FREQ в агенте, используйте OCS_OPT_INVENTORY_ON_START=0
Сложность сравнения больших парков	Экспортируйте историю в CSV/JSON → анализируйте в ELK/Grafana

Чек-лист настройки мониторинга конфигураций в OCS

1. [ ] Включить OCS_OPT_ENABLE_HISTORY=1
2. [ ] Настроить глубину хранения (HISTORY_MAX_DAYS)
3. [ ] Добавить критичные реестры/файлы/команды в ocsinventory-agent.cfg
4. [ ] Настроить кастомные поля под ваши конфигурации
5. [ ] Протестировать сравнение двух инвентаризаций
6. [ ] Реализовать уведомления (cron + API / GLPI / внешние скрипты)
7. [ ] Настроить резервное копирование таблицы assets_history
8. [ ] Документировать, какие параметры отслеживаются, а какие вынесены в другие системы

Итог

• OCS Inventory отлично подходит для инвентарного аудита изменений между циклами сбора данных, но не заменяет системы управления конфигурациями в реальном времени.

Для production-сред рекомендуется связка:

• OCS Inventory (аппаратное/ПО) + GLPI (CMDB/тикетирование) + Wazuh/Elastic (логи/аудит) + Git+Ansible (версионирование конфигов)