[Nut-upsuser] upsd/upsc, LISTEN and hostname resolution in master/slave
spike at drba.org
Wed Mar 29 16:47:24 UTC 2017
oh, my bad, actually, you even mentioned it, the other option would be to
listen on 0.0.0.0 . I guess that'd work even tho it'd then be a good thing
to have local firewall as you suggested. So maybe just have that in the
docs too? I still think it'd be worth clarifying, if I got that right, that
using _hostname_ is not sufficient to make it listen on any interface other
On Wed, Mar 29, 2017 at 8:35 AM Spike <spike at drba.org> wrote:
> thank you Arno, I'm with Manuel on the "IP address or hostname", maybe I
> didn't understand your previous explanation, but to me there's still a
> bigger issue/unclear behavior.
> Let's say I just installed ubuntu on a machine with hostname server1 and
> ip 192.168.0.1 . In /etc/hosts I end up with two lines (per
> 127.0.0.1 localhost
> 127.0.1.1 server1 server1.domain (notice the two entries, with and without
> I then have bind configured on the network to resolve server1
> to 192.168.0.1
> If at this point I install NUT and set upsd.conf as a server and set the
> line such as:
> LISTEN server1.domain 3493
> I expect nut to listen on the local lan interface with ip 192.168.0.1 , ie
> I expect it to be equivalent to:
> LISTEN 192.168.0.1 3493
> But it's not, the latter will listen on that ip while the former will
> listen on 127.0.0.1.
> If I want nut to only listen locally I would use 127.0.0.1 or localhost as
> in the examples on the nut's manual. This is my experience with configuring
> other daemons and how I'd expect nut to behave, again this doesn't mean
> it's right, just trying to explain where my problems are coming from.
> So, if we agree that that's how it's working and that the behavior is
> correct, the documentation should imho explicitly point that out that using
> the hostname is not sufficient to have nut listen on the external ip.
> Does that make sense? If we agree on that then the statement "Bind a
> listening port to the interface specified by its Internet address or name"
> is incorrect or at least unintuitive because I'd think of server1 to refer
> to the lan interface, not lo.
> The other problem is that none of the fixes as far as I can see is
> particularly clean/straightforward:
> - adding a second line with the domain does not help because of what's in
> /etc/hosts, so you still end up with NUT listening on localhost
> - using an ip is not possible if DHCP is in the mix or just inconvenient
> as it often is to hardcode ips in configs
> - adding a line to /etc/hosts with the external ip would make it work, but
> again auto generating that from dhcp with a hook script isn't
> straightforward (not sure if there's a better way)
> what am I missing?
> thank you for your help,
> On Wed, Mar 29, 2017 at 4:57 AM Manuel Wolfshant <wolfy at nobugconsulting.ro>
> On 03/29/2017 02:28 PM, Arnaud Quette wrote:
> 2017-03-29 12:32 GMT+02:00 Arnaud Quette <arnaud.quette at gmail.com>:
> 2017-03-29 5:49 GMT+02:00 Spike <spike at drba.org>:
> Is this really the desired behavior? I can certainly work with it, but it
> seems it'd be nice if it could work with dns resolution (at least client
> side, the LISTEN statement I guess it's ok), but maybe I'm missing some
> good reason why this would cause other issues.
> this is indeed undocumented (will fix it after this mail and a quick
> lunch), but that works
> I've clarified a bit:
> I'm interested in some feedback on whether this clarifies enough or not...
> I'd use "IP address or hostname" rather than "IP address or name"
> Nut-upsuser mailing list
> Nut-upsuser at lists.alioth.debian.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Nut-upsuser