search

openbmc / service-config-manager

Other
2 stars 4 forks source link

No way to disable IPMI net service by default but allow it to be re-enabled #6

Open geissonator opened 2 years ago

geissonator commented 2 years ago

We (IBM) recently wanted to disable network IPMI by default on our systems. But, we wanted the ability via Redfish->bmcweb->service-config-manager to allow our users to enable it if they so wish.

We disabled network IPMI by setting SYSTEMD_AUTOENABLE:${PN} to disable in a phosphor-ipmi-net%.bbappend meta-ibm override. This worked in that the phosphor-ipmi-net@ethX.service and .socket instance services were not installed in the multi-user.target and so network IPMI was disabled by default.

The main issue here is that the service-config-manager, on a fresh boot of a system, requires the systemd units to be present per a query to systemd. They were not present when we disabled IPMI by default, so there was no way to use the service-config-manager to enable them.

We're looking at a workaround where we leave network IPMI enabled by default, but have a service that runs only on the first boot of a fresh system, and automatically disables it (after service-confiog-manager has started and seen the units). Once service-config-manager sees the units, and write out it's /etc/srvcfg-mgr.json file, all is good with being able to re-enable network IPMI after a BMC reboots and such.

This may be more of a feature request. Is there a way we could have service-config-manager work in this scenario? Maybe a parameter we could pass on start to input some units it should always look for? Or a way to say statically always support some specific interfaces?

williamspatrick commented 2 years ago

I'm pretty sure you could add a Requires on a service that checks service-config-manager's answer. Make that a template service. (lots of hand waving here, I know)

geissonator commented 2 years ago

I'm usually pretty good at interpreting your hand wave ideas but I'm not processing this one :)

williamspatrick commented 2 years ago

I was thinking of the ConditionPathExists statements.

Service A : Query service-config-manager for enable state and create a /run file. Service B : Requires/Before A + ConditionPathExists IPMI-net: Requires B

If B fails due to ConditionPathExists, then IPMI-net won't start.

Alternatively, maybe it is simpler to just have IPMI-net call service-config-manager on startup to determine if it should actually bind to the port? ie. starts up and does nothing in the case it is disabled, except listen for the enable state to change?

geissonator commented 2 years ago

I see. The nice thing about service-config-manager right now is that it's basically just utilizing systemctl enable/disable/mask type commands, so there's no real dependencies between it and the services it controls. I'd prefer we keep that if possible, but if not, yeah we may need something along the lines of what you describe.

williamspatrick commented 2 years ago

The nice thing about service-config-manager right now is that it's basically just utilizing systemctl enable/disable/mask type commands, so there's no real dependencies between it and the services it controls.

It already holds a property for the enable/disable state, right? We could also have it supply a simple program that pass/fails based on the enable/disable state. It's probably just a single busctl call and a grep. This wouldn't add any dependencies on service-config-manager itself.

geissonator commented 2 years ago

IBM's solution (workaround?) to this problem is over at https://gerrit.openbmc.org/c/openbmc/openbmc/+/54680