discover_system_properties fails if connecintg account does not have full/admin privileges

[UserXYZ]

Hi all,
I am trying to use this very useful script on some Supermicro servers that are part of Rubrik storage/data protection solution, and I can not get it to work due to restricted account I have.
Initially I have tried to login as read-only account to IPMI and Redfish but I kept getting errors about not being able to read a lot of API endpoints/branches using Redfsih connection.
To try and diagnose, I elevated the privileges to 'operator' but it's still (almost) the same situation.

When I run check_redfish.py to get any data, it immediatelly fails with the error in discover_system_properties function from classes/redfish.py class:

Traceback (most recent call last):
  File "/home/userx/check_redfish/./check_redfish.py", line 152, in <module>
    plugin.rf.discover_system_properties()
  File "/home/userx/check_redfish/cr_module/classes/redfish.py", line 588, in discover_system_properties
    for entity in rf_path.get("Members"):
TypeError: 'NoneType' object is not iterable

This happens because the function defines root objects as ["Chassis", "Managers", "Systems"], and then it tries to read them in a for loop in order to get "Members" for each.

But, in my case, when trying to read "Managers", I get an error from the server related to access privileges:

{
    "error": {
        "code": "Base.v1_10_3.GeneralError",
        "Message": "A general error has occurred. See ExtendedInfo for more information.",
        "@Message.ExtendedInfo": [
            {
                "MessageId": "Base.1.10.InsufficientPrivilege",
                "Severity": "Critical",
...
}

because I can not read "Managers" object directly, unlike "Chassis" and "Systems".

On the other hand, if I hit "Managers/1" then everything works just fine.

Thus I have made a simple workaround and would be pleased if it was accepted or even replaced with something better:

        # this fails on Rubrik Supermicro if admin account is not used, possibly on others as well
        # root_objects = ["Chassis", "Managers", "Systems"]
        # thus we attempt to use root_object/1

            if "Members" not in rf_path:
                root_object = root_object + "/1"
                continue

I can make a diff if this simple solution is good enough and make a pull request etc, but since the change is so small, if it's good then it can be incorporated with the next bug fix.

Thanks.
Andrea

[bb-Ricardo]

Hi Andrea,

Thank you for pointing this out as I never came across this issue.

Looking at this, it appears to me as a insufficient/wrongly implemented permission model. If you can't access /redfish/v1/Managers then you definitely shouldn't be able to access /redfish/v1/Managers/1.

The plugin does a discovery based on the returned values. So it request each path and continues with the reaults returned by the request. The 1 for Managers is an arbitrary value which changes from vendor to vendor. If this would be implemented this way, then it would be an assumption which would work in some cases but fail in a lot of other cases.

I assume you have a paid support contract with Supermicro. In order to get this fixed I would suggest to contact them and raise an issue.

Either way, it's a Software bug within their BMC firmware implementation which should be fixed.

But there is also a bug in the plugin which doesn't take into account that only an error will be returned when requesting the /redfish/v1/Managers/ path.

Will fix this in the next release.

[UserXYZ]

HI Ricardo, thank you for speedy answer...indeed, I assumed that xxx/1 won't always be a case and that the issue comes from lack of proper permissions or weird Redfish implementation on these Supermicro servers.

I did not see any other implementation that did not use .../1 for that initial sub-level below some root object, if it's used at all (we have bunch of Dells of various age, and also relatively new HPEs, all with various Redfish versions), which is why my quick fix was to just add /1 if reading root object path directly fails.

Unfortunatelly, I don't have relationship with Supermicro per-se...I'm working on adding some monitoring for my company for cluster of Supermicro servers that are 'bundled' by Rubrik as a backup/security solution, so I can only ask Rubrik to ask Supermicro to fix their firmware, or I can try to create a ticket to Supermicro directly, which might not go anywhere in space&time... :-)

Anyway, thank's for looking into it and having it fixed in the next release, as much as you can - I guess the rest will be up to Supermicro.

Cheers, Andrea