Debian Bug report logs - #459972
winbind: want to limit libnss_wins checks to WINS (no broadcasting)

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Matt Swift <debian-bugs@mattswift.net>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: winbind: want to limit libnss_wins checks to WINS (no broadcasting)

Date: Wed, 09 Jan 2008 17:23:34 -0500

Package: winbind
Version: 3.0.24-6etch9
Severity: wishlist

I have some Windows hosts connected to a Debian host via a routed
OpenVPN interface.  The names of these hosts can be resolved through
WINS (Samba running on the Debian host), but not through the Debian
name resolution sequence unless I install winbind and include "wins"
in the "hosts:" line of /etc/nsswitch.conf.  Doing that works fine,
but there is a significant penalty: a Debian lookup for a nonexistent
name now takes several orders of magnitude longer, e.g., 1.8 seconds
instead of .004 seconds.  The reason for the delay is that if a name
reaches the "wins" method and is a miss in the WINS server, the "wins"
method always attempts to resolve the name with a broadcast, and this
takes a relatively long time to fail.

It is therefore my wishlist request to be able to configure Debian to
resolve names with a WINS lookup but avoid superfluous broadcasting
for names.  "Superfluous" in my case (and it must be common) means
broadcasts for all but single-label unqualified names (more
specifically, valid Netbios names, e.g., <15 chars).  This could be
done any of several ways, but it would be ideal to be able to
configure the "wins" method to return failure immediately on lookups
of anything but a valid Netbios name.  This requires examining and
parsing the name query, however.  It would work nearly as well to be
able to write an /etc/nsswitch.conf that specifies only WINS lookups
and never broadcasts, since I don't expect ever to find a host via
broadcast that isn't already in the WINS database.  This remedy ought
to be relatively easy to implement: since the WINS lookup and the
broadcast are separate phases anyway, skipping one should be easy.
One could implement new methods "winsonly" and "winsbroadcast" while
retaining legacy "wins" meaning "winsonly winsbroadcast".
Alternatively, if the WINS server is already aware of the Samba config
value of "name resolve order" then this value could determine the
behavior of the "wins" method in /etc/nsswitch.conf.

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (990, 'stable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-13etch3-corax-1
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages winbind depends on:
ii  add 3.102                                Add and remove users and groups
ii  lib 2.6.1-1                              GNU C Library: Shared libraries
ii  lib 1.39+1.40-WIP-2006.11.14+dfsg-2etch1 common error description library
ii  lib 1.4.4-7etch4                         MIT Kerberos runtime libraries
ii  lib 2.1.30-13.3                          OpenLDAP libraries
ii  lib 0.79-5                               Pluggable Authentication Modules l
ii  lib 1.10-3                               lib for parsing cmdline parameters
ii  lsb 3.1-23.2etch1                        Linux Standard Base 3.1 init scrip
ii  sam 3.0.24-6etch9                        Samba common files used by both th

winbind recommends no packages.

-- no debconf information

Message #10 received at 459972@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Matt Swift <debian-bugs@mattswift.net>, 459972@bugs.debian.org

Subject: Re: Bug#459972: winbind: want to limit libnss_wins checks to WINS (no broadcasting)

Date: Wed, 9 Jan 2008 14:44:00 -0800

On Wed, Jan 09, 2008 at 05:23:34PM -0500, Matt Swift wrote:
> Package: winbind
> Version: 3.0.24-6etch9
> Severity: wishlist

> I have some Windows hosts connected to a Debian host via a routed
> OpenVPN interface.  The names of these hosts can be resolved through
> WINS (Samba running on the Debian host), but not through the Debian
> name resolution sequence unless I install winbind and include "wins"
> in the "hosts:" line of /etc/nsswitch.conf.  Doing that works fine,
> but there is a significant penalty: a Debian lookup for a nonexistent
> name now takes several orders of magnitude longer, e.g., 1.8 seconds
> instead of .004 seconds.  The reason for the delay is that if a name
> reaches the "wins" method and is a miss in the WINS server, the "wins"
> method always attempts to resolve the name with a broadcast, and this
> takes a relatively long time to fail.

> It is therefore my wishlist request to be able to configure Debian to
> resolve names with a WINS lookup but avoid superfluous broadcasting
> for names.  "Superfluous" in my case (and it must be common) means
> broadcasts for all but single-label unqualified names (more
> specifically, valid Netbios names, e.g., <15 chars).  This could be
> done any of several ways, but it would be ideal to be able to
> configure the "wins" method to return failure immediately on lookups
> of anything but a valid Netbios name.  This requires examining and
> parsing the name query, however.  It would work nearly as well to be
> able to write an /etc/nsswitch.conf that specifies only WINS lookups
> and never broadcasts, since I don't expect ever to find a host via
> broadcast that isn't already in the WINS database.  This remedy ought
> to be relatively easy to implement: since the WINS lookup and the
> broadcast are separate phases anyway, skipping one should be easy.
> One could implement new methods "winsonly" and "winsbroadcast" while
> retaining legacy "wins" meaning "winsonly winsbroadcast".
> Alternatively, if the WINS server is already aware of the Samba config
> value of "name resolve order" then this value could determine the
> behavior of the "wins" method in /etc/nsswitch.conf.

Just to confirm, are you saying that setting "name resolve order = wins" in
/etc/samba/smb.conf does not fix this timeout problem for you?

I don't think it makes sense to have nss_wins exposing different behavior to
the system than is used by Samba itself; but if it's not respecting the
smb.conf values, that's certainly a bug to be fixed IMHO.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

Message #15 received at 459972@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Matt Swift <debian-bugs@mattswift.net>, 459972@bugs.debian.org

Subject: Re: Bug#459972: winbind: want to limit libnss_wins checks to WINS (no broadcasting)

Date: Wed, 9 Jan 2008 15:42:12 -0800

On Wed, Jan 09, 2008 at 02:44:00PM -0800, Steve Langasek wrote:
> Just to confirm, are you saying that setting "name resolve order = wins" in
> /etc/samba/smb.conf does not fix this timeout problem for you?

> I don't think it makes sense to have nss_wins exposing different behavior to
> the system than is used by Samba itself; but if it's not respecting the
> smb.conf values, that's certainly a bug to be fixed IMHO.

Oh, but of course using the exact some logic as samba would mean causing a
recursion in the case of "name resolve order = hosts".  So what's needed
here is to honor the config file, treating only wins, bcast, and
(optionally) lmhosts, and do something appropriately default-y if none of
these are specified.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

Message #20 received at 459972@bugs.debian.org (full text, mbox, reply):

From: Matt Swift <debian-bugs@mattswift.net>

To: 459972@bugs.debian.org

Subject: Re: Bug#459972: winbind: want to limit libnss_wins checks to WINS (no broadcasting)

Date: Wed, 09 Jan 2008 19:13:05 -0500

>> On Wed Jan  9 17:44:00 2008 -0500, Steve Langasek <vorlon@debian.org> wrote:

    S> Just to confirm, are you saying that setting "name resolve order = wins" in
    S> /etc/samba/smb.conf does not fix this timeout problem for you?

    S> I don't think it makes sense to have nss_wins exposing different behavior to
    S> the system than is used by Samba itself; but if it's not respecting the
    S> smb.conf values, that's certainly a bug to be fixed IMHO.

Yes I confirm.  "name resolve order = wins", and "wins" is last entry
in /etc/nsswitch.conf (and "dns proxy=no" to avoid any kind of a
loop).  If I "ping nonexistent" from a Debian shell and monitor
packets with wireshark, then I see a netbios broadcast from the debian
host looking for "nonexistent".  I've verified this after
double-checking that the nmbd processes were actually restarted after
changing smb.conf, since once in while an nmbd process seems to
survive "/etc/init.d/samba restart" and/or the "restart nmbd" button
in the swat web interface.  So if the "wins" NSS method is supposed to
follow "name resolve order" it's not.  I've been using "ping" on
Debian because that seems to use the NSS layer, whereas some apps
(e.g., "host") seem to use just DNS directly.  If you can't verify
that the WINS is broadcasting even without "bcast" in "name resolve
order" , then I'll try to confirm it on my system even more carefully
because...

Related tests today have given maddeningly variable results.  So far
I've gotten inconsistent results trying to "nblookup nonexistent" from
a Windows host to query the WINS server on the Debian host without
going through the NSS layer (could I also do this with nmblookup on
the Debian host I wonder?) .  Sometimes the Debian host broadcasts,
sometimes not, and sometimes the Windows host broadcasts after getting
a negative from the WINS server.  I must be missing a cache somewhere
or something like that, though I'm trying to vary the name looked up
each time.

Message #25 received at 459972@bugs.debian.org (full text, mbox, reply):

From: Matt Swift <debian-bugs@mattswift.net>

To: 459972@bugs.debian.org

Subject: Re: Bug#459972: winbind: want to limit libnss_wins checks to WINS (no broadcasting)

Date: Wed, 09 Jan 2008 19:23:10 -0500

Yes, and as I alluded in mail just sent, a recursion loop seems
possible with "dns proxy=yes" as well, unless that check is not going
to use the NSS layer.

On a related note, you might want to document that you don't actually
have to run windbindd to get the "hosts: wins" NSS service, you just
need to run a WINS server and have /lib/libnss_wins.so (I think).  The
fact that libnss_wins.so installs by default to run winbindd in Debian
suggests that you need to run it for all features described in
winbindd man page (i.e., be good if the winbindd man page said you
don't have to run winbindd to get the NSS functionality, even though
it's the winbindd man page that's documenting it).

>> On Wed Jan  9 18:42:12 2008 -0500, Steve Langasek <vorlon@debian.org> wrote:

    S> On Wed, Jan 09, 2008 at 02:44:00PM -0800, Steve Langasek wrote:
    >> Just to confirm, are you saying that setting "name resolve order = wins" in
    >> /etc/samba/smb.conf does not fix this timeout problem for you?

    >> I don't think it makes sense to have nss_wins exposing different behavior to
    >> the system than is used by Samba itself; but if it's not respecting the
    >> smb.conf values, that's certainly a bug to be fixed IMHO.

    S> Oh, but of course using the exact some logic as samba would mean causing a
    S> recursion in the case of "name resolve order = hosts".  So what's needed
    S> here is to honor the config file, treating only wins, bcast, and
    S> (optionally) lmhosts, and do something appropriately default-y if none of
    S> these are specified.

Message #30 received at 459972@bugs.debian.org (full text, mbox, reply):

From: Mathias Gug <mathiaz@ubuntu.com>

To: Steve Langasek <vorlon@debian.org>, 459972@bugs.debian.org

Subject: Re: [Pkg-samba-maint] Bug#459972: winbind: want to limit libnss_wins checks to WINS (no broadcasting)

Date: Thu, 10 Jan 2008 09:33:02 -0500

On Wed, Jan 09, 2008 at 03:42:12PM -0800, Steve Langasek wrote:
> On Wed, Jan 09, 2008 at 02:44:00PM -0800, Steve Langasek wrote:
> > Just to confirm, are you saying that setting "name resolve order = wins" in
> > /etc/samba/smb.conf does not fix this timeout problem for you?
> 
> > I don't think it makes sense to have nss_wins exposing different behavior to
> > the system than is used by Samba itself; but if it's not respecting the
> > smb.conf values, that's certainly a bug to be fixed IMHO.
> 
> Oh, but of course using the exact some logic as samba would mean causing a
> recursion in the case of "name resolve order = hosts".  So what's needed
> here is to honor the config file, treating only wins, bcast, and
> (optionally) lmhosts, and do something appropriately default-y if none of
> these are specified.
> 
> -- 
> Steve Langasek                   Give me a lever long enough and a Free OS
> Debian Developer                   to set it on, and I can move the world.
> Ubuntu Developer                                    http://www.debian.org/
> slangasek@ubuntu.com                                     vorlon@debian.org
> 
> 
> 
> _______________________________________________
> Pkg-samba-maint mailing list
> Pkg-samba-maint@lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/pkg-samba-maint

Message #35 received at 459972@bugs.debian.org (full text, mbox, reply):

From: Matt Swift <debian-bugs@mattswift.net>

To: 459972@bugs.debian.org

Subject: Re: Bug#459972: winbind: want to limit libnss_wins checks to WINS (no broadcasting)

Date: Thu, 10 Jan 2008 12:54:59 -0500

I tested a little more carefully, and the results are below

Summary of test environment:

Debian host Corax running Samba (version, dependencies, etc. in
initial report).  smb.conf globals included below. key settings are

	wins support = Yes
	dns proxy = No
	wins proxy = Yes

Corax is on a LAN (that's interface eth2 in smb.conf below).  DNS
server and Internet gateway on an embedded-Linux dedicated firewall
also on the LAN.  Corax is running a routed openvpn server (that's
interface tun0) but no hosts connected.  One other machine on the LAN
during testing: WinXP Pro box called Plankton, whose WINS server is
Corax.

winbindd installed but NOT running.

I conducted four tests (1-4) in each of four conditions (A-D).
During the tests, I monitored network traffic with Wireshark on both
Corax and Plankton (they're connected by a switch, not a hub).

Between conditions, I restarted nmbd and confirmed all instances were
stopped before restarting.

Each test was done with hostname 'luckyN' or 'luckyNN' where N is a
digit.  These are valid Netbios names, and because I increased the
number with each test (never re-using a hostname) caches shouldn't
affect results.  I represent the changing test hostname with just
"<unknown>" below.  The default domain name on all machines is
swift.private.

condition A
  /etc/samba/smb.conf -> name resolve order = wins
  /etc/nsswitch.conf -> hosts: files dns wins

condition B
  /etc/samba/smb.conf -> name resolve order = wins bcast
  /etc/nsswitch.conf -> hosts: files dns wins

Condition C and D are same as A and B but without "wins" in the NSS
layer.

condition C
  /etc/samba/smb.conf -> name resolve order = wins
  /etc/nsswitch.conf -> hosts: files dns

condition D
  /etc/samba/smb.conf -> name resolve order = wins bcast
  /etc/nsswitch.conf -> hosts: files dns

Test 1 gave one of two results (one for conditions A/B, another for
C/D).  Tests 2-4 gave the same results in all four conditions.  There
were other surprises as well.  See my comments on each test. My
expectations are probably incorrect in places, but still there seems
to be a problem with Samba.

test 1 (conditions A B)

  corax% ping <unknown>

  DNS query for <unknown>.swift.private fails
  assume that a WINS lookup fails
  NBNS broadcast from Corax for <unknown> (3 packets)

  comment: Samba SHOULDN'T broadcast when "name resolve order" doesn't
  contain "bcast" (condition B).

test 1 (C D)

  corax% ping <unknown>

  DNS query for <unknown>.swift.private fails

  comment: as expected


test 2 (A B C D)

  corax% nmblookup -U localhost -R <unknown>

  fails, i.e., no network traffic, no broadcast

  comment: Samba SHOULD broadcast when "name resolve order" contains
  "bcast" (conditions B and D).  Comment below on test 4 may apply as
  well.


test 3 (A B C D)

  plankton% ping <unknown>

  DNS query for <unknown>.swift.private fails
  NBNS query to Corax for <unknown> fails
  NBNS broadcast from Plankton for <unknown> (3 packets)

  comment: Samba SHOULD broadcast when "name resolve order" contains
  "bcast" (conditions B and D) -- but maybe Samba is smart enough to
  refrain from broadcasting after a failed query from a WinXP client
  that we know is going to fall back on doing a broadcast itself?

  
test 4 (A B C D)

  plankton% nblookup <unknown>

  NBNS query to Corax for <unknown> fails
  
  comment: same as for test 3, but regarding the question is Samba
  smart enough, etc., in this case, the assumption that Plankton will
  fall back on a broadcast is wrong because the WINS query was made
  with a diagnostic tool (nblookup) not the normal WinXP name
  resolution procedure.


smb.conf excerpt (value of "name resolve order" was varied):

[global]
	workgroup = TRANSFINITES
	netbios aliases = BRAIN
	server string = 
	interfaces = 127.0.0.1, eth2, tun0
	bind interfaces only = Yes
	obey pam restrictions = Yes
	passdb backend = tdbsam
	guest account = sambaguest
	passwd program = /usr/bin/passwd %u
	passwd chat = *Enter\snew\sUNIX\spassword:* %n\n *Retype\snew\sUNIX\spassword:* %n\n *password\supdated\ssuccessfully* .
	log level = 3 passdb:5 auth:10 winbind:5
	log file = /var/log/samba/log.%m
	max log size = 1000
	name resolve order = wins
	printcap name = cups
	lm announce = No
	preferred master = Yes
	domain master = Yes
	dns proxy = No
	wins proxy = Yes
	wins support = Yes
	ldap ssl = no
	panic action = /usr/share/samba/panic-action %d
	invalid users = root
	printer admin = @lp
	printing = cups
	print command = 
	lpq command = %p
	lprm command = 

Message #40 received at 459972@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Matt Swift <debian-bugs@mattswift.net>, 459972@bugs.debian.org

Subject: Re: Bug#459972: winbind: want to limit libnss_wins checks to WINS (no broadcasting)

Date: Thu, 10 Jan 2008 13:14:17 -0800

On Thu, Jan 10, 2008 at 12:54:59PM -0500, Matt Swift wrote:
> test 1 (conditions A B)

>   corax% ping <unknown>
> 
>   DNS query for <unknown>.swift.private fails
>   assume that a WINS lookup fails
>   NBNS broadcast from Corax for <unknown> (3 packets)
> 
>   comment: Samba SHOULDN'T broadcast when "name resolve order" doesn't
>   contain "bcast" (condition B).

Yep, we agree this is a bug.

> test 2 (A B C D)

>   corax% nmblookup -U localhost -R <unknown>

>   fails, i.e., no network traffic, no broadcast

>   comment: Samba SHOULD broadcast when "name resolve order" contains
>   "bcast" (conditions B and D).  Comment below on test 4 may apply as
>   well.

I don't agree.  nmblookup -U has precise semantics, which are "query the
server at this IP".  -R additionally tells it "query it as a WINS server".
Neither of these requests will ever generate external network traffic with
any server, Windows, Samba or otherwise.

nmblookup is not a general-purpose resolver, it's a tool for interacting
with the NMB protocol.  Its behavior is designed to facilitate working with
NMB, not for giving end-users a one-click way to resolve names.

> test 3 (A B C D)

>   plankton% ping <unknown>

>   DNS query for <unknown>.swift.private fails
>   NBNS query to Corax for <unknown> fails
>   NBNS broadcast from Plankton for <unknown> (3 packets)

>   comment: Samba SHOULD broadcast when "name resolve order" contains
>   "bcast" (conditions B and D) -- but maybe Samba is smart enough to
>   refrain from broadcasting after a failed query from a WinXP client
>   that we know is going to fall back on doing a broadcast itself?

Er, if plankton is the WinXP client, it's that client's responsibility to do
a broadcast query for the name if it's a hybrid node and if the WINS server
doesn't know the name.  Samba as WINS server is not going to (should not) do
broadcast queries on behalf of clients for names it doesn't know about.
(For one thing, it's the common case that the client and WINS server will
not be in the same broadcast domain!)

> test 4 (A B C D)

>   plankton% nblookup <unknown>

>   NBNS query to Corax for <unknown> fails

>   comment: same as for test 3, but regarding the question is Samba
>   smart enough, etc., in this case, the assumption that Plankton will
>   fall back on a broadcast is wrong because the WINS query was made
>   with a diagnostic tool (nblookup) not the normal WinXP name
>   resolution procedure.

Yes, Windows won't fall back to a broadcast; but it's still not the WINS
server's responsibility to do a broadcast in that case.  That's not how the
protocol works.

So we still have the same one bug here - nss_wins behaves in a manner
inconsistent with smbclient and samba wrt the "name resolve order" option.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

Message #45 received at 459972@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Matt Swift <debian-bugs@mattswift.net>, 459972@bugs.debian.org

Subject: Re: Bug#459972: winbind: want to limit libnss_wins checks to WINS (no broadcasting)

Date: Thu, 10 Jan 2008 13:38:18 -0800

On Wed, Jan 09, 2008 at 07:23:10PM -0500, Matt Swift wrote:

> Yes, and as I alluded in mail just sent, a recursion loop seems
> possible with "dns proxy=yes" as well, unless that check is not going
> to use the NSS layer.

Heh, yes, the 'dns proxy' option uses gethostbyname(), which is an NSS-based
call, so this could be recursive.  Sorry, "don't do that". :)

(dns proxy is one of those old options that Seemed Like A Good Idea At The
Time, anyway; I can't imagine why anyone would want to use that with any
clients deployed in the past 10 years, all of which should be capable of
doing DNS directly as needed.)

> On a related note, you might want to document that you don't actually
> have to run windbindd to get the "hosts: wins" NSS service, you just
> need to run a WINS server and have /lib/libnss_wins.so (I think).  The
> fact that libnss_wins.so installs by default to run winbindd in Debian
> suggests that you need to run it for all features described in
> winbindd man page (i.e., be good if the winbindd man page said you
> don't have to run winbindd to get the NSS functionality, even though
> it's the winbindd man page that's documenting it).

Hum, it's part of the winbind package because winbind is the "make my
machine integrate with Windows domains" package.  nss_wins is not a
prerequisite for winbindd, nor is winbindd a prerequisite for nss_wins, but
winbindd is started by default and packaged together win nss_wins because I
think it would be splitting hairs to do otherwise when considering the
common usage scenarios.

I agree that there's room for improvement in the documentation here.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

Message #52 received at 459972@bugs.debian.org (full text, mbox, reply):

From: Andrew Bartlett <abartlet@samba.org>

To: 459972@bugs.debian.org

Subject: nss_wins uses winbind, which only does wins

Date: Mon, 17 Jul 2017 20:45:12 +1200

Version: 4.2.0

G'Day,

nss_wins now uses winbindd (not direct socket access), and that only
does a WINS lookup, not a broadcast lookup.

Samba 4.2.14 was forced into all supported releases by the 'badlock'
fixes a year ago.

Thanks,

Andrew Bartlett
-- 
Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba

Message #57 received at 459972-done@bugs.debian.org (full text, mbox, reply):

From: Andrew Bartlett <abartlet@samba.org>

To: 459972-done@bugs.debian.org

Subject: nss_wins uses winbind, which only does wins

Date: Mon, 17 Jul 2017 20:45:31 +1200

Version: 4.2.0

G'Day,

nss_wins now uses winbindd (not direct socket access), and that only
does a WINS lookup, not a broadcast lookup.

Samba 4.2.14 was forced into all supported releases by the 'badlock'
fixes a year ago.

Thanks,

Andrew Bartlett
-- 
Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba

Send a report that this bug log contains spam.