diff options
Diffstat (limited to 'docs/docbook/projdoc/Browsing-Quickguide.sgml')
| -rw-r--r-- | docs/docbook/projdoc/Browsing-Quickguide.sgml | 390 |
1 files changed, 390 insertions, 0 deletions
diff --git a/docs/docbook/projdoc/Browsing-Quickguide.sgml b/docs/docbook/projdoc/Browsing-Quickguide.sgml new file mode 100644 index 0000000000..ed5b9a61af --- /dev/null +++ b/docs/docbook/projdoc/Browsing-Quickguide.sgml @@ -0,0 +1,390 @@ +<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> + +</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> |