feat: add apcupsd

[Eelviny]

Add the apcupsd package to ucore to allow bare metal servers to manage connected APC UPSes and gracefully shutdown when power runs low.

Also in a separate commit I sorted all packages alphabetically to tidy things up.

[Eelviny]

Need opinions on whether this is too opinionated for ucore. Thoughts welcome.

I personally think this is classed as a hardware enablement feature.

[dylanmtaylor]

Need opinions on whether this is too opinionated for ucore. Thoughts welcome.

I personally think this is classed as a hardware enablement feature.

I love it. I didn't realize we don't have this.

[dylanmtaylor]

@bsherman this is a really good idea for bare metal servers.

[Eelviny]

I've also been thinking about UPSs that aren't manufactured by APC but honestly it's a bit of a mess. I've used Network UPS Tools https://networkupstools.org before but it's a much heavier tool, instead more designed for networks of multiple machines and UPSs. IMO if someone is going down that rabbithole, they're probably better off baking their own images.

apcupsd on the other hand is simple and just hooks into any directly connected APC UPS. Generally though APC and Eaton brands are the main 2 that have proper vendor support for Linux, so maybe I'll take a look into Eaton support also

[dylanmtaylor]

I've also been thinking about UPSs that aren't manufactured by APC but honestly it's a bit of a mess. I've used Network UPS Tools https://networkupstools.org before but it's a much heavier tool, instead more designed for networks of multiple machines and UPSs. IMO if someone is going down that rabbithole, they're probably better off baking their own images.

apcupsd on the other hand is simple and just hooks into any directly connected APC UPS. Generally though APC and Eaton brands are the main 2 that have proper vendor support for Linux, so maybe I'll take a look into Eaton support also

I think apcupsd also works with CyberPower brand UPS

[bsherman]

Need opinions on whether this is too opinionated for ucore. Thoughts welcome.

I personally think this is classed as a hardware enablement feature.

I agree, this is clearly hardware enablement, but I also think it could be too opinionated.

I like to push back and see if things like this can be done in containers instead.

I'm not suggesting existing implementations are perfect, but there are examples of UPS software being run in docker:

• https://github.com/gersilex/apcupsd-docker
• https://github.com/gpdm/nut

If there's no GOOD solution, maybe that's something the ucore community could build? some good container images for UPS management?

[dylanmtaylor]

Need opinions on whether this is too opinionated for ucore. Thoughts welcome.
I personally think this is classed as a hardware enablement feature.

I agree, this is clearly hardware enablement, but I also think it could be too opinionated.

I like to push back and see if things like this can be done in containers instead.

I'm not suggesting existing implementations are perfect, but there are examples of UPS software being run in docker:

• https://github.com/gersilex/apcupsd-docker
• https://github.com/gpdm/nut

If there's no GOOD solution, maybe that's something the ucore community could build? some good container images for UPS management?

Setting up a container for hardware enablement is cumbersome, and if the docker container isn't running and power is lost, now the system will not seamlessly shut down.

[dylanmtaylor]

Honestly, I consider proper power failover and safe shutdown of bare-metal machines to be mission-critical, so wouldn't want to risk it with a container solution.

One would still need to run sudo systemctl enable --now apcupsd to activate the unit.

[m2Giles]

Is there a reason why this couldn't just be a quadlet?

[dylanmtaylor]

Is there a reason why this couldn't just be a quadlet?

What's a quadlet?

[bsherman]

Is there a reason why this couldn't just be a quadlet?

What's a quadlet?

https://docs.podman.io/en/latest/markdown/podman-systemd.unit.5.html

[Eelviny]

My take on this - the actions of apcupsd don't fit the container model, as it is a requirement to break out of the container simply by the fact that it needs to shutdown the host. While it may be certainly possible to give a container privileges to shutdown the host, I don't think it is a good idea to encourage that model - containers should be contained.

I'm very happy to have some debate on this point :)

If there's no GOOD solution, maybe that's something the ucore community could build? some good container images for UPS management?

I think a fully thought-out UPS management solution for ucore would be awesome, and it's not something I've seen around in other server builds. But before committing to something like that we'd need to see what kind of uptake/adoption we see, so adding this in would be a nice way to start it off and see how it goes.

[m2Giles]

My take on this - the actions of apcupsd don't fit the container model, as it is a requirement to break out of the container simply by the fact that it needs to shutdown the host. While it may be certainly possible to give a container privileges to shutdown the host, I don't think it is a good idea to encourage that model - containers should be contained.

I'm very happy to have some debate on this point :)

The main pushback you are getting is more due to the fact that things added as part of the build process cannot be easily removed. Layering and/or composing FROM ucore is a valid strategy for adding things like an additional package. One of the things you can do with your ignition file is to run an rpm-ostree install as part of the first boot if composing a package is not needed/necessary. My pushback about thinking that it should not be on the host is that containers provide a wealth of flexibility. Poking holes at the sandbox is a way to solve problems at hand and not compromise the entirety of the system.

You mention interaction via passing a serial device but that isn't any different from passing other hardware resources in my mind. I personally don't use the HCI images because virtualization and passthrough of hardware devices is quite possible inside of a container.