Commissioning changes password in MAAS but not on node

Hi,

can you get us the output of the following command:

maas $ADMIN node-script-result download $SYSTEM_ID current-commissioning

Here you go....

Could you please confirm that calling `bmc-config --commit --key-pair=User3:Password=<somepassword>` actually sets the password for the BMC?
I.e. it doesn't just succeed, but the password is actually updated.

Alberto, I've tried that on the machine in question (hoggus), and the `bmc-config --commit --key-pair=User3:Password=<somepassword>` command SEEMS to succeed (it produces no error message and has a return value of 0), but the password is NOT changed; the old password remains valid.

This looks like a possible bug in bmc-config (from freeipmi-tools), or an issue with the specific hardware (which might be require a specific workaround or extra config option).

@ack the machine is configured for Redfish, should MAAS even be trying to change a user account for machines configured by Redfish? (I thought that password change was only for a MAAS IPMI user account, and if it's not configured to use IPMI why is it even running that code?)

MAAS is trying to configure IPMI because it's failing to detect the Redfish interface:

  INFO: Checking for HP Moonshot...
  INFO: Checking for Redfish...
  ERROR: Redfish configuration failed. Missing SMBIOS data
  INFO: Checking for IPMI...
  INFO: IPMI detected!
  INFO: Reading current IPMI BMC values...

If we look at the output of 'dmidecode -t 42', it's in fact missing the info we expect:

  Handle 0x0024, DMI type 42, 12 bytes
  Management Controller Host Interface

We expect something like:

  Handle 0x00D0, DMI type 42, 169 bytes
  Management Controller Host Interface
    Host Interface Type: Network
    (...)
    idVendor: 0x04b3
    idProduct: 0x4010
    Protocol ID: 04 (Redfish over IP)
        Service UUID: a4b13f22-d0f3-11ea-aca9-e5b8d327f39f
        (...)

I'm not sure that we can work-around this. Commissioning scripts run in an untrusted environment, so they cannot fetch any host-specific data from MAAS to make up for the missing data, and without it the Redfish setup should fail and the script should attempt to configure IPMI (which kind of succeeded).

As an improvement we can explore the viability of MAAS telling the commissioning scripts about the expected power method, so the script can fail immediately instead of using any fallback.

What about having MAAS do this:

chage_password(old_pw, new_pw)
if !test_password(new_pw)
  if test_password(old_pw)
    revert_to_old_password(old_pw)

This should cause MAAS to ignore any password change that doesn't succeed, no matter what the cause of the failure.

MAAS fails to detect Redfish, and proceeds to configure IPMI. We see that the command to set the password succeeds without an error, however: which password is then left unchanged - the Redfish one (expected) or the IPMI one (unexpected)? Could you please clarify how you conclude that the password is unchanged?

MAAS changes the password it believes the node to have, but the change on the node itself was unsuccessful. For instance:

1) Node is already commissioned, with a known password for both web & Redfish access. (IPMI access has never worked on this node.)
2) Re-commission the node in MAAS. This seems to succeed; but....
3) MAAS shows "power error" and cannot control the node.
4) It's possible to log into the BMC's web UI using the old password.
5) Changing the password to the old password in the MAAS web UI clears the "power error" and enables MAAS to control the node once again.

It's been long enough since we enlisted this node that I don't recall what happened during enlistment.