On 07/10/14 01:59, Dave Brolley wrote:
...
First possible problem is that avahi-devel was not available when PCP
was configured/built. Check your configure logs for problems finding the
needed avahi components. However, I would expect pmfind(1) report that
avahi is not supported in this case.
avahi-devel was and is installed.
Next place to look is the pmcd log. If it failed to register itself with
avahi-daemon, then there should be some messages in the log.
As per last mail to Frank, the registration apparently did not work, but
I don't know why ... more strangely, there is no avahi message in pmcd's
log file after I restarted pmcd.
The next, and most common cause of avahi-related problems is that the
mDNS port, udp 5353, is not open in the firewall. Try
avahi-browse -rt _pmcd._tcp
That returns nothing. But there may be a disconnection of understanding
here. I am expecting that pmfind will find pmcd on the local host which
should not involve the firewall (or rather the firewall should not get
in the way). If pmfind is only looking externally, then the QA test is
pathologically broken ... it will only work in an environment where some
_other_ host is also avahi-enabled and accessible via multi-cast udp
packets.
If that works, then pmfind should also work with avahi. avahi-browse is
part of the avahi-tools package.
I it looks like qa/646 checks that avahi-daemon is ok and checks that
service discovery is supported. We should probably create another
pmconfig(1) category, something like 'service_discovery_avahi' which
could be used to catch the first two problems above. I'm not sure how to
portably check that a port is open in the firewall and I'm not sure that
we can depend on avahi-tools being installed for checeking with
avahi-browse.
I hope this helps,
It helps move my understanding along ... it does not help getting the qa
test passing I'm afraid.
|