sync'ing up for 3.0alpha20 release

(This used to be commit b5d03c7b55fb2f34fa4d0228abe4389020e5ed5f)

7 files changed, 650 insertions, 72 deletions

diff --git a/docs/docbook/projdoc/PAM-Authentication-And-Samba.sgml b/docs/docbook/projdoc/PAM-Authentication-And-Samba.sgml
index 594516640d..adcd059bc2 100644
--- a/docs/docbook/projdoc/PAM-Authentication-And-Samba.sgml
+++ b/docs/docbook/projdoc/PAM-Authentication-And-Samba.sgml
@@ -154,7 +154,7 @@ password   required     /lib/security/pam_smbpass.so nodelay smbconf=/etc/samba.
 
 <para>
 Note: PAM allows stacking of authentication mechanisms. It is 
-also possible to pass information obtained within on PAM module through 
+also possible to pass information obtained within one PAM module through 
 to the next module in the PAM stack. Please refer to the documentation for 
 your particular system implementation for details regarding the specific 
 capabilities of PAM in this environment. Some Linux implmentations also 
diff --git a/docs/docbook/projdoc/Samba-BDC-HOWTO.sgml b/docs/docbook/projdoc/Samba-BDC-HOWTO.sgml
index 53a0959c39..08cdc3a668 100644
--- a/docs/docbook/projdoc/Samba-BDC-HOWTO.sgml
+++ b/docs/docbook/projdoc/Samba-BDC-HOWTO.sgml
@@ -64,9 +64,13 @@ parameters in the [global]-section of the smb.conf have to be set:
 </para>
 
 <para><programlisting>
-workgroup = SAMBA
-domain master = yes
-domain logons = yes
+[global]
+     workgroup = SAMBA
+     domain master = yes
+     domain logons = yes
+     encrypt passwords = yes
+     security = user
+     ....
 </programlisting></para>
 
 <para>
@@ -156,35 +160,48 @@ Several things have to be done:
 
 <itemizedlist>
 
-<listitem><para>
-The file private/MACHINE.SID 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.
-</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>
+	<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>
 
 </itemizedlist>
 
@@ -194,9 +211,13 @@ by setting
 </para>
 
 <para><programlisting>
-workgroup = samba
-domain master = no
-domain logons = yes
+[global]
+     workgroup = SAMBA
+     domain master = yes
+     domain logons = yes
+     encrypt passwords = yes
+     security = user
+     ....
 </programlisting></para>
 
 <para>
@@ -213,8 +234,9 @@ 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 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
+(including machine trust account password changes) is done in the
+smbpasswd file and has to be replicated to the BDC. So
 replicating the smbpasswd file very often is necessary.
 </para>
 
@@ -222,11 +244,18 @@ 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
-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.
+<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.
 </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 a66df0c767..6b153af6fe 100644
--- a/docs/docbook/projdoc/Samba-LDAP-HOWTO.sgml
+++ b/docs/docbook/projdoc/Samba-LDAP-HOWTO.sgml
@@ -15,7 +15,7 @@
 	</author>
 
 
-	<pubdate> (13 Jan 2002) </pubdate>
+	<pubdate> (16 Jun 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
-early summer, 2002.
+late 2002.
 </para>
 
 <para>
@@ -51,7 +51,8 @@ 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.
+	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.
 	</para></listitem>
 </itemizedlist>
 
@@ -75,7 +76,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 lareg sites.  What is needed is an indexed approach
+is a performance bottleneck for large sites.  What is needed is an indexed approach
 such as is used in databases.
 </para></listitem>
 
@@ -96,7 +97,7 @@ Identified (RID).
 
 <para>
 As a result of these defeciencies, a more robust means of storing user attributes
-used by smbd was developed.  The API which defines access to user accounts
+used by <command>smbd</command> 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
@@ -105,7 +106,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, smbd (and associated tools) will store and lookup user accounts in
+option, <command>smbd</command> (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.
@@ -162,7 +163,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.2 NAME 'sambaAccount' SUP top STRUCTURAL
+objectclass ( 1.3.1.5.1.4.1.7165.2.2.3 NAME 'sambaAccount' SUP top AUXILARY
      DESC 'Samba Account'
      MUST ( uid $ rid )
      MAY  ( cn $ lmPassword $ ntPassword $ pwdLastSet $ logonTime $
@@ -172,29 +173,45 @@ objectclass ( 1.3.1.5.1.4.1.7165.2.2.2 NAME 'sambaAccount' SUP top STRUCTURAL
 </programlisting></para>
 
 <para>
-The samba.schema file has been formatted for OpenLDAP 2.0.  The OID's are
+The <filename>samba.schema</filename> file has been formatted for OpenLDAP 2.0 & 2.1.  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>
+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.
 </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 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.
+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.
 </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, smbd will still obtain the user's UNIX account
+combination.  However, <command>smbd</command> 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
@@ -254,9 +271,9 @@ like in the following example, to speed up searches made on sambaAccount objectc
 ## required by OpenLDAP 2.0
 index objectclass   eq
 
-## support pb_getsampwnam()
+## support pbb_getsampwnam()
 index uid           pres,eq
-## support pdb_getsambapwrid()
+## support pdb_getsampwrid()
 index rid           eq
 
 ## uncomment these if you are storing posixAccount and
@@ -326,14 +343,44 @@ 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 = "(&amp;(uid=%u)(objectclass=sambaAccount))"
+     # ldap filter = "(&(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>
 
@@ -582,7 +629,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.3 release.
+last updated to reflect the Samba 2.2.5 release.
 
 </para>
 
diff --git a/docs/docbook/projdoc/UNIX_INSTALL.sgml b/docs/docbook/projdoc/UNIX_INSTALL.sgml
index aab193c451..c307636d5f 100644
--- a/docs/docbook/projdoc/UNIX_INSTALL.sgml
+++ b/docs/docbook/projdoc/UNIX_INSTALL.sgml
@@ -359,13 +359,16 @@
 		<title>Printing from UNIX to a Client PC</title>
 
 		<para>To use a printer that is available via a smb-based 
-		server from a unix host you will need to compile the 
+		server from a unix host with LPR you will need to compile the 
 		smbclient program. You then need to install the script 
 		"smbprint". Read the instruction in smbprint for more details.
 		</para>
 
 		<para>There is also a SYSV style script that does much 
 		the same thing called smbprint.sysv. It contains instructions.</para>
+
+		<para>See the CUPS manual for information about setting up 
+		printing from a unix host with CUPS to a smb-based server. </para>
 	</sect2>
 
 	<sect2>
diff --git a/docs/docbook/projdoc/cups.sgml b/docs/docbook/projdoc/cups.sgml
new file mode 100644
index 0000000000..57a12843a8
--- /dev/null
+++ b/docs/docbook/projdoc/cups.sgml
@@ -0,0 +1,445 @@
+<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/printer_driver2.sgml b/docs/docbook/projdoc/printer_driver2.sgml
index 84a24bcdef..85ae0713b3 100644
--- a/docs/docbook/projdoc/printer_driver2.sgml
+++ b/docs/docbook/projdoc/printer_driver2.sgml
@@ -107,7 +107,7 @@ the client.
  
 <para>
 These parameters, including <parameter>printer driver
-file</parameter> parameter, are being depreciated and should not 
+file</parameter> parameter, are being deprecated and should not 
 be used in new installations.  For more information on this change, 
 you should refer to the <link linkend="MIGRATION">Migration section</link>
 of this document.
@@ -260,7 +260,7 @@ driver now?</emphasis>
 
 <para>
 Click "No" in the error dialog and you will be presented with
-the printer properties window.  The way assign a driver to a 
+the printer properties window.  The way to assign a driver to a 
 printer is to either
 </para>
 	
@@ -382,11 +382,65 @@ of the connected user, not necessarily a root account.
 </para>
 
 <para>
-There is a complementing <ulink url="smb.conf.5.html#DELETEPRINTERCOMMAND"><parameter>delete
+There is a complementary <ulink url="smb.conf.5.html#DELETEPRINTERCOMMAND"><parameter>delete
 printer command</parameter></ulink> for removing entries from the "Printers..."
 folder.
 </para>
 
+<para>
+The following is an example <ulink url="smb.conf.5.html#ADDPRINTERCOMMAN"><parameter>add printer command</parameter></ulink> script. It adds the appropriate entries to <filename>/etc/printcap.local</filename> (change that to what you need) and returns a line of 'Done' which is needed for the whole process to work.
+</para>
+
+<programlisting>
+#!/bin/sh
+
+# Script to insert a new printer entry into printcap.local
+#
+# $1, printer name, used as the descriptive name
+# $2, share name, used as the printer name for Linux
+# $3, port name
+# $4, driver name
+# $5, location, used for the device file of the printer
+# $6, win9x location
+
+#
+# Make sure we use the location that RedHat uses for local printer defs
+PRINTCAP=/etc/printcap.local
+DATE=`date +%Y%m%d-%H%M%S`
+LP=lp
+RESTART="service lpd restart"
+
+# Keep a copy
+cp $PRINTCAP $PRINTCAP.$DATE
+# Add the printer to $PRINTCAP
+echo ""				 			>> $PRINTCAP
+echo "$2|$1:\\" 					>> $PRINTCAP
+echo "  :sd=/var/spool/lpd/$2:\\" 			>> $PRINTCAP
+echo "  :mx=0:ml=0:sh:\\" 				>> $PRINTCAP
+echo "  :lp=/usr/local/samba/var/print/$5.prn:" 	>> $PRINTCAP
+
+touch "/usr/local/samba/var/print/$5.prn" >> /tmp/printadd.$$ 2>&1
+chown $LP "/usr/local/samba/var/print/$5.prn" >> /tmp/printadd.$$ 2>&1
+
+mkdir /var/spool/lpd/$2
+chmod 700 /var/spool/lpd/$2
+chown $LP /var/spool/lpd/$2
+#echo $1 >> "/usr/local/samba/var/print/$5.prn"
+#echo $2 >> "/usr/local/samba/var/print/$5.prn"
+#echo $3 >> "/usr/local/samba/var/print/$5.prn"
+#echo $4 >> "/usr/local/samba/var/print/$5.prn"
+#echo $5 >> "/usr/local/samba/var/print/$5.prn"
+#echo $6 >> "/usr/local/samba/var/print/$5.prn"
+$RESTART >> "/usr/local/samba/var/print/$5.prn"
+# Not sure if this is needed
+touch /usr/local/samba/lib/smb.conf
+#
+# You need to return a value, but I am not sure what it means.
+#
+echo "Done"
+exit 0
+</programlisting>
+
 </sect2>
 
 
diff --git a/docs/docbook/projdoc/samba-doc.sgml b/docs/docbook/projdoc/samba-doc.sgml
index 0ec9efe014..75c5c379d3 100644
--- a/docs/docbook/projdoc/samba-doc.sgml
+++ b/docs/docbook/projdoc/samba-doc.sgml
@@ -6,7 +6,6 @@
 <!ENTITY DOMAIN-MEMBER SYSTEM "DOMAIN_MEMBER.sgml">
 <!ENTITY WINBIND SYSTEM "winbind.sgml">
 <!ENTITY NT-Security SYSTEM "NT_Security.sgml">
-<!ENTITY OS2-Client SYSTEM "OS2-Client-HOWTO.sgml">
 <!ENTITY Samba-PDC-HOWTO SYSTEM "Samba-PDC-HOWTO.sgml">
 <!ENTITY Samba-BDC-HOWTO SYSTEM "Samba-BDC-HOWTO.sgml">
 <!ENTITY CVS-Access SYSTEM "CVS-Access.sgml">
@@ -19,7 +18,9 @@
 <!ENTITY SECURITY-LEVEL SYSTEM "security_level.sgml">
 <!ENTITY SPEED SYSTEM "Speed.sgml">
 <!ENTITY BROWSING SYSTEM "Browsing.sgml">
-<!ENTITY INDEX-FILE SYSTEM "index.sgml">
+<!ENTITY GROUP-MAPPING-HOWTO SYSTEM "GROUP-MAPPING-HOWTO.sgml">
+<!ENTITY Portability SYSTEM "Portability.sgml">
+<!ENTITY Other-Clients SYSTEM "Other-Clients.sgml">
 ]>
 
 <book id="Samba-Project-Documentation">
@@ -79,11 +80,10 @@ Cheers, jerry
 &Samba-LDAP;
 &BROWSING;
 &SPEED;
-&OS2-Client;
+&Other-Clients;
 &CVS-Access;
 &BUGS;
-
-<!-- Autogenerated Index -->
-&INDEX-FILE;
+&GROUP-MAPPING-HOWTO;
+&Portability;
 
 </book>