glpi-agent
glpi-agent copied to clipboard
glpi-project
Switchports get deleted on netdiscovery
Bug reporting acknowledgment
Yes, I read it
Professional support
None
Describe the bug
The switch inventory was created via command line and then imported into glpi. On discovery run through the GUI all details for the switch get deleted. We have a total of 74 switches in our inventory but only one switch (Cisco SG350-10P) is affected by the problem.
To reproduce
- Import switch config via
Inventory>upload from file - Run scheduled inventory
- I can then reimport the xml and on next discovery run the switch details get deleted again
Expected behavior
Switch details should remain unchanged
Operating system
Linux
GLPI Agent version
Nightly build (git version in additional context below)
GLPI version
Other (See additional context below)
GLPIInventory plugin or FusionInventory for GLPI plugin version
Other (See additional context below)
Additional context
Nightly build v1.7-gitb7e81f7a but happened with all previous builds and 1.6 release as well. GLPI 10.0.11 but happened in previous build 10.0.10 and 10.0.9 as well. GLPIInventory plugin 1.3.4 but happened with previous build 1.3.3 as well
Hi @GuidoWilden
this seems to be a server-side problem.
@stonebuzz can you put your 2 cents on that issue ?
It's definitely the discovery task causing it. If I run only the inventory task and leave the discovery task out all is fine.
Hi @GuidoWilden
How inventory file is injected in GLPI? GUI ? glpi-agent? glpi-injector?
Sorry I don't think I understand. The output of the discovery looks like this. Is this what you meant?
glpi-netdiscovery --credentials version:3,username:v3user,authprotocol:sha,authpassword:'Password!',privprotocol:des,privpassword:'Password!'
[debug2] /etc/glpi-agent/toolbox.yaml configuration not found
[debug] initializing job 1
[debug] initializing block 10.26.129.236-10.26.129.236
[debug] Current netdiscovery run expiration timeout: few minutes
[debug] using 1 netdiscovery worker
[debug] starting job 1 with 1 ip to scan using 1 worker
[debug] #1, scanning 10.26.129.236
[debug] #1, full match for sysobjectID .1.3.6.1.4.1.9.6.1.95.10.5 in database
[debug] #1, sysobjectID match: cisco mib support enabled
[debug] #1, - scanning 10.26.129.236 with SNMP, credentials 1: success
[debug] #1, - scanning 10.26.129.236 with netbios: no result
[debug] #1, - scanning 10.26.129.236 with echo ping: success
[debug2] #1, executing arp -a 10.26.129.236
[debug] #1, - scanning 10.26.129.236 in arp table: success
<?xml version="1.0" encoding="UTF-8"?>
<REQUEST>
<CONTENT>
<DEVICE>
<AUTHSNMP>1</AUTHSNMP>
<DESCRIPTION>SG350-10P 10-Port Gigabit PoE Managed Switch</DESCRIPTION>
<DNSHOSTNAME>10.26.129.236</DNSHOSTNAME>
<FIRMWARE>2.5.0.92</FIRMWARE>
<IP>10.26.129.236</IP>
<IPS>
<IP>0.1.134.160</IP>
<IP>10.26.129.236</IP>
<IP>127.0.0.1</IP>
<IP>169.254.0.1</IP>
</IPS>
<MAC>54:86:bc:82:cb:f8</MAC>
<MANUFACTURER>Cisco</MANUFACTURER>
<MODEL>SG350-10P-K9</MODEL>
<SERIAL>PSZ23101EUW</SERIAL>
<SNMPHOSTNAME>LON-CO3-SW-P-BASEMENT-220-CL</SNMPHOSTNAME>
<TYPE>NETWORKING</TYPE>
<UPTIME>189 days, 05:16:23.00</UPTIME>
</DEVICE>
<MODULEVERSION>6.0</MODULEVERSION>
<PROCESSNUMBER>1</PROCESSNUMBER>
</CONTENT>
<DEVICEID>foo</DEVICEID>
<QUERY>NETDISCOVERY</QUERY>
</REQUEST>
[debug] #1, #1, worker termination
[debug] #1, Netdiscovery worker terminated
Honestly, it's going to be complicated for me to reproduce (I already don't have the problem on my network equipment).
On my side, I have to inject the XML file, which isn't really identical to what the plugin does (it changes the is_discovery flag to true from native inventory process)
On GLPI there is a protection to prevent a discovery to update an already inventoried equipment.
if ($this->is_discovery === true && !$this->isNew()) {
//if NetworkEquipment
//Or printer that has not changed its IP
//do not update to prevents discoveries to remove all ports, IPs and so on found with network inventory
if (
$itemtype == NetworkEquipment::getType()
||
(
$itemtype == Printer::getType()
&& !AssetPrinter::needToBeUpdatedFromDiscovery($this->item, $val)
)
) {
//only update autoupdatesystems_id, last_inventory_update, snmpcredentials_id
$input = $this->handleInput($val, $this->item);
$this->item->update(Sanitizer::sanitize(['id' => $input['id'],
'autoupdatesystems_id' => $input['autoupdatesystems_id'],
'last_inventory_update' => $input['last_inventory_update'],
'snmpcredentials_id' => $input['snmpcredentials_id'],
'is_dynamic' => true
]));
//add rule matched log
$rulesmatched = new RuleMatchedLog();
$inputrulelog = [
'date' => date('Y-m-d H:i:s'),
'rules_id' => $rules_id,
'items_id' => $items_id,
'itemtype' => $itemtype,
'agents_id' => $this->agent->fields['id'],
'method' => Request::NETDISCOVERY_TASK
];
$rulesmatched->add($inputrulelog, [], false);
$rulesmatched->cleanOlddata($items_id, $itemtype);
return;
}
}
precisely to avoid overwriting SNMP inventory data (with all NetworkPort) with discovery data (which carries very little information)
Can you reset rules (perhaps in a test environment to start with) and retry?
I will try this though I'm pretty certain that everything in the rules is default. I do not remember changing anything in there.
Hi @stonebuzz,
Unfortunately the problem is the same after resetting the rules.
after several injections (from discovery or SNMP inventory)
No network port deletion
Do you have SQL or PHP errors (glpi/files/_logs) at SNMP discovery time?
No nothing that appears to be triggered by the discovery task.
We regularly see these php errors on computer inventory. The software seems to struggle with our shared storage that is mounted on pretty much everything, but I always blamed the size (7 PB) for that. I might be wrong though.
[2023-12-18 15:35:49] glpisqllog.ERROR: DBmysql::doQuery() in /var/www/glpi/src/DBmysql.php line 403
*** MySQL query error:
SQL: INSERT INTO `glpi_items_disks` (`device`, `filesystems_id`, `totalsize`, `freesize`, `name`, `mountpoint`, `is_dynamic`, `items_id`, `itemtype` 'Computer', '1', '2023-12-18 15:35:46', '2023-12-18 15:35:46')
Error: Out of range value for column 'totalsize' at row 1
Backtrace :
src/DBmysql.php:1381 DBmysql->doQuery()
src/CommonDBTM.php:729 DBmysql->insert()
src/CommonDBTM.php:1342 CommonDBTM->addToDB()
src/Inventory/Asset/Volume.php:191 CommonDBTM->add()
src/Inventory/Asset/MainAsset.php:1001 Glpi\Inventory\Asset\Volume->handle()
src/Inventory/Asset/MainAsset.php:916 Glpi\Inventory\Asset\MainAsset->handleAssets()
src/RuleImportAsset.php:981 Glpi\Inventory\Asset\MainAsset->rulepassed()
src/Rule.php:1531 RuleImportAsset->executeActions()
src/RuleCollection.php:1660 Rule->process()
src/Inventory/Asset/MainAsset.php:582 RuleCollection->processAllRules()
src/Inventory/Inventory.php:724 Glpi\Inventory\Asset\MainAsset->handle()
src/Inventory/Inventory.php:355 Glpi\Inventory\Inventory->handleItem()
src/Inventory/Request.php:364 Glpi\Inventory\Inventory->doInventory()
src/Inventory/Request.php:90 Glpi\Inventory\Request->inventory()
src/Agent/Communication/AbstractRequest.php:359 Glpi\Inventory\Request->handleAction()
src/Agent/Communication/AbstractRequest.php:271 Glpi\Agent\Communication\AbstractRequest->handleJSONRequest()
front/inventory.php:95 Glpi\Agent\Communication\AbstractRequest->handleRequest()
...tplace/glpiinventory/front/communication.php:72 include_once()
marketplace/glpiinventory/index.php:45 include_once()
public/index.php:82 require()
{"user":"inventory@glpi01","mem_usage":"0.005\", 11.03Mio)"}
But we see nothing in either log during the discovery.
yes, it's because of disk space (I think it's the first time I've seen a concrete case with this value XD).
It's going to be difficult for me to help you with the discovery issue (as I don't reproduce on my side). and this seems to be a very specific case (as the rest of the discovery works)
You should consider taking a subscription to get professional support and a quick fix on this problem.
Best regards
We had the same Problem. We have now updated to GLPI 10.0.11 and GLPI-Agent 1.7.1 and now all our Cisco Switches show up with their Ports in GLPI again.
My problem unfortunately still exists. GLPI 10.0.11, GLPI-agent nightly build 1.8-git20db853b. Just tested GLPI-agent 1.7.1 and the problem still persists
Closing this one. I no longer have access to this installation since changing jobs.