Импорт справочников GLPI: XML словари оборудования

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

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

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

Быстрый ответ
Справочники оборудования в GLPI — это не простые выпадающие списки, а правила словарей (RuleDictionary), которые выполняются во время инвентаризации и нормализуют сырые данные от агента. Импортировать заготовку названий можно через кнопку «Импорт» в разделе Администрирование → Правила → нужный словарь, загрузив XML нужной структуры. Но готовые XML с именами — это только каркас: без критериев и действий правило существует, но ничего не делает. В статье: где лежит нужный раздел, как подготовить XML под свою инсталляцию, как добавить критерии и действия вручную и массово через API, и что проверить, чтобы словарь реально заработал.

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 10.0.26 (LTS) или 11.0.8 (стабильная) На момент публикации это актуальные сборки. Перед импортом проверь свежие релизы на github.com/glpi-project/glpi/releases
PHP 8.2+ Для GLPI 11.0 обязателен минимум 8.2, для 10.0.x хватает 7.4-8.2
MariaDB / MySQL 10.6+ / 8.0+ Поддержка MariaDB 10.5 и старше прекращена в свежих релизах
GLPI Agent актуальная из Marketplace Именно агент формирует сырые данные, которые ловят правила словарей

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

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

%%{init: {
  'theme': 'base',
  'themeVariables': {
    'primaryColor': '#f8fafc',
    'primaryTextColor': '#1e293b',
    'primaryBorderColor': '#94a3b8',
    'lineColor': '#64748b',
    'fontSize': '15px',
    'fontFamily': 'ui-sans-serif, system-ui, sans-serif'
  },
  'flowchart': {'curve': 'linear', 'nodeSpacing': 50, 'rankSpacing': 50}
}}%%
flowchart TD
    A["GLPI Agent"] --> B["Сырые данные железа"]
    B --> C["Rules Engine словарей"]
    C --> D["Критерий совпал"]
    D --> E["Стандартное значение в актив"]
    C --> F["Критерий не совпал"]
    F --> G["Значение остаётся сырым"]
    style A fill:#f8fafc,stroke:#3b82f6,stroke-width:2px,color:#1e40af
    style B fill:#f8fafc,stroke:#f97316,stroke-width:2px,color:#9a3412
    style C fill:#f8fafc,stroke:#3b82f6,stroke-width:2px,color:#1e40af
    style D fill:#f8fafc,stroke:#22c55e,stroke-width:2px,color:#15803d
    style E fill:#f8fafc,stroke:#22c55e,stroke-width:2px,color:#15803d
    style F fill:#f8fafc,stroke:#ef4444,stroke-width:2px,color:#991b1b
    style G fill:#f8fafc,stroke:#ef4444,stroke-width:2px,color:#991b1b

Смотри на эту схему как на карту дальнейших шагов. Мы сейчас на этапе 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 в раздел словаря мониторов — импорт либо откажется, либо создаст мусор не там. Таблица соответствия:

Файл из архива sub_type в XML Куда грузить в GLPI
glpi_computertypes_import.xml RuleDictionnaryComputerType Администрирование → Правила → Словарь типов компьютеров
glpi_manufacturers_import.xml RuleDictionnaryManufacturer Администрирование → Правила → Словарь производителей
glpi_monitortypes_import.xml RuleDictionnaryMonitorType Администрирование → Правила → Словарь типов мониторов
glpi_networkequipmenttypes_import.xml RuleDictionnaryNetworkEquipment Администрирование → Правила → Словарь сетевого оборудования
glpi_peripheraltypes_import.xml RuleDictionnaryPeripheral Администрирование → Правила → Словарь периферии
glpi_phonetypes_import.xml RuleDictionnaryPhoneType Администрирование → Правила → Словарь типов телефонов
glpi_printertypes_import.xml RuleDictionnaryPrinterType Администрирование → Правила → Словарь типов принтеров

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

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

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

# заменяем "Комета ООО" на реальное имя твоей сущности во всех 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.

Что проверяем Ожидаемый результат
Карточка актива после Replay Производитель и тип показывают нормализованное значение, не сырую строку от агента
Вкладка «Критерии» правила Минимум один критерий, условие соответствует реальному значению из сырых данных
Вкладка «Действия» правила Минимум одно действие с типом «assign» и заполненным значением
Порядок ranking в словаре Специфичные правила выше общих, конфликтов приоритета нет

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

Ошибка Причина Решение Команда / действие
Импорт падает с ошибкой сущности entities_id в файле не совпадает ни с одной существующей сущностью Исправь значение перед загрузкой, сверь точное название в Администрирование → Сущности sed -i 's/<entities_id>.*<\/entities_id>/<entities_id>Root entity<\/entities_id>/' файл.xml
Правила импортировались, но тип/производитель не проставляется У правила нет критериев и действий — это ожидаемо для готовых XML-заготовок Добавь критерий и действие вручную или через скрипт из шага 5 см. Python-скрипт выше
Одинаковые правила задублировались после повторного импорта UUID в файле изменили или сгенерировали заново перед повторной загрузкой Перед повторным импортом убедись что UUID совпадают с уже существующими правилами, либо удали дубликаты вручную Настройка → Словари → сортировка по названию, ручная зачистка
Общее правило перехватывает случаи, которые должны попадать в специфичное Неверный ranking — общее правило стоит выше узкого Перетащи специфичные правила выше общих в списке Drag-and-drop в интерфейсе словаря или правка поля ranking
Правило не срабатывает даже с заполненными критериями Критерий сравнивается не с тем полем — например ищет в «model», а нужное значение приходит в «manufacturer» Сверь реальные сырые данные в необработанном отчёте инвентаризации перед написанием критерия Настройка → Инвентаризация → Просмотр XML/JSON последнего отчёта агента
После обновления GLPI словари словно обнулились Обновление затронуло схему таблиц rule_criteria/rule_action в редких мажорных релизах Проверь changelog версии на предмет изменений Rules Engine, восстанови из бэкапа при необходимости mysql glpidb < backup_rules.sql

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_rules*, glpi_ruledictionary* Перед каждым массовым импортом/Replay Отдельный дамп на файловом хранилище, вне продакшн-сервера mysql glpidb < dump.sql после остановки веб-сервера
Экспортированные XML словарей После каждого значимого изменения правил Git-репозиторий инфраструктурной документации Повторный импорт через UI

Обновление

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

8. FAQ

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

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

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

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

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

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

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

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

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

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

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

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

9. Прогноз

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

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

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

Андрей А.
Author: Андрей А.

Руководитель ИТ / Кризис-менеджер 25 лет в IT: от инженера в МегаФоне до руководителя отдела. Знаю, как выглядит бардак: нестабильные сети, устаревшая инфраструктура, конфликты в команде, раздутые сроки. Помогаю бизнесу выходить из кризиса: навожу порядок в легаси, стабилизирую то, что разваливается, выстраиваю прогнозируемые процессы. Не раз возвращал к жизни ИТ-структуры — знаю цену хаосу. 📍 Ищу проект для полной реорганизации / стабилизации. 📬 Telegram: @over_dude ✉️ mail@it-apteka.com

Оставайтесь на связи

Рецепты от IT-боли. Без воды, без рекламы, без маркетинговой шелухи.

Подписаться на IT-Аптеку →

Мы ВКонтакте

IT-Аптека — советы, новости и помощь рядом.

Вступить в группу ВКонтакте →
Поделитесь:

Связанные записи

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Прокрутить вверх