Samba related question.

bscott at ntisys.com bscott at ntisys.com
Tue Feb 17 23:19:10 EST 2004


On Fri, 13 Feb 2004, at 12:58pm, p.lussier at comcast.net wrote:
> Well, I suppose so.  But it's really client/server no matter how MS wishes
> to look at it :)

  Absolutely.  Alas, if you're using NetBIOS, chances are, you're using
Microsoft, which means you have to deal with their brain damage.

> Right, sorry, as you correctly state further down, I was confusing WINS w/
> NetBIOS.

  Just to be *really* pedantic:

  NetBIOS is the whole suite of protocols.  WINS is a method for centralized
registration of names in NetBIOS.  In fact, the *official* name for WINS is
"NetBIOS Name Service", or NBNS.  Microsoft, of course, had to make up their
own name.  "Broadcast" is the other major form of name resolution under
NetBIOS.

  I realize that, you, Paul, understand this stuff (even if the terminology
is a bit fuzzy), but others might not, so I want to be as clear and exact as
possible.

> My bad.  I was using the term 'broadcast' to mean announce, not actually
> broadcast.  When Samba starts up, it will make a NetBIOS request of 'Can I
> use this hostname', the NetBIOS server will either say yes or no.

  Further pedantic clarification:

NAME RESOLUTION

  When a NetBIOS node starts up, it attempts to register the name(s) it
wants.  Depending on configuration, it will either (1) broadcast to the
local network, (2) contact a WINS server, or (3) both.

  When a NetBIOS node wants to find another NetBIOS name, it will either (1)  
broadcast to the local network, (2) contact a WINS server, or (3) both.

  A NetBIOS node will typically listen on the local network for broadcasts
for its own names, and respond to those broadcasts with unicast replies.

  With Windows, you can configure name resolution by setting the "NetBIOS
Node Type".  There are four values, that translate to "WINS only",
"broadcast only", "WINS then broadcast", or "broadcast then WINS".  This can
be set in the Windows Registry, or with DHCP.  For Samba, you simply define
the "name resolve order".

  For large LANs, or for networks with multiple LANs, I recommend using
"WINS only".  Excessive broadcast traffic can slow down a large LAN, and
broadcasts don't work at all across multiple LANs.

NETBIOS BROWSERS

  When a NetBIOS node wants to enumerate all the other NetBIOS nodes in a
workgroup, it contacts the "master browser" for the workgroup.  It finds the
master browser by searching for the workgroup name (using the name
resolution mechanisms described above).  It then contacts the browser and
asks for the list.

  Master browsers "elect" themselves automatically.  This is good from an
auto-configuration stand-point, but bad in the sense that it is quite easy
for the whole system to go haywire.  Different computers can end up using
different master browsers, and various NetBIOS nodes can constantly fight to
become the master browser (called a "browser war").

  Microsoft Windows is designed to give newer versions of Windows preference
in browser elections.  The "Server" flavors of Windows also get preference.  
Any "Domain Controller" server gets even more preference.  Most of this
stuff is hard coded, and you have very little control over it, other then
"try to become a browser" and "do not try to become a browser" options.

  Samba, in contrast, exposes all this stuff, in the "local master", "domain
master", "preferred master", and "os level" parameters.  For this reason,
the addition of a Samba server, with all values set "on" or to high values,
will solve all your browser war problems.  (Just beware not to do this on
more then *one* Samba server.)

  There are also "backup browsers", as well as "local master browsers" and
"domain master browsers".  But this message is already complex enough.  :)

> Thanks for correcting me once again Ben, and I promise not to answer
> technical e-mails when I should be going to sleep (which is damn near
> all the time ;)

  Join the club.  :-)

-- 
Ben Scott <bscott at ntisys.com>
| The opinions expressed in this message are those of the author and do  |
| not represent the views or policy of any other person or organization. |
| All information is provided without warranty of any kind.              |





More information about the gnhlug-discuss mailing list