diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/docbook/global.ent | 7 | ||||
| -rw-r--r-- | docs/docbook/projdoc/Browsing-Quickguide.sgml | 416 | ||||
| -rw-r--r-- | docs/docbook/projdoc/NetworkBrowsing.sgml (renamed from docs/docbook/projdoc/Browsing.sgml) | 1313 | ||||
| -rw-r--r-- | docs/docbook/projdoc/samba-doc.sgml | 3 |
4 files changed, 901 insertions, 838 deletions
diff --git a/docs/docbook/global.ent b/docs/docbook/global.ent index c69b72d8a6..dcef1084d6 100644 --- a/docs/docbook/global.ent +++ b/docs/docbook/global.ent @@ -407,8 +407,7 @@ an Active Directory environment. <!ENTITY ID-BUGS SYSTEM "bugreport"> <!ENTITY ID-SECURITY-LEVEL SYSTEM "securitylevels"> <!ENTITY ID-SPEED SYSTEM "speed"> -<!ENTITY ID-BROWSING SYSTEM "improved-browsing"> -<!ENTITY ID-BROWSING-Quick SYSTEM "Browsing-Quick"> +<!ENTITY ID-NetworkBrowsing SYSTEM "network-browsing"> <!ENTITY ID-GROUP-MAPPING-HOWTO SYSTEM "groupmapping"> <!ENTITY ID-Portability SYSTEM "Portability"> <!ENTITY ID-Other-Clients SYSTEM "Other-Clients"> @@ -451,8 +450,7 @@ an Active Directory environment. <!ENTITY ADS-HOWTO SYSTEM "projdoc/ADS-HOWTO.sgml"> <!ENTITY AdvancedNetworkAdmin SYSTEM "projdoc/AdvancedNetworkAdmin.sgml"> -<!ENTITY BROWSING SYSTEM "projdoc/Browsing.sgml"> -<!ENTITY BROWSING-Quick SYSTEM "projdoc/Browsing-Quickguide.sgml"> +<!ENTITY NetworkBrowsing SYSTEM "projdoc/NetworkBrowsing.sgml"> <!ENTITY BUGS SYSTEM "projdoc/Bugs.sgml"> <!ENTITY CUPS SYSTEM "projdoc/CUPS-printing.sgml"> <!ENTITY CVS-Access SYSTEM "projdoc/CVS-Access.sgml"> @@ -463,6 +461,7 @@ an Active Directory environment. <!ENTITY GROUP-MAPPING-HOWTO SYSTEM "projdoc/GROUP-MAPPING-HOWTO.sgml"> <!ENTITY IntegratingWithWindows SYSTEM "projdoc/Integrating-with-Windows.sgml"> <!ENTITY IntroSMB SYSTEM "projdoc/IntroSMB.sgml"> +<!ENTITY locking SYSTEM "projdoc/locking.sgml"> <!ENTITY MS-Dfs-Setup SYSTEM "projdoc/msdfs_setup.sgml"> <!ENTITY NT-Security SYSTEM "projdoc/NT_Security.sgml"> <!ENTITY NT4Migration SYSTEM "projdoc/NT4Migration.sgml"> diff --git a/docs/docbook/projdoc/Browsing-Quickguide.sgml b/docs/docbook/projdoc/Browsing-Quickguide.sgml deleted file mode 100644 index d8df57dcb9..0000000000 --- a/docs/docbook/projdoc/Browsing-Quickguide.sgml +++ /dev/null @@ -1,416 +0,0 @@ -<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> diff --git a/docs/docbook/projdoc/Browsing.sgml b/docs/docbook/projdoc/NetworkBrowsing.sgml index ca2f6dc57b..c4b6a07777 100644 --- a/docs/docbook/projdoc/Browsing.sgml +++ b/docs/docbook/projdoc/NetworkBrowsing.sgml @@ -1,18 +1,898 @@ -<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>What is Browsing?</title> + +<para> +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> +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> +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>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 <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> + +<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 <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>Overview of browsing</title> +<title>How Browsing Functions</title> + +<para> +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> +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> + +<sect2> +<title>Setting up Browsing in a WORKGROUP</title> + +<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. +</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 : +</para> + +<para> +<programlisting> + domain master = yes +</programlisting> +</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 : +</para> + +<para> +<programlisting> + domain master = yes + local master = yes + preferred master = yes + os level = 65 +</programlisting> +</para> + +<para> +The domain master browser may be the same machine as the WINS +server, if you require. +</para> + +<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 : +</para> + +<para> +<programlisting> + domain master = no + local master = yes + preferred master = yes + os level = 65 +</programlisting> +</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. +</para> + +<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. +</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 : +</para> + +<para> +<programlisting> + domain master = no + local master = no + preferred master = no + os level = 0 +</programlisting> +</para> + +</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> +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> + domain master = no + local master = yes + preferred master = yes + os level = 65 +</programlisting> +</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. +</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 : +</para> + +<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> +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> +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> +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> + +<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. +</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. +</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. +</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> + 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. + </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. + </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 +</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> +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> + +</sect2> + +<sect2> +<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> +</sect2> +</sect1> + +<sect1> +<title>Technical Overview of browsing</title> <para> SMB networking provides a mechanism by which clients can access a list @@ -40,9 +920,7 @@ WINS allows remote segment clients to obtain NetBIOS name_type information that can NOT be provided by any other means of name resolution. </para> -</sect1> - -<sect1> +<sect2> <title>Browsing support in samba</title> <para> @@ -91,9 +969,9 @@ used for 'unusual' purposes: announcements over the internet, for example. See <command>remote announce</command> in the &smb.conf; man page. </para> -</sect1> +</sect2> -<sect1> +<sect2> <title>Problem resolution</title> <para> @@ -130,9 +1008,9 @@ 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> -</sect1> +</sect2> -<sect1> +<sect2> <title>Browsing across subnets</title> <para> Since the release of Samba 1.9.17(alpha1) Samba has been @@ -163,7 +1041,7 @@ of a WINS server given to them by a DHCP server, or by manual configuration settings) for Samba this is in the &smb.conf; file. </para> -<sect2> +<sect3> <title>How does cross subnet browsing work ?</title> <para> @@ -403,405 +1281,8 @@ If either router R1 or R2 fails the following will occur: </para> </listitem> </orderedlist> +</sect3> </sect2> -</sect1> - -<sect1> -<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 -</para> - -<para> -<command> wins support = yes</command> -</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> -<command>wins server = >name or IP address<</command> -</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> - -</sect1> - -<sect1> -<title>Setting up Browsing in a WORKGROUP</title> - -<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. -</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 : -</para> - -<para> -<command>domain master = yes</command> -</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 : -</para> - -<para> -<programlisting> -domain master = yes -local master = yes -preferred master = yes -os level = 65 -</programlisting> -</para> - -<para> -The domain master browser may be the same machine as the WINS -server, if you require. -</para> - -<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 : -</para> - -<para> -<programlisting> -domain master = no -local master = yes -preferred master = yes -os level = 65 -</programlisting> -</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. -</para> - -<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. -</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 : -</para> - -<para> -<programlisting> -domain master = no -local master = no -preferred master = no -os level = 0 -</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. -</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 : -</para> - -<para> -<programlisting> -domain master = no -local master = yes -preferred master = yes -os level = 65 -</programlisting> -</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. -</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 : -</para> - -<para> -<command> - domain master = no - local master = no - preferred master = no - os level = 0 -</command> -</para> - -</sect1> - -<sect1 id="browse-force-master"> -<title>Forcing samba to be the master</title> - -<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. -</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!) -</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. -</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. -</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. -</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. -</para> - -</sect1> - -<sect1> -<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> - 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. - </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. - </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> - -</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> diff --git a/docs/docbook/projdoc/samba-doc.sgml b/docs/docbook/projdoc/samba-doc.sgml index a0fc27fcb0..5c3793a1ba 100644 --- a/docs/docbook/projdoc/samba-doc.sgml +++ b/docs/docbook/projdoc/samba-doc.sgml @@ -50,7 +50,7 @@ PLEASE read this.</para> </partintro> &IntroSMB; &UNIX-INSTALL; -&BROWSING-Quick; +&NetworkBrowsing; &Passdb; </part> @@ -90,7 +90,6 @@ for various environments. &VFS; &MS-Dfs-Setup; &IntegratingWithWindows; -&BROWSING; &SecuringSamba; &unicode; &locking; |