• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Агенты не поделили 2 разных ПК
#1
Ситуация такая в сети около 60 различных пк на разных версиях видны, на всех установлены fusioninventory-agent, на сервере GLPI они регистрируются шлют данные все замечательно.  НО есть  2 пк,  с именами IVANOV и PETROV. На каждом установлен fusioninventory-agent. Но на сервере GLPI чему-то именно из этих 2х ПК регистрирутется только один агент либо IVANOV, либо PETROV, соответственно если первым выполнить принудительно инвентаризацию на IVANOV, потом на PETROV, то информация о IVANOV, заменяется на PETROV, но агент все равно тот который был на IVANOV и наоборот.

Заметил что в в свойствах агента на IVANOV есть Fusioninventory тэг с именем другого ПК то есть PETROV. Но его оттуда никак не получается удалить. В реестре на IVANOV принудительно прописан тэг IVANOV, в реестре на PETROV принудительно прописан тэг PETROV. Даже если я удаляю агента зачищаю все в реестре на пк IVANOV, запускаю инвентаризацию без уснановки с сохранием в ХML-файл, открываю этот ХML-файл текстовым редактором внутри нет никакого упоминания второго пк PETROV, импортирую ХML-файл в GLPI иду в список компьютеров, пк IVANOV появляется в списке пк PETROV пропадает, вместе с агентом.  Подозреваю это связь где-то на уровне GLPI. Но как и где ее разорвать???
  Reply
#2
(2020-05-24, 16:33:29)bugy Wrote: Ситуация такая в сети около 60 различных пк на разных версиях видны, на всех установлены fusioninventory-agent, на сервере GLPI они регистрируются шлют данные все замечательно.  НО есть  2 пк,  с именами IVANOV и PETROV. На каждом установлен fusioninventory-agent. Но на сервере GLPI чему-то именно из этих 2х ПК регистрирутется только один агент либо IVANOV, либо PETROV, соответственно если первым выполнить принудительно инвентаризацию на IVANOV, потом на PETROV, то информация о IVANOV, заменяется на PETROV, но агент все равно тот который был на IVANOV и наоборот.

Заметил что в в свойствах агента на IVANOV есть Fusioninventory тэг с именем другого ПК то есть PETROV. Но его оттуда никак не получается удалить. В реестре на IVANOV принудительно прописан тэг IVANOV, в реестре на PETROV принудительно прописан тэг PETROV. Даже если я удаляю агента зачищаю все в реестре на пк IVANOV, запускаю инвентаризацию без уснановки с сохранием в ХML-файл, открываю этот ХML-файл текстовым редактором внутри нет никакого упоминания второго пк PETROV, импортирую ХML-файл в GLPI иду в список компьютеров, пк IVANOV появляется в списке пк PETROV пропадает, вместе с агентом.  Подозреваю это связь где-то на уровне GLPI. Но как и где ее разорвать???
Приветствую, если не нашли решение - отпишитесь, объясню как всё разгребать. А копать в сторону правил импорта и связей оборудования в  GLPI. Ищите схожие данные в конфигурациях ПК.
  Reply
#3
(2020-06-15, 10:38:57)maxwal41 Wrote:
(2020-05-24, 16:33:29)bugy Wrote: Ситуация такая в сети около 60 различных пк на разных версиях видны, на всех установлены fusioninventory-agent, на сервере GLPI они регистрируются шлют данные все замечательно.  НО есть  2 пк,  с именами IVANOV и PETROV. На каждом установлен fusioninventory-agent. Но на сервере GLPI чему-то именно из этих 2х ПК регистрирутется только один агент либо IVANOV, либо PETROV, соответственно если первым выполнить принудительно инвентаризацию на IVANOV, потом на PETROV, то информация о IVANOV, заменяется на PETROV, но агент все равно тот который был на IVANOV и наоборот.

Заметил что в в свойствах агента на IVANOV есть Fusioninventory тэг с именем другого ПК то есть PETROV. Но его оттуда никак не получается удалить. В реестре на IVANOV принудительно прописан тэг IVANOV, в реестре на PETROV принудительно прописан тэг PETROV. Даже если я удаляю агента зачищаю все в реестре на пк IVANOV, запускаю инвентаризацию без уснановки с сохранием в ХML-файл, открываю этот ХML-файл текстовым редактором внутри нет никакого упоминания второго пк PETROV, импортирую ХML-файл в GLPI иду в список компьютеров, пк IVANOV появляется в списке пк PETROV пропадает, вместе с агентом.  Подозреваю это связь где-то на уровне GLPI. Но как и где ее разорвать???
Приветствую, если не нашли решение - отпишитесь, объясню как всё разгребать. А копать в сторону правил импорта и связей оборудования в  GLPI. Ищите схожие данные в конфигурациях ПК.

Да решения НЕ НАШЕЛ. Но и конфигурации ПК совершенно РАЗНЫЕ!!!
  Reply
#4
Конфигурации ПК может быть и разные, а вот правила при обработке могут натыкаться на одинаковые показатели и определять два компа как один, у которого меняются комплектующие.

Итак, нас интересует раздел Администрнирование-FI-Правила-Правила импорта и связей оборудования.

Усваиваем основные тезисы этого раздела:
1. Все правила(у меня их 56) выполняются в строгой последовательности сверху-вниз. Если первое не подходит по критериям то система переходит ко второму. Если нарушить порядок, то восстанавливать очень сложно, я до сих пор не восстановил изначальный порядок.
2. Правила по любому типу устройств, если не ошибаюсь, выполняются в порядке "Отклонение по критерию"- "обновление устройства"- "добавление устройства" - "отклонение без критерия". Если добавление устройства будет выше, чем обновление, то одно и тоже устройство будет многократно дублироваться.
3. Правила можно включать, отключать и добавлять новые, но, обязательно, все изменения фиксировать(комментировать) и пять раз проработать в голове порядок проверки правил, иначе будут неожиданные результаты.
4. Кнопка "Сброс правил импорта" на несколько версий постарше у меня творила полную фигню, А также попытки экспортировать и импортировать правила. Из-за этого очень долго не мог восстановить последовательность.

Идем в проблемный компьютер и в разделе "Сведения об импорте" смотрим какие правила срабатывают при обновлении ПК. Например "Computer update (by serial)" - это значит что система при инвентаризации определяет устройство как ПК, у него существует серийный номер, и этот номер есть в базе = обновить параметры компьютера. У некоторых компов, даже с разными конфигурациями, может отсутсвовать или дублироваться уникальный показатель. Например вместо серийника может быть "To be filed by OEM". Два и более ПК с одинаковой уникальной записью, которая обработалась в правилах, будут дублироваться.
Поэтому надо чётко определить правило обновления с уникальным показателем или группой показателей. Например, если вы уверены, что имя ПК это уникальная запись, то можно такое правило обновления сделать выше остальных. У меня по имени не получится, т.к. организации в системе разные и имена могут дублироваться. Более менее уникальный - это мак адрес, но я ему не доверяю, т.к. в компе может быть много МАКов в том числе и программные и какой система будет учитывать несовсем понятно.

Если не совсем понятно объяснил, то скидывайте список правил со значением "computer..." и сведения об импорте проблемного ПК.
  Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)