[Nut-upsuser] Slave only configuration

Charles Lepple
Thu, 29 Aug 2013 03:26:33 -0000

On Aug 28, 2013, at 8:03 PM, John Thurston wrote:

> It appears that, without munging the startup scripts, it isn't possible
to create a slave-only configuration.
>
> The scenario is this:
> My NUT server doesn't need to turn off, it isn't allowed to turn
the UPS off, and it isn't authoritative to turn any other server off. Its
only job is to make UPS status available to NUT clients.
>
> My NUT clients are independent of the NUT server. Each is its own business
case and will independently decide if the shutdown criteria has been met.
>
> The questions are:
> Why am I required to run upsmon on the NUT server?
>
> Is there a way to achieve this configuration without munging the startup
scripts?

The short answer is no, not currently.

If I understand correctly, you just want to run upsd and the driver on the NUT
server. Adding something like "upsdrvctl start && upsd" to the
equivalent of rc.local should work, although this could get messy with newer
distributions that use things like systemd, if rc.local doesn't implicitly
depend on networking. (I don't know what CentOS or SUSE use for their init
process.) If your distributions are reading nut.conf, you would probably need
"MODE=none" to prevent extra copies of upsd, the driver and upsmon.

Creating a dummy upsmon.conf that can't log status or shut down the server
is also a possibility.

It's certainly possible for us to add an option like
"MODE=netdriver" to nut.conf. ("slave only" has a bit of a
namespace collision with the description for MODE=netclient, since that client
logs into the server as a slave.) Then, we would need to get the various
distributions to adopt that additional mode in their init scripts.

I'm concerned that something that was meant to be a shortcut for specifying
common sets of NUT processes is creating more problems that it solves. Right
now, we have four modes to cover three daemons, and this use case introduces a
fifth mode. I can't help but wonder if there is a better way to represent
these configurations.

--
Charles Lepple
clepple at gmail