Convert BROWSING-Config.txt to SGML

(This used to be commit 0b34832e33fbd81cec88730d671ca91abe6cc382)

2 files changed, 141 insertions, 72 deletions

diff --git a/docs/textdocs/BROWSING-Config.txt b/docs/docbook/projdoc/Browsing-Quickguide.sgml
index ba0f399f48..deb431020d 100644
--- a/docs/textdocs/BROWSING-Config.txt
+++ b/docs/docbook/projdoc/Browsing-Quickguide.sgml
@@ -1,44 +1,55 @@
-Date:		July 5, 1998
-Contributor:	John H Terpstra <jht@samba.org>
-
-Subject:	Cross Subnet Browsing / Cross Workgroup Browsing
-===============================================================================
-
-OVERVIEW:
-=========
-
-This document should be read in conjunction with BROWSING.txt and may
+<chapter id="Browsing-Quick">
+<chapterinfo>
+	<author>
+		<firstname>John</firstname><surname>Terpstra</surname>
+	</author>
+	<pubdate>July 5, 1998</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>
 
+<sect1>
+<title>Discussion</title>
 
-DISCUSSION:
-===========
-
+<para>
 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.
+</para>
 
+<para>
 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.
+</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 "remote announce" and
 the "remote browse sync" parameters to your smb.conf file.
+</para>
 
+<para>
 If only one WINS server is used then the use of the "remote announce" and the
 "remote browse sync" parameters should NOT be necessary.
+</para>
 
+<para>
 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
@@ -48,63 +59,85 @@ 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>
 
-A) Use of the "Remote Announce" parameter
-------------------------------------------
+<sect1>
+<title>Use of the "Remote Announce" parameter</title>
+<para>
 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:
-
+<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:
-	a.b.c.d:	is either the LMB (Local Master Browser) IP address
-	e.f.g.h:	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.
-
-	WORKGROUP:	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.
-
-
-B) Use of the "Remote Browse Sync" parameter
---------------------------------------------
-
+<variablelist>
+<varlistentry><term>a.b.c.d and e.f.g.h</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>WORKGROUP</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>
+
+</variablelist>
+
+</sect1>
+
+<sect1>
+<title>Use of the "Remote Browse Sync" parameter</title>
+
+<para>
 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.
+</para>
 
+<para>
 The syntax of the "remote browse  sync" parameter is:
-
+<programlisting>
 	remote browse sync = a.b.c.d
+</programlisting>
 
-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.
+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.
+</para>
 
+</sect1>
 
-C) Use of WINS
---------------
+<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.
@@ -112,13 +145,17 @@ 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
@@ -126,7 +163,9 @@ 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.
+</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
@@ -134,7 +173,9 @@ 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
@@ -142,29 +183,42 @@ 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 "wins support = yes" to the
 smb.conf 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>
 
-DO NOT EVER use both "wins support = yes" together with "wins server = a.b.c.d"
+<para>
+<emphasis>DO NOT EVER</emphasis> use both "wins support = yes" together with "wins server = a.b.c.d"
 particularly not using it's own IP address.
+</para>
 
+</sect1>
 
-D) Do NOT use more than one (1) protocol on MS Windows machines
----------------------------------------------------------------
+<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 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.
+</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
@@ -174,42 +228,53 @@ 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>
 The safest rule of all to follow it this - USE ONLY ONE PROTOCOL!
+</para>
 
+</sect1>
 
-E) Name Resolution Order
-========================
+<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:
-	WINS:		the best tool!
-	LMHOSTS:	is static and hard to maintain.
-	Broadcast:	uses UDP and can not resolve names across
-			remote segments.
-
+<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>
+
+<para>
 Alternative means of name resolution includes:
-	/etc/hosts:	is static, hard to maintain, and lacks name_type info.
-	DNS:		is a good choice but lacks essential name_type info.
+<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>
 
+<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)
-
-the default is:
+</programlisting>
+The default is:
+<programlisting>
 	name  resolve order = host lmhost wins bcast
-
-where:
-	"host" refers the the native methods used by the Unix system
-	to implement the gethostbyname() function call. This is normally
-	controlled by:
-		/etc/host.conf
-		/etc/nsswitch.conf
-		/etc/resolv.conf
-
-===============================================================================
+</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>.
+</sect1>
+</chapter>
diff --git a/docs/docbook/projdoc/samba-doc.sgml b/docs/docbook/projdoc/samba-doc.sgml
index 6fb77750e7..f20849edbf 100644
--- a/docs/docbook/projdoc/samba-doc.sgml
+++ b/docs/docbook/projdoc/samba-doc.sgml
@@ -18,13 +18,14 @@
 <!ENTITY SECURITY-LEVEL SYSTEM "security_level.sgml">
 <!ENTITY SPEED SYSTEM "Speed.sgml">
 <!ENTITY BROWSING SYSTEM "Browsing.sgml">
+<!ENTITY BROWSING-Quick SYSTEM "Browsing-Quickguide.sgml">
 <!ENTITY GROUP-MAPPING-HOWTO SYSTEM "GROUP-MAPPING-HOWTO.sgml">
 <!ENTITY Portability SYSTEM "Portability.sgml">
 <!ENTITY Other-Clients SYSTEM "Other-Clients.sgml">
 <!ENTITY ADS-HOWTO SYSTEM "ADS-HOWTO.sgml">
 ]>
 
-<book id="Samba-Project-Documentation">
+<book id="Samba-HOWTO-Collection">
 
 <title>SAMBA Project Documentation</title>
 
@@ -66,7 +67,6 @@ Cheers, jerry
 
 <!-- Chapters -->
 &UNIX-INSTALL;
-&Diagnosis;
 &IntegratingWithWindows;
 &Samba-PAM;
 &MS-Dfs-Setup;
@@ -81,11 +81,15 @@ Cheers, jerry
 &Samba-LDAP;
 &ADS-HOWTO;
 &BROWSING;
+&BROWSING-Quick;
 &SPEED;
-&Other-Clients;
 &CVS-Access;
 &BUGS;
 &GROUP-MAPPING-HOWTO;
+
+<!-- Appendices -->
 &Portability;
+&Other-Clients;
+&Diagnosis;
 
 </book>