On 03/27/2017 01:32 PM, Daniel Stripes wrote:
> On this CentOS Linux release 7.3.1611 (Core) box:
>
> [root@vega ~]# ls -ald /var/run/avahi-daemon/
> drwxr-xr-x. 2 avahi avahi 80 Mar 24 05:10 /var/run/avahi-daemon/
Same here on Debian (Jessie).
I wonder what's up with that Ubuntu 16.04 instal--presumably this was a bug
in the Debian package that Ubuntu inherited before freezing and then
never fixed...?
Except IIRC it actually takes some work to mess up permissions like that
in a Debian package.... The helper scripts really want to normalize
the permissions on everything for you.
> On 03/27/2017 10:41 AM, Ken D'Ambrosio wrote:
>> Yay, strace. I'm guessing people don't use Avahi for service discovery
>> a whole bunch these days -- at least, on Ubuntu 16.04. (Which makes me
>> wonder what people *do* use -- if anyone has a suggestion for service
>> discovery on a network where *no* IPs are known in advance, I'm all
>> ears.) Anyway:
>> Strace output:
>> connect(4, {sa_family=AF_LOCAL,
>> sun_path="/var/run/avahi-daemon/socket"}, 110) = -1 EACCES (Permission
>> denied)
>>
>> root@clients-1:~# ls -ald /var/run/avahi-daemon/
>> drwx------ 2 avahi avahi 80 Mar 27 05:35 /var/run/avahi-daemon/
>>
>> root@clients-1:~# chmod 777 /var/run/avahi-daemon/
>> root@clients-1:~# ping kentest.local
>> PING kentest.local (192.168.243.16) 56(84) bytes of data.
>> 64 bytes from 192.168.243.16: icmp_seq=1 ttl=64 time=1.31 ms
>> 64 bytes from 192.168.243.16: icmp_seq=2 ttl=64 time=0.742 ms
>>
>> Weird, I tells ya'. *wanders off to file a bug report*
>>
>> -Ken
>>
>> -----------------------------------------------------------------------------
>>
>> On 2017-03-27 10:17, Ken D'Ambrosio wrote:
>>> Hi, all. For service discovery on a cloud subnet, I'm trying to get
>>> the
>>> different VM's to resolve each other -- by strong preference,
>>> seamlessly
>>> -- via Avahi. And it works... kinda:
>>>
>>> root@clients-1:~# avahi-resolve -n -4 kentest.local
>>> kentest.local 192.168.243.16 # This is a good thing
>>>
>>>
>>> These, not so much good:
>>> root@clients-1:~# ping kentest.local
>>> ping: unknown host kentest.local
>>> root@clients-1:~# host kentest.local
>>> Host kentest.local not found: 3(NXDOMAIN)
>>>
>>>
>>> Here's my pertinent nsswitch line:
>>> hosts: files mdns4_minimal [NOTFOUND=return] dns
>>>
>>>
>>> Since the daemon is clearly replying with correct info, I assume I'm
>>> doing something wrong client-side (though as I've never done this
>>> before, I guess it could still be a server-side issue). Any hints or
>>> ideas?
>>>
>>> Thanks,
>>>
>>> -Ken
>>> _______________________________________________
>>> gnhlug-discuss mailing list
>>> gnhlug-discuss@mail.gnhlug.org
>>> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>> _______________________________________________
>> gnhlug-discuss mailing list
>> gnhlug-discuss@mail.gnhlug.org
>> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>>
>
>
>
> _______________________________________________
> gnhlug-discuss mailing list
> gnhlug-discuss@mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>
--
"Don't be afraid to ask (λf.((λx.xx) (λr.f(rr))))."
_______________________________________________
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
