mirror of
https://github.com/samba-team/samba.git
synced 2025-01-19 10:03:58 +03:00
805 lines
20 KiB
HTML
805 lines
20 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<HTML
|
|
><HEAD
|
|
><TITLE
|
|
>Quick Cross Subnet Browsing / Cross Workgroup Browsing guide</TITLE
|
|
><META
|
|
NAME="GENERATOR"
|
|
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
|
|
REL="HOME"
|
|
TITLE="SAMBA Project Documentation"
|
|
HREF="samba-howto-collection.html"><LINK
|
|
REL="UP"
|
|
TITLE="General installation"
|
|
HREF="introduction.html"><LINK
|
|
REL="PREVIOUS"
|
|
TITLE="How to Install and Test SAMBA"
|
|
HREF="install.html"><LINK
|
|
REL="NEXT"
|
|
TITLE="User information database"
|
|
HREF="passdb.html"></HEAD
|
|
><BODY
|
|
CLASS="CHAPTER"
|
|
BGCOLOR="#FFFFFF"
|
|
TEXT="#000000"
|
|
LINK="#0000FF"
|
|
VLINK="#840084"
|
|
ALINK="#0000FF"
|
|
><DIV
|
|
CLASS="NAVHEADER"
|
|
><TABLE
|
|
SUMMARY="Header navigation table"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TH
|
|
COLSPAN="3"
|
|
ALIGN="center"
|
|
>SAMBA Project Documentation</TH
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="left"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="install.html"
|
|
ACCESSKEY="P"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="80%"
|
|
ALIGN="center"
|
|
VALIGN="bottom"
|
|
></TD
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="right"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="passdb.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"></DIV
|
|
><DIV
|
|
CLASS="CHAPTER"
|
|
><H1
|
|
><A
|
|
NAME="BROWSING-QUICK"
|
|
></A
|
|
>Chapter 3. Quick Cross Subnet Browsing / Cross Workgroup Browsing guide</H1
|
|
><DIV
|
|
CLASS="TOC"
|
|
><DL
|
|
><DT
|
|
><B
|
|
>Table of Contents</B
|
|
></DT
|
|
><DT
|
|
>3.1. <A
|
|
HREF="browsing-quick.html#AEN305"
|
|
>Discussion</A
|
|
></DT
|
|
><DT
|
|
>3.2. <A
|
|
HREF="browsing-quick.html#AEN326"
|
|
>How browsing functions and how to deploy stable and
|
|
dependable browsing using Samba</A
|
|
></DT
|
|
><DT
|
|
>3.3. <A
|
|
HREF="browsing-quick.html#AEN340"
|
|
>Use of the <B
|
|
CLASS="COMMAND"
|
|
>Remote Announce</B
|
|
> parameter</A
|
|
></DT
|
|
><DT
|
|
>3.4. <A
|
|
HREF="browsing-quick.html#AEN363"
|
|
>Use of the <B
|
|
CLASS="COMMAND"
|
|
>Remote Browse Sync</B
|
|
> parameter</A
|
|
></DT
|
|
><DT
|
|
>3.5. <A
|
|
HREF="browsing-quick.html#AEN374"
|
|
>Use of WINS</A
|
|
></DT
|
|
><DD
|
|
><DL
|
|
><DT
|
|
>3.5.1. <A
|
|
HREF="browsing-quick.html#AEN391"
|
|
>WINS Replication</A
|
|
></DT
|
|
><DT
|
|
>3.5.2. <A
|
|
HREF="browsing-quick.html#AEN395"
|
|
>Static WINS Entries</A
|
|
></DT
|
|
></DL
|
|
></DD
|
|
><DT
|
|
>3.6. <A
|
|
HREF="browsing-quick.html#AEN400"
|
|
>Do NOT use more than one (1) protocol on MS Windows machines</A
|
|
></DT
|
|
><DT
|
|
>3.7. <A
|
|
HREF="browsing-quick.html#AEN408"
|
|
>Name Resolution Order</A
|
|
></DT
|
|
></DL
|
|
></DIV
|
|
><P
|
|
>This document should be read in conjunction with Browsing and may
|
|
be taken as the fast track guide to implementing browsing across subnets
|
|
and / or across workgroups (or domains). WINS is the best tool for resolution
|
|
of NetBIOS names to IP addesses. WINS is NOT involved in browse list handling
|
|
except by way of name to address mapping.</P
|
|
><DIV
|
|
CLASS="NOTE"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="NOTE"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="/usr/share/sgml/docbook/stylesheet/dsssl/modular/images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
>MS Windows 2000 and later can be configured to operate with NO NetBIOS
|
|
over TCP/IP. Samba-3 and later also supports this mode of operation.</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT1"
|
|
><H1
|
|
CLASS="SECT1"
|
|
><A
|
|
NAME="AEN305"
|
|
>3.1. Discussion</A
|
|
></H1
|
|
><P
|
|
>Firstly, all MS Windows networking is based on SMB (Server Message
|
|
Block) based messaging. SMB messaging may be implemented using NetBIOS or
|
|
without NetBIOS. Samba implements NetBIOS by encapsulating it over TCP/IP.
|
|
MS Windows products can do likewise. NetBIOS based networking uses broadcast
|
|
messaging to affect browse list management. When running NetBIOS over
|
|
TCP/IP this uses UDP based messaging. UDP messages can be broadcast or unicast.</P
|
|
><P
|
|
>Normally, only unicast UDP messaging can be forwarded by routers. The
|
|
<B
|
|
CLASS="COMMAND"
|
|
>remote announce</B
|
|
>
|
|
parameter to smb.conf helps to project browse announcements
|
|
to remote network segments via unicast UDP. Similarly, the
|
|
<B
|
|
CLASS="COMMAND"
|
|
>remote browse sync</B
|
|
> parameter of <TT
|
|
CLASS="FILENAME"
|
|
>smb.conf</TT
|
|
>
|
|
implements browse list collation using unicast UDP.</P
|
|
><P
|
|
>Secondly, in those networks where Samba is the only SMB server technology
|
|
wherever possible <SPAN
|
|
CLASS="APPLICATION"
|
|
>nmbd</SPAN
|
|
> should be configured on one (1) machine as the WINS
|
|
server. This makes it easy to manage the browsing environment. If each network
|
|
segment is configured with it's own Samba WINS server, then the only way to
|
|
get cross segment browsing to work is by using the
|
|
<B
|
|
CLASS="COMMAND"
|
|
>remote announce</B
|
|
> and the <B
|
|
CLASS="COMMAND"
|
|
>remote browse sync</B
|
|
>
|
|
parameters to your <TT
|
|
CLASS="FILENAME"
|
|
>smb.conf</TT
|
|
> file.</P
|
|
><P
|
|
>If only one WINS server is used for an entire multi-segment network then
|
|
the use of the <B
|
|
CLASS="COMMAND"
|
|
>remote announce</B
|
|
> and the
|
|
<B
|
|
CLASS="COMMAND"
|
|
>remote browse sync</B
|
|
> parameters should NOT be necessary.</P
|
|
><P
|
|
>As of Samba 3 WINS replication is being worked on. The bulk of the code has
|
|
been committed, but it still needs maturation.</P
|
|
><P
|
|
>Right now samba WINS does not support MS-WINS replication. This means that
|
|
when setting up Samba as a WINS server there must only be one <SPAN
|
|
CLASS="APPLICATION"
|
|
>nmbd</SPAN
|
|
> configured
|
|
as a WINS server on the network. Some sites have used multiple Samba WINS
|
|
servers for redundancy (one server per subnet) and then used
|
|
<B
|
|
CLASS="COMMAND"
|
|
>remote browse sync</B
|
|
> and <B
|
|
CLASS="COMMAND"
|
|
>remote announce</B
|
|
>
|
|
to affect browse list collation across all
|
|
segments. Note that this means clients will only resolve local names,
|
|
and must be configured to use DNS to resolve names on other subnets in
|
|
order to resolve the IP addresses of the servers they can see on other
|
|
subnets. This setup is not recommended, but is mentioned as a practical
|
|
consideration (ie: an 'if all else fails' scenario).</P
|
|
><P
|
|
>Lastly, take note that browse lists are a collection of unreliable broadcast
|
|
messages that are repeated at intervals of not more than 15 minutes. This means
|
|
that it will take time to establish a browse list and it can take up to 45
|
|
minutes to stabilise, particularly across network segments.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT1"
|
|
><H1
|
|
CLASS="SECT1"
|
|
><A
|
|
NAME="AEN326"
|
|
>3.2. How browsing functions and how to deploy stable and
|
|
dependable browsing using Samba</A
|
|
></H1
|
|
><P
|
|
>As stated above, MS Windows machines register their NetBIOS names
|
|
(i.e.: the machine name for each service type in operation) on start
|
|
up. Also, as stated above, the exact method by which this name registration
|
|
takes place is determined by whether or not the MS Windows client/server
|
|
has been given a WINS server address, whether or not LMHOSTS lookup
|
|
is enabled, or if DNS for NetBIOS name resolution is enabled, etc.</P
|
|
><P
|
|
>In the case where there is no WINS server all name registrations as
|
|
well as name lookups are done by UDP broadcast. This isolates name
|
|
resolution to the local subnet, unless LMHOSTS is used to list all
|
|
names and IP addresses. In such situations Samba provides a means by
|
|
which the samba server name may be forcibly injected into the browse
|
|
list of a remote MS Windows network (using the
|
|
<B
|
|
CLASS="COMMAND"
|
|
>remote announce</B
|
|
> parameter).</P
|
|
><P
|
|
>Where a WINS server is used, the MS Windows client will use UDP
|
|
unicast to register with the WINS server. Such packets can be routed
|
|
and thus WINS allows name resolution to function across routed networks.</P
|
|
><P
|
|
>During the startup process an election will take place to create a
|
|
local master browser if one does not already exist. On each NetBIOS network
|
|
one machine will be elected to function as the domain master browser. This
|
|
domain browsing has nothing to do with MS security domain control.
|
|
Instead, the domain master browser serves the role of contacting each local
|
|
master browser (found by asking WINS or from LMHOSTS) and exchanging browse
|
|
list contents. This way every master browser will eventually obtain a complete
|
|
list of all machines that are on the network. Every 11-15 minutes an election
|
|
is held to determine which machine will be the master browser. By the nature of
|
|
the election criteria used, the machine with the highest uptime, or the
|
|
most senior protocol version, or other criteria, will win the election
|
|
as domain master browser.</P
|
|
><P
|
|
>Clients wishing to browse the network make use of this list, but also depend
|
|
on the availability of correct name resolution to the respective IP
|
|
address/addresses. </P
|
|
><P
|
|
>Any configuration that breaks name resolution and/or browsing intrinsics
|
|
will annoy users because they will have to put up with protracted
|
|
inability to use the network services.</P
|
|
><P
|
|
>Samba supports a feature that allows forced synchonisation
|
|
of browse lists across routed networks using the <B
|
|
CLASS="COMMAND"
|
|
>remote
|
|
browse sync</B
|
|
> parameter in the <TT
|
|
CLASS="FILENAME"
|
|
>smb.conf</TT
|
|
> file.
|
|
This causes Samba to contact the local master browser on a remote network and
|
|
to request browse list synchronisation. This effectively bridges
|
|
two networks that are separated by routers. The two remote
|
|
networks may use either broadcast based name resolution or WINS
|
|
based name resolution, but it should be noted that the <B
|
|
CLASS="COMMAND"
|
|
>remote
|
|
browse sync</B
|
|
> parameter provides browse list synchronisation - and
|
|
that is distinct from name to address resolution, in other
|
|
words, for cross subnet browsing to function correctly it is
|
|
essential that a name to address resolution mechanism be provided.
|
|
This mechanism could be via DNS, <TT
|
|
CLASS="FILENAME"
|
|
>/etc/hosts</TT
|
|
>,
|
|
and so on.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT1"
|
|
><H1
|
|
CLASS="SECT1"
|
|
><A
|
|
NAME="AEN340"
|
|
>3.3. Use of the <B
|
|
CLASS="COMMAND"
|
|
>Remote Announce</B
|
|
> parameter</A
|
|
></H1
|
|
><P
|
|
>The <B
|
|
CLASS="COMMAND"
|
|
>remote announce</B
|
|
> parameter of
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>smb.conf</TT
|
|
> can be used to forcibly ensure
|
|
that all the NetBIOS names on a network get announced to a remote network.
|
|
The syntax of the <B
|
|
CLASS="COMMAND"
|
|
>remote announce</B
|
|
> parameter is:
|
|
<PRE
|
|
CLASS="PROGRAMLISTING"
|
|
> remote announce = <VAR
|
|
CLASS="REPLACEABLE"
|
|
>a.b.c.d [e.f.g.h]</VAR
|
|
> ...</PRE
|
|
>
|
|
_or_
|
|
<PRE
|
|
CLASS="PROGRAMLISTING"
|
|
> remote announce = <VAR
|
|
CLASS="REPLACEABLE"
|
|
>a.b.c.d/WORKGROUP [e.f.g.h/WORKGROUP]</VAR
|
|
> ...</PRE
|
|
>
|
|
|
|
where:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
><VAR
|
|
CLASS="REPLACEABLE"
|
|
>a.b.c.d</VAR
|
|
> and
|
|
<VAR
|
|
CLASS="REPLACEABLE"
|
|
>e.f.g.h</VAR
|
|
></DT
|
|
><DD
|
|
><P
|
|
>is either the LMB (Local Master Browser) IP address
|
|
or the broadcst address of the remote network.
|
|
ie: the LMB is at 192.168.1.10, or the address
|
|
could be given as 192.168.1.255 where the netmask
|
|
is assumed to be 24 bits (255.255.255.0).
|
|
When the remote announcement is made to the broadcast
|
|
address of the remote network every host will receive
|
|
our announcements. This is noisy and therefore
|
|
undesirable but may be necessary if we do NOT know
|
|
the IP address of the remote LMB.</P
|
|
></DD
|
|
><DT
|
|
><VAR
|
|
CLASS="REPLACEABLE"
|
|
>WORKGROUP</VAR
|
|
></DT
|
|
><DD
|
|
><P
|
|
>is optional and can be either our own workgroup
|
|
or that of the remote network. If you use the
|
|
workgroup name of the remote network then our
|
|
NetBIOS machine names will end up looking like
|
|
they belong to that workgroup, this may cause
|
|
name resolution problems and should be avoided.</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT1"
|
|
><H1
|
|
CLASS="SECT1"
|
|
><A
|
|
NAME="AEN363"
|
|
>3.4. Use of the <B
|
|
CLASS="COMMAND"
|
|
>Remote Browse Sync</B
|
|
> parameter</A
|
|
></H1
|
|
><P
|
|
>The <B
|
|
CLASS="COMMAND"
|
|
>remote browse sync</B
|
|
> parameter of
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>smb.conf</TT
|
|
> is used to announce to
|
|
another LMB that it must synchronise it's NetBIOS name list with our
|
|
Samba LMB. It works ONLY if the Samba server that has this option is
|
|
simultaneously the LMB on it's network segment.</P
|
|
><P
|
|
>The syntax of the <B
|
|
CLASS="COMMAND"
|
|
>remote browse sync</B
|
|
> parameter is:
|
|
|
|
<PRE
|
|
CLASS="PROGRAMLISTING"
|
|
>remote browse sync = <VAR
|
|
CLASS="REPLACEABLE"
|
|
>a.b.c.d</VAR
|
|
></PRE
|
|
>
|
|
|
|
where <VAR
|
|
CLASS="REPLACEABLE"
|
|
>a.b.c.d</VAR
|
|
> is either the IP address of the remote LMB or else is the network broadcast address of the remote segment.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT1"
|
|
><H1
|
|
CLASS="SECT1"
|
|
><A
|
|
NAME="AEN374"
|
|
>3.5. Use of WINS</A
|
|
></H1
|
|
><P
|
|
>Use of WINS (either Samba WINS _or_ MS Windows NT Server WINS) is highly
|
|
recommended. Every NetBIOS machine registers it's name together with a
|
|
name_type value for each of of several types of service it has available.
|
|
eg: It registers it's name directly as a unique (the type 0x03) name.
|
|
It also registers it's name if it is running the lanmanager compatible
|
|
server service (used to make shares and printers available to other users)
|
|
by registering the server (the type 0x20) name.</P
|
|
><P
|
|
>All NetBIOS names are up to 15 characters in length. The name_type variable
|
|
is added to the end of the name - thus creating a 16 character name. Any
|
|
name that is shorter than 15 characters is padded with spaces to the 15th
|
|
character. ie: All NetBIOS names are 16 characters long (including the
|
|
name_type information).</P
|
|
><P
|
|
>WINS can store these 16 character names as they get registered. A client
|
|
that wants to log onto the network can ask the WINS server for a list
|
|
of all names that have registered the NetLogon service name_type. This saves
|
|
broadcast traffic and greatly expedites logon processing. Since broadcast
|
|
name resolution can not be used across network segments this type of
|
|
information can only be provided via WINS _or_ via statically configured
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>lmhosts</TT
|
|
> files that must reside on all clients in the
|
|
absence of WINS.</P
|
|
><P
|
|
>WINS also serves the purpose of forcing browse list synchronisation by all
|
|
LMB's. LMB's must synchronise their browse list with the DMB (domain master
|
|
browser) and WINS helps the LMB to identify it's DMB. By definition this
|
|
will work only within a single workgroup. Note that the domain master browser
|
|
has NOTHING to do with what is referred to as an MS Windows NT Domain. The
|
|
later is a reference to a security environment while the DMB refers to the
|
|
master controller for browse list information only.</P
|
|
><P
|
|
>Use of WINS will work correctly only if EVERY client TCP/IP protocol stack
|
|
has been configured to use the WINS server/s. Any client that has not been
|
|
configured to use the WINS server will continue to use only broadcast based
|
|
name registration so that WINS may NEVER get to know about it. In any case,
|
|
machines that have not registered with a WINS server will fail name to address
|
|
lookup attempts by other clients and will therefore cause workstation access
|
|
errors.</P
|
|
><P
|
|
>To configure Samba as a WINS server just add
|
|
<B
|
|
CLASS="COMMAND"
|
|
>wins support = yes</B
|
|
> to the <TT
|
|
CLASS="FILENAME"
|
|
>smb.conf</TT
|
|
>
|
|
file [globals] section.</P
|
|
><P
|
|
>To configure Samba to register with a WINS server just add
|
|
"wins server = a.b.c.d" to your smb.conf file [globals] section.</P
|
|
><DIV
|
|
CLASS="IMPORTANT"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="IMPORTANT"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="/usr/share/sgml/docbook/stylesheet/dsssl/modular/images/important.gif"
|
|
HSPACE="5"
|
|
ALT="Important"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
>Never use both <B
|
|
CLASS="COMMAND"
|
|
>wins support = yes</B
|
|
> together
|
|
with <B
|
|
CLASS="COMMAND"
|
|
>wins server = a.b.c.d</B
|
|
>
|
|
particularly not using it's own IP address.
|
|
Specifying both will cause <SPAN
|
|
CLASS="APPLICATION"
|
|
>nmbd</SPAN
|
|
> to refuse to start!</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN391"
|
|
>3.5.1. WINS Replication</A
|
|
></H2
|
|
><P
|
|
>Samba-3 permits WINS replication through the use of the <TT
|
|
CLASS="FILENAME"
|
|
>wrepld</TT
|
|
> utility.
|
|
This tool is not currently capable of being used as it is still in active development.
|
|
As soon as this tool becomes moderately functional we will prepare man pages and enhance this
|
|
section of the documentation to provide usage and technical details.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN395"
|
|
>3.5.2. Static WINS Entries</A
|
|
></H2
|
|
><P
|
|
>New to Samba-3 is a tool called <TT
|
|
CLASS="FILENAME"
|
|
>winsedit</TT
|
|
> that may be used to add
|
|
static WINS entries to the WINS database. This tool can be used also to modify entries
|
|
existing in the WINS database.</P
|
|
><P
|
|
>The development of the winsedit tool was made necessary due to the migration
|
|
of the older style wins.dat file into a new tdb binary backend data store.</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT1"
|
|
><H1
|
|
CLASS="SECT1"
|
|
><A
|
|
NAME="AEN400"
|
|
>3.6. Do NOT use more than one (1) protocol on MS Windows machines</A
|
|
></H1
|
|
><P
|
|
>A very common cause of browsing problems results from installing more than
|
|
one protocol on an MS Windows machine.</P
|
|
><P
|
|
>Every NetBIOS machine takes part in a process of electing the LMB (and DMB)
|
|
every 15 minutes. A set of election criteria is used to determine the order
|
|
of precidence for winning this election process. A machine running Samba or
|
|
Windows NT will be biased so that the most suitable machine will predictably
|
|
win and thus retain it's role.</P
|
|
><P
|
|
>The election process is "fought out" so to speak over every NetBIOS network
|
|
interface. In the case of a Windows 9x machine that has both TCP/IP and IPX
|
|
installed and has NetBIOS enabled over both protocols the election will be
|
|
decided over both protocols. As often happens, if the Windows 9x machine is
|
|
the only one with both protocols then the LMB may be won on the NetBIOS
|
|
interface over the IPX protocol. Samba will then lose the LMB role as Windows
|
|
9x will insist it knows who the LMB is. Samba will then cease to function
|
|
as an LMB and thus browse list operation on all TCP/IP only machines will
|
|
fail.</P
|
|
><P
|
|
><SPAN
|
|
CLASS="emphasis"
|
|
><I
|
|
CLASS="EMPHASIS"
|
|
>Windows 95, 98, 98se, Me are referred to generically as Windows 9x.
|
|
The Windows NT4, 2000, XP and 2003 use common protocols. These are roughly
|
|
referred to as the WinNT family, but it should be recognised that 2000 and
|
|
XP/2003 introduce new protocol extensions that cause them to behave
|
|
differently from MS Windows NT4. Generally, where a server does NOT support
|
|
the newer or extended protocol, these will fall back to the NT4 protocols.</I
|
|
></SPAN
|
|
></P
|
|
><P
|
|
>The safest rule of all to follow it this - USE ONLY ONE PROTOCOL!</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT1"
|
|
><H1
|
|
CLASS="SECT1"
|
|
><A
|
|
NAME="AEN408"
|
|
>3.7. Name Resolution Order</A
|
|
></H1
|
|
><P
|
|
>Resolution of NetBIOS names to IP addresses can take place using a number
|
|
of methods. The only ones that can provide NetBIOS name_type information
|
|
are:</P
|
|
><P
|
|
></P
|
|
><TABLE
|
|
BORDER="0"
|
|
><TBODY
|
|
><TR
|
|
><TD
|
|
>WINS: the best tool!</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
>LMHOSTS: is static and hard to maintain.</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
>Broadcast: uses UDP and can not resolve names across remote segments.</TD
|
|
></TR
|
|
></TBODY
|
|
></TABLE
|
|
><P
|
|
></P
|
|
><P
|
|
>Alternative means of name resolution includes:</P
|
|
><P
|
|
></P
|
|
><TABLE
|
|
BORDER="0"
|
|
><TBODY
|
|
><TR
|
|
><TD
|
|
>/etc/hosts: is static, hard to maintain, and lacks name_type info</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
>DNS: is a good choice but lacks essential name_type info.</TD
|
|
></TR
|
|
></TBODY
|
|
></TABLE
|
|
><P
|
|
></P
|
|
><P
|
|
>Many sites want to restrict DNS lookups and want to avoid broadcast name
|
|
resolution traffic. The "name resolve order" parameter is of great help here.
|
|
The syntax of the "name resolve order" parameter is:
|
|
<PRE
|
|
CLASS="PROGRAMLISTING"
|
|
>name resolve order = wins lmhosts bcast host</PRE
|
|
>
|
|
_or_
|
|
<PRE
|
|
CLASS="PROGRAMLISTING"
|
|
>name resolve order = wins lmhosts (eliminates bcast and host)</PRE
|
|
>
|
|
The default is:
|
|
<PRE
|
|
CLASS="PROGRAMLISTING"
|
|
>name resolve order = host lmhost wins bcast</PRE
|
|
>.
|
|
where "host" refers the the native methods used by the Unix system
|
|
to implement the gethostbyname() function call. This is normally
|
|
controlled by <TT
|
|
CLASS="FILENAME"
|
|
>/etc/host.conf</TT
|
|
>, <TT
|
|
CLASS="FILENAME"
|
|
>/etc/nsswitch.conf</TT
|
|
> and <TT
|
|
CLASS="FILENAME"
|
|
>/etc/resolv.conf</TT
|
|
>.</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="NAVFOOTER"
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"><TABLE
|
|
SUMMARY="Footer navigation table"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="install.html"
|
|
ACCESSKEY="P"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="samba-howto-collection.html"
|
|
ACCESSKEY="H"
|
|
>Home</A
|
|
></TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="passdb.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
>How to Install and Test SAMBA</TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="introduction.html"
|
|
ACCESSKEY="U"
|
|
>Up</A
|
|
></TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
>User information database</TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></BODY
|
|
></HTML
|
|
> |