Arjen de Korte ha scritto:
Citeren Marco Chiappero <[email protected]>:
More or less, yes. In order to limit the number of variables that need
to be set, I would limit the configuration to LOCAL only and provide
some sensible defaults for the shutdown delay and shutdown timer
however. By explicitly setting these in the driver, this will make
helping people setting this up easier (otherwise it would require
setting up both the NMC and NUT).
Uhm, I feel it's much better to offer a user choice. The main reason is
that we already have reasonable default settings, the NMC ones (which
are probably corrected during initial installation and setups, if
needed). So, a basic configuration would just require the ups address
and the outlet. On the other side it can also be useful to use specific
local settings providing at list the shutdown delay. The driver
configuration it's already simple enough for both "lazy" and "advanced"
users, leaving some freedom of choice; moreover preserving the Eaton
behavior imho is preferrable. For example, due to cable routing
problems, I indeed use both LOCAL and CENTRALIZED settings on different
machines.
I still have to understand, instead, whether the ADMIN and USER settings
have some implications on the type of messages sent through the NSM
communication.
Did you already try to connect multiple drivers yet? The NMC I'm using
(66102 / GA) seems to allow only a single TCP connected subscription
from any single IP. So if a driver is already connected, starting
another one will make the NMC disconnect the others that are connected
from the same IP.
Yes, I think you're right. I tried ones, and I sow that the NMC closes
the second TCP connections immediately after reading the secret key.
However I have to investigate whether the NMC takes into account the IP
or the hostname to reject clones. I'll have a try in these days.
While this makes perfect sense for machines that use
an NSM client to shut them down, this bites us if we want to monitor all
outlets through multiple drivers in NUT.
Sorry, I'm not sure what you mean. I'm not experiencing any problem
connecting to the NMC for both management and web pages at the same time
from the same machine. On the other side connecting a single machine to
different outlets from the same ups makes no sense. Is it right?
BTW, I saw that no authentication is required for all the data and
management pages even though I enabled the authentication for every menu
page. I don't know whether it's a bug in my own firmware or the
authentication is used for the user web pages only by design. I have
seen that it gets never used in the netxml-ups too. I haven't tried the
auth+ssl configuration though.
This problem popped up when I added monitoring of the connection state.
I added an automatic reconnection if the connection was lost. It took
only a few seconds for three NSM connected drivers (connected to the
main, outlet-1 and outlet-2) fighting for a subscription to confuse the
NMC enough to trigger a reset. Ouch! :-)
Three clients on the same machine using different outlets? With my code?
Please, tell me exactly how to reproduce it.
However, if no problems occur, I think I'm going to write a mgensm or
mgensm-ups driver that includes a nsm-xml.c parsing file, cloned from
mge-xml.c. However we have to accurately choose what to parse (= what to
expose as nut variable - I'd say the minimum -), and as I have a small
MGE Evolution I can't say which kind of information the alarm messages
contains in bigger UPSes. I see just AC presents / charging-discharging
/ load / runtime messages and so on but maybe many other can be sent
under certain circumstances on different UPSes; probably you and Arnaud
can help a lot.
BTW, what about mapping System.Outlet[3].RunTimeToShutdown,
System.Outlet[2].RunTimeToShutdown and System.RunTimeToShutdown to a
outlet.runtime variable?
As soon as I have some working code and maybe manpage text, I'll attach
the code for revision and correction. In the meantime let's continue
talking here about problems, news or ideas. Ok?
Best regards,
Marco
_______________________________________________
Nut-upsdev mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
