[Nut-upsdev] MGE NMC and NutShutdownModule (and other stuff)

[Marco Chiappero]

Arjen de Korte ha scritto:
>> No. This would be a problem when using the UDP protocol, that I didn't 
>> implemented, where there is a single socket reading broadcast messages 
>> sent by the UPSes. In such case we would need the driver approach (but 
>> that breaks the single_UPS--single_driver_instance design [1]) or the 
>> new deamon approach (that shall take care about talking to the NMC 
>> directly). Otherwise this is false and you can run every netxml-ups 
>> instances you want (or run UDP in a single UPS scenario only).
> 
> This is what I misunderstood.

Ok, never mind, let's forget about previous messages :)

> I though the driver would have to open a 
> socket for listening and wait for a connection *from* the NMC (like the 
> NSM client that is provided by Eaton),

Mmm, the Eaton software uses two lighttpd instances, one for configuring 
the client via web pages, the other for reading UDP messages I suppose 
(but netstat says it's a TCP socket). The default setting is to try to 
use UDP, which is more efficient and allows more UPSes to be managed by 
the NMC, and switch to TCP on failure. User can change this behavior and 
go through the TCP protocol only. However, as far as I can see, even 
when using TCP through the mgeDAE (Daemon Acquisition Engine), you have 
lighttpd bound to the 4679-4680 ports. If the http approach is a good 
way to support a uniform interface on different systems it's not optimal 
for server machines. You have to configure the client connecting to the 
configuration port (so the server can not be bound to the loopback 
address), you can then disable the http server for example modifying the 
init script (but disabling UDP I suppose), but it's an hack. On the 
other side having to care about a non productive http server it's 
annoying, and this is one of the reasons that make me prefer to go with 
NUT. Moreover, NUT quite widespread and well know to the sysadmins, so I 
can be convenient for them to use a software they already know. As I 
have a small setup I'm using the TCP protocol and the good side effect 
it is that I do not have to allow incoming connections, which can be a 
positive aspect (while the downside is the limited power of the NSM. 
Maybe in the future this will be a much smaller issue?). As I said I own 
an old card, so I can tell the driver to generate random hostnames and 
make some stress test, even though it's not much a NUT related problem.

> but apparently this mechanism 
> isn't used and instead it opens a connection *to* the NMC.

In short the TCP protocol I now explain a bit. The driver reads the 
product page. If it is going to using the centralized settings first 
retrieves them from another page. Then uses the subscription page for 
offering its settings (the previously read or the local ones) and 
receive a key number, at this point it starts the TCP communication and 
starts waiting for alarm messages, after providing the key number as 
authentication. That's all. Alarm messages are host specific, so it's a 
source of information with higher "priority" and should override the 
same values read from the generic web page.

> In that case, 
> you would indeed be able to run multiple NSM enabled drivers in 
> parallel. The only objection that remains then is that putting this in 
> the netxml-ups driver is probably not a good idea. It would be quite a 
> burden on the little micro controller in the NMC 66102, since it would 
> also require parsing the full XML data for each instance.

Yes, if we do care about detailed info. The summary page can be enough 
for that, but at this point we should introduce changes in the 
netxml-driver and a new configuration key (such as "extended = true") 
which is not good. Nonetheless there's no way out if we want many 
variables, we have to read a "lot" of data from every single UPS 
involved and stress the NMC, even though UDP can help. Maybe we can use 
the summary page, by default, when the management is enabled, or use 
different poll intervals for management and data... If I'm not wrong the 
Eaton software polls the summary page every 60 seconds and looks for new 
alarms every 10 seconds.

> If you'd make 
> this NSM driver a separate one however, I'd be all for it.

Sorry, I don't understand this last sentence, what you mean?

> A separate (new) driver would also deal with the case where you'd define 
> a meta UPS (like the globalups example you wrote about earlier) where 
> neither of two (or more) individual UPS devices that would be part of 
> this meta UPS could be the sole source of information like voltages, 
> currents and battery charge.

The "meta UPS" can't expose those values, just driver parameters, total 
remaining capacity, global load, global status.. For detailed info, if 
needed, the netxml-ups driver have to be used as well. Let me explain 
the reasons behind this idea. After using the subdriver approach I 
thought that, to make NUT useful for many different NMC owners, I should 
provide the same functionality and almost the same configuration 
settings. So, to keep things easy for the user I thought to use the same 
Eaton NSM logic in a driver and keep upsmon configuration at minimum 
implementing all the different redundant schema supported by the Eaton 
software directly in the driver. Now, I do not have multiple UPS and I'm 
not experienced with complex upsmon configuration, so I can't say 
accurately whether those redundant configuration (look back at the 
images I linked) can be supported natively by NUT. If so it can be 
avoided dealing with them in the driver, so we can discard this idea and 
use your last one for example. Otherwise we can chose to ignore the UDP 
protocol. There is also the new daemon solution (certainly a clean one, 
but it's too manufacturer specific for a general purpose software like 
NUT). All possible solutions, but it's a bit difficult to say what is 
best, need some help :)

> In such case, you'd only be able to tell 
> whether the clients that connect to that meta UPS would need to shutdown 
> or not.

Yes. That's how the Eaton NSM works. Probably people are not really 
interested in managing the single UPSes directly, so should be fine. 
Otherwise the netxml-ups can still be used.

> All remaining info (for logging purposes) would need to come 
> from drivers that connect to a single UPS device (however, that probably 
> wouldn't be relevant to the clients that connect to the meta UPS anyway).

Exactly.

> Sorry for being such a PITA, but I prefer to get a clear picture on what 
> the pros and cons are before people invest time in writing something, 
> only to find out along the way that they have to start over again later.

I know that the main target for the netxml-ups driver are very large 
setups and the UDP protocol can be useful there, however there are 
certainly environment where the capacity/functionality provided by the 
subdriver solution are fine. It's a smart way, it's easy to configure, 
small code, but no UDP (I don't know exactly about redundant support). 
The Eaton clone driver it's more complex but powerful, configuration 
still quite easy. The mged solution sounds like writing a different 
program, not much related with NUT. The solution you proposed it's 
difficult from the configuration standpoint but could be fine. Knowing 
how the Eaton NSM works can help a bit, so, please, have again a look at 
the images at least.
The subdriver solution it's ok for my own setup, but if we are able to 
find a good approach/compromise the NSM inclusion can maybe be useful 
for other people too. It wouldn't be bad, but it's otherwise fine if we 
can't.


Regards,
Marco