+++ /dev/null
-<chapter id="Browsing-Quick">
-<chapterinfo>
- &author.jht;
- <pubdate>July 5, 1998</pubdate>
- <pubdate>Updated: March 15, 2003</pubdate>
-</chapterinfo>
-
-<title>Quick Cross Subnet Browsing / Cross Workgroup Browsing guide</title>
-
-<para>
-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.
-</para>
-
-<note><para>
-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.
-</para></note>
-
-
-<sect1>
-<title>Discussion</title>
-
-<para>
-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.
-</para>
-
-<para>
-Normally, only unicast UDP messaging can be forwarded by routers. The
-<command>remote announce</command>
-parameter to smb.conf helps to project browse announcements
-to remote network segments via unicast UDP. Similarly, the
-<command>remote browse sync</command> parameter of <filename>smb.conf</filename>
-implements browse list collation using unicast UDP.
-</para>
-
-<para>
-Secondly, in those networks where Samba is the only SMB server technology
-wherever possible &nmbd; 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
-<command>remote announce</command> and the <command>remote browse sync</command>
-parameters to your <filename>smb.conf</filename> file.
-</para>
-
-<para>
-If only one WINS server is used for an entire multi-segment network then
-the use of the <command>remote announce</command> and the
-<command>remote browse sync</command> parameters should NOT be necessary.
-</para>
-
-<para>
-As of Samba 3 WINS replication is being worked on. The bulk of the code has
-been committed, but it still needs maturation.
-</para>
-
-<para>
-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 &nmbd; 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
-<command>remote browse sync</command> and <command>remote announce</command>
-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).
-</para>
-
-<para>
-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.
-</para>
-
-</sect1>
-
-<sect1>
-<title>How browsing functions and how to deploy stable and
-dependable browsing using Samba</title>
-
-
-<para>
-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.
-</para>
-
-<para>
-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
-<command>remote announce</command> parameter).
-</para>
-
-<para>
-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.
-</para>
-
-<para>
-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.
-</para>
-
-<para>
-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.
-</para>
-
-<para>
-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.
-</para>
-
-<para>
-Samba supports a feature that allows forced synchonisation
-of browse lists across routed networks using the <command>remote
-browse sync</command> parameter in the <filename>smb.conf</filename> 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 <command>remote
-browse sync</command> 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, <filename>/etc/hosts</filename>,
-and so on.
-</para>
-
-</sect1>
-
-<sect1>
-<title>Use of the <command>Remote Announce</command> parameter</title>
-<para>
-The <command>remote announce</command> parameter of
-<filename>smb.conf</filename> can be used to forcibly ensure
-that all the NetBIOS names on a network get announced to a remote network.
-The syntax of the <command>remote announce</command> parameter is:
-<programlisting>
- remote announce = <replaceable>a.b.c.d [e.f.g.h]</replaceable> ...
-</programlisting>
-_or_
-<programlisting>
- remote announce = <replaceable>a.b.c.d/WORKGROUP [e.f.g.h/WORKGROUP]</replaceable> ...
-</programlisting>
-
-where:
-<variablelist>
-<varlistentry><term><replaceable>a.b.c.d</replaceable> and
-<replaceable>e.f.g.h</replaceable></term>
-<listitem><para>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.</para></listitem>
-</varlistentry>
-
-<varlistentry>
-<term><replaceable>WORKGROUP</replaceable></term>
-<listitem><para>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.
-</para></listitem>
-</varlistentry>
-</variablelist>
-</para>
-
-</sect1>
-
-<sect1>
-<title>Use of the <command>Remote Browse Sync</command> parameter</title>
-
-<para>
-The <command>remote browse sync</command> parameter of
-<filename>smb.conf</filename> 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.
-</para>
-
-<para>
-The syntax of the <command>remote browse sync</command> parameter is:
-
-<programlisting>
-remote browse sync = <replaceable>a.b.c.d</replaceable>
-</programlisting>
-
-where <replaceable>a.b.c.d</replaceable> is either the IP address of the remote LMB or else is the network broadcast address of the remote segment.
-</para>
-
-</sect1>
-
-<sect1>
-<title>Use of WINS</title>
-
-<para>
-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.
-</para>
-
-<para>
-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).
-</para>
-
-<para>
-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
-<filename>lmhosts</filename> files that must reside on all clients in the
-absence of WINS.
-</para>
-
-<para>
-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.
-</para>
-
-<para>
-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.
-</para>
-
-<para>
-To configure Samba as a WINS server just add
-<command>wins support = yes</command> to the <filename>smb.conf</filename>
-file [globals] section.
-</para>
-
-<para>
-To configure Samba to register with a WINS server just add
-"wins server = a.b.c.d" to your smb.conf file [globals] section.
-</para>
-
-<important><para>
-Never use both <command>wins support = yes</command> together
-with <command>wins server = a.b.c.d</command>
-particularly not using it's own IP address.
-Specifying both will cause &nmbd; to refuse to start!
-</para></important>
-
-<sect2>
-<title>WINS Replication</title>
-
-<para>
-Samba-3 permits WINS replication through the use of the <filename>wrepld</filename> 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.
-</para>
-
-</sect2>
-<sect2>
-<title>Static WINS Entries</title>
-
-<para>
-New to Samba-3 is a tool called <filename>winsedit</filename> 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.
-</para>
-
-<para>
-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.
-</para>
-
-</sect2>
-</sect1>
-
-<sect1>
-<title>Do NOT use more than one (1) protocol on MS Windows machines</title>
-
-<para>
-A very common cause of browsing problems results from installing more than
-one protocol on an MS Windows machine.
-</para>
-
-<para>
-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.
-</para>
-
-<para>
-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.
-</para>
-
-<para><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.
-</emphasis></para>
-
-<para>
-The safest rule of all to follow it this - USE ONLY ONE PROTOCOL!
-</para>
-
-</sect1>
-
-<sect1>
-<title>Name Resolution Order</title>
-
-<para>
-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:</para>
-
-<simplelist>
-<member>WINS: the best tool!</member>
-<member>LMHOSTS: is static and hard to maintain.</member>
-<member>Broadcast: uses UDP and can not resolve names across remote segments.</member>
-</simplelist>
-
-<para>
-Alternative means of name resolution includes:</para>
-<simplelist>
-<member>/etc/hosts: is static, hard to maintain, and lacks name_type info</member>
-<member>DNS: is a good choice but lacks essential name_type info.</member>
-</simplelist>
-
-<para>
-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:
-<programlisting>
-name resolve order = wins lmhosts bcast host
-</programlisting>
-_or_
-<programlisting>
-name resolve order = wins lmhosts (eliminates bcast and host)
-</programlisting>
-The default is:
-<programlisting>
-name resolve order = host lmhost wins bcast
-</programlisting>.
-where "host" refers the the native methods used by the Unix system
-to implement the gethostbyname() function call. This is normally
-controlled by <filename>/etc/host.conf</filename>, <filename>/etc/nsswitch.conf</filename> and <filename>/etc/resolv.conf</filename>.
-</para>
-</sect1>
-</chapter>
-<chapter id="improved-browsing">
+<chapter id="NetworkBrowsing">
<chapterinfo>
- <author>
- <affiliation>
- <orgname>Samba Team</orgname>
- </affiliation>
- </author>
-
- <pubdate> (5 July 1998) </pubdate>
+ &author.jht;
+ <pubdate>July 5, 1998</pubdate>
+ <pubdate>Updated: March 15, 2003</pubdate>
</chapterinfo>
-<title>Improved browsing in samba</title>
+<title>Samba / MS Windows Network Browsing Guide</title>
+
+<para>
+This document contains detailed informataion as well as a 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 resolution.
+</para>
+
+<note><para>
+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.
+When the use of NetBIOS over TCP/IP has been disabled then the primary
+means for resolution of MS Windows machine names is via DNS and Active Directory.
+The following information assumes that your site is running NetBIOS over TCP/IP.
+</para></note>
<sect1>
-<title>Overview of browsing</title>
+<title>What is Browsing?</title>
<para>
-SMB networking provides a mechanism by which clients can access a list
-of machines in a network, a so-called <command>browse list</command>. This list
-contains machines that are ready to offer file and/or print services
-to other machines within the network. Thus it does not include
-machines which aren't currently able to do server tasks. The browse
-list is heavily used by all SMB clients. Configuration of SMB
-browsing has been problematic for some Samba users, hence this
-document.
+To most people browsing means that they can see the MS Windows and Samba servers
+in the Network Neighborhood, and when the computer icon for a particular server is
+clicked, it opens up and shows the shares and printers available on the target server.
</para>
<para>
-MS Windows 2000 and later, as with Samba 3 and later, can be
-configured to not use NetBIOS over TCP/IP. When configured this way
-it is imperative that name resolution (using DNS/LDAP/ADS) be correctly
-configured and operative. Browsing will NOT work if name resolution
-from SMB machine names to IP addresses does not function correctly.
+What seems so simple is in fact a very complex interaction of different technologies.
+The technologies (or methods) employed in making all of this work includes:
</para>
+<simplelist>
+ <member>MS Windows machines register their presence to the network</member>
+ <member>Machines announce themselves to other machines on the network</member>
+ <member>One or more machine on the network collates the local announcements</member>
+ <member>The client machine finds the machine that has the collated list of machines</member>
+ <member>The client machine is able to resolve the machine names to IP addresses</member>
+ <member>The client machine is able to connect to a target machine</member>
+</simplelist>
+
<para>
-Where NetBIOS over TCP/IP is enabled use of a WINS server is highly
-recommended to aid the resolution of NetBIOS (SMB) names to IP addresses.
-WINS allows remote segment clients to obtain NetBIOS name_type information
-that can NOT be provided by any other means of name resolution.
+The samba application that controls/manages browse list management and name resolution is
+called <filename>nmbd</filename>. The configuration parameters involved in nmbd's operation are:
</para>
+<para><programlisting>
+ Browsing options:
+ -----------------
+ * os level
+ lm announce
+ lm interval
+ * preferred master
+ * local master
+ * domain master
+ browse list
+ enhanced browsing
+
+ Name Resolution Method:
+ -----------------------
+ * name resolve order
+
+ WINS options:
+ -------------
+ dns proxy
+ wins proxy
+ * wins server
+ * wins support
+ wins hook
+</programlisting></para>
+
+<para>
+WINS Server and WINS Support are mutually exclusive options. Those marked with an '*' are
+the only options that commonly MAY need to be modified. Even if not one of these parameters
+is set nmbd will still do it's job.
+</para>
</sect1>
<sect1>
-<title>Browsing support in samba</title>
+<title>Discussion</title>
<para>
-Samba facilitates browsing. The browsing is supported by &nmbd;
-and is also controlled by options in the &smb.conf; file.
-Samba can act as a local browse master for a workgroup and the ability
-for samba to support domain logons and scripts is now available.
+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.
</para>
<para>
-Samba can also act as a domain master browser for a workgroup. This
-means that it will collate lists from local browse masters into a
-wide area network server list. In order for browse clients to
-resolve the names they may find in this list, it is recommended that
-both samba and your clients use a WINS server.
+Normally, only unicast UDP messaging can be forwarded by routers. The
+<command>remote announce</command>
+parameter to smb.conf helps to project browse announcements
+to remote network segments via unicast UDP. Similarly, the
+<command>remote browse sync</command> parameter of <filename>smb.conf</filename>
+implements browse list collation using unicast UDP.
</para>
<para>
-Note that you should NOT set Samba to be the domain master for a
-workgroup that has the same name as an NT Domain: on each wide area
-network, you must only ever have one domain master browser per workgroup,
-regardless of whether it is NT, Samba or any other type of domain master
-that is providing this service.
+Secondly, in those networks where Samba is the only SMB server technology
+wherever possible <filename>nmbd</filename> 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
+<command>remote announce</command> and the <command>remote browse sync</command>
+parameters to your <filename>smb.conf</filename> file.
</para>
-<note><para>
-Nmbd can be configured as a WINS server, but it is not
-necessary to specifically use samba as your WINS server. MS Windows
-NT4, Server or Advanced Server 2000 or 2003 can be configured as
-your WINS server. In a mixed NT/2000/2003 server and samba environment on
-a Wide Area Network, it is recommended that you use the Microsoft
-WINS server capabilities. In a samba-only environment, it is
-recommended that you use one and only one Samba server as your WINS server.
-</para></note>
+<para>
+If only one WINS server is used for an entire multi-segment network then
+the use of the <command>remote announce</command> and the
+<command>remote browse sync</command> parameters should NOT be necessary.
+</para>
<para>
-To get browsing to work you need to run nmbd as usual, but will need
-to use the <command>workgroup</command> option in &smb.conf;
-to control what workgroup Samba becomes a part of.
+As of Samba 3 WINS replication is being worked on. The bulk of the code has
+been committed, but it still needs maturation.
</para>
<para>
-Samba also has a useful option for a Samba server to offer itself for
-browsing on another subnet. It is recommended that this option is only
-used for 'unusual' purposes: announcements over the internet, for
-example. See <command>remote announce</command> in the
-&smb.conf; man page.
+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 <filename>nmbd</filename> 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
+<command>remote browse sync</command> and <command>remote announce</command>
+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).
</para>
+
+<para>
+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.
+</para>
+
</sect1>
<sect1>
-<title>Problem resolution</title>
+<title>How Browsing Functions</title>
<para>
-If something doesn't work then hopefully the log.nmb file will help
-you track down the problem. Try a debug level of 2 or 3 for finding
-problems. Also note that the current browse list usually gets stored
-in text form in a file called <filename>browse.dat</filename>.
+As stated above, MS Windows machines register their NetBIOS names
+(ie: 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.
</para>
<para>
-Note that if it doesn't work for you, then you should still be able to
-type the server name as <filename>\\SERVER</filename> in filemanager then
-hit enter and filemanager should display the list of available shares.
+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
+<command>remote announce</command> parameter).
</para>
<para>
-Some people find browsing fails because they don't have the global
-<command>guest account</command> set to a valid account. Remember that the
-IPC$ connection that lists the shares is done as guest, and thus you must
-have a valid guest account.
+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.
</para>
-<para><emphasis>
-MS Windows 2000 and upwards (as with Samba) can be configured to disallow
-anonymous (ie: Guest account) access to the IPC$ share. In that case, the
-MS Windows 2000/XP/2003 machine acting as an SMB/CIFS client will use the
-name of the currently logged in user to query the IPC$ share. MS Windows
-9X clients are not able to do this and thus will NOT be able to browse
-server resources.
-</emphasis></para>
-
<para>
-The other big problem people have is that their broadcast address,
-netmask or IP address is wrong (specified with the "interfaces" option
-in &smb.conf;)
+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.
</para>
-</sect1>
-<sect1>
-<title>Browsing across subnets</title>
<para>
-Since the release of Samba 1.9.17(alpha1) Samba has been
-updated to enable it to support the replication of browse lists
-across subnet boundaries. New code and options have been added to
-achieve this. This section describes how to set this feature up
-in different settings.
+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.
</para>
<para>
-To see browse lists that span TCP/IP subnets (ie. networks separated
-by routers that don't pass broadcast traffic) you must set up at least
-one WINS server. The WINS server acts as a DNS for NetBIOS names, allowing
-NetBIOS name to IP address translation to be done by doing a direct
-query of the WINS server. This is done via a directed UDP packet on
-port 137 to the WINS server machine. The reason for a WINS server is
-that by default, all NetBIOS name to IP address translation is done
-by broadcasts from the querying machine. This means that machines
-on one subnet will not be able to resolve the names of machines on
-another subnet without using a WINS server.
+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.
</para>
<para>
-Remember, for browsing across subnets to work correctly, all machines,
-be they Windows 95, Windows NT, or Samba servers must have the IP address
-of a WINS server given to them by a DHCP server, or by manual configuration
-(for Win95 and WinNT, this is in the TCP/IP Properties, under Network
-settings) for Samba this is in the &smb.conf; file.
+Samba supports a feature that allows forced synchonisation
+of browse lists across routed networks using the <command>remote
+browse sync</command> parameter in the <filename>smb.conf</filename> 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 <command>remote
+browse sync</command> 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, <filename>/etc/hosts</filename>,
+and so on.
</para>
<sect2>
-<title>How does cross subnet browsing work ?</title>
+<title>Setting up Browsing in a WORKGROUP</title>
<para>
-Cross subnet browsing is a complicated dance, containing multiple
-moving parts. It has taken Microsoft several years to get the code
-that achieves this correct, and Samba lags behind in some areas.
-Samba is capable of cross subnet browsing when configured correctly.
+To set up cross subnet browsing on a network containing machines
+in up to be in a WORKGROUP, not an NT Domain you need to set up one
+Samba server to be the Domain Master Browser (note that this is *NOT*
+the same as a Primary Domain Controller, although in an NT Domain the
+same machine plays both roles). The role of a Domain master browser is
+to collate the browse lists from local master browsers on all the
+subnets that have a machine participating in the workgroup. Without
+one machine configured as a domain master browser each subnet would
+be an isolated workgroup, unable to see any machines on any other
+subnet. It is the presense of a domain master browser that makes
+cross subnet browsing possible for a workgroup.
</para>
<para>
-Consider a network set up as follows :
+In an WORKGROUP environment the domain master browser must be a
+Samba server, and there must only be one domain master browser per
+workgroup name. To set up a Samba server as a domain master browser,
+set the following option in the [global] section of the &smb.conf; file :
</para>
<para>
<programlisting>
- (DMB)
- N1_A N1_B N1_C N1_D N1_E
- | | | | |
- -------------------------------------------------------
- | subnet 1 |
- +---+ +---+
- |R1 | Router 1 Router 2 |R2 |
- +---+ +---+
- | |
- | subnet 2 subnet 3 |
- -------------------------- ------------------------------------
- | | | | | | | |
- N2_A N2_B N2_C N2_D N3_A N3_B N3_C N3_D
- (WINS)
+ domain master = yes
</programlisting>
</para>
-
-<para>
-Consisting of 3 subnets (1, 2, 3) connected by two routers
-(R1, R2) - these do not pass broadcasts. Subnet 1 has 5 machines
-on it, subnet 2 has 4 machines, subnet 3 has 4 machines. Assume
-for the moment that all these machines are configured to be in the
-same workgroup (for simplicities sake). Machine N1_C on subnet 1
-is configured as Domain Master Browser (ie. it will collate the
-browse lists for the workgroup). Machine N2_D is configured as
-WINS server and all the other machines are configured to register
-their NetBIOS names with it.
-</para>
<para>
-As all these machines are booted up, elections for master browsers
-will take place on each of the three subnets. Assume that machine
-N1_C wins on subnet 1, N2_B wins on subnet 2, and N3_D wins on
-subnet 3 - these machines are known as local master browsers for
-their particular subnet. N1_C has an advantage in winning as the
-local master browser on subnet 1 as it is set up as Domain Master
-Browser.
+The domain master browser should also preferrably be the local master
+browser for its own subnet. In order to achieve this set the following
+options in the [global] section of the &smb.conf; file :
</para>
<para>
-On each of the three networks, machines that are configured to
-offer sharing services will broadcast that they are offering
-these services. The local master browser on each subnet will
-receive these broadcasts and keep a record of the fact that
-the machine is offering a service. This list of records is
-the basis of the browse list. For this case, assume that
-all the machines are configured to offer services so all machines
-will be on the browse list.
+<programlisting>
+ domain master = yes
+ local master = yes
+ preferred master = yes
+ os level = 65
+</programlisting>
</para>
<para>
-For each network, the local master browser on that network is
-considered 'authoritative' for all the names it receives via
-local broadcast. This is because a machine seen by the local
-master browser via a local broadcast must be on the same
-network as the local master browser and thus is a 'trusted'
-and 'verifiable' resource. Machines on other networks that
-the local master browsers learn about when collating their
-browse lists have not been directly seen - these records are
-called 'non-authoritative'.
+The domain master browser may be the same machine as the WINS
+server, if you require.
</para>
<para>
-At this point the browse lists look as follows (these are
-the machines you would see in your network neighborhood if
-you looked in it on a particular network right now).
+Next, you should ensure that each of the subnets contains a
+machine that can act as a local master browser for the
+workgroup. Any MS Windows NT/2K/XP/2003 machine should be
+able to do this, as will Windows 9x machines (although these
+tend to get rebooted more often, so it's not such a good idea
+to use these). To make a Samba server a local master browser
+set the following options in the [global] section of the
+&smb.conf; file :
</para>
<para>
<programlisting>
-Subnet Browse Master List
------- ------------- ----
-Subnet1 N1_C N1_A, N1_B, N1_C, N1_D, N1_E
-
-Subnet2 N2_B N2_A, N2_B, N2_C, N2_D
-
-Subnet3 N3_D N3_A, N3_B, N3_C, N3_D
+ domain master = no
+ local master = yes
+ preferred master = yes
+ os level = 65
</programlisting>
</para>
<para>
-Note that at this point all the subnets are separate, no
-machine is seen across any of the subnets.
+Do not do this for more than one Samba server on each subnet,
+or they will war with each other over which is to be the local
+master browser.
</para>
<para>
-Now examine subnet 2. As soon as N2_B has become the local
-master browser it looks for a Domain master browser to synchronize
-its browse list with. It does this by querying the WINS server
-(N2_D) for the IP address associated with the NetBIOS name
-WORKGROUP>1B<. This name was registerd by the Domain master
-browser (N1_C) with the WINS server as soon as it was booted.
+The <command>local master</command> parameter allows Samba to act as a
+local master browser. The <command>preferred master</command> causes nmbd
+to force a browser election on startup and the <command>os level</command>
+parameter sets Samba high enough so that it should win any browser elections.
</para>
<para>
-Once N2_B knows the address of the Domain master browser it
-tells it that is the local master browser for subnet 2 by
-sending a MasterAnnouncement packet as a UDP port 138 packet.
-It then synchronizes with it by doing a NetServerEnum2 call. This
-tells the Domain Master Browser to send it all the server
-names it knows about. Once the domain master browser receives
-the MasterAnnouncement packet it schedules a synchronization
-request to the sender of that packet. After both synchronizations
-are done the browse lists look like :
+If you have an NT machine on the subnet that you wish to
+be the local master browser then you can disable Samba from
+becoming a local master browser by setting the following
+options in the <command>[global]</command> section of the
+&smb.conf; file :
</para>
<para>
<programlisting>
-Subnet Browse Master List
------- ------------- ----
-Subnet1 N1_C N1_A, N1_B, N1_C, N1_D, N1_E,
- N2_A(*), N2_B(*), N2_C(*), N2_D(*)
-
-Subnet2 N2_B N2_A, N2_B, N2_C, N2_D
- N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*)
-
-Subnet3 N3_D N3_A, N3_B, N3_C, N3_D
-
-Servers with a (*) after them are non-authoritative names.
+ domain master = no
+ local master = no
+ preferred master = no
+ os level = 0
</programlisting>
</para>
-<para>
-At this point users looking in their network neighborhood on
-subnets 1 or 2 will see all the servers on both, users on
-subnet 3 will still only see the servers on their own subnet.
+</sect2>
+
+<sect2>
+<title>Setting up Browsing in a DOMAIN</title>
+
+<para>
+If you are adding Samba servers to a Windows NT Domain then
+you must not set up a Samba server as a domain master browser.
+By default, a Windows NT Primary Domain Controller for a Domain
+name is also the Domain master browser for that name, and many
+things will break if a Samba server registers the Domain master
+browser NetBIOS name (<replaceable>DOMAIN</replaceable><1B>)
+with WINS instead of the PDC.
</para>
<para>
-The same sequence of events that occured for N2_B now occurs
-for the local master browser on subnet 3 (N3_D). When it
-synchronizes browse lists with the domain master browser (N1_A)
-it gets both the server entries on subnet 1, and those on
-subnet 2. After N3_D has synchronized with N1_C and vica-versa
-the browse lists look like.
+For subnets other than the one containing the Windows NT PDC
+you may set up Samba servers as local master browsers as
+described. To make a Samba server a local master browser set
+the following options in the <command>[global]</command> section
+of the &smb.conf; file :
</para>
<para>
<programlisting>
-Subnet Browse Master List
------- ------------- ----
-Subnet1 N1_C N1_A, N1_B, N1_C, N1_D, N1_E,
- N2_A(*), N2_B(*), N2_C(*), N2_D(*),
- N3_A(*), N3_B(*), N3_C(*), N3_D(*)
+ domain master = no
+ local master = yes
+ preferred master = yes
+ os level = 65
+</programlisting>
+</para>
-Subnet2 N2_B N2_A, N2_B, N2_C, N2_D
- N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*)
+<para>
+If you wish to have a Samba server fight the election with machines
+on the same subnet you may set the <command>os level</command> parameter
+to lower levels. By doing this you can tune the order of machines that
+will become local master browsers if they are running. For
+more details on this see the section <link linkend="browse-force-master">
+Forcing samba to be the master browser</link>
+below.
+</para>
-Subnet3 N3_D N3_A, N3_B, N3_C, N3_D
- N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*),
- N2_A(*), N2_B(*), N2_C(*), N2_D(*)
+<para>
+If you have Windows NT machines that are members of the domain
+on all subnets, and you are sure they will always be running then
+you can disable Samba from taking part in browser elections and
+ever becoming a local master browser by setting following options
+in the <command>[global]</command> section of the &smb.conf;
+file :
+</para>
-Servers with a (*) after them are non-authoritative names.
+<para>
+<programlisting>
+ domain master = no
+ local master = no
+ preferred master = no
+ os level = 0
</programlisting>
</para>
+</sect2>
+
+<sect2 id="browse-force-master">
+<title>Forcing samba to be the master</title>
+
<para>
-At this point users looking in their network neighborhood on
-subnets 1 or 3 will see all the servers on all sunbets, users on
-subnet 2 will still only see the servers on subnets 1 and 2, but not 3.
+Who becomes the <command>master browser</command> is determined by an election
+process using broadcasts. Each election packet contains a number of parameters
+which determine what precedence (bias) a host should have in the
+election. By default Samba uses a very low precedence and thus loses
+elections to just about anyone else.
</para>
<para>
-Finally, the local master browser for subnet 2 (N2_B) will sync again
-with the domain master browser (N1_C) and will recieve the missing
-server entries. Finally - and as a steady state (if no machines
-are removed or shut off) the browse lists will look like :
+If you want Samba to win elections then just set the <command>os level</command> global
+option in &smb.conf; to a higher number. It defaults to 0. Using 34
+would make it win all elections over every other system (except other
+samba systems!)
</para>
<para>
-<programlisting>
-Subnet Browse Master List
------- ------------- ----
-Subnet1 N1_C N1_A, N1_B, N1_C, N1_D, N1_E,
- N2_A(*), N2_B(*), N2_C(*), N2_D(*),
- N3_A(*), N3_B(*), N3_C(*), N3_D(*)
+A <command>os level</command> of 2 would make it beat WfWg and Win95, but not MS Windows
+NT/2K Server. A MS Windows NT/2K Server domain controller uses level 32.
+</para>
-Subnet2 N2_B N2_A, N2_B, N2_C, N2_D
- N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*)
- N3_A(*), N3_B(*), N3_C(*), N3_D(*)
+<para>The maximum os level is 255</para>
-Subnet3 N3_D N3_A, N3_B, N3_C, N3_D
- N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*),
- N2_A(*), N2_B(*), N2_C(*), N2_D(*)
-
-Servers with a (*) after them are non-authoritative names.
-</programlisting>
+<para>
+If you want samba to force an election on startup, then set the
+<command>preferred master</command> global option in &smb.conf; to "yes". Samba will
+then have a slight advantage over other potential master browsers
+that are not preferred master browsers. Use this parameter with
+care, as if you have two hosts (whether they are windows 95 or NT or
+samba) on the same local subnet both set with <command>preferred master</command> to
+"yes", then periodically and continually they will force an election
+in order to become the local master browser.
</para>
<para>
-Synchronizations between the domain master browser and local
-master browsers will continue to occur, but this should be a
-steady state situation.
+If you want samba to be a <command>domain master browser</command>, then it is
+recommended that you also set <command>preferred master</command> to "yes", because
+samba will not become a domain master browser for the whole of your
+LAN or WAN if it is not also a local master browser on its own
+broadcast isolated subnet.
</para>
<para>
-If either router R1 or R2 fails the following will occur:
+It is possible to configure two samba servers to attempt to become
+the domain master browser for a domain. The first server that comes
+up will be the domain master browser. All other samba servers will
+attempt to become the domain master browser every 5 minutes. They
+will find that another samba server is already the domain master
+browser and will fail. This provides automatic redundancy, should
+the current domain master browser fail.
+</para>
+
+</sect2>
+
+<sect2>
+<title>Making samba the domain master</title>
+
+<para>
+The domain master is responsible for collating the browse lists of
+multiple subnets so that browsing can occur between subnets. You can
+make samba act as the domain master by setting <command>domain master = yes</command>
+in &smb.conf;. By default it will not be a domain master.
+</para>
+
+<para>
+Note that you should NOT set Samba to be the domain master for a
+workgroup that has the same name as an NT Domain.
+</para>
+
+<para>
+When samba is the domain master and the master browser it will listen
+for master announcements (made roughly every twelve minutes) from local
+master browsers on other subnets and then contact them to synchronise
+browse lists.
+</para>
+
+<para>
+If you want samba to be the domain master then I suggest you also set
+the <command>os level</command> high enough to make sure it wins elections, and set
+<command>preferred master</command> to "yes", to get samba to force an election on
+startup.
+</para>
+
+<para>
+Note that all your servers (including samba) and clients should be
+using a WINS server to resolve NetBIOS names. If your clients are only
+using broadcasting to resolve NetBIOS names, then two things will occur:
</para>
<orderedlist>
<listitem>
<para>
- Names of computers on each side of the inaccessible network fragments
- will be maintained for as long as 36 minutes, in the network neighbourhood
- lists.
+ your local master browsers will be unable to find a domain master
+ browser, as it will only be looking on the local subnet.
</para>
</listitem>
<listitem>
<para>
- Attempts to connect to these inaccessible computers will fail, but the
- names will not be removed from the network neighbourhood lists.
+ if a client happens to get hold of a domain-wide browse list, and
+ a user attempts to access a host in that list, it will be unable to
+ resolve the NetBIOS name of that host.
</para>
</listitem>
+</orderedlist>
+
+<para>
+If, however, both samba and your clients are using a WINS server, then:
+</para>
+<orderedlist>
<listitem>
<para>
- If one of the fragments is cut off from the WINS server, it will only
- be able to access servers on its local subnet, by using subnet-isolated
- broadcast NetBIOS name resolution. The effects are similar to that of
- losing access to a DNS server.
+ your local master browsers will contact the WINS server and, as long as
+ samba has registered that it is a domain master browser with the WINS
+ server, your local master browser will receive samba's ip address
+ as its domain master browser.
+ </para>
+</listitem>
+
+<listitem>
+ <para>
+ when a client receives a domain-wide browse list, and a user attempts
+ to access a host in that list, it will contact the WINS server to
+ resolve the NetBIOS name of that host. as long as that host has
+ registered its NetBIOS name with the same WINS server, the user will
+ be able to see that host.
</para>
</listitem>
</orderedlist>
+
+</sect2>
+
+<sect2>
+<title>Note about broadcast addresses</title>
+
+<para>
+If your network uses a "0" based broadcast address (for example if it
+ends in a 0) then you will strike problems. Windows for Workgroups
+does not seem to support a 0's broadcast and you will probably find
+that browsing and name lookups won't work.
+</para>
</sect2>
+
+<sect2>
+<title>Multiple interfaces</title>
+
+<para>
+Samba now supports machines with multiple network interfaces. If you
+have multiple interfaces then you will need to use the <command>interfaces</command>
+option in &smb.conf; to configure them.
+</para>
+</sect2>
+<sect2>
+<title>Use of the <command>Remote Announce</command> parameter</title>
+<para>
+The <command>remote announce</command> parameter of
+<filename>smb.conf</filename> can be used to forcibly ensure
+that all the NetBIOS names on a network get announced to a remote network.
+The syntax of the <command>remote announce</command> parameter is:
+<programlisting>
+ remote announce = a.b.c.d [e.f.g.h] ...
+</programlisting>
+_or_
+<programlisting>
+ remote announce = a.b.c.d/WORKGROUP [e.f.g.h/WORKGROUP] ...
+</programlisting>
+
+where:
+<variablelist>
+<varlistentry><term><replaceable>a.b.c.d</replaceable> and
+<replaceable>e.f.g.h</replaceable></term>
+<listitem><para>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.</para></listitem>
+</varlistentry>
+
+<varlistentry>
+<term><replaceable>WORKGROUP</replaceable></term>
+<listitem><para>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.
+</para></listitem>
+</varlistentry>
+</variablelist>
+</para>
+
+</sect2>
+
+<sect2>
+<title>Use of the <command>Remote Browse Sync</command> parameter</title>
+
+<para>
+The <command>remote browse sync</command> parameter of
+<filename>smb.conf</filename> 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.
+</para>
+
+<para>
+The syntax of the <command>remote browse sync</command> parameter is:
+
+<programlisting>
+remote browse sync = <replaceable>a.b.c.d</replaceable>
+</programlisting>
+
+where <replaceable>a.b.c.d</replaceable> is either the IP address of the
+remote LMB or else is the network broadcast address of the remote segment.
+</para>
+
+</sect2>
+
</sect1>
<sect1>
+<title>WINS - The Windows Internetworking Name Server</title>
+
+<para>
+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.
+</para>
+
+<para>
+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).
+</para>
+
+<para>
+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
+<filename>lmhosts</filename> files that must reside on all clients in the
+absence of WINS.
+</para>
+
+<para>
+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.
+</para>
+
+<para>
+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.
+</para>
+
+<para>
+To configure Samba as a WINS server just add
+<command>wins support = yes</command> to the <filename>smb.conf</filename>
+file [globals] section.
+</para>
+
+<para>
+To configure Samba to register with a WINS server just add
+"wins server = a.b.c.d" to your smb.conf file [globals] section.
+</para>
+
+<important><para>
+Never use both <command>wins support = yes</command> together
+with <command>wins server = a.b.c.d</command>
+particularly not using it's own IP address.
+Specifying both will cause &nmbd; to refuse to start!
+</para></important>
+
+<sect2>
<title>Setting up a WINS server</title>
<para>
-Either a Samba machine or a Windows NT Server machine may be set up
-as a WINS server. To set a Samba machine to be a WINS server you must
-add the following option to the &smb.conf; file on the selected machine :
-in the [globals] section add the line
+Either a Samba machine or a Windows NT Server machine may be set up
+as a WINS server. To set a Samba machine to be a WINS server you must
+add the following option to the &smb.conf; file on the selected machine :
+in the [globals] section add the line
+</para>
+
+<para>
+<programlisting>
+ wins support = yes
+</programlisting>
+</para>
+
+<para>
+Versions of Samba prior to 1.9.17 had this parameter default to
+yes. If you have any older versions of Samba on your network it is
+strongly suggested you upgrade to a recent version, or at the very
+least set the parameter to 'no' on all these machines.
+</para>
+
+<para>
+Machines with <command>wins support = yes</command> will keep a list of
+all NetBIOS names registered with them, acting as a DNS for NetBIOS names.
+</para>
+
+<para>
+You should set up only ONE wins server. Do NOT set the
+<command>wins support = yes</command> option on more than one Samba
+server.
+</para>
+
+<para>
+To set up a Windows NT Server as a WINS server you need to set up
+the WINS service - see your NT documentation for details. Note that
+Windows NT WINS Servers can replicate to each other, allowing more
+than one to be set up in a complex subnet environment. As Microsoft
+refuse to document these replication protocols Samba cannot currently
+participate in these replications. It is possible in the future that
+a Samba->Samba WINS replication protocol may be defined, in which
+case more than one Samba machine could be set up as a WINS server
+but currently only one Samba server should have the
+<command>wins support = yes</command> parameter set.
+</para>
+
+<para>
+After the WINS server has been configured you must ensure that all
+machines participating on the network are configured with the address
+of this WINS server. If your WINS server is a Samba machine, fill in
+the Samba machine IP address in the "Primary WINS Server" field of
+the "Control Panel->Network->Protocols->TCP->WINS Server" dialogs
+in Windows 95 or Windows NT. To tell a Samba server the IP address
+of the WINS server add the following line to the [global] section of
+all &smb.conf; files :
+</para>
+
+<para>
+<programlisting>
+ wins server = <name or IP address>
+</programlisting>
+</para>
+
+<para>
+where >name or IP address< is either the DNS name of the WINS server
+machine or its IP address.
+</para>
+
+<para>
+Note that this line MUST NOT BE SET in the &smb.conf; file of the Samba
+server acting as the WINS server itself. If you set both the
+<command>wins support = yes</command> option and the
+<command>wins server = <name></command> option then
+nmbd will fail to start.
+</para>
+
+<para>
+There are two possible scenarios for setting up cross subnet browsing.
+The first details setting up cross subnet browsing on a network containing
+Windows 95, Samba and Windows NT machines that are not configured as
+part of a Windows NT Domain. The second details setting up cross subnet
+browsing on networks that contain NT Domains.
+</para>
+
+</sect2>
+
+<sect2>
+<title>WINS Replication</title>
+
+<para>
+Samba-3 permits WINS replication through the use of the <filename>wrepld</filename> 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.
+</para>
+
+</sect2>
+<sect2>
+<title>Static WINS Entries</title>
+
+<para>
+New to Samba-3 is a tool called <filename>winsedit</filename> 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.
+</para>
+
+<para>
+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.
+</para>
+
+</sect2>
+</sect1>
+
+<sect1>
+<title>Helpful Hints</title>
+
+<para>
+The following hints should be carefully considered as they are stumbling points
+for many new network administrators.
+</para>
+
+<sect2>
+<title>Windows Networking Protocols</title>
+
+<warning><para>
+Do NOT use more than one (1) protocol on MS Windows machines
+</para></warning>
+
+<para>
+A very common cause of browsing problems results from installing more than
+one protocol on an MS Windows machine.
</para>
<para>
-<command> wins support = yes</command>
+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.
</para>
<para>
-Versions of Samba prior to 1.9.17 had this parameter default to
-yes. If you have any older versions of Samba on your network it is
-strongly suggested you upgrade to a recent version, or at the very
-least set the parameter to 'no' on all these machines.
+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.
</para>
+<para><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.
+</emphasis></para>
+
<para>
-Machines with <command>wins support = yes</command> will keep a list of
-all NetBIOS names registered with them, acting as a DNS for NetBIOS names.
+The safest rule of all to follow it this - USE ONLY ONE PROTOCOL!
</para>
+</sect2>
+
+<sect2>
+<title>Name Resolution Order</title>
+
<para>
-You should set up only ONE wins server. Do NOT set the
-<command>wins support = yes</command> option on more than one Samba
-server.
-</para>
+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:</para>
+
+<simplelist>
+ <member>WINS: the best tool!</member>
+ <member>LMHOSTS: is static and hard to maintain.</member>
+ <member>Broadcast: uses UDP and can not resolve names across remote segments.</member>
+</simplelist>
<para>
-To set up a Windows NT Server as a WINS server you need to set up
-the WINS service - see your NT documentation for details. Note that
-Windows NT WINS Servers can replicate to each other, allowing more
-than one to be set up in a complex subnet environment. As Microsoft
-refuse to document these replication protocols Samba cannot currently
-participate in these replications. It is possible in the future that
-a Samba->Samba WINS replication protocol may be defined, in which
-case more than one Samba machine could be set up as a WINS server
-but currently only one Samba server should have the
-<command>wins support = yes</command> parameter set.
+Alternative means of name resolution includes:</para>
+<simplelist>
+<member>/etc/hosts: is static, hard to maintain, and lacks name_type info</member>
+<member>DNS: is a good choice but lacks essential name_type info.</member>
+</simplelist>
+
+<para>
+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:
+<programlisting>
+name resolve order = wins lmhosts bcast host
+</programlisting>
+_or_
+<programlisting>
+name resolve order = wins lmhosts (eliminates bcast and host)
+</programlisting>
+The default is:
+<programlisting>
+name resolve order = host lmhost wins bcast
+</programlisting>.
+where "host" refers the the native methods used by the Unix system
+to implement the gethostbyname() function call. This is normally
+controlled by <filename>/etc/host.conf</filename>, <filename>/etc/nsswitch.conf</filename> and <filename>/etc/resolv.conf</filename>.
</para>
+</sect2>
+</sect1>
+
+<sect1>
+<title>Technical Overview of browsing</title>
<para>
-After the WINS server has been configured you must ensure that all
-machines participating on the network are configured with the address
-of this WINS server. If your WINS server is a Samba machine, fill in
-the Samba machine IP address in the "Primary WINS Server" field of
-the "Control Panel->Network->Protocols->TCP->WINS Server" dialogs
-in Windows 95 or Windows NT. To tell a Samba server the IP address
-of the WINS server add the following line to the [global] section of
-all &smb.conf; files :
+SMB networking provides a mechanism by which clients can access a list
+of machines in a network, a so-called <command>browse list</command>. This list
+contains machines that are ready to offer file and/or print services
+to other machines within the network. Thus it does not include
+machines which aren't currently able to do server tasks. The browse
+list is heavily used by all SMB clients. Configuration of SMB
+browsing has been problematic for some Samba users, hence this
+document.
</para>
<para>
-<command>wins server = >name or IP address<</command>
+MS Windows 2000 and later, as with Samba 3 and later, can be
+configured to not use NetBIOS over TCP/IP. When configured this way
+it is imperative that name resolution (using DNS/LDAP/ADS) be correctly
+configured and operative. Browsing will NOT work if name resolution
+from SMB machine names to IP addresses does not function correctly.
</para>
<para>
-where >name or IP address< is either the DNS name of the WINS server
-machine or its IP address.
+Where NetBIOS over TCP/IP is enabled use of a WINS server is highly
+recommended to aid the resolution of NetBIOS (SMB) names to IP addresses.
+WINS allows remote segment clients to obtain NetBIOS name_type information
+that can NOT be provided by any other means of name resolution.
</para>
+<sect2>
+<title>Browsing support in samba</title>
+
<para>
-Note that this line MUST NOT BE SET in the &smb.conf; file of the Samba
-server acting as the WINS server itself. If you set both the
-<command>wins support = yes</command> option and the
-<command>wins server = <name></command> option then
-nmbd will fail to start.
+Samba facilitates browsing. The browsing is supported by &nmbd;
+and is also controlled by options in the &smb.conf; file.
+Samba can act as a local browse master for a workgroup and the ability
+for samba to support domain logons and scripts is now available.
</para>
<para>
-There are two possible scenarios for setting up cross subnet browsing.
-The first details setting up cross subnet browsing on a network containing
-Windows 95, Samba and Windows NT machines that are not configured as
-part of a Windows NT Domain. The second details setting up cross subnet
-browsing on networks that contain NT Domains.
+Samba can also act as a domain master browser for a workgroup. This
+means that it will collate lists from local browse masters into a
+wide area network server list. In order for browse clients to
+resolve the names they may find in this list, it is recommended that
+both samba and your clients use a WINS server.
</para>
-</sect1>
+<para>
+Note that you should NOT set Samba to be the domain master for a
+workgroup that has the same name as an NT Domain: on each wide area
+network, you must only ever have one domain master browser per workgroup,
+regardless of whether it is NT, Samba or any other type of domain master
+that is providing this service.
+</para>
-<sect1>
-<title>Setting up Browsing in a WORKGROUP</title>
+<note><para>
+Nmbd can be configured as a WINS server, but it is not
+necessary to specifically use samba as your WINS server. MS Windows
+NT4, Server or Advanced Server 2000 or 2003 can be configured as
+your WINS server. In a mixed NT/2000/2003 server and samba environment on
+a Wide Area Network, it is recommended that you use the Microsoft
+WINS server capabilities. In a samba-only environment, it is
+recommended that you use one and only one Samba server as your WINS server.
+</para></note>
<para>
-To set up cross subnet browsing on a network containing machines
-in up to be in a WORKGROUP, not an NT Domain you need to set up one
-Samba server to be the Domain Master Browser (note that this is *NOT*
-the same as a Primary Domain Controller, although in an NT Domain the
-same machine plays both roles). The role of a Domain master browser is
-to collate the browse lists from local master browsers on all the
-subnets that have a machine participating in the workgroup. Without
-one machine configured as a domain master browser each subnet would
-be an isolated workgroup, unable to see any machines on any other
-subnet. It is the presense of a domain master browser that makes
-cross subnet browsing possible for a workgroup.
+To get browsing to work you need to run nmbd as usual, but will need
+to use the <command>workgroup</command> option in &smb.conf;
+to control what workgroup Samba becomes a part of.
</para>
<para>
-In an WORKGROUP environment the domain master browser must be a
-Samba server, and there must only be one domain master browser per
-workgroup name. To set up a Samba server as a domain master browser,
-set the following option in the [global] section of the &smb.conf; file :
+Samba also has a useful option for a Samba server to offer itself for
+browsing on another subnet. It is recommended that this option is only
+used for 'unusual' purposes: announcements over the internet, for
+example. See <command>remote announce</command> in the
+&smb.conf; man page.
</para>
+</sect2>
+
+<sect2>
+<title>Problem resolution</title>
<para>
-<command>domain master = yes</command>
+If something doesn't work then hopefully the log.nmb file will help
+you track down the problem. Try a debug level of 2 or 3 for finding
+problems. Also note that the current browse list usually gets stored
+in text form in a file called <filename>browse.dat</filename>.
</para>
<para>
-The domain master browser should also preferrably be the local master
-browser for its own subnet. In order to achieve this set the following
-options in the [global] section of the &smb.conf; file :
+Note that if it doesn't work for you, then you should still be able to
+type the server name as <filename>\\SERVER</filename> in filemanager then
+hit enter and filemanager should display the list of available shares.
</para>
<para>
-<programlisting>
-domain master = yes
-local master = yes
-preferred master = yes
-os level = 65
-</programlisting>
+Some people find browsing fails because they don't have the global
+<command>guest account</command> set to a valid account. Remember that the
+IPC$ connection that lists the shares is done as guest, and thus you must
+have a valid guest account.
</para>
+<para><emphasis>
+MS Windows 2000 and upwards (as with Samba) can be configured to disallow
+anonymous (ie: Guest account) access to the IPC$ share. In that case, the
+MS Windows 2000/XP/2003 machine acting as an SMB/CIFS client will use the
+name of the currently logged in user to query the IPC$ share. MS Windows
+9X clients are not able to do this and thus will NOT be able to browse
+server resources.
+</emphasis></para>
+
<para>
-The domain master browser may be the same machine as the WINS
-server, if you require.
+The other big problem people have is that their broadcast address,
+netmask or IP address is wrong (specified with the "interfaces" option
+in &smb.conf;)
</para>
+</sect2>
+<sect2>
+<title>Browsing across subnets</title>
<para>
-Next, you should ensure that each of the subnets contains a
-machine that can act as a local master browser for the
-workgroup. Any MS Windows NT/2K/XP/2003 machine should be
-able to do this, as will Windows 9x machines (although these
-tend to get rebooted more often, so it's not such a good idea
-to use these). To make a Samba server a local master browser
-set the following options in the [global] section of the
-&smb.conf; file :
+Since the release of Samba 1.9.17(alpha1) Samba has been
+updated to enable it to support the replication of browse lists
+across subnet boundaries. New code and options have been added to
+achieve this. This section describes how to set this feature up
+in different settings.
</para>
<para>
-<programlisting>
-domain master = no
-local master = yes
-preferred master = yes
-os level = 65
-</programlisting>
+To see browse lists that span TCP/IP subnets (ie. networks separated
+by routers that don't pass broadcast traffic) you must set up at least
+one WINS server. The WINS server acts as a DNS for NetBIOS names, allowing
+NetBIOS name to IP address translation to be done by doing a direct
+query of the WINS server. This is done via a directed UDP packet on
+port 137 to the WINS server machine. The reason for a WINS server is
+that by default, all NetBIOS name to IP address translation is done
+by broadcasts from the querying machine. This means that machines
+on one subnet will not be able to resolve the names of machines on
+another subnet without using a WINS server.
</para>
<para>
-Do not do this for more than one Samba server on each subnet,
-or they will war with each other over which is to be the local
-master browser.
+Remember, for browsing across subnets to work correctly, all machines,
+be they Windows 95, Windows NT, or Samba servers must have the IP address
+of a WINS server given to them by a DHCP server, or by manual configuration
+(for Win95 and WinNT, this is in the TCP/IP Properties, under Network
+settings) for Samba this is in the &smb.conf; file.
</para>
+<sect3>
+<title>How does cross subnet browsing work ?</title>
+
<para>
-The <command>local master</command> parameter allows Samba to act as a
-local master browser. The <command>preferred master</command> causes nmbd
-to force a browser election on startup and the <command>os level</command>
-parameter sets Samba high enough so that it should win any browser elections.
+Cross subnet browsing is a complicated dance, containing multiple
+moving parts. It has taken Microsoft several years to get the code
+that achieves this correct, and Samba lags behind in some areas.
+Samba is capable of cross subnet browsing when configured correctly.
</para>
<para>
-If you have an NT machine on the subnet that you wish to
-be the local master browser then you can disable Samba from
-becoming a local master browser by setting the following
-options in the <command>[global]</command> section of the
-&smb.conf; file :
+Consider a network set up as follows :
</para>
<para>
<programlisting>
-domain master = no
-local master = no
-preferred master = no
-os level = 0
+ (DMB)
+ N1_A N1_B N1_C N1_D N1_E
+ | | | | |
+ -------------------------------------------------------
+ | subnet 1 |
+ +---+ +---+
+ |R1 | Router 1 Router 2 |R2 |
+ +---+ +---+
+ | |
+ | subnet 2 subnet 3 |
+ -------------------------- ------------------------------------
+ | | | | | | | |
+ N2_A N2_B N2_C N2_D N3_A N3_B N3_C N3_D
+ (WINS)
</programlisting>
</para>
-
-</sect1>
-
-<sect1>
-<title>Setting up Browsing in a DOMAIN</title>
-
+
<para>
-If you are adding Samba servers to a Windows NT Domain then
-you must not set up a Samba server as a domain master browser.
-By default, a Windows NT Primary Domain Controller for a Domain
-name is also the Domain master browser for that name, and many
-things will break if a Samba server registers the Domain master
-browser NetBIOS name (<replaceable>DOMAIN</replaceable><1B>)
-with WINS instead of the PDC.
+Consisting of 3 subnets (1, 2, 3) connected by two routers
+(R1, R2) - these do not pass broadcasts. Subnet 1 has 5 machines
+on it, subnet 2 has 4 machines, subnet 3 has 4 machines. Assume
+for the moment that all these machines are configured to be in the
+same workgroup (for simplicities sake). Machine N1_C on subnet 1
+is configured as Domain Master Browser (ie. it will collate the
+browse lists for the workgroup). Machine N2_D is configured as
+WINS server and all the other machines are configured to register
+their NetBIOS names with it.
</para>
<para>
-For subnets other than the one containing the Windows NT PDC
-you may set up Samba servers as local master browsers as
-described. To make a Samba server a local master browser set
-the following options in the <command>[global]</command> section
-of the &smb.conf; file :
+As all these machines are booted up, elections for master browsers
+will take place on each of the three subnets. Assume that machine
+N1_C wins on subnet 1, N2_B wins on subnet 2, and N3_D wins on
+subnet 3 - these machines are known as local master browsers for
+their particular subnet. N1_C has an advantage in winning as the
+local master browser on subnet 1 as it is set up as Domain Master
+Browser.
</para>
<para>
-<programlisting>
-domain master = no
-local master = yes
-preferred master = yes
-os level = 65
-</programlisting>
+On each of the three networks, machines that are configured to
+offer sharing services will broadcast that they are offering
+these services. The local master browser on each subnet will
+receive these broadcasts and keep a record of the fact that
+the machine is offering a service. This list of records is
+the basis of the browse list. For this case, assume that
+all the machines are configured to offer services so all machines
+will be on the browse list.
</para>
<para>
-If you wish to have a Samba server fight the election with machines
-on the same subnet you may set the <command>os level</command> parameter
-to lower levels. By doing this you can tune the order of machines that
-will become local master browsers if they are running. For
-more details on this see the section <link linkend="browse-force-master">
-Forcing samba to be the master browser</link>
-below.
+For each network, the local master browser on that network is
+considered 'authoritative' for all the names it receives via
+local broadcast. This is because a machine seen by the local
+master browser via a local broadcast must be on the same
+network as the local master browser and thus is a 'trusted'
+and 'verifiable' resource. Machines on other networks that
+the local master browsers learn about when collating their
+browse lists have not been directly seen - these records are
+called 'non-authoritative'.
</para>
<para>
-If you have Windows NT machines that are members of the domain
-on all subnets, and you are sure they will always be running then
-you can disable Samba from taking part in browser elections and
-ever becoming a local master browser by setting following options
-in the <command>[global]</command> section of the &smb.conf;
-file :
+At this point the browse lists look as follows (these are
+the machines you would see in your network neighborhood if
+you looked in it on a particular network right now).
</para>
<para>
-<command>
- domain master = no
- local master = no
- preferred master = no
- os level = 0
-</command>
-</para>
+<programlisting>
+Subnet Browse Master List
+------ ------------- ----
+Subnet1 N1_C N1_A, N1_B, N1_C, N1_D, N1_E
-</sect1>
+Subnet2 N2_B N2_A, N2_B, N2_C, N2_D
-<sect1 id="browse-force-master">
-<title>Forcing samba to be the master</title>
+Subnet3 N3_D N3_A, N3_B, N3_C, N3_D
+</programlisting>
+</para>
<para>
-Who becomes the <command>master browser</command> is determined by an election
-process using broadcasts. Each election packet contains a number of parameters
-which determine what precedence (bias) a host should have in the
-election. By default Samba uses a very low precedence and thus loses
-elections to just about anyone else.
+Note that at this point all the subnets are separate, no
+machine is seen across any of the subnets.
</para>
<para>
-If you want Samba to win elections then just set the <command>os level</command> global
-option in &smb.conf; to a higher number. It defaults to 0. Using 34
-would make it win all elections over every other system (except other
-samba systems!)
+Now examine subnet 2. As soon as N2_B has become the local
+master browser it looks for a Domain master browser to synchronize
+its browse list with. It does this by querying the WINS server
+(N2_D) for the IP address associated with the NetBIOS name
+WORKGROUP>1B<. This name was registerd by the Domain master
+browser (N1_C) with the WINS server as soon as it was booted.
</para>
<para>
-A <command>os level</command> of 2 would make it beat WfWg and Win95, but not MS Windows
-NT/2K Server. A MS Windows NT/2K Server domain controller uses level 32.
+Once N2_B knows the address of the Domain master browser it
+tells it that is the local master browser for subnet 2 by
+sending a MasterAnnouncement packet as a UDP port 138 packet.
+It then synchronizes with it by doing a NetServerEnum2 call. This
+tells the Domain Master Browser to send it all the server
+names it knows about. Once the domain master browser receives
+the MasterAnnouncement packet it schedules a synchronization
+request to the sender of that packet. After both synchronizations
+are done the browse lists look like :
</para>
-<para>The maximum os level is 255</para>
-
<para>
-If you want samba to force an election on startup, then set the
-<command>preferred master</command> global option in &smb.conf; to "yes". Samba will
-then have a slight advantage over other potential master browsers
-that are not preferred master browsers. Use this parameter with
-care, as if you have two hosts (whether they are windows 95 or NT or
-samba) on the same local subnet both set with <command>preferred master</command> to
-"yes", then periodically and continually they will force an election
-in order to become the local master browser.
+<programlisting>
+Subnet Browse Master List
+------ ------------- ----
+Subnet1 N1_C N1_A, N1_B, N1_C, N1_D, N1_E,
+ N2_A(*), N2_B(*), N2_C(*), N2_D(*)
+
+Subnet2 N2_B N2_A, N2_B, N2_C, N2_D
+ N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*)
+
+Subnet3 N3_D N3_A, N3_B, N3_C, N3_D
+
+Servers with a (*) after them are non-authoritative names.
+</programlisting>
</para>
<para>
-If you want samba to be a <command>domain master browser</command>, then it is
-recommended that you also set <command>preferred master</command> to "yes", because
-samba will not become a domain master browser for the whole of your
-LAN or WAN if it is not also a local master browser on its own
-broadcast isolated subnet.
+At this point users looking in their network neighborhood on
+subnets 1 or 2 will see all the servers on both, users on
+subnet 3 will still only see the servers on their own subnet.
</para>
<para>
-It is possible to configure two samba servers to attempt to become
-the domain master browser for a domain. The first server that comes
-up will be the domain master browser. All other samba servers will
-attempt to become the domain master browser every 5 minutes. They
-will find that another samba server is already the domain master
-browser and will fail. This provides automatic redundancy, should
-the current domain master browser fail.
+The same sequence of events that occured for N2_B now occurs
+for the local master browser on subnet 3 (N3_D). When it
+synchronizes browse lists with the domain master browser (N1_A)
+it gets both the server entries on subnet 1, and those on
+subnet 2. After N3_D has synchronized with N1_C and vica-versa
+the browse lists look like.
</para>
-</sect1>
+<para>
+<programlisting>
+Subnet Browse Master List
+------ ------------- ----
+Subnet1 N1_C N1_A, N1_B, N1_C, N1_D, N1_E,
+ N2_A(*), N2_B(*), N2_C(*), N2_D(*),
+ N3_A(*), N3_B(*), N3_C(*), N3_D(*)
-<sect1>
-<title>Making samba the domain master</title>
+Subnet2 N2_B N2_A, N2_B, N2_C, N2_D
+ N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*)
+
+Subnet3 N3_D N3_A, N3_B, N3_C, N3_D
+ N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*),
+ N2_A(*), N2_B(*), N2_C(*), N2_D(*)
+
+Servers with a (*) after them are non-authoritative names.
+</programlisting>
+</para>
<para>
-The domain master is responsible for collating the browse lists of
-multiple subnets so that browsing can occur between subnets. You can
-make samba act as the domain master by setting <command>domain master = yes</command>
-in &smb.conf;. By default it will not be a domain master.
+At this point users looking in their network neighborhood on
+subnets 1 or 3 will see all the servers on all sunbets, users on
+subnet 2 will still only see the servers on subnets 1 and 2, but not 3.
</para>
<para>
-Note that you should NOT set Samba to be the domain master for a
-workgroup that has the same name as an NT Domain.
+Finally, the local master browser for subnet 2 (N2_B) will sync again
+with the domain master browser (N1_C) and will recieve the missing
+server entries. Finally - and as a steady state (if no machines
+are removed or shut off) the browse lists will look like :
</para>
<para>
-When samba is the domain master and the master browser it will listen
-for master announcements (made roughly every twelve minutes) from local
-master browsers on other subnets and then contact them to synchronise
-browse lists.
+<programlisting>
+Subnet Browse Master List
+------ ------------- ----
+Subnet1 N1_C N1_A, N1_B, N1_C, N1_D, N1_E,
+ N2_A(*), N2_B(*), N2_C(*), N2_D(*),
+ N3_A(*), N3_B(*), N3_C(*), N3_D(*)
+
+Subnet2 N2_B N2_A, N2_B, N2_C, N2_D
+ N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*)
+ N3_A(*), N3_B(*), N3_C(*), N3_D(*)
+
+Subnet3 N3_D N3_A, N3_B, N3_C, N3_D
+ N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*),
+ N2_A(*), N2_B(*), N2_C(*), N2_D(*)
+
+Servers with a (*) after them are non-authoritative names.
+</programlisting>
</para>
<para>
-If you want samba to be the domain master then I suggest you also set
-the <command>os level</command> high enough to make sure it wins elections, and set
-<command>preferred master</command> to "yes", to get samba to force an election on
-startup.
+Synchronizations between the domain master browser and local
+master browsers will continue to occur, but this should be a
+steady state situation.
</para>
<para>
-Note that all your servers (including samba) and clients should be
-using a WINS server to resolve NetBIOS names. If your clients are only
-using broadcasting to resolve NetBIOS names, then two things will occur:
+If either router R1 or R2 fails the following will occur:
</para>
<orderedlist>
<listitem>
<para>
- your local master browsers will be unable to find a domain master
- browser, as it will only be looking on the local subnet.
- </para>
-</listitem>
-
-<listitem>
- <para>
- if a client happens to get hold of a domain-wide browse list, and
- a user attempts to access a host in that list, it will be unable to
- resolve the NetBIOS name of that host.
+ Names of computers on each side of the inaccessible network fragments
+ will be maintained for as long as 36 minutes, in the network neighbourhood
+ lists.
</para>
</listitem>
-</orderedlist>
-
-<para>
-If, however, both samba and your clients are using a WINS server, then:
-</para>
-<orderedlist>
<listitem>
<para>
- your local master browsers will contact the WINS server and, as long as
- samba has registered that it is a domain master browser with the WINS
- server, your local master browser will receive samba's ip address
- as its domain master browser.
+ Attempts to connect to these inaccessible computers will fail, but the
+ names will not be removed from the network neighbourhood lists.
</para>
</listitem>
<listitem>
<para>
- when a client receives a domain-wide browse list, and a user attempts
- to access a host in that list, it will contact the WINS server to
- resolve the NetBIOS name of that host. as long as that host has
- registered its NetBIOS name with the same WINS server, the user will
- be able to see that host.
+ If one of the fragments is cut off from the WINS server, it will only
+ be able to access servers on its local subnet, by using subnet-isolated
+ broadcast NetBIOS name resolution. The effects are similar to that of
+ losing access to a DNS server.
</para>
</listitem>
</orderedlist>
+</sect3>
+</sect2>
-</sect1>
-
-<sect1>
-<title>Note about broadcast addresses</title>
-
-<para>
-If your network uses a "0" based broadcast address (for example if it
-ends in a 0) then you will strike problems. Windows for Workgroups
-does not seem to support a 0's broadcast and you will probably find
-that browsing and name lookups won't work.
-</para>
-</sect1>
-
-<sect1>
-<title>Multiple interfaces</title>
-
-<para>
-Samba now supports machines with multiple network interfaces. If you
-have multiple interfaces then you will need to use the <command>interfaces</command>
-option in &smb.conf; to configure them.
-</para>
</sect1>
</chapter>
git.samba.org / samba.git / commitdiff