Skip to content

Add snmp_init_mib function to allow MIB tree to be reset using environment variables#21452

Draft
eskyuu wants to merge 2 commits intophp:masterfrom
eskyuu:snmp-init-mib
Draft

Add snmp_init_mib function to allow MIB tree to be reset using environment variables#21452
eskyuu wants to merge 2 commits intophp:masterfrom
eskyuu:snmp-init-mib

Conversation

@eskyuu
Copy link

@eskyuu eskyuu commented Mar 15, 2026

I have been trying to use the PHP SNMP extension in LibreNMS to replace calls to external snmp* programs. One issue I have come across is that there is no way to clear the MIB tree in the PHP SNMP extension. It becomes even worse with PHP-FPM where the MIB tree is persistent across different requests.

The above causes issues when a script wants to do multiple SNMP queries against incompatible MIBs because there is currently no way to clear the MIB tree and start again.

This PR add a new snmp_init_mib() function that frees up the existing MIB tree and then calls init_mib(), which will:

  • Set the MIB directories according to the MIBDIRS environment variable
  • Load MIBs according to the MIBS environment variable (plus any IMPORTs)
  • Load MIB files according to the MIBFILES variable

I have chosen to only expose the one function above because the other functions like shutdown_mib(), init_mib_internals() netsnmp_read_module() require understanding how the net-snmp internals work to ensure everything is initialised properly. The proposed function can be used to clear the MIB tree back to the default state if the environment variables are not changed, or to reset to a known state if the environment variables are updated.

It's marked as draft until I have tested that it works.

@eskyuu
Copy link
Author

eskyuu commented Mar 16, 2026

I would also like to add function to do the following:

  • Set the mibAllowUnderline flag globally
  • Set the extendedIndex flag on the session
  • Set the dontPrintUnits flag on the session
  • Set the numericTimeticks flag on the session

The above can be set as flags, but the documentation says to set them before calling init_snmp(). I'm happy to run some tests to see if they can be changed safely, but am wondering if the above should be another PR.

I did also think that another option would be to call read_premib_configs() in the snmp_init_mib() function, which would allow the SNMPCONFPATH environment variable to be set to point to an explicit snmp config file, where any combination of client config options can be set. I would suggest a separate function to read the config, but I think it's tied in with the MIB tree initialisation.

The option that I thought about would be to defer the initialisation of the snmp library until the first use, in which case the environment variables above can be set early on in a program to control the library config. I would be happy to pivot to this if it's considered the cleanest/best way to achieve the desired outcome.

@devnexen
Copy link
Member

I would also like to add function to do the following:

  • Set the mibAllowUnderline flag globally
  • Set the extendedIndex flag on the session
  • Set the dontPrintUnits flag on the session
  • Set the numericTimeticks flag on the session

The above can be set as flags, but the documentation says to set them before calling init_snmp(). I'm happy to run some tests to see if they can be changed safely, but am wondering if the above should be another PR.

I did also think that another option would be to call read_premib_configs() in the snmp_init_mib() function, which would allow the SNMPCONFPATH environment variable to be set to point to an explicit snmp config file, where any combination of client config options can be set. I would suggest a separate function to read the config, but I think it's tied in with the MIB tree initialisation.

The option that I thought about would be to defer the initialisation of the snmp library until the first use, in which case the environment variables above can be set early on in a program to control the library config. I would be happy to pivot to this if it's considered the cleanest/best way to achieve the desired outcome.

even more reasons to write a RFC IMHO :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants