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