Large number of small fixes to the layout and the build system.

(This used to be commit 73fac0653c774a8ed8654b064fd63d4e486f6b0f)

1 files changed, 340 insertions, 0 deletions

diff --git a/docs/Samba3-HOWTO/TOSHARG-DNS-DHCP-Configuration.xml b/docs/Samba3-HOWTO/TOSHARG-DNS-DHCP-Configuration.xml
new file mode 100644
index 0000000000..d693c7edf6
--- /dev/null
+++ b/docs/Samba3-HOWTO/TOSHARG-DNS-DHCP-Configuration.xml
@@ -0,0 +1,340 @@
+<?xml version="1.0" encoding="iso-8859-1"?>
+<!DOCTYPE chapter PUBLIC "-//Samba-Team//DTD DocBook V4.2-Based Variant V1.0//EN" "http://www.samba.org/samba/DTD/samba-doc">
+<chapter id="DNSDHCP">
+<chapterinfo>
+	&author.jht;
+</chapterinfo>
+
+<title>DNS and DHCP Configuration Guide</title>
+
+<sect1>
+<title>Features and Benefits</title>
+
+<para>
+There are few subjects in the UNIX world that might raise as much contention as
+Domain Name System (DNS) and Dynamic Host Configuration Protocol (DHCP).
+Not all opinions held for or against particular implementations of DNS and DHCP
+are valid.
+</para>
+
+<para>
+We live in a modern age where many information technology users demand mobility
+and freedom. Microsoft Windows users in particular expect to be able to plug their
+notebook computer into a network port and have things <quote>just work.</quote>
+</para>
+
+<para>
+UNIX administrators have a point. Many of the normative practices in the Microsoft
+Windows world at best border on bad practice from a security perspective.
+Microsoft Windows networking protocols allow workstations to arbitrarily register
+themselves on a network. Windows 2000 Active Directory registers entries in the DNS name space
+that are equally perplexing to UNIX administrators. Welcome to the new world!
+</para>
+
+
+<para>
+<indexterm><primary>ISC</primary><secondary>DNS</secondary></indexterm>
+<indexterm><primary>ISC</primary><secondary>DHCP</secondary></indexterm>
+The purpose of this chapter is to demonstrate the configuration of the Internet
+Software Consortium (ISC) DNS and DHCP servers to provide dynamic services that are
+compatible with their equivalents in the Microsoft Windows 2000 Server products.
+</para>
+
+<para>
+The purpose of this chapter is to provide no more than a working example of
+configuration files for both DNS and DHCP servers. The examples used match
+configuration examples used elsewhere in this document.
+</para>
+
+<para>
+This chapter explicitly does not provide a tutorial, nor does it pretend to be
+a reference guide on DNS and DHCP, as this is well beyond the scope and intent
+of this document as a whole. Anyone who wants more detailed reference materials
+on DNS or DHCP should visit the ISC Web sites at <ulink noescape="1" url="http://www.isc.org">
+http://www.isc.org</ulink>. Those wanting a written text might also be interested
+in the O'Reilly publications on these two subjects.
+</para>
+
+</sect1>
+
+<sect1>
+<title>Example Configuration</title>
+
+<para>
+The domain name system is to the Internet what water is to life. By it nearly all
+information resources (host names) are resolved to their Internet protocol (IP) address.
+Windows networking tried hard to avoid the complexities of DNS, but alas, DNS won.
+<indexterm><primary>WINS</primary></indexterm>
+The alternative to DNS, the Windows Internet Name Service (WINS) an artifact of
+NetBIOS networking over the TCP/IP protocols, has demonstrated scalability problems as
+well as a flat non-hierarchical name space that became unmanageable as the size and
+complexity of information technology networks grew.
+</para>
+
+<para>
+WINS is a Microsoft implementation of the RFC1001/1002 NetBIOS Name Service (NBNS).
+It allows NetBIOS clients (like Microsoft Windows Machines) to register an arbitrary
+machine name that the administrator or user has chosen together with the IP
+address that the machine has been given. Through the use of WINS, network client machines
+could resolve machine names to their IP address.
+</para>
+
+<para>
+The demand for an alternative to the limitations of NetBIOS networking finally drove
+Microsoft to use DNS and Active Directory. Microsoft's new implementation attempts
+to use DNS in a manner similar to the way that WINS is used for NetBIOS networking.
+Both WINS and Microsoft DNS rely on dynamic name registration.
+</para> 
+
+<para>
+Microsoft Windows clients can perform dynamic name registration to the DNS server
+on start-up. Alternately, where DHCP is used to assign workstation IP addresses,
+it is possible to register host names and their IP address by the DHCP server as
+soon as a client acknowledges an IP address lease. Lastly, Microsoft DNS can resolve
+hostnames via Microsoft WINS.
+</para>
+
+<para>
+The following configurations demonstrate a simple insecure Dynamic DNS server and
+a simple DHCP server that matches the DNS configuration.
+</para>
+
+	<sect2>
+	<title>Dynamic DNS</title>
+
+	<para>
+	<indexterm><primary>DNS</primary><secondary>Dynamic</secondary></indexterm>
+	The example DNS configuration is for a private network in the IP address
+	space for network 192.168.1.0/24. The private class network address space
+	is set forth in RFC1918.
+	</para>
+
+
+	<para>
+	<indexterm><primary>BIND</primary></indexterm>
+	It is assumed that this network will be situated behind a secure firewall.
+	The files that follow work with ISC BIND version 9. BIND is the Berkeley
+	Internet Name Daemon. The following configuration files are offered:
+	</para>
+
+	<para>
+	The master configuration file <filename>/etc/named.conf</filename>
+	determines the location of all further configuration files used.
+	The location and name of this file is specified in the start-up script
+	that is part of the operating system.
+	<smbfile name="named.conf">
+<programlisting>
+# Quenya.Org configuration file
+
+acl mynet {
+	192.168.1.0/24;
+	127.0.0.1;
+};
+
+options {
+
+	directory "/var/named";
+	listen-on-v6 { any; };
+	notify no;
+	forward first;
+	forwarders {
+		192.168.1.1;
+		};
+	auth-nxdomain yes;
+	multiple-cnames yes;
+	listen-on {
+		mynet;
+		};
+};
+
+# The following three zone definitions do not need any modification.
+# The first one defines localhost while the second defines the
+# reverse lookup for localhost. The last zone "." is the
+# definition of the root name servers.
+
+zone "localhost" in {
+	type master;
+	file "localhost.zone";
+};
+
+zone "0.0.127.in-addr.arpa" in {
+	type master;
+	file "127.0.0.zone";
+};
+
+zone "." in {
+	type hint;
+	file "root.hint";
+};
+
+# You can insert further zone records for your own domains below.
+
+zone "quenya.org" {
+	type master;
+	file "/var/named/quenya.org.hosts";
+	allow-query {
+		mynet;
+		};
+	allow-transfer {
+		mynet;
+		};
+	allow-update {
+		mynet;
+		};
+	};
+
+zone "1.168.192.in-addr.arpa" {
+	type master;
+	file "/var/named/192.168.1.0.rev";
+	allow-query {
+		mynet;
+	};
+	allow-transfer {
+		mynet;
+	};
+	allow-update {
+		mynet;
+	};
+};
+</programlisting>
+</smbfile>
+	</para>
+
+	<para>
+	The following files are all located in the directory <filename>/var/named</filename>.
+	This is the <filename>/var/named/localhost.zone</filename> file:
+	<smbfile name="localhost.zone">
+<programlisting>
+$TTL 1W
+@               IN SOA  @   root (
+				42              ; serial (d. adams)
+				2D              ; refresh
+				4H              ; retry
+				6W              ; expiry
+				1W )            ; minimum
+
+		IN NS           @
+		IN A            127.0.0.1
+	</programlisting>
+</smbfile>
+	</para>
+
+	<para>
+	The <filename>/var/named/127.0.0.zone</filename> file:
+	<smbfile name="127.0.0.0.zone">
+<programlisting>
+$TTL 1W
+@               IN SOA          localhost.  root.localhost. (
+				42              ; serial (d. adams)
+				2D              ; refresh
+				4H              ; retry
+				6W              ; expiry
+				1W )            ; minimum
+
+				IN NS           localhost.
+1               IN PTR          localhost.
+</programlisting>
+</smbfile>
+	</para>
+
+	<para>
+		The <filename>/var/named/quenya.org.host</filename> file:
+			<smbfile name="quenya.org.host">
+<programlisting>
+$ORIGIN .
+$TTL 38400      ; 10 hours 40 minutes
+quenya.org      IN SOA  marvel.quenya.org. root.quenya.org. (
+				2003021832 ; serial
+				10800      ; refresh (3 hours)
+				3600       ; retry (1 hour)
+				604800     ; expire (1 week)
+				38400      ; minimum (10 hours 40 minutes)
+				)
+			NS      marvel.quenya.org.
+			MX      10 mail.quenya.org.
+$ORIGIN quenya.org.
+frodo                   A       192.168.1.1
+marvel                  A       192.168.1.2
+;
+mail                    CNAME   marvel
+www                     CNAME   marvel
+</programlisting>
+</smbfile>
+</para>
+
+<para>
+	The <filename>/var/named/192.168.1.0.rev</filename> file:
+	<smbfile name="192.168.1.0.rev">
+<programlisting>
+$ORIGIN .
+$TTL 38400      ; 10 hours 40 minutes
+1.168.192.in-addr.arpa  IN SOA  marvel.quenya.org. root.quenya.org. (
+				2003021824 ; serial
+				10800      ; refresh (3 hours)
+				3600       ; retry (1 hour)
+				604800     ; expire (1 week)
+				38400      ; minimum (10 hours 40 minutes)
+				)
+			NS      marvel.quenya.org.
+$ORIGIN 1.168.192.in-addr.arpa.
+1                       PTR     frodo.quenya.org.
+2                       PTR     marvel.quenya.org.
+</programlisting>
+</smbfile>
+	</para>
+
+	<para>
+	The above were copied from a fully working system. All dynamically registered
+	entries have been removed. In addition to these files, BIND version 9 will
+	create for each of the dynamic registration files a file that has a 
+	<filename>.jnl</filename> extension. Do not edit or tamper with the configuration
+	files or with the <filename>.jnl</filename> files that are created.
+	</para>
+
+	</sect2>
+
+	<sect2 id="DHCP">
+	<title>DHCP Server</title>
+
+	<para>
+	The following file is used with the ISC DHCP Server version 3.
+	The file is located in <filename>/etc/dhcpd.conf</filename>:
+	</para>
+
+	<para>
+		<smbfile name="dhcpd.conf">
+	<programlisting>
+ddns-updates on;
+ddns-domainname "quenya.org";
+option ntp-servers 192.168.1.2;
+ddns-update-style ad-hoc;
+allow unknown-clients;
+default-lease-time 86400;
+max-lease-time 172800;
+
+option domain-name "quenya.org";
+option domain-name-servers 192.168.1.2;
+option netbios-name-servers 192.168.1.2;
+option netbios-dd-server 192.168.1.2;
+option netbios-node-type 8;
+
+subnet 192.168.1.0 netmask 255.255.255.0 {
+	range dynamic-bootp 192.168.1.60 192.168.1.254;
+	option subnet-mask 255.255.255.0;
+	option routers 192.168.1.2;
+	allow unknown-clients;
+}
+</programlisting>
+</smbfile>
+	</para>
+
+	<para>
+	In the above example, IP addresses between 192.168.1.1 and 192.168.1.59 are
+	reserved for fixed address (commonly called <constant>hard-wired</constant>) IP addresses. The
+	addresses between 192.168.1.60 and 192.168.1.254 are allocated for dynamic use.
+	</para>
+
+	</sect2>
+
+</sect1>
+</chapter>