syncing with HEAD some more

(This used to be commit 805a89fbb771659ce9d397daad59f47d8b5fefcc)

6 files changed, 70 insertions, 726 deletions

diff --git a/docs/docbook/projdoc/OS2-Client-HOWTO.sgml b/docs/docbook/projdoc/OS2-Client-HOWTO.sgml
deleted file mode 100644
index ca7ad6a754..0000000000
--- a/docs/docbook/projdoc/OS2-Client-HOWTO.sgml
+++ /dev/null
@@ -1,142 +0,0 @@
-<chapter id="os2">
-
-
-<chapterinfo>
-	<author>
-		<firstname>Jim</firstname><surname>McDonough</surname>
-		<affiliation>
-			<orgname>IBM</orgname>
-			<address>
-				<email>jerry@samba.org</email>
-			</address>
-		</affiliation>
-	</author>
-	
-		
-	<pubdate>5 Mar 2001</pubdate>
-</chapterinfo>
-
-<title>OS2 Client HOWTO</title>
-
-<sect1>
-	<title>FAQs</title>
-
-	<sect2>
-		<title>How can I configure OS/2 Warp Connect or 
-		OS/2 Warp 4 as a client for Samba?</title>
-
-		<para>A more complete answer to this question can be 
-		found on <ulink url="http://carol.wins.uva.nl/~leeuw/samba/warp.html">
-		http://carol.wins.uva.nl/~leeuw/samba/warp.html</ulink>.</para>
-		
-		<para>Basically, you need three components:</para>
-		
-		<itemizedlist>
-			<listitem><para>The File and Print Client ('IBM Peer')
-			</para></listitem>
-			<listitem><para>TCP/IP ('Internet support') 
-			</para></listitem>
-			<listitem><para>The "NetBIOS over TCP/IP" driver ('TCPBEUI')
-			</para></listitem>
-		</itemizedlist>
-		
-		<para>Installing the first two together with the base operating 
-		system on a blank system is explained in the Warp manual. If Warp 
-		has already been installed, but you now want to install the 
-		networking support, use the "Selective Install for Networking" 
-		object in the "System Setup" folder.</para>
-
-		<para>Adding the "NetBIOS over TCP/IP" driver is not described 
-		in the manual and just barely in the online documentation. Start 
-		MPTS.EXE, click on OK, click on "Configure LAPS" and click 
-		on "IBM OS/2 NETBIOS OVER TCP/IP" in  'Protocols'.  This line 
-		is then moved to 'Current Configuration'. Select that line, 
-		click on "Change number" and increase it from 0 to 1. Save this
-		configuration.</para>
-
-		<para>If the Samba server(s) is not on your local subnet, you 
-		can optionally add IP names and addresses of these servers 
-		to the "Names List", or specify a  WINS server ('NetBIOS 
-		Nameserver' in IBM and RFC terminology). For Warp Connect you 
-		may need to download an update for 'IBM Peer' to bring it on 
-		the same level as Warp 4. See the webpage mentioned above.</para>
-	</sect2>
-	
-	<sect2>
-		<title>How can I configure OS/2 Warp 3 (not Connect), 
-		OS/2 1.2, 1.3 or 2.x for Samba?</title>
-		
-		<para>You can use the free Microsoft LAN Manager 2.2c Client 
-		for OS/2 from 
-		<ulink url="ftp://ftp.microsoft.com/BusSys/Clients/LANMAN.OS2/">
-		ftp://ftp.microsoft.com/BusSys/Clients/LANMAN.OS2/</ulink>.
-   	See <ulink url="http://carol.wins.uva.nl/~leeuw/lanman.html">
-		http://carol.wins.uva.nl/~leeuw/lanman.html</ulink> for 
-		more information on how to install and use this client. In 
-		a nutshell, edit the file \OS2VER in the root directory of 
-		the OS/2 boot partition and add the lines:</para>
-		
-		<para><programlisting>
-		20=setup.exe
-		20=netwksta.sys
-		20=netvdd.sys
-		</programlisting></para>
-		
-		<para>before you install the client. Also, don't use the 
-		included NE2000 driver because it is buggy. Try the NE2000 
-		or NS2000 driver from 
-		<ulink url="ftp://ftp.cdrom.com/pub/os2/network/ndis/">
- 		ftp://ftp.cdrom.com/pub/os2/network/ndis/</ulink> instead.
-		</para>
-	</sect2>
-	
-	<sect2>
-		<title>Are there any other issues when OS/2 (any version) 
-		is used as a client?</title>
-		
-		<para>When you do a NET VIEW or use the "File and Print 
-		Client Resource Browser", no Samba servers show up. This can 
-		be fixed by a patch from <ulink
-		url="http://carol.wins.uva.nl/~leeuw/samba/fix.html">
-		http://carol.wins.uva.nl/~leeuw/samba/fix.html</ulink>.
-		The patch will be included in a later version of Samba. It also 
-		fixes a couple of other problems, such as preserving long 
-		filenames when objects are dragged from the Workplace Shell 
-		to the Samba server. </para>
-	</sect2>
-	
-	<sect2>
-		<title>How do I get printer driver download working 
-		for OS/2 clients?</title>
-
-		<para>First, create a share called [PRINTDRV] that is 
-		world-readable.  Copy your OS/2 driver files there.  Note 
-		that the .EA_ files must still be separate, so you will need 
-		to use the original install files, and not copy an installed 
-		driver from an OS/2 system.</para>
-		
-		<para>Install the NT driver first for that printer.  Then, 
-		add to your smb.conf a parameter, "os2 driver map = 
-		<replaceable>filename</replaceable>".  Then, in the file 
-		specified by <replaceable>filename</replaceable>, map the 
-		name of the NT driver name to the OS/2 driver name as 
-		follows:</para>
-		
-		<para>&lt;nt driver name&gt; = &lt;os2 driver 
-		name&gt;.&lt;device name&gt;, e.g.:
-		HP LaserJet 5L = LASERJET.HP LaserJet 5L</para>
-
-		<para>You can have multiple drivers mapped in this file.</para>
-	
-		<para>If you only specify the OS/2 driver name, and not the 
-		device name, the first attempt to download the driver will 
-		actually download the files, but the OS/2 client will tell 
-		you the driver is not available.  On the second attempt, it 
-		will work.  This is fixed simply by adding the device name
-  		 to the mapping, after which it will work on the first attempt.
-		</para>
-	</sect2>
-</sect1>
-
-</chapter>
-   
diff --git a/docs/docbook/projdoc/Printing.sgml b/docs/docbook/projdoc/Printing.sgml
index cb7e5cdfb7..ce9f40e88b 100644
--- a/docs/docbook/projdoc/Printing.sgml
+++ b/docs/docbook/projdoc/Printing.sgml
@@ -1,4 +1,4 @@
-<chapter id="printing_debug">
+<chapter id="printingdebug">
 <chapterinfo>
 	<author>
 		<firstname>Patrick</firstname><surname>Powell</surname>
diff --git a/docs/docbook/projdoc/Samba-BDC-HOWTO.sgml b/docs/docbook/projdoc/Samba-BDC-HOWTO.sgml
index 08cdc3a668..7653e3d1c0 100644
--- a/docs/docbook/projdoc/Samba-BDC-HOWTO.sgml
+++ b/docs/docbook/projdoc/Samba-BDC-HOWTO.sgml
@@ -64,13 +64,9 @@ parameters in the [global]-section of the smb.conf have to be set:
 </para>
 
 <para><programlisting>
-[global]
-     workgroup = SAMBA
-     domain master = yes
-     domain logons = yes
-     encrypt passwords = yes
-     security = user
-     ....
+workgroup = SAMBA
+domain master = yes
+domain logons = yes
 </programlisting></para>
 
 <para>
@@ -160,48 +156,42 @@ Several things have to be done:
 
 <itemizedlist>
 
-	<listitem><para>
-	The file <filename>private/MACHINE.SID</filename> identifies the domain. When a samba
-	server is first started, it is created on the fly and must never be
-	changed again. This file has to be the same on the PDC and the BDC,
-	so the MACHINE.SID has to be copied from the PDC to the BDC.  Note that in the
-	latest Samba 2.2.x releases, the machine SID (and therefore domain SID) is stored
-	in the <filename>private/secrets.tdb</filename> database.  This file cannot just
-	be copied because Samba looks under the key <constant>SECRETS/SID/<replaceable>DOMAIN</replaceable></constant>.
-	where <replaceable>DOMAIN</replaceable> is the machine's netbios name.  Since this name has
-	to be unique for each SAMBA server, this lookup will fail.  </para>
-	<para>
-	A new option has been added to the <command>smbpasswd(8)</command>
-	command to help ease this problem.  When running <command>smbpasswd -S</command> as the root user,
-	the domain SID will be retrieved from a domain controller matching the value of the
-	<parameter>workgroup</parameter> parameter in <filename>smb.conf</filename> and stored as the
-	new Samba server's machine SID.  See the <ulink url="smbpasswd.8.html"><command>smbpasswd(8)</command></ulink>
-	man page for more details on this functionality.
-	</para></listitem>
-
-	<listitem><para>
-	The Unix user database has to be synchronized from the PDC to the
-	BDC. This means that both the /etc/passwd and /etc/group have to be
-	replicated from the PDC to the BDC. This can be done manually
-	whenever changes are made, or the PDC is set up as a NIS master
-	server and the BDC as a NIS slave server. To set up the BDC as a
-	mere NIS client would not be enough, as the BDC would not be able to
-	access its user database in case of a PDC failure.  LDAP is also a
-	potential vehicle for sharing this information.
-	</para></listitem>
-
-	<listitem><para>
-	The Samba password database in the file <filename>private/smbpasswd</filename>
-	has to be replicated from the PDC to the BDC. This is a bit tricky, see the
-	next section.
-	</para></listitem>
-
-	<listitem><para>
-	Any netlogon share has to be replicated from the PDC to the
-	BDC. This can be done manually whenever login scripts are changed,
-	or it can be done automatically together with the smbpasswd
-	synchronization.
-	</para></listitem>
+<listitem><para>
+The domain SID has to be the same on the PDC and the BDC. This used to
+be stored in the file private/MACHINE.SID. This file is not created
+anymore since Samba 2.2.5 or even earlier. Nowadays the domain SID is
+stored in the file private/secrets.tdb. Simply copying the secrets.tdb
+from the PDC to the BDC does not work, as the BDC would
+generate a new SID for itself and override the domain SID with this
+new BDC SID.</para>
+
+<para>
+To retrieve the domain SID from the PDC or an existing BDC and store it in the
+secrets.tdb, execute 'net rpc getsid' on the BDC.
+</para></listitem>
+
+<listitem><para>
+The Unix user database has to be synchronized from the PDC to the
+BDC. This means that both the /etc/passwd and /etc/group have to be
+replicated from the PDC to the BDC. This can be done manually
+whenever changes are made, or the PDC is set up as a NIS master
+server and the BDC as a NIS slave server. To set up the BDC as a
+mere NIS client would not be enough, as the BDC would not be able to
+access its user database in case of a PDC failure.
+</para></listitem>
+
+<listitem><para>
+The Samba password database in the file private/smbpasswd has to be
+replicated from the PDC to the BDC. This is a bit tricky, see the
+next section.
+</para></listitem>
+
+<listitem><para>
+Any netlogon share has to be replicated from the PDC to the
+BDC. This can be done manually whenever login scripts are changed,
+or it can be done automatically together with the smbpasswd
+synchronization.
+</para></listitem>
 
 </itemizedlist>
 
@@ -211,13 +201,9 @@ by setting
 </para>
 
 <para><programlisting>
-[global]
-     workgroup = SAMBA
-     domain master = yes
-     domain logons = yes
-     encrypt passwords = yes
-     security = user
-     ....
+workgroup = samba
+domain master = no
+domain logons = yes
 </programlisting></para>
 
 <para>
@@ -234,9 +220,8 @@ name is reserved for the Primary Domain Controller.
 
 <para>
 Replication of the smbpasswd file is sensitive. It has to be done
-whenever changes to the SAM are made. Every user's password change
-(including machine trust account password changes) is done in the
-smbpasswd file and has to be replicated to the BDC. So
+whenever changes to the SAM are made. Every user's password change is
+done in the smbpasswd file and has to be replicated to the BDC. So
 replicating the smbpasswd file very often is necessary.
 </para>
 
@@ -244,18 +229,11 @@ replicating the smbpasswd file very often is necessary.
 As the smbpasswd file contains plain text password equivalents, it
 must not be sent unencrypted over the wire. The best way to set up
 smbpasswd replication from the PDC to the BDC is to use the utility
-<command>rsync(1)</command>. <command>rsync</command> can use
-<command>ssh(1)</command> as a transport. <command>ssh</command> itself
-can be set up to accept <emphasis>only</emphasis> <command>rsync</command> transfer without requiring the user to
-type a password.  Refer to the man pages for these two tools for more details.
+rsync. rsync can use ssh as a transport. ssh itself can be set up to
+accept *only* rsync transfer without requiring the user to type a
+password.
 </para>
 
-<para>
-Another solution with high potential is to use Samba's <parameter>--with-ldapsam</parameter>
-for sharing and/or replicating the list of <constant>sambaAccount</constant> entries.
-This can all be done over SSL to ensure security.  See the <ulink url="Samba-LDAP-HOWTO.html">Samba-LDAP-HOWTO</ulink>
-for more details.
-</para>
 
 </sect2>
 </sect1>
diff --git a/docs/docbook/projdoc/Samba-LDAP-HOWTO.sgml b/docs/docbook/projdoc/Samba-LDAP-HOWTO.sgml
index 6b153af6fe..a66df0c767 100644
--- a/docs/docbook/projdoc/Samba-LDAP-HOWTO.sgml
+++ b/docs/docbook/projdoc/Samba-LDAP-HOWTO.sgml
@@ -15,7 +15,7 @@
 	</author>
 
 
-	<pubdate> (16 Jun 2002) </pubdate>
+	<pubdate> (13 Jan 2002) </pubdate>
 </chapterinfo>
 
 <title>Storing Samba's User/Machine Account information in an LDAP Directory</title>
@@ -39,7 +39,7 @@ on LDAP architectures and Directories, please refer to the following sites.
 <para>
 Note that <ulink url="http://www.ora.com/">O'Reilly Publishing</ulink> is working on
 a guide to LDAP for System Administrators which has a planned release date of
-late 2002.
+early summer, 2002.
 </para>
 
 <para>
@@ -51,8 +51,7 @@ Two additional Samba resources which may prove to be helpful are
 	maintained by Ignacio Coupeau.</para></listitem>
 
 	<listitem><para>The NT migration scripts from <ulink url="http://samba.idealx.org/">IDEALX</ulink> that are
-	geared to manage users and group in such a Samba-LDAP Domain Controller configuration.  These scripts can
-	be found in the Samba 2.2.5 release in the <filename>examples/LDAP/smbldap-tools/</filename> directory.
+	geared to manage users and group in such a Samba-LDAP Domain Controller configuration.
 	</para></listitem>
 </itemizedlist>
 
@@ -76,7 +75,7 @@ in the thousands).
 The first is that all lookups must be performed sequentially.  Given that
 there are approximately two lookups per domain logon (one for a normal
 session connection such as when mapping a network drive or printer), this
-is a performance bottleneck for large sites.  What is needed is an indexed approach
+is a performance bottleneck for lareg sites.  What is needed is an indexed approach
 such as is used in databases.
 </para></listitem>
 
@@ -97,7 +96,7 @@ Identified (RID).
 
 <para>
 As a result of these defeciencies, a more robust means of storing user attributes
-used by <command>smbd</command> was developed.  The API which defines access to user accounts
+used by smbd was developed.  The API which defines access to user accounts
 is commonly referred to as the samdb interface (previously this was called the passdb
 API, and is still so named in the CVS trees). In Samba 2.2.3, enabling support
 for a samdb backend (e.g. <parameter>--with-ldapsam</parameter> or
@@ -106,7 +105,7 @@ for a samdb backend (e.g. <parameter>--with-ldapsam</parameter> or
 
 <para>
 When compiling Samba to include the <parameter>--with-ldapsam</parameter> autoconf
-option, <command>smbd</command> (and associated tools) will store and lookup user accounts in
+option, smbd (and associated tools) will store and lookup user accounts in
 an LDAP directory.  In reality, this is very easy to understand.  If you are
 comfortable with using an smbpasswd file, simply replace "smbpasswd" with
 "LDAP directory" in all the documentation.
@@ -163,7 +162,7 @@ in 2.2.2).  The sambaAccount objectclass is given here:
 </para>
 
 <para><programlisting>
-objectclass ( 1.3.1.5.1.4.1.7165.2.2.3 NAME 'sambaAccount' SUP top AUXILARY
+objectclass ( 1.3.1.5.1.4.1.7165.2.2.2 NAME 'sambaAccount' SUP top STRUCTURAL
      DESC 'Samba Account'
      MUST ( uid $ rid )
      MAY  ( cn $ lmPassword $ ntPassword $ pwdLastSet $ logonTime $
@@ -173,45 +172,29 @@ objectclass ( 1.3.1.5.1.4.1.7165.2.2.3 NAME 'sambaAccount' SUP top AUXILARY
 </programlisting></para>
 
 <para>
-The <filename>samba.schema</filename> file has been formatted for OpenLDAP 2.0 & 2.1.  The OID's are
+The samba.schema file has been formatted for OpenLDAP 2.0.  The OID's are
 owned by the Samba Team and as such is legal to be openly published.
 If you translate the schema to be used with Netscape DS, please
-submit the modified schema file as a patch to <ulink url="jerry@samba.org">jerry@samba.org</ulink>
-</para>
-
-<para>
-Since the original release, schema files for
-</para>
-
-<itemizedlist>
-	<listitem><para>IBM's SecureWay Server</para></listitem>
-	<listitem><para>Netscape Directory Server version 4.x and 5.x</para></listitem>
-</itemizedlist>
-
-<para>
-have been submitted and included in the Samba source distribution.  I cannot
-personally comment on the integration of these commercial directory servers since
-I have not had the oppotinuity to work with them.
+submit the modified schema file as a patch to <ulink
+url="jerry@samba.org">jerry@samba.org</ulink>
 </para>
 
 <para>
 Just as the smbpasswd file is mean to store information which supplements a
 user's <filename>/etc/passwd</filename> entry, so is the sambaAccount object
-meant to supplement the UNIX user account information.  A sambaAccount is now an
-<constant>AUXILARY</constant> objectclass so it can be stored alongside
-a posixAccount or person objectclass in the directory.  Note that there are
-several fields (e.g. uid) which overlap with the posixAccount objectclass
-outlined in RFC2307.  This is by design.  The move from a STRUCTURAL objectclass
-to an AUXILIARY one was compliance with the LDAP data model which states that
-an entry can contain only one STRUCTURAL objectclass per entry.  This is now
-enforced by the OpenLDAP 2.1 server.
+meant to supplement the UNIX user account information.  A sambaAccount is a
+<constant>STRUCTURAL</constant> objectclass so it can be stored individually
+in the directory.  However, there are several fields (e.g. uid) which overlap
+with the posixAccount objectclass outlined in RFC2307.  This is by design.
 </para>
 
+<!--olem: we should perhaps have a note about shadowAccounts too as many
+systems use them, isn'it ? -->
 
 <para>
 In order to store all user account information (UNIX and Samba) in the directory,
 it is necessary to use the sambaAccount and posixAccount objectclasses in
-combination.  However, <command>smbd</command> will still obtain the user's UNIX account
+combination.  However, smbd will still obtain the user's UNIX account
 information via the standard C library calls (e.g. getpwnam(), et. al.).
 This means that the Samba server must also have the LDAP NSS library installed
 and functioning correctly.  This division of information makes it possible to
@@ -271,9 +254,9 @@ like in the following example, to speed up searches made on sambaAccount objectc
 ## required by OpenLDAP 2.0
 index objectclass   eq
 
-## support pbb_getsampwnam()
+## support pb_getsampwnam()
 index uid           pres,eq
-## support pdb_getsampwrid()
+## support pdb_getsambapwrid()
 index rid           eq
 
 ## uncomment these if you are storing posixAccount and
@@ -343,44 +326,14 @@ use with an LDAP directory could appear as
      ldap suffix = "ou=people,dc=samba,dc=org"
 
      # generally the default ldap search filter is ok
-     # ldap filter = "(&(uid=%u)(objectclass=sambaAccount))"
+     # ldap filter = "(&amp;(uid=%u)(objectclass=sambaAccount))"
 </programlisting></para>
 
 
 </sect2>
-
-
-<sect2>
-<title>Importing <filename>smbpasswd</filename> entries</title>
-
-<para>
-Import existing user entries from an <filename>smbpasswd</filename> can be trivially done using
-a Perl script named <filename>import_smbpasswd.pl</filename> included in the
-<filename>examples/LDAP/</filename> directory of the Samba source distribution.  There are
-two main requirements of this script:
-</para>
-
-<itemizedlist>
-	<listitem><para>All users to be imported to the directory must have a valid uid on the
-	local system.  This can be a problem if using a machinej different from the Samba server
-	to import the file.</para></listitem>
-
-	<listitem><para>The local system must have a working installation of the Net::LDAP perl
-	module which can be obtained from with <ulink url="http://search.cpan.org/">http://search.cpan.org/</ulink>
-	by searching for <filename>perl-ldap</filename> or directly from <ulink
-	url="http://perl-ldap.sf.net/">http://perl-ldap.sf.net/</ulink>.
-	</para></listitem>
-</itemizedlist>
-
-<para>
-Please refer to the documentation in the same directory as the script for more details.
-</para>
-
-</sect2>
 </sect1>
 
 
-
 <sect1>
 <title>Accounts and Groups management</title>
 
@@ -629,7 +582,7 @@ ntPassword: 878D8014606CDA29677A44EFA1353FC7
 <para>
 Please mail all comments regarding this HOWTO to <ulink
 url="mailto:jerry@samba.org">jerry@samba.org</ulink>.  This documents was
-last updated to reflect the Samba 2.2.5 release.
+last updated to reflect the Samba 2.2.3 release.
 
 </para>
 
diff --git a/docs/docbook/projdoc/cups.sgml b/docs/docbook/projdoc/cups.sgml
deleted file mode 100644
index 57a12843a8..0000000000
--- a/docs/docbook/projdoc/cups.sgml
+++ /dev/null
@@ -1,445 +0,0 @@
-<chapter id="cups">
-
-
-<chapterinfo>
-	<author>
-		<firstname>Kurt</firstname><surname>Pfeifle</surname>
-		<affiliation>
-			<address>
-				<email>kpfeifle@danka.de</email>
-			</address>
-		</affiliation>
-	</author>
-
-
-	<pubdate> (24 May 2002) </pubdate>
-</chapterinfo>
-
-<title>Printing with CUPS in Samba 2.2.x</title>
-
-
-<sect1>
-<title>Printing with CUPS in Samba 2.2.x</title>
-
-<para>
-<ulink url="http://www.cups.org/">CUPS</ulink> is a newcomer in
-the UNIX printing scene, which has convinced many people upon first trial
-already. However, it has quite a few new features, which make it different
-from other, more traditional printing systems.
-</para>
-</sect1>
-
-
-<sect1>
-<title>Configuring <filename>smb.conf</filename> for CUPS</title>
-
-<para>
-Printing with CUPS in the most basic <filename>smb.conf</filename>
-setup in Samba 2.2.x only needs two settings: <command>printing = cups</command> and
-<command>printcap = cups</command>. While CUPS itself doesn't need a printcap
-anymore, the <filename>cupsd.conf</filename> configuration file knows two directives
-(example: <command>Printcap /etc/printcap</command> and <command>PrintcapFormat
-BSD</command>), which control if such a file should be created for the
-convenience of third party applications. Make sure it is set! For details see
-<command>man cupsd.conf</command> and other CUPS-related documentation.
-</para>
-
-<para>
-If SAMBA is compiled against libcups, then <command>printcap =
-cups</command> uses the CUPS API to list printers, submit jobs, etc. Otherwise it
-maps to the System V commands with an additional <parameter>-oraw</parameter>
-option for printing. On a Linux system, you can use the <command>ldd</command> command to
-find out details (ldd may not be present on other OS platforms, or its
-function may be embodied by a different command):
-</para>
-
-<para>
-<programlisting>transmeta:/home/kurt # ldd `which smbd`
-        libssl.so.0.9.6 => /usr/lib/libssl.so.0.9.6 (0x4002d000)
-        libcrypto.so.0.9.6 => /usr/lib/libcrypto.so.0.9.6 (0x4005a000)
-        libcups.so.2 => /usr/lib/libcups.so.2 (0x40123000)
-        libdl.so.2 => /lib/libdl.so.2 (0x401e8000)
-        libnsl.so.1 => /lib/libnsl.so.1 (0x401ec000)
-        libpam.so.0 => /lib/libpam.so.0 (0x40202000)
-        libc.so.6 => /lib/libc.so.6 (0x4020b000)
-        /lib/ld-linux.so.2 =&gt; /lib/ld-linux.so.2 (0x40000000)
-</programlisting></para>
-
-<para>
-The line "libcups.so.2 =&gt; /usr/lib/libcups.so.2
-(0x40123000)" shows there is CUPS support compiled into this version of
-Samba. If this is the case, and <command>printing = cups</command> is set, then any
-otherwise manually set print command in smb.conf is ignored.
-</para>
-</sect1>
-
-
-
-
-<sect1>
-<title>Using CUPS as a mere spooling print server -- "raw"
-printing with vendor drivers download</title>
-
-<para>
-You can setup Samba and your Windows clients to use the
-CUPS print subsystem just as you would with any of the more traditional print
-subsystems: that means the use of vendor provided, native Windows printer
-drivers for each target printer. If you setup the [print$] share to
-download these drivers to the clients, their GDI system (Graphical Device
-Interface) will output the Wndows EMF (Enhanced MetaFile) and
-convert it -- with the help of the printer driver -- locally into the format
-the printer is expecting. Samba and the CUPS print subsystem will have to
-treat these files as raw print files  -- they are already in the
-shape to be digestable for the printer. This is the same traditional setup
-for Unix print servers handling Windows client jobs. It does not take much
-CPU power to handle this kind of task efficiently.
-</para>
-</sect1>
-
-
-
-
-<sect1>
-<title>CUPS as a network PostScript RIP -- CUPS drivers working on server, Adobe
-PostScript driver with CUPS-PPDs downloaded to clients</title>
-
-
-<para>
-CUPS is perfectly able to use PPD files (PostScript
-Printer Descriptions). PPDs can control all print device options. They
-are usually provided by the manufacturer -- if you own a PostSript printer,
-that is. PPD files are always a component of PostScript printer drivers on MS
-Windows or Apple Mac OS systems. They are ASCII files containing
-user-selectable print options, mapped to appropriate PostScript, PCL or PJL
-commands for the target printer. Printer driver GUI dialogs translate these
-options "on-the-fly" into buttons and drop-down lists for the user to
-select.
-</para>
-
-<para>
-CUPS can load, without any conversions, the PPD file from
-any Windows (NT is recommended) PostScript driver and handle the options.
-There is a web browser interface to the print options (select
-http://localhost:631/printers/ and click on one "Configure Printer" button
-to see it), a commandline interface (see <command>man lpoptions</command> or
-try if you have <command>lphelp</command> on your system) plus some different GUI frontends on Linux
-UNIX, which can present PPD options to the users. PPD options are normally
-meant to become evaluated by the PostScript RIP on the real PostScript
-printer.
-</para>
-
-<para>
-CUPS doesn't stop at "real" PostScript printers in its
-usage of PPDs. The CUPS developers have extended the PPD concept, to also
-describe available device and driver options for non-PostScript printers
-through  CUPS-PPDs.
-</para>
-
-<para>
-This is logical, as CUPS includes a fully featured
-PostScript interpreter (RIP). This RIP is based on Ghostscript. It can
-process all received PostScript (and additionally many other file formats)
-from clients. All CUPS-PPDs geared to non-PostScript printers contain an
-additional line, starting with the keyword <parameter>*cupsFilter</parameter>.
-This line
-tells the CUPS print system which printer-specific filter to use for the
-interpretation of the accompanying PostScript. Thus CUPS lets all its
-printers appear as PostScript devices to its clients, because it can act as a
-PostScript RIP for those printers, processing the received PostScript code
-into a proper raster print format.
-</para>
-
-<para>
-CUPS-PPDs can also be used on Windows-Clients, on top of a
-PostScript driver (recommended is the Adobe one).
-</para>
-
-<para>
-This feature enables CUPS to do a few tricks no other
-spooler can do:
-</para>
-
-<itemizedlist>
-  <listitem><para>act as a networked PostScript RIP (Raster Image Processor), handling
-    printfiles from all client platforms in a uniform way;</para></listitem>
-  <listitem><para>act as a central accounting and billing server, as all files are passed
-    through the <command>pstops</command> Filter and are therefor logged in
-    the CUPS <filename>page&lowbar;log</filename>. - <emphasis>NOTE: </emphasis>this
-    can not happen with "raw" print jobs, which always remain unfiltered
-    per definition;</para></listitem>
-  <listitem><para>enable clients to consolidate on a single PostScript driver, even for
-    many different target printers.</para></listitem>
-</itemizedlist>
-</sect1>
-
-
-
-<sect1>
-<title>Windows Terminal Servers (WTS) as CUPS clients</title>
-
-<para>
-This setup may be of special interest to people
-experiencing major problems in WTS environments. WTS need often a multitude
-of non-PostScript drivers installed to run their clients' variety of
-different printer models. This often imposes the price of much increased
-instability. In many cases, in an attempt to overcome this problem, site
-administrators have resorted to restrict the allowed drivers installed on
-their WTS to one generic PCL- and one PostScript driver. This however
-restricts the clients in the amount of printer options available for them --
-often they can't get out more then simplex prints from one standard paper
-tray, while their devices could do much better, if driven by a different
-driver!
-</para>
-
-<para>
-Using an Adobe PostScript driver, enabled with a CUPS-PPD,
-seems to be a very elegant way to overcome all these shortcomings. The
-PostScript driver is not known to cause major stability problems on WTS (even
-if used with many different PPDs). The clients will be able to (again) chose
-paper trays, duplex printing and other settings. However, there is a certain
-price for this too: a  CUPS server acting as a PostScript RIP for its clients
-requires more CPU and RAM than just to act as  a "raw spooling" device. Plus,
-this setup is not yet widely tested, although the first feedbacks look very
-promising...
-</para>
-</sect1>
-
-
-<sect1>
-<title>Setting up CUPS for driver download</title>
-
-<para>
-The <command>cupsadsmb</command> utility (shipped with all current
-CUPS versions) makes the sharing of any (or all) installed CUPS printers very
-easy. Prior to using it, you need the following settings in smb.conf:
-</para>
-
-<para><programlisting>[global]
-         load printers = yes
-         printing = cups
-         printcap name = cups
-
-[printers]
-         comment = All Printers
-         path = /var/spool/samba
-         browseable = no
-         public = yes
-         guest ok = yes
-         writable = no
-         printable = yes
-         printer admin = root
-
-[print$]
-         comment = Printer Drivers
-         path = /etc/samba/drivers
-         browseable = yes
-         guest ok = no
-         read only = yes
-         write list = root
-</programlisting></para>
-
-<para>
-For licensing reasons the necessary files of the Adobe
-Postscript driver can not be distributed with either Samba or CUPS. You need
-to download them yourself from the Adobe website. Once extracted, create a
-<filename>drivers</filename> directory in the CUPS data directory (usually
-<filename>/usr/share/cups/</filename>). Copy the Adobe files using
-UPPERCASE filenames, to this directory as follows:
-</para>
-
-<para><programlisting>
-        ADFONTS.MFM
-        ADOBEPS4.DRV
-        ADOBEPS4.HLP
-        ADOBEPS5.DLL
-        ADOBEPSU.DLL
-        ADOBEPSU.HLP
-        DEFPRTR2.PPD
-        ICONLIB.DLL
-</programlisting></para>
-
-<para>
-Users of the ESP Print Pro software are able to install
-their "Samba Drivers" package for this purpose with no problem.
-</para>
-</sect1>
-
-
-
-<sect1>
-<title>Sources of CUPS drivers / PPDs</title>
-
-<para>
-On the internet you can find now many thousand CUPS-PPD
-files (with their companion filters), in many national languages,
-supporting more than 1.000 non-PostScript models.
-</para>
-
-<itemizedlist>
-  <listitem><para><ulink url="http://wwwl.easysw.com/printpro/">ESP PrintPro
-    (http://wwwl.easysw.com/printpro/)</ulink>
-    (commercial, non-Free) is packaged with more than 3.000 PPDs, ready for
-    successful usage "out of the box" on Linux, IBM-AIX, HP-UX, Sun-Solaris,
-    SGI-IRIX, Compaq Tru64, Digital Unix and some more commercial Unices (it
-    is written by the CUPS developers themselves and its sales help finance
-    the further development of CUPS, as they feed their creators)</para></listitem>
-  <listitem><para>the <ulink
-    url="http://gimp-print.sourceforge.net/">Gimp-Print-Project
-    (http://gimp-print.sourceforge.net/)</ulink>
-    (GPL, Free Software) provides around 120 PPDs (supporting nearly 300
-    printers, many driven to photo quality output), to be used alongside the
-    Gimp-Print CUPS filters;</para></listitem>
-  <listitem><para><ulink url="http://www.turboprint.com/">TurboPrint
-    (http://www.turboprint.com/)</ulink>
-    (Shareware, non-Freee) supports roughly the same amount of printers in
-    excellent quality;</para></listitem>
-  <listitem><para><ulink
-    url="http://www-124.ibm.com/developerworks/oss/linux/projects/omni/">OMNI
-    (http://www-124.ibm.com/developerworks/oss/linux/projects/omni/)</ulink>
-    (LPGL, Free) is a package made by IBM, now containing support for more
-    than 400 printers, stemming from the inheritance of IBM OS/2 KnowHow
-    ported over to Linux (CUPS support is in a Beta-stage at present);</para></listitem>
-  <listitem><para><ulink url="http://hpinkjet.sourceforge.net/">HPIJS
-    (http://hpinkjet.sourceforge.net/)</ulink>
-    (BSD-style licnes, Free) supports around 120 of HP's own printers and is
-    also providing excellent print quality now;</para></listitem>
-  <listitem><para><ulink
-    url="http://www.linuxprinting.org/">Foomatic/cupsomatic (http://www.linuxprinting.org/)</ulink> 
-    (LPGL, Free) from Linuxprinting.org are providing PPDs for practically every
-    Ghostscript filter known to the world, now usable with CUPS.</para></listitem>
-</itemizedlist>
-
-<para>
-<emphasis>NOTE: </emphasis>the cupsomatic trick from Linuxprinting.org is
-working different from the other drivers. While the other drivers take the
-generic CUPS raster (produced by CUPS' own pstoraster PostScript RIP) as
-their input, cupsomatic "kidnaps" the PostScript inside CUPS, before
-RIP-ping, deviates it to an external Ghostscript installation (which now
-becomes the RIP) and gives it back to a CUPS backend once Ghostscript is
-finished. -- CUPS versions from 1.1.15 and later will provide their pstoraster
-PostScript RIP function again inside a system-wide Ghostscript 
-installation rather than in "their own" pstoraster filter. (This 
-CUPS-enabling Ghostscript version may be installed either as a 
-patch to GNU or AFPL Ghostscript, or as a complete ESP Ghostscript package).
-However, this will not change the cupsomatic approach of guiding the printjob
-along a different path through the filtering system than the standard CUPS
-way...
-</para>
-
-<para>
-Once you installed a printer inside CUPS with one of the
-recommended methods (the lpadmin command, the web browser interface or one of
-the available GUI wizards), you can use <command>cupsaddsmb</command> to share the
-printer via Samba. <command>cupsaddsmb</command> prepares the driver files for
-comfortable client download and installation upon their first contact with
-this printer share.
-</para>
-
-
-
-<sect2>
-<title><command>cupsaddsmb</command></title>
-
-
-<para>
-The <command>cupsaddsmb</command> command copies the needed files
-for convenient Windows client installations from the previously prepared CUPS
-data directory to your [print$] share. Additionally, the PPD
-associated with this printer is copied from <filename>/etc/cups/ppd/</filename> to
-[print$].
-</para>
-
-<para><programlisting>
-<prompt>root# </prompt> <command>cupsaddsmb -U root infotec_IS2027</command>
-Password for root required to access localhost via SAMBA: <userinput>[type in password 'secret']</userinput>
-</programlisting></para>
-
-<para>
-To share all printers and drivers, use the <parameter>-a</parameter>
-parameter instead of a printer name.
-</para>
-
-
-<para>
-Probably you want to see what's going on. Use the
-<parameter>-v</parameter> parameter to get a more verbose output:
-</para>
-
-<para><programlisting>
-<prompt>root# </prompt> cupsaddsmb -v -U root infotec_IS2027
-    Password for root required to access localhost via SAMBA:
-    Running command: smbclient //localhost/print\$ -N -U'root%secret' -c 'mkdir W32X86;put /var/spool/cups/tmp/3cd1cc66376c0 W32X86/infotec_IS2027.PPD;put /usr/share/cups/drivers/ADOBEPS5.DLL W32X86/ADOBEPS5.DLL;put /usr/share/cups/drivers/ADOBEPSU.DLL W32X86/ADOBEPSU.DLL;put /usr/share/cups/drivers/ADOBEPSU.HLP W32X86/ADOBEPSU.HLP'
-    added interface ip=10.160.16.45 bcast=10.160.31.255 nmask=255.255.240.0
-    added interface ip=192.168.182.1 bcast=192.168.182.255 nmask=255.255.255.0
-    added interface ip=172.16.200.1 bcast=172.16.200.255 nmask=255.255.255.0
-    Domain=[TUX-NET] OS=[Unix] Server=[Samba 2.2.3a.200204262025cvs]
-    NT_STATUS_OBJECT_NAME_COLLISION making remote directory \W32X86
-    putting file /var/spool/cups/tmp/3cd1cc66376c0 as \W32X86/infotec_IS2027.PPD (17394.6 kb/s) (average 17395.2 kb/s)
-    putting file /usr/share/cups/drivers/ADOBEPS5.DLL as \W32X86/ADOBEPS5.DLL (10877.4 kb/s) (average 11343.0 kb/s)
-    putting file /usr/share/cups/drivers/ADOBEPSU.DLL as \W32X86/ADOBEPSU.DLL (5095.2 kb/s) (average 9260.4 kb/s)
-    putting file /usr/share/cups/drivers/ADOBEPSU.HLP as \W32X86/ADOBEPSU.HLP (8828.7 kb/s) (average 9247.1 kb/s)
-
-    Running command: smbclient //localhost/print\$ -N -U'root%secret' -c 'mkdir WIN40;put /var/spool/cups/tmp/3cd1cc66376c0 WIN40/infotec_IS2027.PPD;put /usr/share/cups/drivers/ADFONTS.MFM WIN40/ADFONTS.MFM;put /usr/share/cups/drivers/ADOBEPS4.DRV WIN40/ADOBEPS4.DRV;put /usr/share/cups/drivers/ADOBEPS4.HLP WIN40/ADOBEPS4.HLP;put /usr/share/cups/drivers/DEFPRTR2.PPD WIN40/DEFPRTR2.PPD;put /usr/share/cups/drivers/ICONLIB.DLL WIN40/ICONLIB.DLL;put /usr/share/cups/drivers/PSMON.DLL WIN40/PSMON.DLL;'
-    added interface ip=10.160.16.45 bcast=10.160.31.255 nmask=255.255.240.0
-    added interface ip=192.168.182.1 bcast=192.168.182.255 nmask=255.255.255.0
-    added interface ip=172.16.200.1 bcast=172.16.200.255 nmask=255.255.255.0
-    Domain=[TUX-NET] OS=[Unix] Server=[Samba 2.2.3a.200204262025cvs]
-    NT_STATUS_OBJECT_NAME_COLLISION making remote directory \WIN40
-    putting file /var/spool/cups/tmp/3cd1cc66376c0 as \WIN40/infotec_IS2027.PPD (26091.5 kb/s) (average 26092.8 kb/s)
-    putting file /usr/share/cups/drivers/ADFONTS.MFM as \WIN40/ADFONTS.MFM (11241.6 kb/s) (average 11812.9 kb/s)
-    putting file /usr/share/cups/drivers/ADOBEPS4.DRV as \WIN40/ADOBEPS4.DRV (16640.6 kb/s) (average 14679.3 kb/s)
-    putting file /usr/share/cups/drivers/ADOBEPS4.HLP as \WIN40/ADOBEPS4.HLP (11285.6 kb/s) (average 14281.5 kb/s)
-    putting file /usr/share/cups/drivers/DEFPRTR2.PPD as \WIN40/DEFPRTR2.PPD (823.5 kb/s) (average 12944.0 kb/s)
-    putting file /usr/share/cups/drivers/ICONLIB.DLL as \WIN40/ICONLIB.DLL (19226.2 kb/s) (average 13169.7 kb/s)
-    putting file /usr/share/cups/drivers/PSMON.DLL as \WIN40/PSMON.DLL (18666.1 kb/s) (average 13266.7 kb/s)
-
-    Running command: rpcclient localhost -N -U'root%secret' -c 'adddriver "Windows NT x86" "infotec_IS2027:ADOBEPS5.DLL:infotec_IS2027.PPD:ADOBEPSU.DLL:ADOBEPSU.HLP:NULL:RAW:NULL"'
-    cmd = adddriver "Windows NT x86" "infotec_IS2027:ADOBEPS5.DLL:infotec_IS2027.PPD:ADOBEPSU.DLL:ADOBEPSU.HLP:NULL:RAW:NULL"
-    Printer Driver infotec_IS2027 successfully installed.
-
-    Running command: rpcclient localhost -N -U'root%secret' -c 'adddriver "Windows 4.0" "infotec_IS2027:ADOBEPS4.DRV:infotec_IS2027.PPD:NULL:ADOBEPS4.HLP:PSMON.DLL:RAW:ADFONTS.MFM,DEFPRTR2.PPD,ICONLIB.DLL"'
-    cmd = adddriver "Windows 4.0" "infotec_IS2027:ADOBEPS4.DRV:infotec_IS2027.PPD:NULL:ADOBEPS4.HLP:PSMON.DLL:RAW:ADFONTS.MFM,DEFPRTR2.PPD,ICONLIB.DLL"
-    Printer Driver infotec_IS2027 successfully installed.
-
-    Running command: rpcclient localhost -N -U'root%secret' -c 'setdriver infotec_IS2027 infotec_IS2027'
-    cmd = setdriver infotec_IS2027 infotec_IS2027
-    Succesfully set infotec_IS2027 to driver infotec_IS2027.
-
-    <prompt>root# </prompt>
-</programlisting></para>
-
-<para>
-If you look closely, you'll discover your root password
-was transfered unencrypted over the wire, so beware! Also, if you look
-further her, you'll discover error messages like
-<constant>NT_STATUS_OBJECT_NAME_COLLISION</constant> in between. They occur, because
-the directories <filename>WIN40</filename> and <filename>W32X86</filename> already
-existed in the [print$] driver download share (from a previous driver
-installation). They are harmless here.
-</para>
-
-<para>
-Now your printer is prepared for the clients to use. From
-a client, browse to the CUPS/Samba server, open the "Printers"
-share, right-click on this printer and select "Install..." or
-"Connect..." (depending on the Windows version you use). Now their
-should be a new printer in your client's local "Printers" folder,
-named (in my case) "infotec_IS2027 on kdebitshop"
-</para>
-
-<para>
-<emphasis>NOTE: </emphasis>
-<command>cupsaddsmb</command> will only reliably work i
-with CUPS version 1.1.15 or higher
-and Samba from 2.2.4. If it doesn't work, or if the automatic printer
-driver download to the clients doesn't succeed, you can still manually
-install the CUPS printer PPD on top of the Adobe PostScript driver on
-clients and then point the client's printer queue to the Samba printer
-share for connection, should you desire to use the CUPS networked
-PostScript RIP functions.
-</para>
-</sect2>
-</sect1>
-
-
-</chapter>
diff --git a/docs/docbook/projdoc/security_level.sgml b/docs/docbook/projdoc/security_level.sgml
index 46a2ad7fe4..efe2b6eaf3 100644
--- a/docs/docbook/projdoc/security_level.sgml
+++ b/docs/docbook/projdoc/security_level.sgml
@@ -1,4 +1,4 @@
-<chapter id="security_levels">
+<chapter id="securitylevels">
 <chapterinfo>
 	<author>
 		<firstname>Andrew</firstname><surname>Tridgell</surname>