MAAS should not require an IPMI Administrator user to commission/deploy a node

Bug #1889788 reported by Victor Tapia on 2020-07-31
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Lee Trager
Lee Trager
Lee Trager

Bug Description

According to the spec[1], for IPMI users is enough to have the Operator privilege level to handle the power and device boot order of a node. Downgrading the privilege level of the maas IPMI user from Administrator to Operator in an HP iLO4 makes the power on process, for both commissioning and deploying, fail in MAAS with the following error:

/usr/sbin/ipmi-config: privilege level cannot be obtained for this user

This issue appears because ipmi-chassis-config tries to run with an Administrator privilege level by default. Adding the '-l OPERATOR' parameter to the command line seems to fix this issue.

Also, the privilege level (Lan_Privilege_Limit) for the maas IPMI user is set to Administrator when it's created/updated. Is there a reason for that? For iLO4, setting the privilege level to Operator and the ipmi-chassis-config parameter makes the deployment work fine with the limited privilege level.


Related branches

Lee Trager (ltrager) on 2020-07-31
Changed in maas:
status: New → In Progress
importance: Undecided → High
assignee: nobody → Lee Trager (ltrager)
Lee Trager (ltrager) wrote :

The ipmipower command uses OPERATOR by default while both ipmi-chassis-config and ipmitool use ADMIN by default. I've updated MAAS to always interact with IPMI BMC's using the OPERATOR level. For basic IPMI machines MAAS only uses the ipmipower command so most users won't be effected by this change. This does change the privilege level for both HP Moonshot/iLo and Seamicro users. We don't have either chassis in our CI so I can't test if this change works or breaks anything. Please test the attached branch and let me know if it solves this bug.

I'm not sure of the exact reason the MAAS IPMI user is created as admin. The code was written before I joined and there aren't comments explaining why. I will say from personal experience I've found it useful in debugging issues both in the MAAS CI and in the field. I can use the MAAS created IPMI user to access the console over IPMI and log into the BMC's web console to change BIOS settings.

I think we should discuss changing the privilege level separately.

tags: added: sts
Changed in maas:
milestone: none → next
status: In Progress → Fix Committed
Lee Trager (ltrager) wrote :

I've backported this to 2.7 and 2.8. Please let me know if 2.4(bionic-updates) or 2.3(xenial-updates) need this as well.

Changed in maas:
milestone: next → 2.9.0b1
Victor Tapia (vtapia) wrote :

Thanks for the patch Lee, and sorry for the late reply. I tried to find moonshot and seamicro machines without success, but according to the moonshot documentation[1], both booting and setting the boot device should be achievable by operator users (haven't found anything about seamicro, but the company/brand died in 2015). I confirmed that 2.7 and 2.8 work fine with HP iLOs from different generations.

I'll open a different bug to discuss the creation of the maas user as an operator instead of an admin. Regarding backports, 2.4 and 2.3 are not needed unless the privilege level on user creation is changed for those releases.


Lee Trager (ltrager) on 2020-09-08
Changed in maas:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers