Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switchports get deleted on netdiscovery #559

Closed
GuidoWilden opened this issue Dec 18, 2023 · 16 comments
Closed

Switchports get deleted on netdiscovery #559

GuidoWilden opened this issue Dec 18, 2023 · 16 comments
Labels
bug Something isn't working

Comments

@GuidoWilden
Copy link

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

  1. Import switch config via Inventory > upload from file
  2. Run scheduled inventory
  3. I can then reimport the xml and on next discovery run the switch details get deleted again
    Capture

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

@GuidoWilden GuidoWilden added the bug Something isn't working label Dec 18, 2023
@GuidoWilden
Copy link
Author

Switch inventory attached
cisco_mer.xml.zip

@g-bougard
Copy link
Member

Hi @GuidoWilden

this seems to be a server-side problem.

@stonebuzz can you put your 2 cents on that issue ?

@GuidoWilden
Copy link
Author

It's definitely the discovery task causing it. If I run only the inventory task and leave the discovery task out all is fine.

@stonebuzz
Copy link

Hi @GuidoWilden

How inventory file is injected in GLPI? GUI ? glpi-agent? glpi-injector?

@GuidoWilden
Copy link
Author

The xml is imported via the GUI

Capture

@stonebuzz
Copy link

idem for discovery file ?

@GuidoWilden
Copy link
Author

GuidoWilden commented Dec 18, 2023

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

@stonebuzz
Copy link

stonebuzz commented Dec 18, 2023

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?

image

@GuidoWilden
Copy link
Author

I will try this though I'm pretty certain that everything in the rules is default. I do not remember changing anything in there.

@GuidoWilden
Copy link
Author

Hi @stonebuzz,

Unfortunately the problem is the same after resetting the rules.

@stonebuzz
Copy link

after several injections (from discovery or SNMP inventory)

image

No network port deletion

image

Do you have SQL or PHP errors (glpi/files/_logs) at SNMP discovery time?

@GuidoWilden
Copy link
Author

GuidoWilden commented Dec 18, 2023

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.

@stonebuzz
Copy link

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

@air8orne
Copy link

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.

@GuidoWilden
Copy link
Author

GuidoWilden commented Jan 12, 2024

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

@GuidoWilden
Copy link
Author

Closing this one. I no longer have access to this installation since changing jobs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants