beginning to sync up for 2.2.5 release....

8 files changed, 850 insertions, 431 deletions

diff --git a/docs/docbook/projdoc/Integrating-with-Windows.sgml b/docs/docbook/projdoc/Integrating-with-Windows.sgml
index 0b6abaf80f6..701e48678c3 100644
--- a/docs/docbook/projdoc/Integrating-with-Windows.sgml
+++ b/docs/docbook/projdoc/Integrating-with-Windows.sgml
@@ -132,7 +132,7 @@ by the TCP/IP configuration control files. The file
 
 <para>
 When the IP address of the destination interface has been 
-determined a protocol called ARP/RARP isused to identify 
+determined a protocol called ARP/RARP is used to identify 
 the MAC address of the target interface. ARP stands for Address 
 Resolution Protocol, and is a broadcast oriented method that 
 uses UDP (User Datagram Protocol) to send a request to all 
@@ -335,7 +335,7 @@ architecture of the MS Windows network. The term "workgroup" indicates
 that the primary nature of the network environment is that of a 
 peer-to-peer design. In a WORKGROUP all machines are responsible for 
 their own security, and generally such security is limited to use of 
-just a password (known as SHARE MORE security). In most situations 
+just a password (known as SHARE MODE security). In most situations 
 with peer-to-peer networking the users who control their own machines 
 will simply opt to have no security at all. It is possible to have 
 USER MODE security in a WORKGROUP environment, thus requiring use 
@@ -366,8 +366,8 @@ limited to this area.
 
 <para>
 All MS Windows machines employ an in memory buffer in which is 
-stored the NetBIOS names and their IP addresses for all external 
-machines that that the local machine has communicated with over the 
+stored the NetBIOS names and IP addresses for all external 
+machines that that machine has communicated with over the 
 past 10-15 minutes. It is more efficient to obtain an IP address 
 for a machine from the local cache than it is to go through all the 
 configured name resolution mechanisms.
@@ -377,7 +377,7 @@ configured name resolution mechanisms.
 If a machine whose name is in the local name cache has been shut 
 down before the name had been expired and flushed from the cache, then 
 an attempt to exchange a message with that machine will be subject 
-to time-out delays. ie: It's name is in the cache, so a name resolution 
+to time-out delays. i.e.: Its name is in the cache, so a name resolution 
 lookup will succeed, but the machine can not respond. This can be 
 frustrating for users - but it is a characteristic of the protocol.
 </para>
@@ -563,7 +563,7 @@ dependable browsing using Samba</title>
 
 <para>
 As stated above, MS Windows machines register their NetBIOS names 
-(ie: the machine name for each service type in operation) on start 
+(i.e.: the machine name for each service type in operation) on start 
 up. Also, as stated above, the exact method by which this name registration 
 takes place is determined by whether or not the MS Windows client/server 
 has been given a WINS server address, whether or not LMHOSTS lookup 
@@ -594,7 +594,7 @@ Instead, the domain master browser serves the role of contacting each local
 master browser (found by asking WINS or from LMHOSTS) and exchanging browse 
 list contents. This way every master browser will eventually obtain a complete 
 list of all machines that are on the network. Every 11-15 minutes an election 
-is held to determine which machine will be the master browser. By nature of 
+is held to determine which machine will be the master browser. By the nature of 
 the election criteria used, the machine with the highest uptime, or the 
 most senior protocol version, or other criteria, will win the election 
 as domain master browser.
@@ -679,8 +679,8 @@ these versions no longer support plain text passwords by default.
 <para>
 MS Windows clients have a habit of dropping network mappings that 
 have been idle for 10 minutes or longer. When the user attempts to 
-use the mapped drive connection that has been dropped the SMB protocol 
-has a mechanism by which the connection can be re-established using 
+use the mapped drive connection that has been dropped, the client
+re-establishes the connection using 
 a cached copy of the password.
 </para>
 
@@ -835,7 +835,7 @@ this HOWTO collection.
 
 <para>
 This mode of authentication demands that there be on the 
-Unix/Linux system both a Unix style account as well as and 
+Unix/Linux system both a Unix style account as well as an 
 smbpasswd entry for the user. The Unix system account can be 
 locked if required as only the encrypted password will be 
 used for SMB client authentication.
diff --git a/docs/docbook/projdoc/Samba-BDC-HOWTO.sgml b/docs/docbook/projdoc/Samba-BDC-HOWTO.sgml
index 53a0959c39a..08cdc3a6680 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 c6c04ccab83..6b153af6feb 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
@@ -331,9 +348,39 @@ use with an LDAP directory could appear as
 
 
 </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 90d48435770..39c0213d79e 100644
--- a/docs/docbook/projdoc/UNIX_INSTALL.sgml
+++ b/docs/docbook/projdoc/UNIX_INSTALL.sgml
@@ -231,7 +231,7 @@
 	<para><prompt>$ </prompt><userinput>smbclient -L 
 	<replaceable>yourhostname</replaceable></userinput></para>
 
-	<para>Your should get back a list of shares available on 
+	<para>You should get back a list of shares available on 
 	your server. If you don't then something is incorrectly setup. 
 	Note that this method can also be used to see what shares 
 	are available on other LanManager clients (such as WfWg).</para>
@@ -316,8 +316,8 @@
 		<para>By default Samba uses a blank scope ID. This means 
 		all your windows boxes must also have a blank scope ID. 
 		If you really want to use a non-blank scope ID then you will 
-		need to use the -i &lt;scope&gt; option to nmbd, smbd, and 
-		smbclient. All your PCs will need to have the same setting for 
+		need to use the 'netbios scope' smb.conf option.
+                All your PCs will need to have the same setting for 
 		this to work. I do not recommend scope IDs.</para>
 	</sect2>
 
@@ -421,12 +421,6 @@
 		its open. A client may ask for DENY_NONE, DENY_READ, DENY_WRITE 
 		or DENY_ALL. There are also special compatibility modes called 
 		DENY_FCB and  DENY_DOS.</para>
-
-		<para>You can disable share modes using "share modes = no". 
-		This may be useful on a heavily loaded server as the share 
-		modes code is very slow. See also the FAST_SHARE_MODES 
-		option in the Makefile for a way to do full share modes 
-		very fast using shared memory (if your OS supports it).</para>
 	</sect2>
 	
 	<sect2>
diff --git a/docs/docbook/projdoc/cups.sgml b/docs/docbook/projdoc/cups.sgml
new file mode 100644
index 00000000000..57a12843a84
--- /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 84a24bcdefc..2afba6b5968 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.
@@ -259,37 +259,37 @@ driver now?</emphasis>
 </para>
 
 <para>
-Click "No" in the error dialog and you will be presented with
-the printer properties window.  The way assign a driver to a 
+Click <emphasis>No</emphasis> in the error dialog and you will be presented with
+the printer properties window.  The way assign a driver to a
 printer is to either
 </para>
-	
+
 <itemizedlist>
-	<listitem><para>Use the "New Driver..." button to install 
+	<listitem><para>Use the "New Driver..." button to install
 	a new printer driver, or</para></listitem>
-	
-	<listitem><para>Select a driver from the popup list of 
+
+	<listitem><para>Select a driver from the popup list of
 	installed drivers.  Initially this list will be empty.</para>
 	</listitem>
 </itemizedlist>
-	
-<para>If you wish to install printer drivers for client 
-operating systems other than "Windows NT x86", you will need 
+
+<para>If you wish to install printer drivers for client
+operating systems other than "Windows NT x86", you will need
 to use the "Sharing" tab of the printer properties dialog.</para>
 
-<para>Assuming you have connected with a root account, you 
-will also be able modify other printer properties such as 
+<para>Assuming you have connected with a root account, you
+will also be able modify other printer properties such as
 ACLs and device settings using this dialog box.</para>
 
-<para>A few closing comments for this section, it is possible 
+<para>A few closing comments for this section, it is possible
 on a Windows NT print server to have printers
 listed in the Printers folder which are not shared.  Samba does
 not make this distinction.  By definition, the only printers of
 which Samba is aware are those which are specified as shares in
 <filename>smb.conf</filename>.</para>
-  
+
 <para>Another interesting side note is that Windows NT clients do
-not use the SMB printer share, but rather can print directly 
+not use the SMB printer share, but rather can print directly
 to any printer on another Windows NT host using MS-RPC.  This
 of course assumes that the printing client has the necessary
 privileges on the remote host serving the printer.  The default
@@ -297,42 +297,77 @@ permissions assigned by Windows NT to a printer gives the "Print"
 permissions to the "Everyone" well-known group.
 </para>
 
-</sect2>	
+</sect2>
+
+<sect2>
+<title>DeviceModes and New Printers</title>
+
+<para>
+In order for a printer to be truly usbla eby a Windows NT/2k/XP client,
+it must posses:
+</para>
+
+<itemizedlist>
+	<listitem><para>a valid Device Mode generated by the driver for the printer, and</para></listitem>
+	<listitem><para>a complete set of PrinterDriverData generated by the driver.</para></listitem>
+</itemizedlist>
+
+<para>
+If either one of these is incomplete, the clients can produce less than optimal 
+output at best or in the worst cases, unreadable garbage or nothing at all.  
+Fortunately, most driver generate the printer driver that is needed.
+However, the client must be tickled to generate a valid Device Mode and set it on the
+server.  The easist means of doing so is to simply set the page orientation on 
+the server's printer using the native Windows NT/2k printer properties page from 
+a Window clients.  Make sure to apply changes between swapping the page orientation
+to cause the change to actually take place.  Be aware that this can only be done
+by a "printer admin" (the reason should be obvious I hope).
+</para>
+
+<para>
+Samba also includes a service level parameter name <ulink url="smb.conf.5.html#DEFAULTDEVMODE">default
+devmode</ulink> for generating a default device mode for a printer.  Some driver
+will function fine with this default set of properties.  Others may crash the client's
+spooler service.  Use this parameter with caution. It is always better to have the client
+generate a valid device mode for the printer and store it on the server for you.
+</para>
+
+</sect2>
 
 
 <sect2>
 <title>Support a large number of printers</title>
-		
+
 <para>One issue that has arisen during the development
 phase of Samba 2.2 is the need to support driver downloads for
-100's of printers.  Using the Windows NT APW is somewhat 
-awkward to say the list.  If more than one printer are using the 
+100's of printers.  Using the Windows NT APW is somewhat
+awkward to say the list.  If more than one printer are using the
 same driver, the <ulink url="rpcclient.1.html"><command>rpcclient's
-setdriver command</command></ulink> can be used to set the driver
+setdriver</command></ulink> command can be used to set the driver
 associated with an installed driver.  The following is example
 of how this could be accomplished:</para>
-		
-<para><programlisting> 
+
+<para><programlisting>
 <prompt>$ </prompt>rpcclient pogo -U root%secret -c "enumdrivers"
 Domain=[NARNIA] OS=[Unix] Server=[Samba 2.2.0-alpha3]
- 
+
 [Windows NT x86]
 Printer Driver Info 1:
      Driver Name: [HP LaserJet 4000 Series PS]
- 
+
 Printer Driver Info 1:
      Driver Name: [HP LaserJet 2100 Series PS]
- 
+
 Printer Driver Info 1:
      Driver Name: [HP LaserJet 4Si/4SiMX PS]
-				  
+
 <prompt>$ </prompt>rpcclient pogo -U root%secret -c "enumprinters"
 Domain=[NARNIA] OS=[Unix] Server=[Samba 2.2.0-alpha3]
      flags:[0x800000]
      name:[\\POGO\hp-print]
      description:[POGO\\POGO\hp-print,NO DRIVER AVAILABLE FOR THIS PRINTER,]
      comment:[]
-				  
+
 <prompt>$ </prompt>rpcclient pogo -U root%secret \
 <prompt>&gt; </prompt> -c "setdriver hp-print \"HP LaserJet 4000 Series PS\""
 Domain=[NARNIA] OS=[Unix] Server=[Samba 2.2.0-alpha3]
@@ -344,10 +379,10 @@ Successfully set hp-print to driver HP LaserJet 4000 Series PS.
 
 <sect2>
 <title>Adding New Printers via the Windows NT APW</title>
-	
+
 <para>
 By default, Samba offers all printer shares defined in <filename>smb.conf</filename>
-in the "Printers..." folder.  Also existing in this folder is the Windows NT 
+in the "Printers..." folder.  Also existing in this folder is the Windows NT
 Add Printer Wizard icon.  The APW will be show only if
 </para>
 
@@ -356,24 +391,24 @@ Add Printer Wizard icon.  The APW will be show only if
 	execute an OpenPrinterEx(\\server) with administrative
 	privileges (i.e. root or <parameter>printer admin</parameter>).
 	</para></listitem>
-	
-	<listitem><para><ulink url="smb.conf.5.html#SHOWADDPRINTERWIZARD"><parameter>show 
+
+	<listitem><para><ulink url="smb.conf.5.html#SHOWADDPRINTERWIZARD"><parameter>show
 	add printer wizard = yes</parameter></ulink> (the default).
 	</para></listitem>
 </itemizedlist>
 
 <para>
-In order to be able to use the APW to successfully add a printer to a Samba 
-server, the <ulink url="smb.conf.5.html#ADDPRINTERCOMMAND"><parameter>add 
+In order to be able to use the APW to successfully add a printer to a Samba
+server, the <ulink url="smb.conf.5.html#ADDPRINTERCOMMAND"><parameter>add
 printer command</parameter></ulink> must have a defined value.  The program
-hook must successfully add the printer to the system (i.e. 
-<filename>/etc/printcap</filename> or appropriate files) and 
+hook must successfully add the printer to the system (i.e.
+<filename>/etc/printcap</filename> or appropriate files) and
 <filename>smb.conf</filename> if necessary.
 </para>
 
 <para>
-When using the APW from a client, if the named printer share does 
-not exist, <command>smbd</command> will execute the <parameter>add printer 
+When using the APW from a client, if the named printer share does
+not exist, <command>smbd</command> will execute the <parameter>add printer
 command</parameter> and reparse to the <filename>smb.conf</filename>
 to attempt to locate the new printer share.  If the share is still not defined,
 an error of "Access Denied" is returned to the client.  Note that the 
@@ -429,6 +464,13 @@ that generates a listing of ports on a system.
 	http://imprints.sourceforge.net/</ulink> as well as the documentation 
 	included with the imprints source distribution.  This section will 
 	only provide a brief introduction to the features of Imprints.</para>
+
+	<para>As of June 16, 2002 (quite a bit earlier actually), the Imprints
+	project is in need of a new maintainer.  The most important skill
+	is decent perl coding and an interest in MS-RPC based printing using Samba.
+	If you wich to volunteer, please coordinate your efforts on the samba-technical
+	mailing list.
+	</para>
 	
 	
 	<sect2>
@@ -614,76 +656,21 @@ installations
 </warning>
 
 
+<sect2>
+<title>Parameters in <filename>smb.conf(5)</filename> for Backwards Compatibility</title>
+
 <para>
 The have been two new parameters add in Samba 2.2.2 to for 
 better support of Samba 2.0.x backwards capability (<parameter>disable
 spoolss</parameter>) and for using local printers drivers on Windows 
 NT/2000 clients (<parameter>use client driver</parameter>). Both of 
 these options are described in the smb.coinf(5) man page and are 
-disabled by default.
+disabled by default.  Use them with caution.
 </para>
+</sect2>
 
 
 </sect1>
 
 
-<!--
-
-  This comment from rpc_server/srv_spoolss_nt.c:_spoolss_open_printer_ex()
-  needs to be added into a section probably.  This is to remind me it needs 
-  to be done.  -jerry
-
-                /*
-                 * If the openprinterex rpc call contains a devmode,
-                 * it's a per-user one. This per-user devmode is derivated
-                 * from the global devmode. Openprinterex() contains a per-user
-                 * devmode for when you do EMF printing and spooling.
-                 * In the EMF case, the NT workstation is only doing half the job
-                 * of rendering the page. The other half is done by running the printer
-                 * driver on the server.
-                 * The EMF file doesn't contain the page description (paper size, orientation, ...).
-                 * The EMF file only contains what is to be printed on the page.
-                 * So in order for the server to know how to print, the NT client sends
-                 * a devicemode attached to the openprinterex call.
-                 * But this devicemode is short lived, it's only valid for the current print job.
-                 *
-                 * If Samba would have supported EMF spooling, this devicemode would
-                 * have been attached to the handle, to sent it to the driver to correctly
-                 * rasterize the EMF file.
-                 *
-                 * As Samba only supports RAW spooling, we only receive a ready-to-print file,
-                 * we just act as a pass-thru between windows and the printer.
-                 *
-                 * In order to know that Samba supports only RAW spooling, NT has to call
-                 * getprinter() at level 2 (attribute field) or NT has to call startdoc()
-                 * and until NT sends a RAW job, we refuse it.
-                 *
-                 * But to call getprinter() or startdoc(), you first need a valid handle,
-                 * and to get an handle you have to call openprintex(). Hence why you have
-                 * a devicemode in the openprinterex() call.
-                 *
-                 *
-                 * Differences between NT4 and NT 2000.
-                 * NT4:
-                 * 
-                 * On NT4, you only have a global devicemode. This global devicemode can be changed
-                 * by the administrator (or by a user with enough privs). Every time a user
-                 * wants to print, the devicemode is reset to the default. In Word, every time
-                 * you print, the printer's characteristics are always reset to the global devicemode.
-                 *
-                 * NT 2000:
-                 * 
-                 * In W2K, there is the notion of per-user devicemode. The first time you use
-                 * a printer, a per-user devicemode is build from the global devicemode.
-                 * If you change your per-user devicemode, it is saved in the registry, under the
-                 * H_KEY_CURRENT_KEY sub_tree. So that every time you print, you have your default
-                 * printer preferences available.
-                 *
-                 * To change the per-user devicemode: it's the "Printing Preferences ..." button
-                 * on the General Tab of the printer properties windows.
-                 *
-                 * To change the global devicemode: it's the "Printing Defaults..." button
-                 * on the Advanced Tab of the printer properties window.
--->
-
 </chapter>
diff --git a/docs/docbook/projdoc/samba-doc.sgml b/docs/docbook/projdoc/samba-doc.sgml
index 28baa7f6094..671ff453176 100644
--- a/docs/docbook/projdoc/samba-doc.sgml
+++ b/docs/docbook/projdoc/samba-doc.sgml
@@ -3,6 +3,7 @@
 <!ENTITY ENCRYPTION SYSTEM "ENCRYPTION.sgml">
 <!ENTITY MS-Dfs-Setup SYSTEM "msdfs_setup.sgml">
 <!ENTITY PRINTER-DRIVER2 SYSTEM "printer_driver2.sgml">
+<!ENTITY CUPS SYSTEM "cups.sgml">
 <!ENTITY DOMAIN-MEMBER SYSTEM "DOMAIN_MEMBER.sgml">
 <!ENTITY WINBIND SYSTEM "winbind.sgml">
 <!ENTITY NT-Security SYSTEM "NT_Security.sgml">
@@ -63,6 +64,7 @@ Cheers, jerry
 &MS-Dfs-Setup;
 &NT-Security;
 &PRINTER-DRIVER2;
+&CUPS;
 &DOMAIN-MEMBER;
 &Samba-PDC-HOWTO;
 &Samba-BDC-HOWTO;
diff --git a/docs/docbook/projdoc/winbind.sgml b/docs/docbook/projdoc/winbind.sgml
index 6fd7d09d3e5..52f608fc276 100644
--- a/docs/docbook/projdoc/winbind.sgml
+++ b/docs/docbook/projdoc/winbind.sgml
@@ -139,7 +139,7 @@
 		workstations into a NT based organization.</para>
 		
 		<para>Another interesting way in which we expect Winbind to 
-		be used is as a central part of UNIX based appliances. Appliances 
+		be used is as a central part of UNIX based appliances. Appliances
 		that provide file and print services to Microsoft based networks 
 		will be able to use Winbind to provide seamless integration of 
 		the appliance into the domain.</para>
@@ -315,21 +315,13 @@
 <para>
 Many thanks to John Trostel <ulink 
 url="mailto:jtrostel@snapserver.com">jtrostel@snapserver.com</ulink>
-for providing the HOWTO for this section.
-</para>
-
-<para>
-This HOWTO describes how to get winbind services up and running 
+for providing the original Linux version of this HOWTO which 
+describes how to get winbind services up and running 
 to control access and authenticate users on your Linux box using 
-the winbind services which come with SAMBA 2.2.2.
+the winbind services which are included with the SAMBA 2.2.2 and later
+releases.
 </para>
 
-<para>
-There is also some Solaris specific information in 
-<filename>docs/textdocs/Solaris-Winbind-HOWTO.txt</filename>.
-Future revisions of this document will incorporate that
-information.
-</para>
 
 
 
@@ -338,16 +330,16 @@ information.
 
 <para>
 This HOWTO describes the procedures used to get winbind up and 
-running on my RedHat 7.1 system.  Winbind is capable of providing access 
-and authentication control for Windows Domain users through an NT 
-or Win2K PDC for 'regular' services, such as telnet a nd ftp, as
-well for SAMBA services.
+running on a RedHat 7.1 system.  Winbind is capable of providing access
+and authentication control for Windows Domain users through an NT
+or Win2K PDC for 'regular' services, such as telnet and ftp, as
+well providing dynamic uid/gid allocation for Samba.
 </para>
 
 <para>
-This HOWTO has been written from a 'RedHat-centric' perspective, so if 
-you are using another distribution, you may have to modify the instructions 
-somewhat to fit the way your distribution works.
+This HOWTO has been written from a 'RedHat-centric' perspective, so if
+you are using another distribution (or operating system), you may have
+to modify the instructions somewhat to fit the way your distribution works.
 </para>
 
 
@@ -356,10 +348,10 @@ somewhat to fit the way your distribution works.
 	<para>
 	<emphasis>Why should I to this?</emphasis>
 	</para>
-	
-	<para>This allows the SAMBA administrator to rely on the 
-	authentication mechanisms on the NT/Win2K PDC for the authentication 
-	of domain members.  NT/Win2K users no longer need to have separate 
+
+	<para>This allows the SAMBA administrator to rely on the
+	authentication mechanisms on the NT/Win2K PDC for the authentication
+	of domain members.  NT/Win2K users no longer need to have separate
 	accounts on the SAMBA server.
 	</para>
 </listitem>
@@ -368,14 +360,12 @@ somewhat to fit the way your distribution works.
 	<para>
 	<emphasis>Who should be reading this document?</emphasis>
 	</para>
-	
+
 	<para>
-	This HOWTO is designed for system administrators.  If you are 
-	implementing SAMBA on a file server and wish to (fairly easily) 
+	This HOWTO is designed for system administrators.  If you are
+	implementing SAMBA on a file server and wish to (fairly easily)
 	integrate existing NT/Win2K users from your PDC onto the
-	SAMBA server, this HOWTO is for you.  That said, I am no NT or PAM 
-	expert, so you may find a better or easier way to accomplish 
-	these tasks.
+	SAMBA server, this HOWTO is for you.
 	</para>
 </listitem>
 </itemizedlist>
@@ -386,38 +376,39 @@ somewhat to fit the way your distribution works.
 <title>Requirements</title>
 
 <para>
-If you have a samba configuration file that you are currently 
-using... <emphasis>BACK IT UP!</emphasis>  If your system already uses PAM, 
-<emphasis>back up the <filename>/etc/pam.d</filename> directory 
-contents!</emphasis> If you haven't already made a boot disk, 
+If you have a samba configuration file that you are currently
+using... <emphasis>BACK IT UP!</emphasis>  If your system already uses PAM,
+<emphasis>back up the <filename>/etc/pam.d</filename> (or <filename>/etc/pam.conf</filename>)
+directory contents!</emphasis> If you haven't already made a boot disk,
 <emphasis>MAKE ONE NOW!</emphasis>
 </para>
 
 <para>
-Messing with the pam configuration files can make it nearly impossible 
-to log in to yourmachine. That's why you want to be able to boot back 
-into your machine in single user mode and restore your 
-<filename>/etc/pam.d</filename> back to the original state they were in if 
-you get frustrated with the way things are going.  ;-)
+Messing with the pam configuration files can make it nearly impossible
+to log in to your machine. That's why you want to be able to boot back
+into your machine in single user mode and restore your
+<filename>/etc/pam.d</filename> (or <filename>pam.conmf</filename>) back to
+the original state they were in if
+you get frustrated with the way things are going.
 </para>
 
 <para>
-The latest version of SAMBA (version 2.2.2 as of this writing), now 
-includes a functioning winbindd daemon.  Please refer to the 
-<ulink url="http://samba.org/">main SAMBA web page</ulink> or, 
-better yet, your closest SAMBA mirror site for instructions on 
-downloading the source code.
+The first SAMBA release to inclue a stable winbindd daemon was 2.2.2.  Please refer to the
+<ulink url="http://samba.org/">main SAMBA web page</ulink> or,
+better yet, your closest SAMBA mirror site for instructions on
+downloading the source code.  it is generally advised to obtain the lates
+Samba release as bugs are constantly being fixed.
 </para>
 
 <para>
-To allow Domain users the ability to access SAMBA shares and 
-files, as well as potentially other services provided by your 
+To allow Domain users the ability to access SAMBA shares and
+files, as well as potentially other services provided by your
 SAMBA machine, PAM (pluggable authentication modules) must
-be setup properly on your machine.  In order to compile the 
-winbind modules, you should have at least the pam libraries resident 
-on your system.  For recent RedHat systems (7.1, for instance), that 
-means <filename>pam-0.74-22</filename>.  For best results, it is helpful to also
-install the development packages in <filename>pam-devel-0.74-22</filename>.
+be setup properly on your machine.  In order to compile the
+winbind modules, you must have at the PAM libraries and header files resident
+on your system.  For recent RedHat systems (7.x, for instance), that
+means installing both <filename>pam</filename> and <filename>pam-devel</filename> RPM.
+The former is installed by default on all Linux systems of which the author is aware.
 </para>
 
 </sect2>
@@ -427,33 +418,33 @@ install the development packages in <filename>pam-devel-0.74-22</filename>.
 <title>Testing Things Out</title>
 
 <para>
-Before starting, it is probably best to kill off all the SAMBA 
-related daemons running on your server.  Kill off all <command>smbd</command>, 
-<command>nmbd</command>, and <command>winbindd</command> processes that may 
-be running.  To use PAM, you will want to make sure that you have the 
-standard PAM package (for RedHat) which supplies the <filename>/etc/pam.d</filename> 
-directory structure, including the pam modules are used by pam-aware 
-services, several pam libraries, and the <filename>/usr/doc</filename> 
-and <filename>/usr/man</filename> entries for pam.  Winbind built better 
-in SAMBA if the pam-devel package was also installed.  This package includes 
-the header files needed to compile pam-aware applications. For instance, 
-my RedHat system has both <filename>pam-0.74-22</filename> and
-<filename>pam-devel-0.74-22</filename> RPMs installed.
+Before starting, kill off all the SAMBA related daemons running on your server.  Kill off
+all <command>smbd</command>, <command>nmbd</command>, and <command>winbindd</command> processes that may
+be running (<command>winbindd</command> will only be running if you have ao previous Winbind
+installation...but why would you be reading tis if that were the case?).  To use PAM, you will
+want to make sure that you have the standard PAM package (for RedHat) which supplies the <filename>/etc/pam.d</filename>
+directory structure, including the pam modules are used by pam-aware
+services, several pam libraries, and the <filename>/usr/doc</filename>
+and <filename>/usr/man</filename> entries for pam.  Samba will require
+the pam-devel package if you plan to build the <filename>pam_winbind.so</filename> library or
+include the <command>--with-pam</command> option to the configure script.
+This package includes the header files needed to compile pam-aware applications.
+</para>
+
+<para>
+[I have no idea which Solaris packages are quired for PAM libraries and
+development files.  If you know, please mail me the information and I will include
+it in the next revision of this HOWTO.  --jerry@samba.org]
 </para>
 
 <sect3>
-<title>Configure and compile SAMBA</title>
+<title>Configure and Compile SAMBA</title>
 
 <para>
-The configuration and compilation of SAMBA is pretty straightforward.
-The first three steps may not be necessary depending upon
-whether or not you have previously built the Samba binaries.
+The configuration and compilation of SAMBA is straightforward.
 </para>
 
 <para><programlisting>
-<prompt>root#</prompt> <command>autoconf</command>
-<prompt>root#</prompt> <command>make clean</command>
-<prompt>root#</prompt> <command>rm config.cache</command>
 <prompt>root#</prompt> <command>./configure --with-winbind</command>
 <prompt>root#</prompt> <command>make</command>
 <prompt>root#</prompt> <command>make install</command>
@@ -463,26 +454,27 @@ whether or not you have previously built the Samba binaries.
 <para>
 This will, by default, install SAMBA in <filename>/usr/local/samba</filename>.
 See the main SAMBA documentation if you want to install SAMBA somewhere else.
-It will also build the winbindd executable and libraries. 
+It will also build the winbindd executable and NSS library.
 </para>
 
 </sect3>
 
 <sect3>
-<title>Configure <filename>nsswitch.conf</filename> and the 
+<title>Configure <filename>nsswitch.conf</filename> and the
 winbind libraries</title>
 
 <para>
-The libraries needed to run the <command>winbindd</command> daemon 
-through nsswitch need to be copied to their proper locations, so
+The libraries needed to run the <command>winbindd</command> daemon
+through nsswitch need to be copied to their proper locations.
 </para>
 
 <para>
-<prompt>root#</prompt> <command>cp ../samba/source/nsswitch/libnss_winbind.so /lib</command>
+<prompt>root#</prompt> <command>cp nsswitch/libnss_winbind.so /lib</command>
+<prompt>root#</prompt> <command>chmod 755 /lib/libnss_winbind.so</command>
 </para>
 
 <para>
-I also found it necessary to make the following symbolic link:
+It necessary to make the following symbolic link:
 </para>
 
 <para>
@@ -490,45 +482,35 @@ I also found it necessary to make the following symbolic link:
 </para>
 
 <para>
-Now, as root you need to edit <filename>/etc/nsswitch.conf</filename> to 
-allow user and group entries to be visible from the <command>winbindd</command> 
-daemon.  My <filename>/etc/nsswitch.conf</filename> file look like 
-this after editing:
+The <filename>.2</filename> extension is due to the version of glibc used on your Linux host.
+for most modern systems, the file extension is correct.  However, some other operating systems,
+Solaris 7/8 being the most common, the destination filename should be replaced with
+<filename>/lib/nss_winbind.so.1</filename>
+</para>
+
+<para>
+Now, as root edit <filename>/etc/nsswitch.conf</filename> to
+allow user and group entries to be visible from the <command>winbindd</command>
+daemon.  After editing, the file look appear:
 </para>
 
 <para><programlisting>
 	passwd:     files winbind
-	shadow:     files 
+	shadow:     files
 	group:      files winbind
 </programlisting></para>
 
-<para>	
-The libraries needed by the winbind daemon will be automatically 
-entered into the <command>ldconfig</command> cache the next time 
-your system reboots, but it 
-is faster (and you don't need to reboot) if you do it manually:
-</para>
-
-<para>
-<prompt>root#</prompt> <command>/sbin/ldconfig -v | grep winbind</command>
-</para>
-
-<para>
-This makes <filename>libnss_winbind</filename> available to winbindd 
-and echos back a check to you.
-</para>
-
 </sect3>
 
 
 <sect3>
-<title>Configure smb.conf</title>
+<title>Configure <filename>smb.conf</filename></title>
 
 <para>
-Several parameters are needed in the smb.conf file to control 
-the behavior of <command>winbindd</command>. Configure 
-<filename>smb.conf</filename> These are described in more detail in 
-the <ulink url="winbindd.8.html">winbindd(8)</ulink> man page.  My 
+Several parameters are needed in the smb.conf file to control
+the behavior of <command>winbindd</command>. Configure
+<filename>smb.conf</filename> These are described in more detail in
+the <ulink url="winbindd.8.html">winbindd(8)</ulink> man page.  My
 <filename>smb.conf</filename> file was modified to
 include the following entries in the [global] section:
 </para>
@@ -543,9 +525,11 @@ include the following entries in the [global] section:
      # use gids from 10000 to 20000 for domain groups
      <ulink url="winbindd.8.html#WINBINDGID">winbind gid</ulink> = 10000-20000
      # allow enumeration of winbind users and groups
+     # might need to disable these next two for performance
+     # reasons on the winbindd host
      <ulink url="winbindd.8.html#WINBINDENUMUSERS">winbind enum users</ulink> = yes
      <ulink url="winbindd.8.html#WINBINDENUMGROUP">winbind enum groups</ulink> = yes
-     # give winbind users a real shell (only needed if they have telnet access)
+     # give winbind users a real shell (only needed if they have telnet/sshd/etc... access)
      <ulink url="winbindd.8.html#TEMPLATEHOMEDIR">template homedir</ulink> = /home/winnt/%D/%U
      <ulink url="winbindd.8.html#TEMPLATESHELL">template shell</ulink> = /bin/bash
 </programlisting></para>
@@ -557,12 +541,12 @@ include the following entries in the [global] section:
 <title>Join the SAMBA server to the PDC domain</title>
 
 <para>
-Enter the following command to make the SAMBA server join the 
-PDC domain, where <replaceable>DOMAIN</replaceable> is the name of 
-your Windows domain and <replaceable>Administrator</replaceable> is 
+Enter the following command to make the SAMBA server join the
+PDC domain, where <replaceable>DOMAIN</replaceable> is the name of
+your Windows domain and <replaceable>Administrator</replaceable> is
 a domain user who has administrative privileges in the domain.
 </para>
-	
+
 
 <para>
 <prompt>root#</prompt> <command>/usr/local/samba/bin/smbpasswd -j DOMAIN -r PDC -U Administrator</command>
@@ -570,8 +554,8 @@ a domain user who has administrative privileges in the domain.
 
 
 <para>
-The proper response to the command should be: "Joined the domain 
-<replaceable>DOMAIN</replaceable>" where <replaceable>DOMAIN</replaceable> 
+The proper response to the command should be: "Joined the domain
+<replaceable>DOMAIN</replaceable>" where <replaceable>DOMAIN</replaceable>
 is your DOMAIN name.
 </para>
 
@@ -582,19 +566,20 @@ is your DOMAIN name.
 <title>Start up the winbindd daemon and test it!</title>
 
 <para>
-Eventually, you will want to modify your smb startup script to 
-automatically invoke the winbindd daemon when the other parts of 
+Eventually, you will want to modify your smb startup script to
+automatically invoke the winbindd daemon when the other parts of
 SAMBA start, but it is possible to test out just the winbind
-portion first.  To start up winbind services, enter the following 
+portion first.  To start up winbind services, enter the following
 command as root:
 </para>
-	
+
 <para>
-<prompt>root#</prompt> <command>/usr/local/samba/bin/winbindd</command>
+<prompt>root#</prompt> <command>export PATH=$PATH:/usr/local/samba/bin</command>
+<prompt>root#</prompt> <command>winbindd</command>
 </para>
 
 <para>
-I'm always paranoid and like to make sure the daemon 
+I'm always paranoid and like to make sure the daemon
 is really running...
 </para>
 
@@ -609,16 +594,21 @@ This command should produce output like this, if the daemon is running
 </para>
 
 <para>
-Now... for the real test, try to get some information about the 
+Note that a sample RedHat init script for starting winbindd is included in
+the SAMBA sourse distribution as <filename>packaging/RedHat/winbind.init</filename>.
+</para>
+
+<para>
+Now... for the real test, try to get some information about the
 users on your PDC
 </para>
 
 <para>
-<prompt>root#</prompt> <command>/usr/local/samba/bin/wbinfo -u</command>
+<prompt>root#</prompt> <command>wbinfo -u</command>
 </para>
 
-<para>	
-This should echo back a list of users on your Windows users on 
+<para>
+This should echo back a list of users on your Windows users on
 your PDC.  For example, I get the following response:
 </para>
 
@@ -637,7 +627,7 @@ separator</parameter> is '+'.
 </para>
 
 <para>
-You can do the same sort of thing to get group information from 
+You can do the same sort of thing to get group information from
 the PDC:
 </para>
 
@@ -655,7 +645,7 @@ CEO+Group Policy Creator Owners
 </programlisting></para>
 
 <para>
-The function 'getent' can now be used to get unified 
+The function 'getent' can now be used to get unified
 lists of both local and PDC users and groups.
 Try the following command:
 </para>
@@ -663,11 +653,12 @@ Try the following command:
 <para>
 <prompt>root#</prompt> <command>getent passwd</command>
 </para>
-	
+
 <para>
-You should get a list that looks like your <filename>/etc/passwd</filename> 
-list followed by the domain users with their new uids, gids, home 
-directories and default shells.
+You should get a list that looks like your <filename>/etc/passwd</filename>
+list followed by the domain users with their new uids, gids, home
+directories and default shells.  If you do not, verify that the permissions on the
+libnss_winbind.so library are <filename>rwxr-xr-x</filename>.
 </para>
 
 <para>
@@ -681,94 +672,20 @@ The same thing can be done for groups with the command
 </sect3>
 
 
-<sect3>
-<title>Fix the <filename>/etc/rc.d/init.d/smb</filename> startup files</title>
-
-<para>
-The <command>winbindd</command> daemon needs to start up after the 
-<command>smbd</command> and <command>nmbd</command> daemons are running.  
-To accomplish this task, you need to modify the <filename>/etc/init.d/smb</filename>
-script to add commands to invoke this daemon in the proper sequence.  My 
-<filename>/etc/init.d/smb</filename> file starts up <command>smbd</command>, 
-<command>nmbd</command>, and <command>winbindd</command> from the 
-<filename>/usr/local/samba/bin</filename> directory directly.  The 'start' 
-function in the script looks like this:
-</para>
-
-<para><programlisting>
-start() {
-        KIND="SMB"
-        echo -n $"Starting $KIND services: "
-        daemon /usr/local/samba/bin/smbd $SMBDOPTIONS
-        RETVAL=$?
-        echo
-        KIND="NMB"
-        echo -n $"Starting $KIND services: "
-        daemon /usr/local/samba/bin/nmbd $NMBDOPTIONS
-        RETVAL2=$?
-        echo
-        KIND="Winbind"
-        echo -n $"Starting $KIND services: "
-        daemon /usr/local/samba/bin/winbindd
-        RETVAL3=$?
-        echo
-        [ $RETVAL -eq 0 -a $RETVAL2 -eq 0 -a $RETVAL3 -eq 0 ] && touch /var/lock/subsys/smb || \
-           RETVAL=1
-        return $RETVAL
-}
-</programlisting></para>
-
-<para>
-The 'stop' function has a corresponding entry to shut down the 
-services and look s like this:
-</para>
-
-<para><programlisting>
-stop() {
-        KIND="SMB"
-        echo -n $"Shutting down $KIND services: "
-        killproc smbd
-        RETVAL=$?
-        echo
-        KIND="NMB"
-        echo -n $"Shutting down $KIND services: "
-        killproc nmbd
-        RETVAL2=$?
-        echo
-        KIND="Winbind"
-        echo -n $"Shutting down $KIND services: "
-        killproc winbindd
-        RETVAL3=$?
-        [ $RETVAL -eq 0 -a $RETVAL2 -eq 0 -a $RETVAL3 -eq 0 ] && rm -f /var/lock/subsys/smb
-        echo ""
-        return $RETVAL
-}
-</programlisting></para>
-
-<para>
-If you restart the <command>smbd</command>, <command>nmbd</command>, 
-and <command>winbindd</command> daemons at this point, you
-should be able to connect to the samba server as a domain member just as
-if you were a local user.
-</para>
-
-</sect3>
-
-
 
 <sect3>
 <title>Configure Winbind and PAM</title>
 
 <para>
-If you have made it this far, you know that winbindd and samba are working
-together.  If you want to use winbind to provide authentication for other 
+At this point we are assured that <command>winbindd</command> and <command>smbd</command>
+are working together.  If you want to use winbind to provide authentication for other
 services, keep reading.  The pam configuration files need to be altered in
-this step.  (Did you remember to make backups of your original 
-<filename>/etc/pam.d</filename> files? If not, do it now.)
+this step.  (Did you remember to make backups of your original
+<filename>/etc/pam.d</filename> (or <filename>/etc/pam.conf</filename>) file[s]? If not, do it now.)
 </para>
 
 <para>
-You will need a pam module to use winbindd with these other services.  This 
+You will need a PAM module to use <command>winbindd</command> with these other services.  This
 module will be compiled in the <filename>../source/nsswitch</filename> directory
 by invoking the command
 </para>
@@ -780,34 +697,24 @@ by invoking the command
 <para>
 from the <filename>../source</filename> directory.  The
 <filename>pam_winbind.so</filename> file should be copied to the location of
-your other pam security modules.  On my RedHat system, this was the
+your other pam security modules.  On Linux and Solaris systems, this is the
 <filename>/lib/security</filename> directory.
 </para>
 
 <para>
-<prompt>root#</prompt> <command>cp ../samba/source/nsswitch/pam_winbind.so /lib/security</command>
+<prompt>root#</prompt> <command>cp nsswitch/pam_winbind.so /lib/security</command>
+<prompt>root#</prompt> <command>chmod 755 /lib/security/pam_winbind.so</command>
 </para>
 
 <para>
-The <filename>/etc/pam.d/samba</filename> file does not need to be changed. I 
-just left this fileas it was:
-</para>
-
-
-<para><programlisting>
-auth    required        /lib/security/pam_stack.so service=system-auth
-account required        /lib/security/pam_stack.so service=system-auth
-</programlisting></para>
-
-<para>
-The other services that I modified to allow the use of winbind 
-as an authentication service were the normal login on the console (or a terminal 
-session), telnet logins, and ftp service.  In order to enable these 
-services, you may first need to change the entries in 
-<filename>/etc/xinetd.d</filename> (or <filename>/etc/inetd.conf</filename>).  
-RedHat 7.1 uses the new xinetd.d structure, in this case you need 
-to change the lines in <filename>/etc/xinetd.d/telnet</filename> 
-and <filename>/etc/xinetd.d/wu-ftp</filename> from 
+Other services, such as the normal login on the console (or a terminal
+session), telnet logins, and ftp service, can be modified to allow the use of winbind
+as an authentication service.  In order to enable these
+services, you may first need to change the entries in
+<filename>/etc/xinetd.d</filename> (or <filename>/etc/inetd.conf</filename>).
+RedHat 7.1 uses the new xinetd.d structure, in this case you need
+to change the lines in <filename>/etc/xinetd.d/telnet</filename>
+and <filename>/etc/xinetd.d/wu-ftp</filename> from
 </para>
 
 <para><programlisting>
@@ -822,19 +729,19 @@ to
 enable = yes
 </programlisting></para>
 
-<para>	
-For ftp services to work properly, you will also need to either 
-have individual directories for the domain users already present on 
+<para>
+For ftp services to work properly, you will also need to either
+have individual directories for the domain users already present on
 the server, or change the home directory template to a general
-directory for all domain users.  These can be easily set using 
-the <filename>smb.conf</filename> global entry 
+directory for all domain users.  These can be easily set using
+the <filename>smb.conf</filename> global entry
 <command>template homedir</command>.
 </para>
 
 <para>
-The <filename>/etc/pam.d/ftp</filename> file can be changed 
+The <filename>/etc/pam.d/ftp</filename> file can be changed
 to allow winbind ftp access in a manner similar to the
-samba file.  My <filename>/etc/pam.d/ftp</filename> file was 
+samba file.  My <filename>/etc/pam.d/ftp</filename> file was
 changed to look like this:
 </para>
 
@@ -849,7 +756,7 @@ session    required     /lib/security/pam_stack.so service=system-auth
 </programlisting></para>
 
 <para>
-The <filename>/etc/pam.d/login</filename> file can be changed nearly the 
+The <filename>/etc/pam.d/login</filename> file can be changed nearly the
 same way.  It now looks like this:
 </para>
 
@@ -867,15 +774,31 @@ session    optional     /lib/security/pam_console.so
 </programlisting></para>
 
 <para>
-In this case, I added the <command>auth sufficient /lib/security/pam_winbind.so</command> 
-lines as before, but also added the <command>required pam_securetty.so</command> 
-above it, to disallow root logins over the network.  I also added a 
+In this case, I added the <command>auth sufficient /lib/security/pam_winbind.so</command>
+lines as before, but also added the <command>required pam_securetty.so</command>
+above it, to disallow root logins over the network.  I also added a
 <command>sufficient /lib/security/pam_unix.so use_first_pass</command>
-line after the <command>winbind.so</command> line to get rid of annoying 
+line after the <command>winbind.so</command> line to get rid of annoying
 double prompts for passwords.
 </para>
 
 
+<para>
+Note that a Solaris <filename>/etc/pam.conf</filename> confiruation file looks
+very similar to this except thaty the service name is included as the first entry
+per line.  An example for the login service is given here.
+</para>
+
+<para><programlisting>
+## excerpt from /etc/pam.conf on a Solaris 8 system
+login   auth required   /lib/security/pam_winbind.so
+login   auth required   /lib/security/$ISA/pam_unix.so.1 try_first_pass
+login   auth required   /lib/security/$ISA/pam_dial_auth.so.1 try_first_pass
+</programlisting></para>
+
+
+
+
 </sect3>
 
 </sect2>
@@ -884,29 +807,21 @@ double prompts for passwords.
 
 <sect1>
 	<title>Limitations</title>
-	
-	<para>Winbind has a number of limitations in its current 
-	released version that we hope to overcome in future 
+
+	<para>Winbind has a number of limitations in its current
+	released version that we hope to overcome in future
 	releases:</para>
 
 	<itemizedlist>
-		<listitem><para>Winbind is currently only available for 
-		the Linux operating system, although ports to other operating 
-		systems are certainly possible. For such ports to be feasible, 
-		we require the C library of the target operating system to 
-		support the Name Service Switch and Pluggable Authentication
-		Modules systems. This is becoming more common as NSS and 
-		PAM gain	support among UNIX vendors.</para></listitem>
-		
-		<listitem><para>The mappings of Windows NT RIDs to UNIX ids 
-		is not made algorithmically and depends on the order in which 
-		unmapped users or groups are seen by winbind. It may be difficult 
-		to recover the mappings of rid to UNIX id mapping if the file 
+		<listitem><para>The mappings of Windows NT RIDs to UNIX ids
+		is not made algorithmically and depends on the order in which
+		unmapped users or groups are seen by winbind. It may be difficult
+		to recover the mappings of rid to UNIX id mapping if the file
 		containing this information is corrupted or destroyed.</para>
 		</listitem>
-		
-		<listitem><para>Currently the winbind PAM module does not take 
-		into account possible workstation and logon time restrictions 
+
+		<listitem><para>Currently the winbind PAM module does not take
+		into account possible workstation and logon time restrictions
 		that may be been set for Windows NT users.</para></listitem>
 	</itemizedlist>
 </sect1>