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

[Frédéric Bohé]

On Wed, 2011-06-29 at 07:13 -0400, Charles Lepple wrote:
> 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 - 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.

Scanning port is not the only feature of nut scanner. It is currently
able to detect USB devices and it is planned to have avahi and ipmi
support. Moreover it is able to extract the device configured on the
upsd server discovered.
Finally It should be used by some sort of "nut configurator/wizard" to
help users configure their devices, or be integrated in appliances
firmware to auto-detect devices.

> 
> > 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...
> 
> > 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?
> 
> _______________________________________________
> Nut-upsdev mailing list
> Nut-upsdev at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

-- 
Team Open Source Eaton - http://powerquality.eaton.com

--------------------------------------------------------------------------