[Nut-upsuser] Slave only configuration

[Charles Lepple]

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