diff options
| author | cvs2svn Import User <samba-bugs@samba.org> | 2002-10-21 18:01:03 +0000 |
|---|---|---|
| committer | cvs2svn Import User <samba-bugs@samba.org> | 2002-10-21 18:01:03 +0000 |
| commit | c1d854e7845749bc3483bcf728089a32bbbae06d (patch) | |
| tree | 8813e598b9f91e7173a9ed2a8f3acaf590a4e474 /docs/htmldocs/browsing-quick.html | |
| parent | 7fedc7a7a27dc93351b99abd8473f2e4f8445cf6 (diff) | |
| parent | 6c82e994d9d796a6ffd6061eb2b5a368edfa8969 (diff) | |
| download | samba-c1d854e7845749bc3483bcf728089a32bbbae06d.tar.gz samba-c1d854e7845749bc3483bcf728089a32bbbae06d.tar.bz2 samba-c1d854e7845749bc3483bcf728089a32bbbae06d.zip | |
This commit was manufactured by cvs2svn to create branch 'SAMBA_3_0'.(This used to be commit d39b53ba5486fc09e5332d77aad9a6047b0e91a6)
Diffstat (limited to 'docs/htmldocs/browsing-quick.html')
| -rw-r--r-- | docs/htmldocs/browsing-quick.html | 445 |
1 files changed, 445 insertions, 0 deletions
diff --git a/docs/htmldocs/browsing-quick.html b/docs/htmldocs/browsing-quick.html new file mode 100644 index 0000000000..340302a102 --- /dev/null +++ b/docs/htmldocs/browsing-quick.html @@ -0,0 +1,445 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> +<HTML +><HEAD +><TITLE +>Quick Cross Subnet Browsing / Cross Workgroup Browsing guide</TITLE +><META +NAME="GENERATOR" +CONTENT="Modular DocBook HTML Stylesheet Version 1.77"><LINK +REL="HOME" +TITLE="SAMBA Project Documentation" +HREF="samba-howto-collection.html"><LINK +REL="PREVIOUS" +TITLE="Improved browsing in samba" +HREF="improved-browsing.html"><LINK +REL="NEXT" +TITLE="Samba performance issues" +HREF="speed.html"></HEAD +><BODY +CLASS="CHAPTER" +BGCOLOR="#FFFFFF" +TEXT="#000000" +LINK="#0000FF" +VLINK="#840084" +ALINK="#0000FF" +><DIV +CLASS="NAVHEADER" +><TABLE +SUMMARY="Header navigation table" +WIDTH="100%" +BORDER="0" +CELLPADDING="0" +CELLSPACING="0" +><TR +><TH +COLSPAN="3" +ALIGN="center" +>SAMBA Project Documentation</TH +></TR +><TR +><TD +WIDTH="10%" +ALIGN="left" +VALIGN="bottom" +><A +HREF="improved-browsing.html" +ACCESSKEY="P" +>Prev</A +></TD +><TD +WIDTH="80%" +ALIGN="center" +VALIGN="bottom" +></TD +><TD +WIDTH="10%" +ALIGN="right" +VALIGN="bottom" +><A +HREF="speed.html" +ACCESSKEY="N" +>Next</A +></TD +></TR +></TABLE +><HR +ALIGN="LEFT" +WIDTH="100%"></DIV +><DIV +CLASS="CHAPTER" +><H1 +><A +NAME="BROWSING-QUICK" +></A +>Chapter 16. Quick Cross Subnet Browsing / Cross Workgroup Browsing guide</H1 +><P +>This document should be read in conjunction with Browsing and may +be taken as the fast track guide to implementing browsing across subnets +and / or across workgroups (or domains). WINS is the best tool for resolution +of NetBIOS names to IP addesses. WINS is NOT involved in browse list handling +except by way of name to address mapping.</P +><DIV +CLASS="SECT1" +><H1 +CLASS="SECT1" +><A +NAME="AEN2665" +></A +>16.1. Discussion</H1 +><P +>Firstly, all MS Windows networking is based on SMB (Server Message +Block) based messaging. SMB messaging is implemented using NetBIOS. Samba +implements NetBIOS by encapsulating it over TCP/IP. MS Windows products can +do likewise. NetBIOS based networking uses broadcast messaging to affect +browse list management. When running NetBIOS over TCP/IP this uses UDP +based messaging. UDP messages can be broadcast or unicast.</P +><P +>Normally, only unicast UDP messaging can be forwarded by routers. The +"remote announce" parameter to smb.conf helps to project browse announcements +to remote network segments via unicast UDP. Similarly, the "remote browse sync" +parameter of smb.conf implements browse list collation using unicast UDP.</P +><P +>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 "remote announce" and +the "remote browse sync" parameters to your smb.conf file.</P +><P +>If only one WINS server is used then the use of the "remote announce" and the +"remote browse sync" parameters should NOT be necessary.</P +><P +>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 "remote browse sync" and "remote announce" +to affect browse list collation across all segments. Note that this means +clients will only resolve local names, and must be configured to use DNS to +resolve names on other subnets in order to resolve the IP addresses of the +servers they can see on other subnets. This setup is not recommended, but is +mentioned as a practical consideration (ie: an 'if all else fails' scenario).</P +><P +>Lastly, take note that browse lists are a collection of unreliable broadcast +messages that are repeated at intervals of not more than 15 minutes. This means +that it will take time to establish a browse list and it can take up to 45 +minutes to stabilise, particularly across network segments.</P +></DIV +><DIV +CLASS="SECT1" +><H1 +CLASS="SECT1" +><A +NAME="AEN2673" +></A +>16.2. Use of the "Remote Announce" parameter</H1 +><P +>The "remote announce" parameter of smb.conf can be used to forcibly ensure +that all the NetBIOS names on a network get announced to a remote network. +The syntax of the "remote announce" parameter is: +<PRE +CLASS="PROGRAMLISTING" +> remote announce = a.b.c.d [e.f.g.h] ...</PRE +> +_or_ +<PRE +CLASS="PROGRAMLISTING" +> remote announce = a.b.c.d/WORKGROUP [e.f.g.h/WORKGROUP] ...</PRE +> + +where: +<P +></P +><DIV +CLASS="VARIABLELIST" +><DL +><DT +>a.b.c.d and e.f.g.h</DT +><DD +><P +>is either the LMB (Local Master Browser) IP address +or the broadcst address of the remote network. +ie: the LMB is at 192.168.1.10, or the address +could be given as 192.168.1.255 where the netmask +is assumed to be 24 bits (255.255.255.0). +When the remote announcement is made to the broadcast +address of the remote network every host will receive +our announcements. This is noisy and therefore +undesirable but may be necessary if we do NOT know +the IP address of the remote LMB.</P +></DD +><DT +>WORKGROUP</DT +><DD +><P +>is optional and can be either our own workgroup +or that of the remote network. If you use the +workgroup name of the remote network then our +NetBIOS machine names will end up looking like +they belong to that workgroup, this may cause +name resolution problems and should be avoided.</P +></DD +></DL +></DIV +> </P +></DIV +><DIV +CLASS="SECT1" +><H1 +CLASS="SECT1" +><A +NAME="AEN2687" +></A +>16.3. Use of the "Remote Browse Sync" parameter</H1 +><P +>The "remote browse sync" parameter of smb.conf is used to announce to +another LMB that it must synchronise it's NetBIOS name list with our +Samba LMB. It works ONLY if the Samba server that has this option is +simultaneously the LMB on it's network segment.</P +><P +>The syntax of the "remote browse sync" parameter is: +<PRE +CLASS="PROGRAMLISTING" +> remote browse sync = a.b.c.d</PRE +> + +where a.b.c.d is either the IP address of the remote LMB or else is the network broadcast address of the remote segment.</P +></DIV +><DIV +CLASS="SECT1" +><H1 +CLASS="SECT1" +><A +NAME="AEN2692" +></A +>16.4. Use of WINS</H1 +><P +>Use of WINS (either Samba WINS _or_ MS Windows NT Server WINS) is highly +recommended. Every NetBIOS machine registers it's name together with a +name_type value for each of of several types of service it has available. +eg: It registers it's name directly as a unique (the type 0x03) name. +It also registers it's name if it is running the lanmanager compatible +server service (used to make shares and printers available to other users) +by registering the server (the type 0x20) name.</P +><P +>All NetBIOS names are up to 15 characters in length. The name_type variable +is added to the end of the name - thus creating a 16 character name. Any +name that is shorter than 15 characters is padded with spaces to the 15th +character. ie: All NetBIOS names are 16 characters long (including the +name_type information).</P +><P +>WINS can store these 16 character names as they get registered. A client +that wants to log onto the network can ask the WINS server for a list +of all names that have registered the NetLogon service name_type. This saves +broadcast traffic and greatly expedites logon processing. Since broadcast +name resolution can not be used across network segments this type of +information can only be provided via WINS _or_ via statically configured +"lmhosts" files that must reside on all clients in the absence of WINS.</P +><P +>WINS also serves the purpose of forcing browse list synchronisation by all +LMB's. LMB's must synchronise their browse list with the DMB (domain master +browser) and WINS helps the LMB to identify it's DMB. By definition this +will work only within a single workgroup. Note that the domain master browser +has NOTHING to do with what is referred to as an MS Windows NT Domain. The +later is a reference to a security environment while the DMB refers to the +master controller for browse list information only.</P +><P +>Use of WINS will work correctly only if EVERY client TCP/IP protocol stack +has been configured to use the WINS server/s. Any client that has not been +configured to use the WINS server will continue to use only broadcast based +name registration so that WINS may NEVER get to know about it. In any case, +machines that have not registered with a WINS server will fail name to address +lookup attempts by other clients and will therefore cause workstation access +errors.</P +><P +>To configure Samba as a WINS server just add "wins support = yes" to the +smb.conf file [globals] section.</P +><P +>To configure Samba to register with a WINS server just add +"wins server = a.b.c.d" to your smb.conf file [globals] section.</P +><P +><SPAN +CLASS="emphasis" +><I +CLASS="EMPHASIS" +>DO NOT EVER</I +></SPAN +> use both "wins support = yes" together with "wins server = a.b.c.d" +particularly not using it's own IP address.</P +></DIV +><DIV +CLASS="SECT1" +><H1 +CLASS="SECT1" +><A +NAME="AEN2703" +></A +>16.5. Do NOT use more than one (1) protocol on MS Windows machines</H1 +><P +>A very common cause of browsing problems results from installing more than +one protocol on an MS Windows machine.</P +><P +>Every NetBIOS machine take part in a process of electing the LMB (and DMB) +every 15 minutes. A set of election criteria is used to determine the order +of precidence for winning this election process. A machine running Samba or +Windows NT will be biased so that the most suitable machine will predictably +win and thus retain it's role.</P +><P +>The election process is "fought out" so to speak over every NetBIOS network +interface. In the case of a Windows 9x machine that has both TCP/IP and IPX +installed and has NetBIOS enabled over both protocols the election will be +decided over both protocols. As often happens, if the Windows 9x machine is +the only one with both protocols then the LMB may be won on the NetBIOS +interface over the IPX protocol. Samba will then lose the LMB role as Windows +9x will insist it knows who the LMB is. Samba will then cease to function +as an LMB and thus browse list operation on all TCP/IP only machines will +fail.</P +><P +>The safest rule of all to follow it this - USE ONLY ONE PROTOCOL!</P +></DIV +><DIV +CLASS="SECT1" +><H1 +CLASS="SECT1" +><A +NAME="AEN2709" +></A +>16.6. Name Resolution Order</H1 +><P +>Resolution of NetBIOS names to IP addresses can take place using a number +of methods. The only ones that can provide NetBIOS name_type information +are: +<P +></P +><TABLE +BORDER="0" +><TBODY +><TR +><TD +>WINS: the best tool!</TD +></TR +><TR +><TD +>LMHOSTS: is static and hard to maintain.</TD +></TR +><TR +><TD +>Broadcast: uses UDP and can not resolve names across remote segments.</TD +></TR +></TBODY +></TABLE +><P +></P +></P +><P +>Alternative means of name resolution includes: +<P +></P +><TABLE +BORDER="0" +><TBODY +><TR +><TD +>/etc/hosts: is static, hard to maintain, and lacks name_type info</TD +></TR +><TR +><TD +>DNS: is a good choice but lacks essential name_type info.</TD +></TR +></TBODY +></TABLE +><P +></P +></P +><P +>Many sites want to restrict DNS lookups and want to avoid broadcast name +resolution traffic. The "name resolve order" parameter is of great help here. +The syntax of the "name resolve order" parameter is: +<PRE +CLASS="PROGRAMLISTING" +> name resolve order = wins lmhosts bcast host</PRE +> +_or_ +<PRE +CLASS="PROGRAMLISTING" +> name resolve order = wins lmhosts (eliminates bcast and host)</PRE +> +The default is: +<PRE +CLASS="PROGRAMLISTING" +> name resolve order = host lmhost wins bcast</PRE +>. +where "host" refers the the native methods used by the Unix system +to implement the gethostbyname() function call. This is normally +controlled by <TT +CLASS="FILENAME" +>/etc/host.conf</TT +>, <TT +CLASS="FILENAME" +>/etc/nsswitch.conf</TT +> and <TT +CLASS="FILENAME" +>/etc/resolv.conf</TT +>.</P +></DIV +></DIV +><DIV +CLASS="NAVFOOTER" +><HR +ALIGN="LEFT" +WIDTH="100%"><TABLE +SUMMARY="Footer navigation table" +WIDTH="100%" +BORDER="0" +CELLPADDING="0" +CELLSPACING="0" +><TR +><TD +WIDTH="33%" +ALIGN="left" +VALIGN="top" +><A +HREF="improved-browsing.html" +ACCESSKEY="P" +>Prev</A +></TD +><TD +WIDTH="34%" +ALIGN="center" +VALIGN="top" +><A +HREF="samba-howto-collection.html" +ACCESSKEY="H" +>Home</A +></TD +><TD +WIDTH="33%" +ALIGN="right" +VALIGN="top" +><A +HREF="speed.html" +ACCESSKEY="N" +>Next</A +></TD +></TR +><TR +><TD +WIDTH="33%" +ALIGN="left" +VALIGN="top" +>Improved browsing in samba</TD +><TD +WIDTH="34%" +ALIGN="center" +VALIGN="top" +> </TD +><TD +WIDTH="33%" +ALIGN="right" +VALIGN="top" +>Samba performance issues</TD +></TR +></TABLE +></DIV +></BODY +></HTML +>
\ No newline at end of file |