[Nut-upsdev] Changes to upscli_connect (and general discovery)

[Arnaud Quette]

2011/6/29 Charles Lepple <clepple at gmail.com>

> On Jun 29, 2011, at 3:29 AM, Arjen de Korte wrote:
>
>  Citeren Stuart D Gathman <stuart at bmsi.com>:
>>
>>  Your test is with localhost - so any non-existent socket would get
>>> immediately rejected.  The nut scanner has to deal with hosts on the
>>> network.  If they send an ICMP reject, then there is no need for a timeout.
>>>  But it is very common for a host to simply "eat" attempts to connect to a
>>> port not allowed in their firewall.  So nut scanner needs a non-blocking
>>> version of upscli_connect.
>>>
>>
>> This probably won't scale very well. On a small /24 subnet this might be
>> feasible, but as soon as you hit /20 (or even larger) this is impractical
>> (let alone what will happen if you happen to use a /64 IPv6).
>>
>
> To be honest, I'm not terribly excited about the notion of a NUT scanner


just to disambiguate your words for Fred and others: you were probably
referring to nut-scanner discovery NUT hosts with the *old* method.
and not the nut-scanner effort as a whole?!


> - specialized tools like nmap can do a much better job at port scanning,
> and corporate network security teams may get upset at seeing that sort of
> activity on infrastructure machines. But it's a separate tool that gets
> invoked manually, so I don't want to get in the way of development.
>

if only there was a standard tool, where we just have to declare our USB,
SNMP, (...) info, I would probably be the first to run that way.


>  For the purpose of auto-detecting servers I'd propose to resurrect the UDP
>> code and broadcast the servers presence once every 10 seconds or so. Yes,
>> this has its drawbacks too (to make sure the broadcasts reach the potential
>> clients), but this has the advantage to be setup by a (knowledgeable)
>> network administrator instead of an aspiring NUT user that has no clue where
>> the server (s)he needs to connect to is located.
>>
>
> On the other hand, broadcasting presence is the kind of feature that would
> need to be enabled manually in order to be useful, and if enabled by
> default, would be a nuisance.
>
> I wouldn't want NUT to get a reputation for being as noisy on the network
> as a protocol like NMB or even the Cisco Discovery Protocol. This is where a
> protocol like Multicast DNS (mDNS) really shines. When a service comes up,
> the UDP DNS message is sent out on the link-local multicast group, and
> retransmissions are sent with an exponential backoff time. Clients can also
> initiate a query, and the idea is that queries would be managed by a
> long-lived daemon that caches query responses beyond the lifetime of the
> clients requesting information.
>
> This has come up a few times before - the usual mDNS implementation on *nix
> system is Avahi, and in the simplest case, NUT only needs to provide a
> static .service file to the Avahi daemon which says "contact upsd on this
> port at this hostname". It's just the usual "round tuit" shortage...
>

you summed up very well Charles ;-)
moreover, the UDP broadcast approach is IPv4 only, and is reinventing the
(mDNS) wheel...
and that's all we want to avoid.

I've just committed the Avahi service file to trunk (r3109), since the other
approach I've been investigating (avahi-publish call from init script) was
causing problems with systemd/upstard and friends
the only drawback I see, WRT upscli_connect(), is the fact that avahi
exposure only means that nut is installed, not started...

note that avahi support still need some completion, for installing the file
upon detection of avahi presence...

 Furthermore I don't think it is a good idea to add timeouts to the existing
>> upscli_connect and/or make it non-blocking. What we're looking for in
>> nut-scanner is something that quickly probes a large number of hosts for the
>> presence of a server and only then initializes a connection. So preferably
>> we would like to split the connection of the socket and the initialization
>> of the protocol.
>>
>
> I guess I see the scanning code as a stopgap way to contact "legacy"
> servers (or what would be legacy after some discovery protocol like mDNS is
> set up), and either timeouts or non-blocking is just a kludge to make that
> work a little better. And isn't opening a non-blocking socket just a way to
> split socket connection and protocol initialization?
>

indeed.
as for the compat, IIRC Fred proposed a a new _tryconnect() method, upon
which the standard _connect() would be mapped, with no behavior change.

cheers,
Arno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20110629/4e69874a/attachment-0001.html>