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

[Arnaud Quette]

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

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

nut-scanner is a small tool, specialized in detecting all the possible NUT
supported device (ie probably the biggest range in the "market") and
providing parsable or ups.conf formatted output. protocols are also enabled
at compile and run time.

we even try to reuse / share the more possible code and knowledges in NUT,
and bring it to the world as a command line tool and as a library.

imo, we perfectly fit the unix way of life... at least, we are not creating
a scan + config + client whole, that would indeed not be root'ed.

the most important use I see is not in nut-scanner, but the library.
this will be used by nut-config and any derived bindings.


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

you still have to know about nut, and then select 1 of the 5 USB drivers.
not considering the one that select a wrong driver (apcsmart for a USB APC
for example)

the scan and config tool will hopefully help, along with more integration in
OSs.

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

last time I checked, SLP was almost defunct, and mDNS in drafting stage.
I'm not sure if I've heard about a 2nd SLP version, which aborted due to
mDNS ramp up...


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

well, it's not impossible, but it requires to have a complete overview.
ie upstart and systemd scripts for NUT, since the only suitable way to start
avahi-publish would be to bind it to NUT startup ( [upsdrvctl + upsd] and /
or upsmon)

so, this was not fitting with the timelines.
for now, we have something basic, but working.
but there are room for improvements...

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


which explains why I left the short run integration to the packagers will.
as for bash-completion.d, and soon for Augeas files in Debian.
there, we don't want to have a hard dependency, and leave to the user to
enable these (ie bash-completion and Augeas)


> It's slightly more complicated if you want to detect errors
> when calling avahi-publish.
>

and even more to start it up appropriately.

cheers,
Arno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20110630/1140880f/attachment.html>