librenms
Ubiquiti UniFi Gateway initial support
Initial support for Ubiquiti Gateways.
At the moment
After fix (starting with Unifi OS 4.1)
DO NOT DELETE THE UNDERLYING TEXT
Please note
Please read this information carefully. You can run
./lnms dev:checkto check your code before submitting.
- [ ] Have you followed our code guidelines?
- [ ] If my Pull Request does some changes/fixes/enhancements in the WebUI, I have inserted a screenshot of it.
- [ ] If my Pull Request makes discovery/polling/yaml changes, I have added/updated test data.
Testers
If you would like to test this pull request then please run: ./scripts/github-apply <pr_id>, i.e ./scripts/github-apply 5926
After you are done testing, you can remove the changes with ./scripts/github-remove. If there are schema changes, you can ask on discord how to revert.
I looked this over, it should just be part of the regular "unifi" os IMO
Technically you are right, UniFi switches and UniFi Gateways both part of UniFi ecosystem, but they have different SNMP implementation under the hood. Unifi switches have custom MIBs and designated sysObjectID OID, whilst UniFI gateways don't and support only standard MIBs. I'm not against joining them together per se, I just not sure how save to do this.
Does this warrant a new OS or could it share with existing unifi stuff ?
@Jellyfrog Sorry, missed the comment. It's different SNMP implementation/adoption. To be more specific, new support is for everything that is here (Cloud gateways): https://store.ui.com/us/en?category=all-unifi-cloud-gateways
And all the gateways from here: https://store.ui.com/us/en?category=all-cloud-keys-gateways
the yaml detection supports multiple entries. Just add the detection for the gateway in a new - if it doesn't share with the other detections.
the yaml detection supports multiple entries. Just add the detection for the gateway in a new
-if it doesn't share with the other detections.
@murrant Sorry, I'm not fully following you! Maybe you can reference an existing example?
I'm looking at the saf-interga-b and saf-integra-w, they have separate definitions.
Maybe unifios not that great of a name, should be something like ubiquiti-unifi-gw.
Also unifi has a type of wireless.
the yaml detection supports multiple entries. Just add the detection for the gateway in a new
-if it doesn't share with the other detections.
Are you still suggesting adding a new section to discovery in the existing includes/definitions/unifi.yaml file? If so, how do we make these devices to show under the "network" section and not the "wireless" section?
I do think that unifi-gw would be a clearer name for the distinction between this and unifi access points.
OS is defined by the software OS, not the hardware. How many different kinds of devices run Cisco IOS?
@murrant
How many different kinds of devices run Cisco IOS?
I don't know, never worked with CISCO or for CISCO. How many?
OS is defined by the software OS, not the hardware.
Most of the products here have the same OS here - Linux and yet so many files.
Never addressed this: https://github.com/librenms/librenms/pull/16524#issuecomment-2418515146
Is this more like IOS vs IOS-XE vs IOS-XR? Different OSes by the same company. I think this is what @romansj1 is trying to say above by commenting that the MIB support is different on UnifiOS vs the Unifi AP firmware.
I had a look at the unifi download page (https://ui.com/download/releases/firmware) and it looks like they may be different.
@murrant
How many different kinds of devices run Cisco IOS?
I don't know, never worked with CISCO or for CISCO. How many?
OS is defined by the software OS, not the hardware.
Most of the products here have the same OS here - Linux and yet so many files.
Never addressed this: #16524 (comment)
The point about OS is that we don't want to define a new OS in LibreNMS if a manufacturer uses a common OS between different devices. Mikrotik RotuerOS is a good example where a ceiling access points, routers and switches all run the same OS. So another OS definition isn't the correct solution if UnifiOS is just another variant of the AP software.
To address your question about the different SAF OSes, I think the main thing to note is that just because there is something in the code it doesn't mean it is the current correct way of doing it. I have personally submitted a number of PRs that I have had to re-write because I modelled it from old code that is no longer the correct way we want to implement new code. The SAF definitions that you have pointed out were added in 2017, so it is very possible that they would not be accepted today assuming they are all the same OS.
@eskyuu Yes, thank you! Technically yes, they all are UniFi OS products, but this only means that can be adopted to UniFi ecosystem, which is run on a cloudkey, or selfhosted on PC or as a "cloud". In reality Unifi AP, Unifi Switch and Unifi Gateway (+ cloud gateway keys) have different build environment. "Unifi Switch" supports proprietary MIBs, whilst "Unifi Gateway" doesn't.
It would be nice to combine them, I just don't see how you can tell in yaml:
"If this regex then this is the 'type', use this set of MIBs, if this OID then this 'type' and only STD MIBs are supported".
Also, I do not see that RotuerOS overrides type anywhere.
The fact that it can be managed by a unifi controller is irrelevant. EdgeOS and AiroOS devices can also be managed by the Unifi network server, but these have different OS definitions in LibreNMS. I've had a quick look at the unifi yaml file, and it currently only detects UAP products.
I think the point to be determined here is whether the UAP firmware, UnifiOS and USW OS code bases are different OSes, or just a variant of the same OS. I am interested to hear if my comments above have changed the view of @murrant
Mostly it is MIBs + actual branded OS.
Also, try to prevent the OS count from going into the stratosphere. Having 3 OS that support the same thing likely means those 3 have lower feature sets than they could and also things need to be fixed x3 instead of once.
Just add your detection to unifi os and we should be good to merge it. Thanks.
If the main goal is to get the device classified as a "Network" device, and to use the ubiquiti icon, is it acceptable for the discovery be added to the edgeos definition since they are still both ubiquiti products?
Actually... @romansj1 The Unifi gateway OS does implement the UBNT-UniFi-MIB which is the same as the existing unifi OS. This is where the Operating system and Hardware fields are populated from, and this is why it belongs in the unifi.yaml file.
What are everyone's thoughts on https://github.com/librenms/librenms/pull/16674
It allows the OS type to be set within each discovery condition, removing the assumption that an OS defines the type of device. It also adds the discovery for the UnifiOS devices into the unifi.yaml file, but setting the type to "network" instead of "wireless".
@eskyuu
If the main goal is to get the device classified as a "Network" device, and to use the ubiquiti icon, is it acceptable for the discovery be added to the edgeos definition since they are still both ubiquiti products?
Sorry I don't see how it is better the having multiple yaml targets. It will be quite a surprise for next guy to find UniFi device in the legacy OS section.
Actually... @romansj1 The Unifi gateway OS does implement the UBNT-UniFi-MIB which is the same as the existing unifi OS.
No it doesn't. ATM UniFi Gateway devices do not support any proprietary MIB.
What are everyone's thoughts on https://github.com/librenms/librenms/pull/16674
If it works, it's fine by me! I can test it if you want?
Sorry I don't see how it is better the having multiple yaml targets. It will be quite a surprise for next guy to find UniFi device in the legacy OS section.
No it doesn't. ATM UniFi Gateway devices do not support any proprietary MIB.
The issue we are avoiding is having to implement the same OIDs in multiple operating system definitions in LibreNMS.
The "Hardware" and "Operating system" fields shown in your screenshot above come from OIDS in the UBNT-UniFi-MIB file, which is the same proprietary MIB as the existing wireless unifi OS. This is why there is a preference to keep them together in the unifi yaml file.
What are everyone's thoughts on #16674
If it works, it's fine by me! I can test it if you want?
Yes, can you please test 16674 and confirm that the device detects correctly.
@eskyuu Bad news,
I think the issue is with the Unifi Switch proprietary MIB.
Thanks for testing. It looks like my comments about are wrong about how the OS and version were detected. I can see now that they are defined in the includes/definitions/discovery/unifi-gw.yaml file.
@murrant What do we do now? Adding an additional definition to the unifi.yaml file doesn't work because Unifi gateway OS does not implement any of the custom OIDS that are defined by the Unifi AP OS.
Again Unifi is very often corner casing us due to their poor SNMP implementations.
OS does not implement any of the custom OIDS that are defined by the Unifi AP OS.
This doesn't matter. Discovery will check for their existence and not poll them. Most of our OS define more OIDs than the exist in devices (if not all).
I've update https://github.com/librenms/librenms/pull/16674 again.
@murrant Can you please confirm that this is the appropriate way to detect info for these new UnifiOS devices?
@romansj1 Can you please test this PR again and see if it detects the device info correctly?
@eskyuu This is how the UI looks with the original patch:
This is with the yours latest PR
Main menu looks OK, but interfaces aren't recognized properly! CPU and memory also missing!
@murrant Can you also please advise how to define different graphs for UnifiOS devices, because the unifi.yaml file is configured to show wireless statistics from the Unifi AP OS.
Not possible, but you could expand your type work @eskyuu
I had a look at this, but am having trouble coming up with a clean solution. My issue is as follows:
- I believe that I need to use a database field to look up something new in the includes/definitions/os.yaml file. This is where the "over:" field is stored, and also where the different discovery configs are stored.
- The only database fields set based on data in the includes/definitions/os.yaml file are OS and type. OS is used later on to load the same YAML file (so it can't vary), and the user can manually override the type of a device so it doesn't make sense to vary the graphs based on this field.
- There are other fields (version, hardware, features and serial) that are set in the discovery yaml file or discoverOS() function. Of these, the features field looks like the most likely place to store an identifier to toggle different graphs. As a side question - is there a preference to implement discovery in the yaml file, or OS specific PHP file? I'm asking because the only way I can see to implement this feature would be in the PHP file.
The best solutions I can think of are:
- A new database field that stores the OS sub-type. This could be used to override many of the OS level fields as needed.
- Use the "features" field, which looks like it's the most suitable, but add a third location where this can be set (and have a reference to the field in the includes/definitions/os.yaml file.
- Use the "features" field and move where it's discovered into the includes/definitions/os.yaml file
- Use the generic OS for unifiOS devices, but set the icon and type to unifi and network.
I need help understanding whether there is a preference for more DB fields, or expanding the scope of where the features field is defined.
I imagined a device attribute to override the overview graphs. (which would also allow manual editing per-device)