GLPI объединяет компьютеры или создаёт дубли: диагностика UUID и правил импорта

Если данные двух компьютеров по очереди появляются в одной карточке GLPI, это не обычное дублирование. Система могла сопоставить разные машины с одним объектом по совпавшему идентификатору или слишком широкому правилу. Если один компьютер получает несколько карточек, искать нужно другой сценарий: изменение идентификаторов, области поиска, сущности или порядка правил.

Ниже — порядок диагностики для GLPI 10/11 и GLPI Agent. Названия меню зависят от версии и перевода; инвентаризация ядра и старые установки с FusionInventory требуют разных процедур. Не начинайте с отключения всех проверок UUID и не исправляйте связи прямым удалением строк из базы.

1. Разделите объединение машин и создание дублей

Для каждой проблемной карточки запишите ID объекта, сущность, имя, серийный номер, UUID, время обновления и историю изменения полей. Сопоставьте их с двумя реальными компьютерами. Если после отчёта A карточка описывает A, а после отчёта B — B, вероятна ошибочная привязка обеих инвентаризаций к одному объекту.

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

Отдельно проверьте, что вы сравниваете компьютеры, а не компьютер и сетевое устройство, обнаруженное другим заданием. Зафиксируйте версии GLPI, Agent и задействованного плагина. Этот набор позволяет воспроизвести проблему без предположения «GLPI просто работает неправильно».

2. Какие идентификаторы нельзя считать одинаковыми

SMBIOS UUID, серийный номер оборудования, hostname, MAC, Windows SID и идентификатор агента описывают разные свойства. IP выдаётся DHCP и меняется; имя может повторяться в разных организациях; MAC бывает у виртуального адаптера или общего устройства. Ни одно из этих полей нельзя объявить уникальным без проверки источника.

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

Sysprep /generalize обобщает Windows-установку. Не считайте его доказательством смены SMBIOS UUID гипервизора: аппаратную идентичность и подготовку гостевой ОС проверяют отдельно. Повторное имя или пустой serial особенно опасны при правилах с широким логическим «ИЛИ».

3. Как получить локальную инвентаризацию без отправки

Сначала сохраните отчёты A и B отдельно. Для этого удобен самостоятельный инструмент glpi-inventory. Он предназначен для локального формирования отчёта. Не заменяйте его бездумно на запуск обычного агента: тот может прочитать настроенные серверные цели.

На Linux с установленной утилитой:

umask 077
glpi-inventory --json > "$HOME/inventory-a.json"
python3 -m json.tool "$HOME/inventory-a.json" > /dev/null

При ошибке генерации не используйте неполный файл. Для Windows путь зависит от способа установки. Пример сохраняет UTF-8 без BOM и проверяет код завершения:

$tool = 'C:\Program Files\GLPI-Agent\glpi-inventory.bat'
if (!(Test-Path -LiteralPath $tool)) { throw 'Проверьте путь GLPI Agent' }
$inventory = & $tool --json
if ($LASTEXITCODE -ne 0) { throw 'Инвентаризация завершилась с ошибкой' }
$out = Join-Path $env:USERPROFILE 'inventory-a.json'
$text = $inventory -join [Environment]::NewLine
$null = $text | ConvertFrom-Json
[IO.File]::WriteAllText($out, $text, [Text.UTF8Encoding]::new($false))

На второй машине используйте имя inventory-b.json. Выполняйте сбор с согласованными полномочиями: доступность аппаратных сведений зависит от прав и платформы. Отчёты содержат внутренние сведения о системе и ПО; передача в публичный форум требует отдельного обезличивания.

4. Как сравнить UUID и серийные номера

JSON-протокол описан в документации GLPI inventory. Проверьте фактическую структуру своего отчёта: в типовом JSON используются content.hardware.uuid, content.hardware.name, content.bios.ssn и верхнеуровневый deviceid. Отсутствие поля нельзя подменять выдуманным значением.

Для локального сравнения двух отчётов:

import json
from pathlib import Path

for filename in ("inventory-a.json", "inventory-b.json"):
    data = json.loads(Path(filename).read_text(encoding="utf-8-sig"))
    content = data.get("content", {})
    hardware = content.get("hardware", {})
    bios = content.get("bios", {})
    print(filename, {
        "deviceid": data.get("deviceid"),
        "name": hardware.get("name"),
        "uuid": hardware.get("uuid"),
        "serial": bios.get("ssn"),
    })

Этот пример только читает файлы; он не отправляет отчёты в GLPI. Запустите его в каталоге с копиями. Совпавший UUID у двух разных VM — основание исследовать клонирование. Совпавший пустой serial — основание проверить обработку пустых значений и чёрные списки, а не объединять все машины без serial.

Одинаковые поля в локальном сборе и иной результат серверного импорта указывают на следующую область исследования: правила, сущности и состояние уже существующих объектов. Различия между локальным и штатным сбором сначала объясните правами и конфигурацией агента.

5. Как работают сущности и порядок правил

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

Откройте административный раздел правил и найдите правила назначения сущностей и импорта/связывания компьютеров. Просмотрите активные правила сверху вниз: критерии, соединение «И/ИЛИ», действия, область поиска и первый подходящий результат. Установка конкретного плагина может добавлять другие механизмы — учитывайте именно свой тракт импорта.

Например, условие «UUID совпадает ИЛИ имя совпадает» шире условия, требующего обеих проверок. Но и простое ужесточение до «И» способно создавать дубли после разрешённого переименования. Правило выбирают по стабильным идентификаторам своих активов и документированному жизненному циклу, затем тестируют нормальные изменения.

6. Что исправлять в источнике, а что в правилах

Для клонированных VM проверьте процедуру создания нового экземпляра и генерацию аппаратного UUID в используемом гипервизоре. Менять его на работающей машине без оценки последствий нельзя: идентификатор может использоваться лицензированием и другими системами. Подготовьте изменение на тестовом клоне с подходящим руководством платформы.

Для некорректного серийного номера используйте штатную обработку известных невалидных значений, если она поддерживается вашим механизмом инвентаризации. Добавляйте конкретное подтверждённое значение, а не отключайте весь критерий для организации. Плагин и инвентаризация ядра могут иметь разные настройки; смотрите документацию GLPI Inventory.

Для ошибки правил исправляйте конкретное условие или область. Сначала покажите, какое правило связывает A и B и почему его критерий недостаточен. Исключение для узкой категории оборудования безопаснее глобального обхода, если оно проверено для этой категории. Имя компьютера, IP и MAC не должны становиться универсальной заменой аппаратной идентичности.

7. Как проверить изменение на отдельном контуре

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

На изолированной копии GLPI воспроизведите импорт отчётов штатным механизмом вашей версии. Сначала импортируйте A, затем B, затем снова A и B. Для двух разных машин ожидаются две независимые карточки, а повторный импорт обновляет каждую свою карточку. Запишите ID после каждого шага.

Добавьте проверки разрешённого переименования, замены NIC и сущностей. Отчёты из разных организаций не должны связываться из-за одинакового hostname. Проверка одного успешного импорта не выявляет перезапись после второго отчёта. В тестовой копии отключите боевые уведомления, интеграции и внешние задания.

8. Как разбирать дубли и уже ошибочно объединённые карточки

Сначала остановите повторение ошибочной привязки согласованным узким способом: исправленным правилом или временным ограничением конкретного источника. Остановка всей инвентаризации без оценки создаёт дополнительный провал актуальности данных.

Проверьте связи карточек с заявками, документами, договорами, лицензиями, пользователями и историей. Удаление дубля может потерять эти связи. Доступность объединения или переноса зависит от версии и установленного инструмента; не обещайте универсальную кнопку и не используйте прямой SQL как замену управляемой процедуре.

Ошибочное объединение не всегда исправляется возвращением старого правила: уже перезаписанные поля остаются. Для восстановления нужны история, исходные отчёты и резервная копия. Возврат всей БД назад может потерять изменения других пользователей; решение о таком откате принимают отдельно, сопоставляя новые операции. Восстановление отдельных активов выполняют по проверенной процедуре с владельцем данных.

9. Как отличить доставку отчёта от успешного импорта

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

HTTP 200 подтверждает успешный ответ на уровне запроса, но не доказывает правильную связь с объектом. Проверяйте фактический ID карточки, сущность, поля и отметку обновления после конкретного отчёта. «Компьютер появился» также недостаточно, если рядом возник второй объект.

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

10. Как предотвратить повторение после исправления

Зафиксируйте процедуру подготовки шаблонов VM и Windows, критерии уникальности активов, обработку невалидных serial и изменения сущностей. Приложите обезличенные примеры A/B, правило до и после, результаты четырёх импортов и порядок возврата.

Для новых шаблонов включите проверку UUID и serial нескольких независимых экземпляров. При обновлении Agent или GLPI повторяйте ограниченный тест важных сценариев. Массовый сброс состояния агента без инструкции способен породить новые дубли и скрыть исходную причину.

Исправление считается принятым, когда разные машины имеют независимые карточки, повторная инвентаризация обновляет нужные объекты, нормальные изменения не создают лишних записей, а связи с заявками и документами сохранены. Работающий механизм сопоставления подтверждается этой последовательностью, а не отключением всех проверок идентичности.