[Proposal] Remove dns_sd API

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[Proposal] Remove dns_sd API

Samba - samba-technical mailing list
Currently, Samba is able [1] to use both Avahi (since 2009) and dns_sd (since 2007) to advertise mDNS/DNS-SD services (smbd).
It is also able to use dns_sd to browse for SMB services on the network (smbclient).

However, after the move to Waf and the removal of autotools four years ago in cd4b413, support for enabling the dns_sd layer was lost.
In testing, reenabling support resulted in compile errors in source3/client/dnsbrowse.c.
These errors that have existed since February 2011 due to 5b26cfe and b28a2e5 (side note: the commits say they are untested).

Furthermore, advertising services (source3/smbd/dnsregister.c) has been broken since 2009, when it was changed to be event-driven (bf2347b).
In dns_register_smbd_fde_handler(), once a response from the mDNS daemon is received, the service deregisters itself—which happens almost immediately.
This means that, although it compiles, dnsregister.c does not work—it does not advertise mDNS/DNS-SD services.

The only platform (that I found) that actively uses the Samba dns_sd API support is FreeBSD, which patches Samba to enable dns_sd.
FreeBSD compiles Samba with *both* Avahi and dns_sd support.
OpenBSD only uses Avahi, while NetBSD appears to not use either.
None of Homebrew, MacPorts, or Fink contain a modern, maintained version of Samba; Samba is not much used on macOS due to Apple’s own SMB implementation.

Since the dns_sd code is broken, unmaintained, and seldom-used, I propose removing it.
mDNS/DNS-SD advertisement is well-served by Avahi on all platforms (*including* FreeBSD, as the dns_sd implementation does not work).
An Avahi-based replacement for browsing with smbclient can be made, which has the additional benefit of bringing support for this feature to Linux platforms.
The Avahi code has remained nearly unchanged since it was introduced, and continues to work fine—it is enabled with nearly all Samba distributions.

Otherwise, someone needs to take up the job of fixing and maintaining the code—which *must* include actually testing patches (5b26cfe and b28a2e5).
Keeping the status quo untenable.

Thanks,
Omri Mor

[1]: Theoretically; as explained above, dns_sd support is broken
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Remove dns_sd API

Samba - samba-technical mailing list
On Sun, Jul 23, 2017 at 10:07:23PM -0700, Omri Mor wrote:
> Otherwise, someone needs to take up the job of fixing and maintaining the
> code—which *must* include actually testing patches (5b26cfe and b28a2e5).
> Keeping the status quo untenable.

ack and happy to review patches that remove it.

-slow

--
Ralph Boehme, Samba Team       https://samba.org/
Samba Developer, SerNet GmbH   https://sernet.de/en/samba/

Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Remove dns_sd API

Samba - samba-technical mailing list
On Sun, Nov 5, 2017 at 9:57 AM, Ralph Böhme <[hidden email]> wrote:

> On Sun, Jul 23, 2017 at 10:07:23PM -0700, Omri Mor wrote:
> > Otherwise, someone needs to take up the job of fixing and maintaining the
> > code—which *must* include actually testing patches (5b26cfe and b28a2e5).
> > Keeping the status quo untenable.
>

ack and happy to review patches that remove it.
>

Thanks for the offer, Ralph, if you could give me/us a bit of direction in
the way what tests and how they should be written - we can invest some time
into writing them.

As a matter of fact dns_sd is working and used in the FreeBSD ports and in
the FreeNAS. Actually, FreeNAS uses mDNSResponder to provide service
auto-discovery
and used dns_sd code on a regular basics. So I wouldn't call this part of
the code "non-working".

With regards,
Timur Bakeyev.
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Remove dns_sd API

Samba - samba-technical mailing list
On Sun, Nov 05, 2017 at 09:56:13PM +0100, Timur I. Bakeyev wrote:

> On Sun, Nov 5, 2017 at 9:57 AM, Ralph Böhme <[hidden email]> wrote:
>
> > On Sun, Jul 23, 2017 at 10:07:23PM -0700, Omri Mor wrote:
> > > Otherwise, someone needs to take up the job of fixing and maintaining the
> > > code—which *must* include actually testing patches (5b26cfe and b28a2e5).
> > > Keeping the status quo untenable.
> >
>
> ack and happy to review patches that remove it.
> >
>
> Thanks for the offer, Ralph, if you could give me/us a bit of direction in
> the way what tests and how they should be written - we can invest some time
> into writing them.
>
> As a matter of fact dns_sd is working and used in the FreeBSD ports and in
> the FreeNAS. Actually, FreeNAS uses mDNSResponder to provide service
> auto-discovery
> and used dns_sd code on a regular basics. So I wouldn't call this part of
> the code "non-working".

ah, so we're getting some traction here. :)

So you say it's working? Omri, can you check?

If it's working it would be good to upstream the patches that the FreeBSD port
carries.

-slow

--
Ralph Boehme, Samba Team       https://samba.org/
Samba Developer, SerNet GmbH   https://sernet.de/en/samba/

Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Remove dns_sd API

Samba - samba-technical mailing list
Sorry for taking a bit to respond, I’ve been busy with work for the past couple days.

> As a matter of fact dns_sd is working and used in the FreeBSD ports and in
> the FreeNAS. Actually, FreeNAS uses mDNSResponder to provide service
> auto-discovery
> and used dns_sd code on a regular basics. So I wouldn't call this part of
> the code "non-working”.

It _is_ true that FreeBSD and its derivatives, including FreeNAS, use mDNSResponder and the dns_sd API—I noted that in my original email. As I stated, however, in upstream, the dns_sd-based client browsing code does not compile, and hasn’t in over 6 years.
Patches fixing this were added to FreeBSD in 2013; they have not been upstreamed since then, though there was a request to do so 2 years ago (also note that I think that the patch isn’t entirely correct, as it frees a talloc context that was obtained via `talloc_tos()`).

As I also stated in the first email, the dns_sd-based service advertising, though it compiles, _does not work_, and hasn’t in 8 years. FreeBSD compiles with both dns_sd/mDNSResponder and Avahi support, so that while it appears to work, it’s actually using the Avahi code (since they are _both_ enabled).

Best would be, I think, to write new Avahi-based client browsing code and remove the the _currently_ nonfunctional dns_sd code.

In any case, attached is a diff I created back in July when I originally looked at it which might fix some things, but I haven’t tested it since.

Omri

tmp.diff (5K) Download Attachment