I'm walking through installing smokeping, and running into some minor issues in the docs.
Basically:
1. Smokeping is a `fastcgi` application, and the config in the docs assumes that you have a fastcgi handler installed (`fastcgi_pass unix:/var/run/fcgiwrap.socket;`). I did not, and you get confusing errors.
2. I'm still not sure where the smokeping stuff is supposed to show up in the UI.
* add mibs,first commit
* adds support for Nokia ISAM Plattform
* remove some comments
* change os polling to multi oid
* Restore file headers
* Fix discovery by sysObjectID
* first deactivate checks against IHUB (timos), It not necessary so long we can not provide more thatn one snmp community per device
* move snmp state and temperature from pre-cache
* Update os_schema.json
* Change in the Canopsis transport to make it 3.9.0 compliant and link to
the new documentation
* Add missing php72 module on Centos
* Fixing documentation for AMQP based tranport outside of the main doc
* EDS support
* EDS support
* EDS support
* EDS support
* EDS support (tests)
* EDS support
* EDS support
* Adding DS18B20 sensors
* Adding DS18B20 sensors
* read tables separatly in precache instead
* Update Applications.md
Added the directions for installing the Nagios check check_postgres.pl for the Postgres Application.
* Update Applications.md
Remove git building instructions and simply adding a link to https://github.com/bucardo/check_postgres.
* Restore gitignore file contents
Set permissions to 664
Add tests to check existence, mode, and size of .gitignore files
* add trailing line return
* git only cares about executable bit, just check that.
* define gitignores separately
* add migrate:install to lnms, but hide it
* Fix Database migration validation
* remove extra import
* Don't allow install to continue if db build fails
PR #9546 has resulted in Platform being detected as
"Juniper Virtual Chassis Switch" when a set of devices
is stacked. Hence, no more possibility to see whether
it is for example an EX2300 or EX3400 virtual-chassis.
This commit falls back to using rewrite_junos_hardware()
if the "Juniper Virtual Chassis Switch" string is detected
in boxDescr, resulting in usable hardware data.
Caveat - it's possible to build a virtual-chassis of
multiple switch models, but only for higher end hardware:
https://www.juniper.net/documentation/en_US/junos/topics/concept/virtual-chassis-ex4200-overview.html#jd0e75
Example SNMP output:
mschmidt@nlrtm1-librenms1:~$ snmpwalk -v2c -cremoved -m JUNIPER-MIB -M /opt/librenms/mibs hostname jnxBoxDescr
JUNIPER-MIB::jnxBoxDescr.0 = STRING: Juniper Virtual Chassis Switch
Also reported previously via the community forums:
https://community.librenms.org/t/pr-9546-results-in-junos-platform-detection-quirks-in-combination-with-virtual-chassis/6537
* update some mibs
* extend snmpwalk_cache_twopart_oid function
* add raisecom dbm and temperature sensors
* add test data
* add some more sensors
* Update raisecom.inc.php
* Update raisecom.inc.php
