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?
--
Do things because you should, not just because you can.
John Thurston 907-465-8591
John.Thurston at alaska.gov
Enterprise Technology Services
Department of Administration
State of Alaska
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
On 8/28/2013 7:26 PM, Charles Lepple wrote:> On Aug 28, 2013, at 8:03 PM, John Thurston wrote:...>> 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....> Creating a dummy upsmon.conf that can't log status or shut down the server is also a possibility.This is where I'm heading at the moment. If I define a dummy-ups, and make the upsmon on the NUT server monitor that as a master, it will never see a state change and will never do anything. I can then define the physical devices as slaves and my other NUT clients can get their status. I run one extra daemon on the server, but it is lightweight and shouldn't get in my way.> It's certainly possible for us to add an option like "MODE=netdriver" to nut.conf. . . . > > 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.During my initial setup, I found the nut.conf to be rather confusing. I see now that it was designed to unify three daemons as one "product" and handle startup dependencies. My initial reaction was, 'I have three daemons, I should have three init/kill scripts/links. Where are they?' I think that using a dummy-ups will meet my needs. Thank you for your guidance and suggestions. -- Do things because you should, not just because you can. John Thurston 907-465-8591 John.Thurston at alaska.gov Enterprise Technology Services Department of Administration State of Alaska