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

[Charles Lepple]

On Wed, Jun 29, 2011 at 3:56 PM, Arnaud Quette <aquette.dev at gmail.com> wrote:
>
> 2011/6/29 Charles Lepple <clepple at gmail.com>
>
>> 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?!

In my mind, the nut-scanner idea doesn't fit the general Unix model of
small specialized tools. I didn't say I think it's a bad idea, I am
personally just not excited at the prospect of trying to lump together
so many different communication protocols into a single tool.

>> - 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.

Maybe I'm just not in the target audience for the tool. If I am
bringing up a server in a rack, I'll ask one of the other sysadmins
where the power is coming from, and by following the wires, it should
be obvious what protocol is being used to talk to the UPS. If it's
USB, I run lsusb to verify connectivity.

>>> 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

not necessarily, but...

>, and is reinventing the (mDNS) wheel...
> and that's all we want to avoid.

...agreed. We use tcp-wrappers since we are not in the business of
writing connection filtering code; thus, if we *need* to provide an
IP-based discovery service, I argue we should consider a library
designed to keep the discovery protocol traffic at a manageable level.
I admit I don't know much about SLP libraries, but Avahi is a
well-behaved mDNS implementation, and seems to me to be the right
answer.

> 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...

Hmm, disappointing that avahi-publish isn't working. I was thinking
that it would be nice if we could have additional information in the
TXT record, such as the names of the configured UPSes.

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

There's precedent for installing a configuration file in a directory
that isn't used at the time (e.g. ignore files for log watching
programs). It's slightly more complicated if you want to detect errors
when calling avahi-publish.

-- 
- Charles Lepple