Импорт справочников GLPI: как за один заход загрузить словари оборудования вместо недели кликов

Основной ключ этой статьи — импорт справочников GLPI. Если ты сюда попал, значит уже открывал раздел «Правила» в GLPI и понял, что руками создавать семьдесят производителей и двадцать типов компьютеров — это не работа, а наказание.

1. Диагноз

Смотри, с чем обычно приходят. Поднял GLPI. Прогнал первую инвентаризацию агентом. Открыл список компьютеров — а там зоопарк: «Hewlett-Packard» и «HP» вперемешку, «Dell Inc.» рядом с «Dell», тип оборудования у половины серверов — пустой. Знакомо?

Дальше начинается классика: заходишь в Настройка → Словари, видишь пустые справочники производителей, типов компьютеров, мониторов, принтеров, телефонов, периферии и сетевого оборудования — и понимаешь, что создавать это все руками через веб-форму придётся раз по семьдесят. GLPI импорт справочников оборудования — это именно про то, как этого избежать.

Что получишь на выходе этой статьи:

• Готовые к правке XML-файлы для семи словарей: типы компьютеров, производители, типы мониторов, сетевое оборудование, периферия, типы телефонов, типы принтеров
• Понимание, почему голый импорт имён — это половина работы, а не вся
• Рабочий способ добавить критерии и действия правилам массово, без 150 кликов
• Чек-лист проверки, что словарь реально подхватывает данные при инвентаризации

Время на весь цикл — час-полтора, если файлы уже готовы. Значительная часть уйдёт не на импорт, а на то, чтобы прописать логику распознавания. Импорт имён — это пять минут на файл.

Нужны права администратора в GLPI, доступ к разделу Правила и минимум один прогон инвентаризации агентом, чтобы видеть сырые значения от реального железа — без них критерии писать вслепую.

2. Причины

Почему вообще словари оборудования превращаются в проблему, а не остаются тихой административной рутиной.

• GLPI по умолчанию почти пустой. Базовая установка даёт минимальный набор типов и производителей. Реальный парк техники в компании на 40-60 моделей этого набора не покрывает.
• Агент присылает сырые строки, а не готовые категории. WMI и dmidecode отдают то, что зашито производителем в BIOS/SMBIOS: «Hewlett-Packard», «HPE», «HP Inc.» — три разных строки для одной компании.
• Ручное создание записи в словаре — это отдельная форма на каждое значение. Открыл, заполнил название, сохранил, снова открыл. Семьдесят производителей — это не пять минут.
• Правило словаря (RuleDictionary) — это не просто список. У каждого правила есть критерии (что искать в сырых данных) и действия (что присвоить в итоге). Без обоих компонентов правило существует, но бездействует.
• Ranking решает, какое правило сработает первым. Если не выстроить порядок, общее правило «HP» может перехватить то, что должно было уйти в более узкое «HP Inc. — серверы».
• Сущности (entities_id) в мультитенантных инсталляциях ломают импорт. Если у тебя одна сущность в GLPI называется не так, как в экспортированном файле, импорт либо упадёт, либо привяжет правила не туда.
• Разные версии GLPI по-разному ведут себя с пустыми критериями. В части версий правило без критериев считается «всегда истинным», в других — никогда не срабатывает. Разница критична для итогового поведения.

3. Рецепт

Подготовка

Права в GLPI: профиль администратора с доступом к разделу «Правила» (Rules). Без этого пункта меню словарей просто не появится в интерфейсе.

Архивчик с готовыми XML-заготовками я выложил тут: glpi_import.zip. Внутри семь файлов — по одному на каждый словарь: типы компьютеров, производители, типы мониторов, сетевое оборудование, периферия, типы телефонов, типы принтеров.

Смотри на эту схему как на карту дальнейших шагов. Мы сейчас на этапе C — создаём правила. Всё, что справа и ниже, заработает только если правильно настроить критерии.

Шаг 1. Пойми структуру XML, прежде чем что-то грузить

Формат импорта у GLPI жёсткий. Каждый файл — это набор тегов <rule> внутри корня <rules>. Вот минимальный валидный блок для одного правила словаря производителей:

<?xml version='1.0' encoding='utf-8'?>
<rules>
  <rule>
    <entities_id>Root entity</entities_id>
    <sub_type>RuleDictionnaryManufacturer</sub_type>
    <ranking>0</ranking>
    <name>Dell</name>
    <description>Серверы, ПК, ноутбуки, мониторы</description>
    <match>AND</match>
    <is_active>1</is_active>
    <comment />
    <is_recursive>0</is_recursive>
    <condition>0</condition>
  </rule>
</rules>

Вот тут важно не перепутать: sub_type жёстко привязывает файл к конкретному разделу интерфейса. Загрузишь файл с RuleDictionnaryComputerType в раздел словаря мониторов — импорт либо откажется, либо создаст мусор не там. Таблица соответствия:

Шаг 2. Почини entities_id перед загрузкой

Вот тут людей режет чаще всего. В экспортированном файле entities_id хранится как имя сущности, а не как её ID из базы. Если название сущности в файле не совпадает буква в букву с твоей — импорт либо откатится на корневую сущность, либо выдаст ошибку в зависимости от версии.

# заменяем "Комета ООО" на реальное имя твоей сущности во всех XML разом
cd glpi_import
for f in *.xml; do
  sed -i 's/Комета ООО<\/entities_id>/Root entity<\/entities_id>/' "$f"
done

# проверяем что замена прошла
grep -c "entities_id" *.xml

Результат: во всех семи файлах строка entities_id указывает на реально существующую в твоей инсталляции сущность. Если работаешь с несколькими сущностями (филиалы, клиенты в мультиарендной GLPI) — разбей файлы и распредели правила по нужным веткам заранее, до загрузки.

Шаг 3. Загрузи файл через интерфейс

CLI-команды для импорта правил в GLPI нет — это операция строго через веб-интерфейс. Заходи в нужный раздел словаря, листай список правил до конца страницы, там кнопка «Импорт». Выбираешь файл, GLPI показывает предпросмотр — сколько правил будет создано, сколько уже существует с таким же UUID (их пропустит).

Setup → Rules → Dictionary rules → [нужный словарь] → Import

После подтверждения GLPI создаёт правила пачкой. Проверь ranking — импорт сохраняет порядок из файла, но если у тебя уже были свои правила в этом словаре, новые встанут в конец списка. Порядок стоит пересобрать вручную сразу после импорта, иначе более специфичные правила окажутся ниже общих и никогда не сработают.

Шаг 4. Пойми, чего не хватает в готовых файлах

А вот и главный подвох. Открой любое правило из только что импортированных — и увидишь пустые вкладки «Критерии» и «Действия». Заготовка даёт только имя и описание. Это каркас дома без начинки: стены стоят, а жить в нём пока нельзя.

Ну и запросы у вас, — сказала база данных и повисла. Шучу. На самом деле GLPI ничего не роняет. Просто правило без действия молча ничего не делает, и это молчание можно принять за баг, хотя это ожидаемое поведение.

Чтобы правило заработало, нужны минимум одно условие (критерий) и минимум одно действие. Пример для правила «Dell» в словаре производителей:

• Критерий: поле «Производитель» (raw manufacturer) содержит «Dell Inc.»
• Действие: присвоить стандартное значение производителя «Dell»

Через интерфейс это делается так: открываешь правило → вкладка «Критерии» → «Добавить критерий» → выбираешь поле, условие («содержит», «равно», регулярное выражение) и паттерн. Дальше вкладка «Действия» → «Присвоить стандартное значение» → выбираешь итоговое значение из выпадающего списка (оно должно уже существовать как запись словаря — собственно, для этого и нужен был импорт имён на шаге 3).

Шаг 5. Автоматизируй добивку критериев и действий через API

Кликать это вручную по семьдесят раз — то же самое мучение, от которого мы бежали изначально. GLPI REST API умеет создавать RuleCriteria и RuleAction программно. Вот рабочий скрипт, который проходит по всем правилам словаря производителей и для каждого добавляет критерий «содержит имя правила» плюс действие «присвоить это же имя как стандартное значение»:

import requests

GLPI_URL = "https://it-apteka.com/glpi/apirest.php"
APP_TOKEN = "твой_app_token"
USER_TOKEN = "твой_user_token"

session = requests.post(
    f"{GLPI_URL}/initSession",
    headers={"App-Token": APP_TOKEN, "Authorization": f"user_token {USER_TOKEN}"}
).json()["session_token"]

headers = {"App-Token": APP_TOKEN, "Session-Token": session}

# получаем все правила словаря производителей без критериев
rules = requests.get(
    f"{GLPI_URL}/Rule",
    headers=headers,
    params={"searchText[sub_type]": "RuleDictionnaryManufacturer", "range": "0-200"}
).json()

for rule in rules:
    rule_id = rule["id"]
    name = rule["name"]

    # критерий: raw manufacturer содержит имя правила
    requests.post(f"{GLPI_URL}/RuleCriteria", headers=headers, json={
        "input": {
            "rules_id": rule_id,
            "criteria": "manufacturer",
            "condition": 0,  # 0 = содержит
            "pattern": name
        }
    })

    # действие: присвоить стандартное значение
    requests.post(f"{GLPI_URL}/RuleAction", headers=headers, json={
        "input": {
            "rules_id": rule_id,
            "action_type": "assign",
            "field": "manufacturer",
            "value": name
        }
    })

requests.post(f"{GLPI_URL}/killSession", headers=headers)
print("Готово: критерии и действия добавлены")

Это базовый шаблон — под реальные данные придётся подправить паттерны, потому что «Dell» и «Dell Inc.» это не одно и то же для строгого сравнения. Для производителей почти всегда нужно несколько альтернативных написаний на одно правило: добавь второй критерий с условием «ИЛИ» на вкладке критериев вручную для тех производителей, у которых зоопарк названий в реальных отчётах агента.

Шаг 6. Выставь ranking осознанно

GLPI проверяет правила по порядку ranking и по умолчанию останавливается на первом совпадении, если в самом правиле не включена галочка «продолжить проверку». Значит: узкие и специфичные правила должны стоять выше общих.

Пример на словаре типов компьютеров: если у тебя есть отдельное правило «Сервер (виртуальный хост)» и общее «Сервер (стоечный)», специфичное должно проверяться первым — иначе виртуальный хост навсегда осядет в общей категории.

Правильный порядок (сверху вниз = выше приоритет):
0. Сервер (виртуальный хост)  - узкий критерий по модели/hypervisor
1. Сервер (блейд)              - узкий критерий по форм-фактору
2. Сервер (стоечный)           - общий признак "rack" в модели
3. Рабочая станция (CAD/3D)    - узкий критерий по видеокарте
4. Рабочая станция             - общее правило по умолчанию

Шаг 7. Повтори для остальных шести словарей

Логика идентична для типов мониторов, сетевого оборудования, периферии, телефонов и принтеров. Разница только в наборе полей критериев — для сетевого оборудования это будет тип устройства и производитель из SNMP-опроса, для принтеров — модель и класс устройства (МФУ определяется по наличию функции сканирования в отчёте агента).

Не пытайся сделать все семь словарей идеально с первого захода. Загрузи имена везде, добавь критерии для 15-20 самых частых позиций в твоём парке техники — это закроет 80% реальных случаев. Остальное доводи по мере появления новых моделей в инвентаризации.

4. Проверка

После настройки критериев и действий проверка в три шага.

1. Ручной прогон правила на существующем активе:
   Открой актив → вкладка "Правила" (если доступна) → "Тестировать правило"
   
2. Принудительный пересчёт словарей на всём парке:
   Настройка → Словари → кнопка "Заменить"
   Это прогонит уже накопленные данные через обновлённые правила

3. Прогон свежей инвентаризации:
   Запусти агента вручную на одной машине и сверь итоговое
   значение производителя/типа в карточке актива

Смотри логи GLPI при массовой замене — раздел Настройка → Журналы → отфильтруй по типу события «rules». Если правило сработало, там будет запись о применении с указанием rules_id.

5. Осложнения

6. Альтернативы

Импорт правил словарей — не единственный путь, но для GLPI импорт справочников оборудования именно так и задуман архитектурно.

• Ручное создание через UI без импорта. Работает для 5-10 значений. На семидесяти производителях умирает от скуки задолго до завершения.
• Прямая правка через SQL в таблицах glpi_rules, glpi_rulecriterias, glpi_ruleactions. Быстрее, но легко сломать целостность данных, если не знаешь точную структуру внешних ключей. Используй только если понимаешь схему и держишь свежий бэкап под рукой.
• Плагин Data Injection. Позволяет массово загружать данные через CSV с маппингом полей, включая словарные значения. Хорош для разовой миграции из другой CMDB, избыточен для регулярного пополнения словарей.
• Полный отказ от нормализации, работа с сырыми значениями. Технически возможно — GLPI не заставляет использовать словари. На практике превращает отчёты и дашборды в кашу из разнописных значений одного и того же производителя.

Основной ключ выбран не случайно: импорт справочников GLPI через XML — единственный способ, который сохраняет ranking, UUID и структуру правил в переносимом виде между инсталляциями. Остальные варианты либо медленнее, либо рискованнее для целостности базы.

7. Профилактика

Капля никотина убивает лошадь. Одна забытая заглушка ranking в словаре производителей — весь квартальный отчёт по парку техники, потому что половина серверов Dell вдруг оказалась «неизвестным производителем».

• Бэкап перед любой массовой операцией. Таблицы rules, rulecriterias, ruleactions, dictionary-справочники — в отдельный дамп перед импортом или Replay.
• Мониторинг «сырых» значений. Раз в месяц смотри в разделе активов, сколько записей осталось с нераспознанным производителем или пустым типом — это сигнал добавить недостающие критерии.
• Регламент на новые модели техники. Как только в компании закупили новую линейку оборудования, сразу добавь для неё правило, а не жди пока накопится сотня немаркированных активов.
• Версионирование правил. Экспортируй словари в XML после каждого значимого изменения и храни рядом с остальной инфраструктурной документацией — это твой откат на случай кривого редактирования.
• Тестируй критерии на реальных данных, а не на предположениях. То что «Dell» встречается в отчёте именно так, а не «DELL INC.» — нужно проверить, а не угадать.
• Разделяй права на редактирование словарей. Не давай всем администраторам GLPI доступ к правкам ranking — один неаккуратный клик ломает порядок проверки для всей компании.
• Проверяй словари после каждого крупного обновления GLPI. Мажорные релизы иногда меняют поведение движка правил — молча.

Резервное копирование

Обновление

Перед обновлением GLPI на мажорную версию: сними дамп таблиц правил, прочитай changelog на предмет изменений в Rules Engine, прогони обновление сначала на тестовом стенде с копией продакшн-базы. Откат при проблеме — восстановление дампа плюс возврат к предыдущему архиву GLPI.

8. FAQ

Почему тип оборудования не проставляется автоматически после настройки словаря?

Чаще всего потому что у импортированного правила нет критериев и действий — готовый XML даёт только имя и описание, это каркас, а не рабочую логику. Проверь вкладки «Критерии» и «Действия» у конкретного правила, при пустых вкладках распознавания не будет никогда.

Как проверить что словарь работает правильно?

Запусти кнопку «Заменить» (Replay) в разделе словаря — она прогонит уже существующие данные через текущие правила. Дальше сверь карточки активов: производитель и тип должны показывать нормализованное значение, а не сырую строку от агента.

Что делать если entities_id не совпадает с моей инсталляцией?

Замени значение на точное название твоей сущности перед загрузкой файла — GLPI ищет строгое текстовое совпадение, а не по ID. Проверить корректное имя можно в разделе Администрирование → Сущности.

Чем словарь-правило (RuleDictionary) отличается от обычного справочника (Dropdown)?

Обычный справочник — это статичный список значений, который выбирают вручную при заполнении карточки. Правило словаря работает автоматически во время инвентаризации: сравнивает сырые данные от агента с критериями и само присваивает нужное стандартное значение, без участия человека.

Можно ли ошибиться и сломать существующие данные при импорте?

Сам импорт создаёт только новые записи правил и не трогает уже существующие активы. Риск появляется на этапе Replay — принудительный пересчёт может переписать значения на активах, если критерии настроены неточно. Перед Replay всегда снимай бэкап.

Почему один и тот же производитель встречается в разных написаниях у одного вендора?

Прошивка и агенты разных версий на разном железе одного вендора отдают разные строки в SMBIOS — это не баг GLPI, а особенность оборудования. Решение — несколько критериев с условием «ИЛИ» внутри одного правила, покрывающих все варианты написания.

9. Прогноз

Если прошёл все семь шагов — словари оборудования в GLPI перестали быть пустой формальностью и начали реально работать при каждой инвентаризации. Новые активы, которые попадают в систему через агента, автоматически получают нормализованное имя производителя и корректный тип, без ручной правки карточки.

Дальше это просто живёт само — раз в квартал сверяешь список нераспознанных значений и добавляешь пару новых критериев под свежекупленное железо. Рождённый в legacy рефакторинга не боится, а вот к пустым словарям возвращаться никому не хочется.

Если после импорта что-то не завелось — пиши в комментарии, разберёмся.