Bug 200356 - dns/mDNSResponder_nss: Build and install nss_mdns
Summary: dns/mDNSResponder_nss: Build and install nss_mdns
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: freebsd-ports-bugs mailing list
URL:
Keywords: needs-qa, patch
Depends on:
Blocks:
 
Reported: 2015-05-21 01:12 UTC by sef
Modified: 2018-09-14 09:36 UTC (History)
4 users (show)

See Also:


Attachments
Diffs for the port (4.85 KB, text/plain)
2015-05-21 01:12 UTC, sef
no flags Details
mDNSResponder diff (6.67 KB, patch)
2015-06-08 17:37 UTC, Sunpoet Po-Chuan Hsieh
no flags Details | Diff
Patch for nss_mdns.c (817 bytes, patch)
2015-06-08 18:40 UTC, sef
no flags Details | Diff
The right patch file (10.11 KB, patch)
2015-06-08 19:14 UTC, sef
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description sef 2015-05-21 01:12:57 UTC
Created attachment 156993 [details]
Diffs for the port

I've attached diffs to the port to build and install nss_mdns, which allows resolution of .local hosts.

Note that this doesn't change nsswitch.conf; a post-install script could do that, I suppose.
Comment 1 Sunpoet Po-Chuan Hsieh freebsd_committer 2015-05-21 09:34:44 UTC
We have dns/mDNSResponder_nss to install lib/nss_mdns.so. I think that's the correct port to patch.
Comment 2 Kubilay Kocak freebsd_committer freebsd_triage 2015-05-21 10:21:53 UTC
Correctly set maintainer-feedback email value
Comment 3 Matthieu Volat 2015-05-21 15:35:32 UTC
When I wrote the dns/mDNSResponder_nss port, the NSS module in mDNSResponder was GNU/Linux only, and I needed a shim[1] to make it work with *BSD.

Did the situation change? The patch do not apply on my port tree (git-patch related issue?) so I can't test it right now.

But regarding the PR, I think either it means to merge both ports (not really an issue on my side), or it will need to be rewritten against dns/mDNSResponder_nss because I'm not sure yet it changes anything for my port...

Regards,

[1] https://svnweb.freebsd.org/ports/head/dns/mDNSResponder_nss/files/nss_mdns_freebsd.c?revision=364862&view=markup


PS. would be a fan of freenas being able to resolve .local :)
Comment 4 sef 2015-05-21 16:20:07 UTC
FreeNAS can do this already, as I wrote a small stupid port; I was not aware of dns/mDNSResponder-nss.

I don't think there should be two ports for this; that seems excessive.

I'd suggest, I think, taking my patch for mDNSResponder/mDNSPosix/Makefile, and either using my patches for nss_mdns.c, or folding the ones from mDNSResponder-nss in.  The code is remarkably similar ;).  (Except I did not use getaddrinfo() to create an ai.)
Comment 5 Matthieu Volat 2015-05-22 05:10:15 UTC
If the maintainer of mDNSResponder don't mind to continue to maintain and test the NSS module functionality, I am OK with that.
Comment 6 Kubilay Kocak freebsd_committer freebsd_triage 2015-05-26 10:27:36 UTC
The maintainer of net/mDNSResponder_nss has indicated they are not sure whether or not the existing changes are material for their port.

In either case, a new patch should be submitted in a new issue if the change applies to net/mDNSResponder_nss for subsequent approval by that ports maintainer.

The current patch (attachment 156993 [details]) is against net/mDNSResponder so sunpoet is the correct (current) assignee to resolve this issue.

1) accept or reject current patch and close, OR
2) request an updated patch with specific instructions

Clarity on the original Reporters part on what should instead be done now is also pending.
Comment 7 Kubilay Kocak freebsd_committer freebsd_triage 2015-05-26 10:29:08 UTC
Restore original issue summary, as this is what the current change/attachment intends
Comment 8 Sunpoet Po-Chuan Hsieh freebsd_committer 2015-06-08 17:37:45 UTC
Created attachment 157538 [details]
mDNSResponder diff

Based on original submission and dns/mDNSResponder_nss, I've prepared this patch. Please check if it works for you. Thanks!
Comment 9 Matthieu Volat 2015-06-08 18:32:11 UTC
Ok, so I tried it and:

1. nss module is installed as libnss_mdns.so

I am pretty sure it should be nss_mdns.so, the manuals evades the question, but unless I am missing something nss_load_module() (src/lib/libc/net/nsdispatch.c:469 in 10.1) do seems do load nss_<name>.so


2. lib is GNU/Linux only

Even renaming the module won't give anything:

Jun  8 20:16:15 freedom ping: NSSWITCH(_nsdispatch): mdns, hosts, gethostbyname2_r, not found, and no fallback provided

So having a look at the patch, patched sources: the nss_mdns.c file do not provide the nss_module_register() function, even less the needed hooks.

Regarding the manpages, nss_module_register() is not documented, so once again nss_load_module() serves as reference. However, regarding the partial linux compatibility, nsdispatch(3) manpage specify that only passwd and group compat is available.


I'm a bit curious on how this was able to function elsewhere. If you do plan to merge both ports, please do it including everything needed, but if you don't rely on the nss module functionality, please keep it separate (I may convert it to a slave port to better chase version bumps).

Other thoughts: nss module should conflict with avahi's own plugin which hijack the name, so if the ports were to be merged, maybe the nss functionality should be optional?
Comment 10 sef 2015-06-08 18:40:33 UTC
I haven't looked at the new patches yet -- Monday morning and all that -- so I haven't compared what was done.

It should install libnss_mdns.so, and a link to nss_mdns.so, or just the latter (since that's what nsswitch uses).

I don't see my patch for nss_mdns.c in the attached diffs now, which would explain why the register didn't show up.

Attaching that file.
Comment 11 sef 2015-06-08 18:40:59 UTC
Created attachment 157540 [details]
Patch for nss_mdns.c
Comment 12 sef 2015-06-08 19:14:20 UTC
Blast it, wrong file.  Here's the one I had, sorry.
Comment 13 sef 2015-06-08 19:14:46 UTC
Created attachment 157542 [details]
The right patch file
Comment 14 Matthieu Volat 2015-06-08 19:53:20 UTC
Also, the port should install/manage a nss_mdns.conf file.
Comment 15 Sunpoet Po-Chuan Hsieh freebsd_committer 2015-06-19 20:47:59 UTC
Like what I said in Comment 1, it would be better to merge sef's patch with dns/mDNSResponder_nss.
The reason are:
- A separate port is better than an off-by-default option (which means no package).
- Matthieu Volat knows more about nss than me.
Comment 16 Matthieu Volat 2015-08-24 18:02:13 UTC
Sorry for the delay, one way to go about this problem would be to try and submit (maybe cleaned up) code to upstream maybe?

But I had little success any time I had try to contact the developers for bugs and such...

Btw, I tried to make the port a slave of net/mDNSResponder, but the post-install rules are conflicting.
Comment 17 sef 2015-08-24 18:07:55 UTC
Hm.  I wonder who at Apple maintains this now.
Comment 18 Walter Schwarzenfeld freebsd_triage 2018-01-13 21:47:41 UTC
Is this still relevant?
Comment 19 sef 2018-01-13 22:02:29 UTC
Yes, it is still relevant, since it handle IPv6.
Comment 20 Matthieu Volat 2018-01-14 08:15:49 UTC
Not sure what you mean by that: are you suggesting that dns/mDNSResponder_nss has no IPv6 support? I use/prefer ipv6 addresses on my local network without any issue with my setup(*)

(*) Appart from the fact that, those days, mdnsd won't advertize hostname without mdnsresponderposix advertizing other(s) service(s)...
Comment 21 sef 2018-01-14 16:43:43 UTC
My patch-to-the-patch adds the ability for getaddrinfo to return IPv4 and IPv6 addresses.
Comment 22 Tobias Kortkamp freebsd_committer 2018-08-09 11:53:52 UTC
It's unclear how to apply this patch to the port?  I think this needs a rebase.
Comment 23 Matthieu Volat 2018-08-11 16:00:28 UTC
Hi,

Totaly forgot about this issue: the issue with getaddrinfo not returning inet *and* inet6 was a bug in the shim, for which I submitted an update to issue #225912 (which was originaly an update to 878.30.4 that I forgot to ping due to life events).

Can you test it and confirm for the expected behavior?

Thanks,