summaryrefslogtreecommitdiff
path: root/docs/htmldocs/browsing-quick.html
diff options
context:
space:
mode:
Diffstat (limited to 'docs/htmldocs/browsing-quick.html')
-rw-r--r--docs/htmldocs/browsing-quick.html445
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
+>&#13;</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"
+>&nbsp;</TD
+><TD
+WIDTH="33%"
+ALIGN="right"
+VALIGN="top"
+>Samba performance issues</TD
+></TR
+></TABLE
+></DIV
+></BODY
+></HTML
+> \ No newline at end of file