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
_______________________________________________
Nut-upsdev mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
