diff options
Diffstat (limited to 'docs-xml/Samba3-HOWTO/TOSHARG-Printing.xml')
| -rw-r--r-- | docs-xml/Samba3-HOWTO/TOSHARG-Printing.xml | 3273 |
1 files changed, 3273 insertions, 0 deletions
diff --git a/docs-xml/Samba3-HOWTO/TOSHARG-Printing.xml b/docs-xml/Samba3-HOWTO/TOSHARG-Printing.xml new file mode 100644 index 00000000000..1cf35fb7c4f --- /dev/null +++ b/docs-xml/Samba3-HOWTO/TOSHARG-Printing.xml @@ -0,0 +1,3273 @@ +<?xml version="1.0" encoding="iso-8859-1"?> +<!DOCTYPE chapter PUBLIC "-//Samba-Team//DTD DocBook V4.2-Based Variant V1.0//EN" "http://www.samba.org/samba/DTD/samba-doc"> +<chapter id="classicalprinting"> + +<chapterinfo> + <author> + <firstname>Kurt</firstname><surname>Pfeifle</surname> + <affiliation> + <orgname>Danka Deutschland GmbH</orgname> + <address><email>kpfeifle@danka.de</email></address> + </affiliation> + </author> + &author.jerry; + &author.jht; + <pubdate>May 31, 2003</pubdate> +</chapterinfo> + +<title>Classical Printing Support</title> + +<sect1> +<title>Features and Benefits</title> + +<para> +<indexterm><primary>mission-critical</primary></indexterm> +Printing is often a mission-critical service for the users. Samba can provide this service reliably and +seamlessly for a client network consisting of Windows workstations. +</para> + +<para> +<indexterm><primary>print service</primary></indexterm> +<indexterm><primary>domain member server</primary></indexterm> +<indexterm><primary>standalone server</primary></indexterm> +<indexterm><primary>file serving</primary></indexterm> +<indexterm><primary>dedicated print server</primary></indexterm> +<indexterm><primary>print server</primary></indexterm> +<indexterm><primary>printing support</primary></indexterm> +<indexterm><primary>Point'n'Print</primary></indexterm> +<indexterm><primary>Add Printer Wizard</primary></indexterm> +<indexterm><primary>upload drivers</primary></indexterm> +<indexterm><primary>manage drivers</primary></indexterm> +<indexterm><primary>install drivers</primary></indexterm> +<indexterm><primary>print accounting</primary></indexterm> +<indexterm><primary>Common UNIX Printing System</primary><see>CUPS</see></indexterm> +A Samba print service may be run on a standalone or domain member server, side by side with file serving +functions, or on a dedicated print server. It can be made as tightly or as loosely secured as needs dictate. +Configurations may be simple or complex. Available authentication schemes are essentially the same as +described for file services in previous chapters. Overall, Samba's printing support is now able to replace an +NT or Windows 2000 print server full-square, with additional benefits in many cases. Clients may download and +install drivers and printers through their familiar <literal>Point'n'Print</literal> mechanism. Printer +installations executed by <literal>Logon Scripts</literal> are no problem. Administrators can upload and manage +drivers to be used by clients through the familiar <literal>Add Printer Wizard</literal>. As an additional +benefit, driver and printer management may be run from the command line or through scripts, making it more +efficient in case of large numbers of printers. If a central accounting of print jobs (tracking every single +page and supplying the raw data for all sorts of statistical reports) is required, this function is best +supported by the newer Common UNIX Printing System (CUPS) as the print subsystem underneath the Samba hood. +</para> + +<para> +<indexterm><primary>BSD</primary></indexterm> +<indexterm><primary>CUPS</primary></indexterm> +This chapter outlines the fundamentals of Samba printing as implemented by the more traditional UNIX +BSD- and System V-style printing systems. Much of the information in this chapter applies also to CUPS. If +you use CUPS, you may be tempted to jump to the next chapter, but you will certainly miss a few things if you +do. For further information refer to <link linkend="CUPS-printing">CUPS Printing Support</link>. +</para> + +<note> +<para> +<indexterm><primary>Windows XP Professional</primary></indexterm> +<indexterm><primary>Windows 200x/XP</primary></indexterm> +<indexterm><primary>Windows NT4</primary></indexterm> +Most of the following examples have been verified on Windows XP Professional clients. Where this document +describes the responses to commands given, bear in mind that Windows 200x/XP clients are quite similar but may +differ in minor details. Windows NT4 is somewhat different again. +</para> +</note> + +</sect1> + +<sect1> +<title>Technical Introduction</title> + +<para> +<indexterm><primary>printing support</primary></indexterm> +<indexterm><primary>print subsystem</primary></indexterm> +<indexterm><primary>printing system</primary></indexterm> +Samba's printing support always relies on the installed print subsystem of the UNIX OS it runs on. Samba is a +<literal>middleman.</literal> It takes print files from Windows (or other SMB) clients and passes them to the real +printing system for further processing; therefore, it needs to communicate with both sides: the Windows print +clients and the UNIX printing system. Hence, we must differentiate between the various client OS types, each +of which behave differently, as well as the various UNIX print subsystems, which themselves have different +features and are accessed differently. +</para> + +<para> +<indexterm><primary>UNIX printing</primary></indexterm> +<indexterm><primary>CUPS</primary></indexterm> +This chapter deals with the traditional way of UNIX printing. The next chapter covers in great detail the more +modern CUPS. +</para> + +<important><para> +<indexterm><primary>CUPS</primary></indexterm> +CUPS users, be warned: do not just jump on to the next chapter. You might miss important information only found here! +</para></important> + +<para> +<indexterm><primary>print configuration</primary></indexterm> +<indexterm><primary>problematic print</primary></indexterm> +<indexterm><primary>print processing</primary></indexterm> +<indexterm><primary>print filtering</primary></indexterm> +It is apparent from postings on the Samba mailing list that print configuration is one of the most problematic +aspects of Samba administration today. Many new Samba administrators have the impression that Samba performs +some sort of print processing. Rest assured, Samba does not perform any type of print processing. It does not +do any form of print filtering. +</para> + +<para> +<indexterm><primary>data stream</primary></indexterm> +<indexterm><primary>local spool area</primary></indexterm> +<indexterm><primary>spooled file</primary></indexterm> +<indexterm><primary>local system printing</primary></indexterm> +Samba obtains from its clients a data stream (print job) that it spools to a local spool area. When the entire +print job has been received, Samba invokes a local UNIX/Linux print command and passes the spooled file to it. +It is up to the local system printing subsystems to correctly process the print job and to submit it to the +printer. +</para> + +<sect2> +<title>Client to Samba Print Job Processing</title> + +<para> +Successful printing from a Windows client via a Samba print server to a UNIX +printer involves six (potentially seven) stages: +</para> + +<orderedlist> + <listitem><para>Windows opens a connection to the printer share.</para></listitem> + + <listitem><para>Samba must authenticate the user.</para></listitem> + + <listitem><para>Windows sends a copy of the print file over the network + into Samba's spooling area.</para></listitem> + + <listitem><para>Windows closes the connection.</para></listitem> + + <listitem><para>Samba invokes the print command to hand the file over + to the UNIX print subsystem's spooling area.</para></listitem> + + <listitem><para>The UNIX print subsystem processes the print job.</para></listitem> + + <listitem><para>The print file may need to be explicitly deleted + from the Samba spooling area. This item depends on your print spooler + configuration settings.</para></listitem> +</orderedlist> +</sect2> + +<sect2> +<title>Printing-Related Configuration Parameters</title> + +<para> +<indexterm><primary>global-level</primary></indexterm> +<indexterm><primary>service-level</primary></indexterm> +<indexterm><primary>printing behavior</primary></indexterm> +There are a number of configuration parameters to control Samba's printing behavior. Please refer to the man +page for &smb.conf; for an overview of these. As with other parameters, there are global-level (tagged with a +<emphasis>G</emphasis> in the listings) and service-level (<emphasis>S</emphasis>) parameters. +</para> + +<variablelist> + <varlistentry><term>Global Parameters</term> + <listitem><para> These <emphasis>may not</emphasis> go into + individual share definitions. If they go in by error, + the <command>testparm</command> utility can discover this + (if you run it) and tell you so. + </para></listitem> + </varlistentry> + + <varlistentry><term>Service-Level Parameters</term> + <listitem><para> These may be specified in the + <smbconfsection name="[global]"/> section of &smb.conf;. + In this case they define the default behavior of all individual + or service-level shares (provided they do not have a different + setting defined for the same parameter, thus overriding the + global default). + </para></listitem> + </varlistentry> +</variablelist> +</sect2> + +</sect1> + +<sect1> +<title>Simple Print Configuration</title> + +<para> +<indexterm><primary>BSD Printing</primary></indexterm> +<indexterm><primary>simple printing</primary></indexterm> +<indexterm><primary>enables clients to print</primary></indexterm> +<indexterm><primary>print environment</primary></indexterm> +<link linkend="simpleprc">Simple Configuration with BSD Printing</link> shows a simple printing configuration. +If you compare this with your own, you may find additional parameters that have been preconfigured by your OS +vendor. Following is a discussion and explanation of the parameters. This example does not use many +parameters. However, in many environments these are enough to provide a valid &smb.conf; file that enables +all clients to print. +</para> + +<example id="simpleprc"> +<title>Simple Configuration with BSD Printing</title> +<smbconfblock> +<smbconfsection name="[global]"/> +<smbconfoption name="printing">bsd</smbconfoption> +<smbconfoption name="load printers">yes</smbconfoption> + +<smbconfsection name="[printers]"/> +<smbconfoption name="path">/var/spool/samba</smbconfoption> +<smbconfoption name="printable">yes</smbconfoption> +<smbconfoption name="public">yes</smbconfoption> +<smbconfoption name="writable">no</smbconfoption> +</smbconfblock> +</example> + +<para> +<indexterm><primary>testparm</primary></indexterm> +<indexterm><primary>misconfigured settings</primary></indexterm> +<indexterm><primary>pager program</primary></indexterm> +This is only an example configuration. Samba assigns default values to all configuration parameters. The +defaults are conservative and sensible. When a parameter is specified in the &smb.conf; file, this overwrites +the default value. The <command>testparm</command> utility when run as root is capable of reporting all +settings, both default as well as &smb.conf; file settings. <command>Testparm</command> gives warnings for all +misconfigured settings. The complete output is easily 360 lines and more, so you may want to pipe it through a +pager program. +</para> + +<para> +<indexterm><primary>configuration syntax</primary></indexterm> +<indexterm><primary>syntax tolerates spelling errors</primary></indexterm> +<indexterm><primary>case-insensitive</primary></indexterm> +The syntax for the configuration file is easy to grasp. You should know that is not very picky about its +syntax. As has been explained elsewhere in this book, Samba tolerates some spelling errors (such as +<smbconfoption name="browseable"/> instead of <smbconfoption name="browsable"/>), and spelling is +case-insensitive. It is permissible to use <parameter>Yes/No</parameter> or <parameter>True/False</parameter> +for Boolean settings. Lists of names may be separated by commas, spaces, or tabs. +</para> + +<sect2> +<title>Verifying Configuration with <command>testparm</command></title> + +<para> +<indexterm><primary>printing-related settings</primary></indexterm> +<indexterm><primary>lp</primary></indexterm> +<indexterm><primary>print</primary></indexterm> +<indexterm><primary>spool</primary></indexterm> +<indexterm><primary>driver</primary></indexterm> +<indexterm><primary>ports</primary></indexterm> +<indexterm><primary>testparm</primary></indexterm> +<indexterm><primary>smbd</primary></indexterm> +<indexterm><primary>print configuration</primary></indexterm> +<indexterm><primary>printer shares </primary></indexterm> +<indexterm><primary>spooling path</primary></indexterm> +To see all (or at least most) printing-related settings in Samba, including the implicitly used ones, try the +command outlined below. This command greps for all occurrences of <constant>lp</constant>, +<constant>print</constant>, <constant>spool</constant>, <constant>driver</constant>, +<constant>ports</constant>, and <constant>[</constant> in <command>testparm</command>'s output. This provides +a convenient overview of the running <command>smbd</command> print configuration. This command does not show +individually created printer shares or the spooling paths they may use. Here is the output of my Samba setup, +with settings shown in <link linkend="simpleprc">the example above</link>: +<screen> +&rootprompt;<userinput>testparm -s -v | egrep "(lp|print|spool|driver|ports|\[)"</userinput> + Load smb config files from /etc/samba/smb.conf + Processing section "[homes]" + Processing section "[printers]" + + [global] + smb ports = 139 445 + lpq cache time = 10 + load printers = Yes + printcap name = /etc/printcap + disable spoolss = No + enumports command = + addprinter command = + deleteprinter command = + show add printer wizard = Yes + os2 driver map = + printer admin = + min print space = 0 + max print jobs = 1000 + printable = No + printing = bsd + print command = lpr -r -P'%p' %s + lpq command = lpq -P'%p' + lprm command = lprm -P'%p' %j + lppause command = + lpresume command = + printer name = + use client driver = No + + [homes] + + [printers] + path = /var/spool/samba + printable = Yes +</screen> +</para> + +<para> +You can easily verify which settings were implicitly added by Samba's default behavior. <emphasis>Remember: it +may be important in your future dealings with Samba.</emphasis> +</para> + +<note><para> +The <command>testparm</command> in Samba-3 behaves differently from that in 2.2.x: used without the +<quote>-v</quote> switch, it only shows you the settings actually written into! To see the complete +configuration used, add the <quote>-v</quote> parameter to testparm. +</para></note> + +</sect2> + +<sect2> +<title>Rapid Configuration Validation</title> + +<para> +<indexterm><primary>troubleshoot</primary></indexterm> +<indexterm><primary>testparm</primary></indexterm> +<indexterm><primary>parameters</primary></indexterm> +<indexterm><primary>verify</primary></indexterm> +Should you need to troubleshoot at any stage, please always come back to this point first and verify if +<command>testparm</command> shows the parameters you expect. To give you a warning from personal experience, +try to just comment out the <smbconfoption name="load printers"/> parameter. If your 2.2.x system behaves like +mine, you'll see this: +</para> + +<para><screen> +&rootprompt;grep "load printers" /etc/samba/smb.conf + # load printers = Yes + # This setting is commented out!! + +&rootprompt;testparm -v /etc/samba/smb.conf | egrep "(load printers)" + load printers = Yes +</screen></para> + +<para> +<indexterm><primary>commenting out setting</primary></indexterm> +<indexterm><primary>publishing printers</primary></indexterm> +I assumed that commenting out of this setting should prevent Samba from +publishing my printers, but it still did. It took some time to figure out +the reason. But I am no longer fooled ... at least not by this. +<screen> +&rootprompt;<userinput>grep -A1 "load printers" /etc/samba/smb.conf</userinput> + load printers = No + # The above setting is what I want! + # load printers = Yes + # This setting is commented out! + +&rootprompt;<userinput>testparm -s -v smb.conf.simpleprinting | egrep "(load printers)"</userinput> + load printers = No +</screen></para> + +<para> +<indexterm><primary>explicitly set</primary></indexterm> +Only when the parameter is explicitly set to <smbconfoption name="load printers">No</smbconfoption> would +Samba conform with my intentions. So, my strong advice is: +</para> + +<itemizedlist> + <listitem><para>Never rely on commented-out parameters.</para></listitem> + + <listitem><para>Always set parameters explicitly as you intend them to + behave.</para></listitem> + + <listitem><para>Use <command>testparm</command> to uncover hidden + settings that might not reflect your intentions.</para></listitem> +</itemizedlist> + +<para> +The following is the most minimal configuration file: +<screen> +&rootprompt;<userinput>cat /etc/samba/smb.conf-minimal</userinput> + [printers] +</screen></para> + +<para> +<indexterm><primary>testparm</primary></indexterm> +<indexterm><primary>smbd</primary></indexterm> +This example should show that you can use <command>testparm</command> to test any Samba configuration file. +Actually, we encourage you <emphasis>not</emphasis> to change your working system (unless you know exactly +what you are doing). Don't rely on the assumption that changes will only take effect after you restart smbd! +This is not the case. Samba rereads it every 60 seconds and on each new client connection. You might have to +face changes for your production clients that you didn't intend to apply. You will now note a few more +interesting things; <command>testparm</command> is useful to identify what the Samba print configuration would +be if you used this minimalistic configuration. Here is what you can expect to find: +<screen> +&rootprompt;<userinput>testparm -v smb.conf-minimal | egrep "(print|lpq|spool|driver|ports|[)"</userinput> + Processing section "[printers]" + WARNING: [printers] service MUST be printable! + No path in service printers - using /tmp + + lpq cache time = 10 + load printers = Yes + printcap name = /etc/printcap + disable spoolss = No + enumports command = + addprinter command = + deleteprinter command = + show add printer wizard = Yes + os2 driver map = + printer admin = + min print space = 0 + max print jobs = 1000 + printable = No + printing = bsd + print command = lpr -r -P%p %s + lpq command = lpq -P%p + printer name = + use client driver = No + + [printers] + printable = Yes +</screen></para> + +<para> +<command>testparm</command> issued two warnings: +</para> + +<itemizedlist> + <listitem><para>We did not specify the <smbconfsection name="[printers]"/> section as printable.</para></listitem> + <listitem><para>We did not tell Samba which spool directory to use.</para></listitem> +</itemizedlist> + +<para> +<indexterm><primary>compile-time options</primary></indexterm> +<indexterm><primary></primary></indexterm> +<indexterm><primary></primary></indexterm> +<indexterm><primary></primary></indexterm> +However, this was not fatal, and Samba will default to values that will work. Please, do not rely on this and +do not use this example. This was included to encourage you to be careful to design and specify your setup to +do precisely what you require. The outcome on your system may vary for some parameters given, since Samba may +have been built with different compile-time options. <emphasis>Warning:</emphasis> do not put a comment sign +<emphasis>at the end</emphasis> of a valid line. It will cause the parameter to be ignored (just as if you had +put the comment sign at the front). At first I regarded this as a bug in my Samba versions. But the man page +clearly says: <literal>Internal whitespace in a parameter value is retained verbatim.</literal> This means +that a line consisting of, for example, +<smbconfblock> +<smbconfcomment>This defines LPRng as the printing system</smbconfcomment> +<smbconfoption name="printing"> lprng</smbconfoption> +</smbconfblock> +</para> + +<para> +will regard the whole of the string after the <literal>=</literal> sign as the value you want to define. This +is an invalid value that will be ignored, and a default value will be used in its place. +</para> + +</sect2> + +</sect1> + +<sect1> +<title>Extended Printing Configuration</title> + +<para> +<indexterm><primary>Extended BSD Printing</primary></indexterm> +<indexterm><primary>BSD-style printing</primary></indexterm> +<indexterm><primary>CUPS</primary></indexterm> +<indexterm><primary>testparm</primary></indexterm> +<link linkend="extbsdpr">Extended BSD Printing Configuration</link> shows a more verbose configuration for +print-related settings in a BSD-style printing environment. What follows is a discussion and explanation of +the various parameters. We chose to use BSD-style printing here because it is still the most commonly used +system on legacy UNIX/Linux installations. New installations predominantly use CUPS, which is discussed in a +separate chapter. The example explicitly names many parameters that do not need to be specified because they +are set by default. You could use a much leaner &smb.conf; file, or you can use <command>testparm</command> or +<command>SWAT</command> to optimize the &smb.conf; file to remove all parameters that are set at default. +</para> + +<example id="extbsdpr"> +<title>Extended BSD Printing Configuration</title> +<smbconfblock> +<smbconfsection name="[global]"/> +<smbconfoption name="printing">bsd</smbconfoption> +<smbconfoption name="load printers">yes</smbconfoption> +<smbconfoption name="show add printer wizard">yes</smbconfoption> +<smbconfoption name="printcap name">/etc/printcap</smbconfoption> +<smbconfoption name="printer admin">@ntadmin, root</smbconfoption> +<smbconfoption name="max print jobs">100</smbconfoption> +<smbconfoption name="lpq cache time">20</smbconfoption> +<smbconfoption name="use client driver">no</smbconfoption> + +<smbconfsection name="[printers]"/> +<smbconfoption name="comment">All Printers</smbconfoption> +<smbconfoption name="printable">yes</smbconfoption> +<smbconfoption name="path">/var/spool/samba</smbconfoption> +<smbconfoption name="browseable">no</smbconfoption> +<smbconfoption name="guest ok">yes</smbconfoption> +<smbconfoption name="public">yes</smbconfoption> +<smbconfoption name="read only">yes</smbconfoption> +<smbconfoption name="writable">no </smbconfoption> + +<smbconfsection name="[my_printer_name]"/> +<smbconfoption name="comment">Printer with Restricted Access</smbconfoption> +<smbconfoption name="path">/var/spool/samba_my_printer</smbconfoption> +<smbconfoption name="printer admin">kurt</smbconfoption> +<smbconfoption name="browseable">yes</smbconfoption> +<smbconfoption name="printable">yes</smbconfoption> +<smbconfoption name="writable">no</smbconfoption> +<smbconfoption name="hosts allow">0.0.0.0</smbconfoption> +<smbconfoption name="hosts deny">turbo_xp, 10.160.50.23, 10.160.51.60</smbconfoption> +<smbconfoption name="guest ok">no</smbconfoption> +</smbconfblock></example> + +<para> +<indexterm><primary></primary></indexterm> +<indexterm><primary></primary></indexterm> +<indexterm><primary></primary></indexterm> +This is an example configuration. You may not find all the settings that are in the configuration file that +was provided by the OS vendor. Samba configuration parameters, if not explicitly set, default to a sensible +value. To see all settings, as <constant>root</constant> use the <command>testparm</command> utility. +<command>testparm</command> gives warnings for misconfigured settings. +</para> + +<sect2> +<title>Detailed Explanation Settings</title> + +<para> +The following is a discussion of the settings from <link linkend="extbsdpr">Extended BSD Printing +Configuration</link> <link linkend="extbsdpr">Extended BSD Printing Configuration</link>. +</para> + +<sect3> +<title>The [global] Section</title> + +<para> +<indexterm><primary>global section</primary></indexterm> +<indexterm><primary>special sections</primary></indexterm> +<indexterm><primary>individual section</primary></indexterm> +<indexterm><primary>share</primary></indexterm> +The <smbconfsection name="[global]"/> section is one of four special sections (along with <smbconfsection +name="[homes]"/>, <smbconfsection name="[printers]"/>, and <smbconfsection name="[print$]"/>). The +<smbconfsection name="[global]"/> contains all parameters that apply to the server as a whole. It is the place +for parameters that have only a global meaning. It may also contain service-level parameters that define +default settings for all other sections and shares. This way you can simplify the configuration and avoid +setting the same value repeatedly. (Within each individual section or share, you may, however, override these +globally set share settings and specify other values). +</para> + +<variablelist> + <varlistentry><term><smbconfoption name="printing">bsd </smbconfoption></term> + <listitem><para> +<indexterm><primary>default print commands</primary></indexterm> +<indexterm><primary>RFC 1179</primary></indexterm> +<indexterm><primary>printing</primary></indexterm> +<indexterm><primary>CUPS</primary></indexterm> +<indexterm><primary>LPD</primary></indexterm> +<indexterm><primary>LPRNG</primary></indexterm> +<indexterm><primary>SYSV</primary></indexterm> +<indexterm><primary>HPUX</primary></indexterm> +<indexterm><primary>AIX</primary></indexterm> +<indexterm><primary>QNX</primary></indexterm> +<indexterm><primary>PLP</primary></indexterm> +<indexterm><primary>queue control</primary></indexterm> + Causes Samba to use default print commands applicable for the BSD (also known as RFC 1179 style or LPR/LPD) + printing system. In general, the <parameter>printing</parameter> parameter informs Samba about the print + subsystem it should expect. Samba supports CUPS, LPD, LPRNG, SYSV, HPUX, AIX, QNX, and PLP. Each of these + systems defaults to a different <smbconfoption name="print command"/> (and other queue control commands). + </para> + + <caution><para> +<indexterm><primary>service-level</primary></indexterm> +<indexterm><primary>SOFTQ printing system</primary></indexterm> + The <smbconfoption name="printing"/> parameter is normally a service-level parameter. Since it is included + here in the <smbconfsection name="[global]"/> section, it will take effect for all printer shares that are not + defined differently. Samba-3 no longer supports the SOFTQ printing system. + </para></caution> + </listitem></varlistentry> + + <varlistentry><term><smbconfoption name="load printers">yes </smbconfoption></term> + <listitem><para> +<indexterm><primary>printer shares</primary></indexterm> +<indexterm><primary>printcap</primary></indexterm> +<indexterm><primary>separate shares</primary></indexterm> +<indexterm><primary>UNIX printer</primary></indexterm> + Tells Samba to create automatically all available printer shares. Available printer shares are discovered by + scanning the printcap file. All created printer shares are also loaded for browsing. If you use this + parameter, you do not need to specify separate shares for each printer. Each automatically created printer + share will clone the configuration options found in the <smbconfsection name="[printers]"/> section. (The + <parameter>load printers = no</parameter> setting will allow you to specify each UNIX printer you want to + share separately, leaving out some you do not want to be publicly visible and available). + </para> + </listitem></varlistentry> + + <varlistentry><term><smbconfoption name="show add printer wizard">yes </smbconfoption></term> + <listitem><para> +<indexterm><primary>Add Printer Wizard</primary></indexterm> +<indexterm><primary>Printers</primary></indexterm> +<indexterm><primary>Network Neighborhood</primary></indexterm> +<indexterm><primary>net view</primary></indexterm> +<indexterm><primary>uploaded driver</primary></indexterm> + Setting is normally enabled by default (even if the parameter is not specified in &smb.conf;). It causes the + <guiicon>Add Printer Wizard</guiicon> icon to appear in the <guiicon>Printers</guiicon> folder of the Samba + host's share listing (as shown in <guiicon>Network Neighborhood</guiicon> or by the <command>net + view</command> command). To disable it, you need to explicitly set it to <constant>no</constant> (commenting + it out will not suffice). The <parameter>Add Printer Wizard</parameter> lets you upload a printer driver to + the <smbconfsection name="[print$]"/> share and associate it with a printer (if the respective queue exists + before the action), or exchange a printer's driver for any other previously uploaded driver. + </para> + </listitem></varlistentry> + + <varlistentry><term><smbconfoption name="max print jobs">100 </smbconfoption></term> + <listitem><para> +<indexterm><primary>print jobs</primary></indexterm> + Sets the upper limit to 100 print jobs being active on the Samba server at any one time. Should a client + submit a job that exceeds this number, a "no more space available on server" type of error message will be + returned by Samba to the client. A setting of zero (the default) means there is <emphasis>no</emphasis> limit + at all. + </para> + </listitem></varlistentry> + + <varlistentry><term><smbconfoption name="printcap name">/etc/printcap </smbconfoption></term> + <listitem><para> +<indexterm><primary>CUPS</primary></indexterm> +<indexterm><primary>available printerd</primary></indexterm> +<indexterm><primary>printcap</primary></indexterm> + Tells Samba where to look for a list of available printer names. Where CUPS is used, make sure that a printcap + file is written. This is controlled by the <constant>Printcap</constant> directive in the + <filename>cupsd.conf</filename> file. + </para></listitem></varlistentry> + + <varlistentry><term><smbconfoption name="printer admin">@ntadmin </smbconfoption></term> + <listitem><para> +<indexterm><primary>add drivers</primary></indexterm> +<indexterm><primary>/etc/group</primary></indexterm> +<indexterm><primary>printer share</primary></indexterm> +<indexterm><primary>set printer properties</primary></indexterm> + Members of the ntadmin group should be able to add drivers and set printer properties + (<constant>ntadmin</constant> is only an example name; it needs to be a valid UNIX group name); root is + implicitly always a <smbconfoption name="printer admin"/>. The <literal>@</literal> sign precedes group names + in the <filename>/etc/group</filename>. A printer admin can do anything to printers via the remote + administration interfaces offered by MS-RPC (see <link linkend="cups-msrpc">Printing Developments Since + Samba-2.2</link>). In larger installations, the <smbconfoption name="printer admin"/> parameter is normally a + per-share parameter. This permits different groups to administer each printer share. + </para></listitem></varlistentry> + + <varlistentry><term><smbconfoption name="lpq cache time">20 </smbconfoption></term> + <listitem><para> +<indexterm><primary>lpq command</primary></indexterm> +<indexterm><primary>lpq cache time</primary></indexterm> + Controls the cache time for the results of the lpq command. It prevents the lpq command being called too often + and reduces the load on a heavily used print server. + </para></listitem></varlistentry> + + <varlistentry><term><smbconfoption name="use client driver">no </smbconfoption></term> + <listitem><para> +<indexterm><primary>Windows NT/200x/XP</primary></indexterm> + If set to <constant>yes</constant>, only takes effect for Windows NT/200x/XP clients (and not for Win + 95/98/ME). Its default value is <constant>No</constant> (or <constant>False</constant>). It must + <emphasis>not</emphasis> be enabled on print shares (with a <constant>yes</constant> or + <constant>true</constant> setting) that have valid drivers installed on the Samba server. For more detailed + explanations, see the &smb.conf; man page. + </para></listitem></varlistentry> +</variablelist> + +</sect3> + +<sect3 id="ptrsect"> +<title>The [printers] Section</title> + +<para> +<indexterm><primary>printers section</primary></indexterm> +<indexterm><primary>printcap</primary></indexterm> +The printers section is the second special section. If a section with this name appears in the &smb.conf;, +users are able to connect to any printer specified in the Samba host's printcap file, because Samba on startup +then creates a printer share for every printer name it finds in the printcap file. You could regard this +section as a convenient shortcut to share all printers with minimal configuration. It is also a container for +settings that should apply as default to all printers. (For more details, see the &smb.conf; man page.) +Settings inside this container must be share-level parameters. +</para> + +<variablelist> + <varlistentry><term><smbconfoption name="comment">All printers </smbconfoption></term> + <listitem><para> + The <smbconfoption name="comment"/> is shown next to the share if + a client queries the server, either via <guiicon>Network Neighborhood</guiicon> or with + the <command>net view</command> command, to list available shares. + </para></listitem> + </varlistentry> + + <varlistentry><term><smbconfoption name="printable">yes </smbconfoption></term> + <listitem><para> + The <smbconfsection name="[printers]"/> service <emphasis>must</emphasis> + be declared as printable. If you specify otherwise, smbd will refuse to load at + startup. This parameter allows connected clients to open, write to, and submit spool files + into the directory specified with the <smbconfoption name="path"/> + parameter for this service. It is used by Samba to differentiate printer shares from + file shares. + </para></listitem> + </varlistentry> + + <varlistentry><term><smbconfoption name="path">/var/spool/samba </smbconfoption></term> + <listitem><para> + Must point to a directory used by Samba to spool incoming print files. <emphasis>It + must not be the same as the spool directory specified in the configuration of your UNIX + print subsystem!</emphasis> The path typically points to a directory that is world + writable, with the <emphasis>sticky</emphasis> bit set to it. + </para></listitem> + </varlistentry> + + <varlistentry><term><smbconfoption name="browseable">no </smbconfoption></term> + <listitem><para> + Is always set to <constant>no</constant> if + <smbconfoption name="printable">yes</smbconfoption>. It makes + the <smbconfsection name="[printer]"/> share itself invisible in the list of + available shares in a <command>net view</command> command or in the Explorer browse + list. (You will of course see the individual printers.) + </para></listitem> + </varlistentry> + + <varlistentry><term><smbconfoption name="guest ok">yes </smbconfoption></term> + <listitem><para> + If this parameter is set to <constant>yes</constant>, no password is required to + connect to the printer's service. Access will be granted with the privileges of the + <smbconfoption name="guest account"/>. On many systems the guest + account will map to a user named "nobody." This user will usually be found + in the UNIX passwd file with an empty password, but with no valid UNIX login. On some + systems the guest account might not have the privilege to be able to print. Test this + by logging in as your guest user using <command>su - guest</command> and run a system + print command like: + </para> + + <para> + <userinput>lpr -P printername /etc/motd</userinput> + </para></listitem> + </varlistentry> + + <varlistentry><term><smbconfoption name="public">yes </smbconfoption></term> + <listitem><para> + Is a synonym for <smbconfoption name="guest ok">yes</smbconfoption>. + Since we have <smbconfoption name="guest ok">yes</smbconfoption>, it + really does not need to be here. (This leads to the interesting question, <quote>What if I + by accident have two contradictory settings for the same share?</quote> The answer is that the + last one encountered by Samba wins. <command>testparm</command> does not complain about different settings + of the same parameter for the same share. You can test this by setting up multiple + lines for the <parameter>guest account</parameter> parameter with different usernames, + and then run testparm to see which one is actually used by Samba.) + </para></listitem> + </varlistentry> + + <varlistentry><term><smbconfoption name="read only">yes </smbconfoption></term> + <listitem><para> + Normally (for other types of shares) prevents users from creating or modifying files + in the service's directory. However, in a <emphasis>printable</emphasis> service, it is + <emphasis>always</emphasis> allowed to write to the directory (if user privileges allow the + connection), but only via print spooling operations. Normal write operations are not permitted. + </para></listitem> + </varlistentry> + + <varlistentry><term><smbconfoption name="writable">no </smbconfoption></term> + <listitem><para> + Is a synonym for <smbconfoption name="read only">yes</smbconfoption>. + </para></listitem> + </varlistentry> +</variablelist> +</sect3> + +<sect3> +<title>Any [my_printer_name] Section</title> + +<para> +<indexterm><primary>loading printer drivers</primary></indexterm> +<indexterm><primary>name conflict</primary></indexterm> +If a <parameter>[my_printer_name]</parameter> section appears in the &smb.conf; file, which includes the +parameter <smbconfoption name="printable">yes</smbconfoption> Samba will configure it as a printer share. +Windows 9x/Me clients may have problems with connecting or loading printer drivers if the share name has more +than eight characters. Do not name a printer share with a name that may conflict with an existing user or file +share name. On client connection requests, Samba always tries to find file shares with that name first. If it +finds one, it will connect to this and will not connect to a printer with the same name! +</para> + +<?latex \newpage ?> +<variablelist> + <varlistentry><term><smbconfoption name="comment">Printer with Restricted Access </smbconfoption></term> + <listitem><para> + The comment says it all. + </para></listitem> + </varlistentry> + + <varlistentry><term><smbconfoption name="path">/var/spool/samba_my_printer </smbconfoption></term> + <listitem><para> + Sets the spooling area for this printer to a directory other than the default. It is not + necessary to set it differently, but the option is available. + </para></listitem> + </varlistentry> + + <varlistentry><term><smbconfoption name="printer admin">kurt </smbconfoption></term> + <listitem><para> + The printer admin definition is different for this explicitly defined printer share from the general + <smbconfsection name="[printers]"/> share. It is not a requirement; we did it to show that it is possible. + </para></listitem> + </varlistentry> + + <varlistentry><term><smbconfoption name="browseable">yes </smbconfoption></term> + <listitem><para> + This makes the printer browseable so the clients may conveniently find it when browsing the + <guiicon>Network Neighborhood</guiicon>. + </para></listitem> + </varlistentry> + + <varlistentry><term><smbconfoption name="printable">yes </smbconfoption></term> + <listitem><para> + See <link linkend="ptrsect">Section 20.4.1.2</link>. + </para></listitem> + </varlistentry> + + <varlistentry><term><smbconfoption name="writable">no </smbconfoption></term> + <listitem><para> + See <link linkend="ptrsect">Section 20.4.1.2</link>. + </para></listitem> + </varlistentry> + + <varlistentry><term><smbconfoption name="hosts allow">10.160.50.,10.160.51. </smbconfoption></term> + <listitem><para> + Here we exercise a certain degree of access control by using the <smbconfoption name="hosts allow"/> + and <smbconfoption name="hosts deny"/> parameters. This is not by any means a safe bet. It is not a + way to secure your printers. This line accepts all clients from a certain subnet in a first evaluation of + access control. + </para></listitem> + </varlistentry> + + <varlistentry><term><smbconfoption name="hosts deny">turbo_xp,10.160.50.23,10.160.51.60 </smbconfoption></term> + <listitem><para> + All listed hosts are not allowed here (even if they belong to the allowed subnets). As + you can see, you could name IP addresses as well as NetBIOS hostnames here. + </para></listitem> + </varlistentry> + + <varlistentry><term><smbconfoption name="guest ok">no </smbconfoption></term> + <listitem><para> + This printer is not open for the guest account. + </para></listitem> + </varlistentry> +</variablelist> +</sect3> + +<sect3> +<title>Print Commands</title> + +<para> +<indexterm><primary>print command</primary></indexterm> +<indexterm><primary>print subsystem</primary></indexterm> +<indexterm><primary>temporary location</primary></indexterm> +<indexterm><primary>shell scripts</primary></indexterm> +In each section defining a printer (or in the <smbconfsection name="[printers]"/> section), +a <parameter>print command</parameter> parameter may be defined. It sets a command to process the files +that have been placed into the Samba print spool directory for that printer. (That spool directory was, +if you remember, set up with the <smbconfoption name="path"/> parameter). Typically, +this command will submit the spool file to the Samba host's print subsystem, using the suitable system +print command. But there is no requirement that this needs to be the case. For debugging or +some other reason, you may want to do something completely different than print the file. An example is a +command that just copies the print file to a temporary location for further investigation when you need +to debug printing. If you craft your own print commands (or even develop print command shell scripts), +make sure you pay attention to the need to remove the files from the Samba spool directory. Otherwise, +your hard disk may soon suffer from shortage of free space. +</para> +</sect3> + +<sect3> +<title>Default UNIX System Printing Commands</title> + +<para> +<indexterm><primary>default print command</primary></indexterm> +You learned earlier that Samba, in most cases, uses its built-in settings for many parameters if it cannot +find an explicitly stated one in its configuration file. The same is true for the <smbconfoption name="print +command"/>. The default print command varies depending on the <smbconfoption name="printing"/> parameter +setting. In the commands listed in <link linkend="printOptions">Default Printing Settings</link> , you will +notice some parameters of the form <emphasis>%X</emphasis> where <emphasis>X</emphasis> is <emphasis>p, s, +J</emphasis>, and so on. These letters stand for printer name, spool file, and job ID, respectively. They are +explained in more detail in <link linkend="printOptions">Default Printing Settings</link> presents an overview +of key printing options but excludes the special case of CUPS, is discussed in <link +linkend="CUPS-printing">CUPS Printing Support</link>. +</para> + +<table frame='all' id="printOptions"> + <title>Default Printing Settings</title> + <tgroup cols='2' align='left' colsep='1' rowsep='1'> + <colspec align="left"/> + <colspec align="left"/> + <thead> + <row> + <entry>Setting</entry> + <entry>Default Printing Commands</entry> + </row> + </thead> + <tbody> + <row> + <entry><smbconfoption name="printing">bsd|aix|lprng|plp</smbconfoption></entry> + <entry>print command is <command>lpr -r -P%p %s</command></entry> + </row> + <row> + <entry><smbconfoption name="printing">sysv|hpux</smbconfoption></entry> + <entry>print command is <command>lp -c -P%p %s; rm %s</command></entry> + </row> + <row> + <entry> <smbconfoption name="printing">qnx</smbconfoption></entry> + <entry>print command is <command>lp -r -P%p -s %s</command></entry> + </row> + <row> + <entry><smbconfoption name="printing">bsd|aix|lprng|plp</smbconfoption></entry> + <entry>lpq command is <command>lpq -P%p</command></entry> + </row> + <row> + <entry><smbconfoption name="printing">sysv|hpux</smbconfoption></entry> + <entry>lpq command is <command>lpstat -o%p</command></entry> + </row> + <row> + <entry><smbconfoption name="printing">qnx</smbconfoption></entry> + <entry>lpq command is <command>lpq -P%p</command></entry> + </row> + <row> + <entry><smbconfoption name="printing">bsd|aix|lprng|plp</smbconfoption></entry> + <entry>lprm command is <command>lprm -P%p %j</command></entry> + </row> + <row> + <entry><smbconfoption name="printing">sysv|hpux</smbconfoption></entry> + <entry>lprm command is <command>cancel %p-%j</command></entry> + </row> + <row> + <entry><smbconfoption name="printing">qnx</smbconfoption></entry> + <entry>lprm command is <command>cancel %p-%j</command></entry> + </row> + <row> + <entry><smbconfoption name="printing">bsd|aix|lprng|plp</smbconfoption></entry> + <entry>lppause command is <command>lp -i %p-%j -H hold</command></entry> + </row> + <row> + <entry><smbconfoption name="printing">sysv|hpux</smbconfoption></entry> + <entry>lppause command (...is empty)</entry> + </row> + <row> + <entry><smbconfoption name="printing">qnx</smbconfoption></entry> + <entry>lppause command (...is empty)</entry> + </row> + <row> + <entry><smbconfoption name="printing">bsd|aix|lprng|plp</smbconfoption></entry> + <entry>lpresume command is <command>lp -i %p-%j -H resume</command></entry> + </row> + <row> + <entry><smbconfoption name="printing">sysv|hpux</smbconfoption></entry> + <entry>lpresume command (...is empty)</entry> + </row> + <row> + <entry><smbconfoption name="printing">qnx</smbconfoption></entry> + <entry>lpresume command (...is empty)</entry> + </row> + </tbody> + </tgroup> +</table> + +<para> +<indexterm><primary>CUPS API</primary></indexterm> +<indexterm><primary>cupsd.conf</primary></indexterm> +<indexterm><primary>autogenerated printcap</primary></indexterm> +<indexterm><primary>libcups</primary></indexterm> +For <parameter>printing = CUPS</parameter>, if Samba is compiled against libcups, it uses the CUPS API to +submit jobs. (It is a good idea also to set <smbconfoption name="printcap">cups</smbconfoption> in case your +<filename>cupsd.conf</filename> is set to write its autogenerated printcap file to an unusual place). +Otherwise, Samba maps to the System V printing commands with the -oraw option for printing; that is, it uses +<command>lp -c -d%p -oraw; rm %s</command>. With <parameter>printing = cups</parameter>, and if Samba is +compiled against libcups, any manually set print command will be ignored! +</para> + +</sect3> + +<sect3> +<title>Custom Print Commands</title> + +<para> +<indexterm><primary>print job</primary></indexterm> +<indexterm><primary>spooling</primary></indexterm> +After a print job has finished spooling to a service, the <smbconfoption name="print command"/> will be used +by Samba via a system() call to process the spool file. Usually the command specified will submit the spool +file to the host's printing subsystem. But there is no requirement at all that this must be the case. The +print subsystem may not remove the spool file on its own, so whatever command you specify, you should ensure +that the spool file is deleted after it has been processed. +</para> + +<para> +<indexterm><primary>traditional printing</primary></indexterm> +<indexterm><primary>customized print commands</primary></indexterm> +<indexterm><primary>built-in commands</primary></indexterm> +<indexterm><primary>macros</primary></indexterm> +There is no difficulty with using your own customized print commands with the traditional printing systems. +However, if you do not wish to roll your own, you should be well informed about the default built-in commands +that Samba uses for each printing subsystem (see <link linkend="printOptions">Default Printing +Settings</link>). In all the commands listed in the last paragraphs, you see parameters of the form +<emphasis>%X</emphasis>. These are <emphasis>macros</emphasis>, or shortcuts, used as placeholders for the +names of real objects. At the time of running a command with such a placeholder, Samba will insert the +appropriate value automatically. Print commands can handle all Samba macro substitutions. In regard to +printing, the following ones do have special relevance: +</para> + +<itemizedlist> + <listitem><para><parameter>%s, %f</parameter> &smbmdash; the path to the spool file name.</para></listitem> + <listitem><para><parameter>%p</parameter> &smbmdash; the appropriate printer name.</para></listitem> + <listitem><para><parameter>%J</parameter> &smbmdash; the job name as transmitted by the client.</para></listitem> + <listitem><para><parameter>%c</parameter> &smbmdash; the number of printed pages of the spooled job (if known).</para></listitem> + <listitem><para><parameter>%z</parameter> &smbmdash; the size of the spooled print job (in bytes).</para></listitem> +</itemizedlist> + +<para> +<indexterm><primary>default printer</primary></indexterm> +The print command must contain at least one occurrence of <parameter>%s</parameter> or +<parameter>%f</parameter>. The <parameter>%p</parameter> is optional. If no printer name is supplied, +the <parameter>%p</parameter> will be silently removed from the print command. In this case, the job is +sent to the default printer. +</para> + +<para> +<indexterm><primary>global print command</primary></indexterm> +<indexterm><primary>spool files</primary></indexterm> +If specified in the <smbconfsection name="[global]"/> section, the print command given will be +used for any printable service that does not have its own print command specified. If there is neither a +specified print command for a printable service nor a global print command, spool files will be created +but not processed! Most importantly, print files will not be removed, so they will consume disk space. +</para> + +<para> +<indexterm><primary>nobody account</primary></indexterm> +<indexterm><primary>guest account</primary></indexterm> +Printing may fail on some UNIX systems when using the <emphasis>nobody</emphasis> account. If this happens, create an +alternative guest account and give it the privilege to print. Set up this guest account in the +<smbconfsection name="[global]"/> section with the <parameter>guest account</parameter> parameter. +</para> + +<para> +<indexterm><primary>environment variables</primary></indexterm> +<indexterm><primary>print commands</primary></indexterm> +<indexterm><primary>print job</primary></indexterm> +You can form quite complex print commands. You need to realize that print commands are just +passed to a UNIX shell. The shell is able to expand the included environment variables as +usual. (The syntax to include a UNIX environment variable <parameter>$variable</parameter> +in the Samba print command is <parameter>%$variable</parameter>.) To give you a working +<smbconfoption name="print command"/> example, the following will log a print job +to <filename>/tmp/print.log</filename>, print the file, then remove it. The semicolon (<quote>;</quote> +is the usual separator for commands in shell scripts: +</para> + +<para><smbconfblock> + <smbconfoption name="print command">echo Printing %s >> /tmp/print.log; lpr -P %p %s; rm %s</smbconfoption> +</smbconfblock></para> + +<para> +You may have to vary your own command considerably from this example depending on how you normally print +files on your system. The default for the <smbconfoption name="print command"/> +parameter varies depending on the setting of the <smbconfoption name="printing"/> +parameter. Another example is: +</para> + +<para><smbconfblock> +<smbconfoption name="print command">/usr/local/samba/bin/myprintscript %p %s</smbconfoption> +</smbconfblock></para> +</sect3> +</sect2> +</sect1> + +<sect1 id="cups-msrpc"> +<title>Printing Developments Since Samba-2.2</title> + +<para> +<indexterm><primary>LanMan</primary></indexterm> +<indexterm><primary>MS-RPC</primary></indexterm> +<indexterm><primary>SPOOLSS</primary></indexterm> +Prior to Samba-2.2.x, print server support for Windows clients was limited to <emphasis>LanMan</emphasis> +printing calls. This is the same protocol level as Windows 9x/Me PCs offer when they share printers. +Beginning with the 2.2.0 release, Samba started to support the native Windows NT printing mechanisms. These +are implemented via <emphasis>MS-RPC</emphasis> (Remote Procedure Calls). +MS-RPCs use the <emphasis>SPOOLSS</emphasis> named pipe for all printing. +</para> + +<para> +The additional functionality provided by the new SPOOLSS support includes: +</para> + +<itemizedlist> + <listitem><para> +<indexterm><primary>Point'n'Print</primary></indexterm> + Support for downloading printer driver files to Windows 95/98/NT/2000 clients upon + demand (<emphasis>Point'n'Print</emphasis>). + </para></listitem> + + <listitem><para> +<indexterm><primary>Add Printer Wizard</primary></indexterm> + Uploading of printer drivers via the Windows NT <emphasis>Add Printer Wizard</emphasis> (APW) + or the <ulink url="http://imprints.sourceforge.net/">Imprints</ulink> tool set. + </para></listitem> + + <listitem><para> +<indexterm><primary>MS-RPC</primary></indexterm> +<indexterm><primary>printing calls</primary></indexterm> +<indexterm><primary>StartDocPrinter</primary></indexterm> +<indexterm><primary>EnumJobs()</primary></indexterm> +<indexterm><primary>Win32 printing API</primary></indexterm> + Support for the native MS-RPC printing calls such as StartDocPrinter, EnumJobs(), and so on. (See the + <ulink url="http://msdn.microsoft.com/">MSDN documentation</ulink> for more information on the + Win32 printing API). + </para></listitem> + + <listitem><para> +<indexterm><primary>ACL</primary></indexterm> +<indexterm><primary>printer objects</primary></indexterm> + Support for NT Access Control Lists (ACL) on printer objects. + </para></listitem> + + <listitem><para> +<indexterm><primary>printer queue</primary></indexterm> + Improved support for printer queue manipulation through the use of internal databases for spooled + job information (implemented by various <filename>*.tdb</filename> files). + </para></listitem> +</itemizedlist> + +<para> +<indexterm><primary>ADS</primary></indexterm> +<indexterm><primary>LDAP</primary></indexterm> +A benefit of updating is that Samba-3 is able to publish its printers to Active Directory (or LDAP). +</para> + +<para> +<indexterm><primary>publish printers</primary></indexterm> +A fundamental difference exists between MS Windows NT print servers and Samba operation. Windows NT +permits the installation of local printers that are not shared. This is an artifact of the fact that +any Windows NT machine (server or client) may be used by a user as a workstation. Samba will publish all +printers that are made available, either by default or by specific declaration via printer-specific shares. +</para> + +<para> +<indexterm><primary>SMB</primary></indexterm> +<indexterm><primary>MS-RPC</primary></indexterm> +<indexterm><primary>Everyone group</primary></indexterm> +<indexterm><primary>privileges</primary></indexterm> +<indexterm><primary>printer default permissions</primary></indexterm> +Windows NT/200x/XP Professional clients do not have to use the standard SMB printer share; they can +print directly to any printer on another Windows NT host using MS-RPC. This, of course, assumes that +the client has the necessary privileges on the remote host that serves the printer resource. The +default permissions assigned by Windows NT to a printer gives the print permissions to the well-known +<emphasis>Everyone</emphasis> group. (The older clients of type Windows 9x/Me can only print to shared +printers.) +</para> + +<sect2> +<title>Point'n'Print Client Drivers on Samba Servers</title> + +<para> +<indexterm><primary>printer drivers</primary></indexterm> +There is much confusion about what all this means. The question is often asked, <quote>Is it or is +it not necessary for printer drivers to be installed on a Samba host in order to support printing from +Windows clients?</quote> The answer to this is no, it is not necessary. +</para> + +<para> +<indexterm><primary>install drivers</primary></indexterm> +<indexterm><primary>print queue</primary></indexterm> +Windows NT/2000 clients can, of course, also run their APW to install drivers <emphasis>locally</emphasis> +(which then connect to a Samba-served print queue). This is the same method used by Windows 9x/Me +clients. (However, a bug existed in Samba 2.2.0 that made Windows NT/2000 clients +require that the Samba server possess a valid driver for the printer. This was fixed in Samba 2.2.1). +</para> + +<para> +<indexterm><primary>printer drivers</primary></indexterm> +<indexterm><primary>uploading</primary></indexterm> +But it is a new capability to install the printer drivers into the <smbconfsection name="[print$]"/> +share of the Samba server, and a big convenience, too. Then <emphasis>all</emphasis> clients +(including 95/98/ME) get the driver installed when they first connect to this printer share. The +<emphasis>uploading</emphasis> or <emphasis>depositing</emphasis> of the driver into this +<smbconfsection name="[print$]"/> share and the following binding of this driver to an existing +Samba printer share can be achieved by different means: +</para> + +<itemizedlist> + <listitem><para> + Running the <emphasis>APW</emphasis> on an NT/200x/XP Professional client (this does not work from 95/98/ME clients). + </para></listitem> + + <listitem><para> + Using the <emphasis>Imprints</emphasis> toolset. + </para></listitem> + + <listitem><para> + Using the <emphasis>smbclient</emphasis> and <emphasis>rpcclient</emphasis> command-line tools. + </para></listitem> + + <listitem><para> + Using <emphasis>cupsaddsmb</emphasis> (only works for the CUPS printing system, not for LPR/LPD, LPRng, and so on). + </para></listitem> +</itemizedlist> + +<para> +<indexterm><primary>uploaded drivers</primary></indexterm> +<indexterm><primary>Point'n'Print</primary></indexterm> +Samba does not use these uploaded drivers in any way to process spooled files. These drivers are utilized +entirely by the clients who download and install them via the <quote>Point'n'Print</quote> mechanism +supported by Samba. The clients use these drivers to generate print files in the format the printer +(or the UNIX print system) requires. Print files received by Samba are handed over to the UNIX printing +system, which is responsible for all further processing, as needed. +</para> +</sect2> + +<sect2> +<title>The Obsoleted [printer$] Section</title> + + <para> +<indexterm><primary>printer$ share</primary></indexterm> +<indexterm><primary>printer driver</primary></indexterm> + Versions of Samba prior to 2.2 made it possible to use a share named <parameter>[printer$]</parameter>. This + name was taken from the same named service created by Windows 9x/Me clients when a printer was shared by them. + Windows 9x/Me printer servers always have a <smbconfsection name="[printer$]"/> service that provides + read-only access (with no password required) to support printer driver downloads. However, Samba's initial + implementation allowed for a parameter named <parameter>printer driver location</parameter> to be used on a + per-share basis. This specified the location of the driver files associated with that printer. Another + parameter named <parameter>printer driver</parameter> provided a means of defining the printer driver name to + be sent to the client. + </para> + + <para> +<indexterm><primary>printer driver file</primary></indexterm> +<indexterm><primary>read-write access</primary></indexterm> +<indexterm><primary>ACLs</primary></indexterm> + These parameters, including the <parameter>printer driver file</parameter> parameter, + are now removed and cannot be used in installations of Samba-3. The share name + <smbconfsection name="[print$]"/> is now used for the location of downloadable printer + drivers. It is taken from the <smbconfsection name="[print$]"/> service created + by Windows NT PCs when a printer is shared by them. Windows NT print servers always have a + <smbconfsection name="[print$]"/> service that provides read-write access (in the context + of its ACLs) to support printer driver downloads and uploads. This does not mean Windows + 9x/Me clients are now thrown aside. They can use Samba's <smbconfsection name="[print$]"/> + share support just fine. + </para> +</sect2> + +<sect2> +<title>Creating the [print$] Share</title> + +<para> +<indexterm><primary>printer driver</primary></indexterm> +In order to support the uploading and downloading of printer driver files, you must first configure a +file share named <smbconfsection name="[print$]"/>. The public name of this share is hard coded +in the MS Windows clients. It cannot be renamed, since Windows clients are programmed to search for a +service of exactly this name if they want to retrieve printer driver files. +</para> + +<para> +You should modify the server's file to add the global parameters and create the +<smbconfsection name="[print$]"/> file share (of course, some of the parameter values, such +as <smbconfoption name="path"/>, are arbitrary and should be replaced with appropriate values for your +site). See <link linkend="prtdollar">[print\$] Example</link>. +</para> + +<example id="prtdollar"> +<title>[print$] Example</title> +<smbconfblock> +<smbconfsection name="[global]"/> +<smbconfcomment>members of the ntadmin group should be able to add drivers and set</smbconfcomment> +<smbconfcomment>printer properties. root is implicitly always a 'printer admin'.</smbconfcomment> +<smbconfoption name="printer admin">@ntadmin</smbconfoption> +<smbconfcomment>...</smbconfcomment> + +<smbconfsection name="[printers]"/> +<smbconfcomment>...</smbconfcomment> + +<smbconfsection name="[print$]"/> +<smbconfoption name="comment">Printer Driver Download Area</smbconfoption> +<smbconfoption name="path">/etc/samba/drivers</smbconfoption> +<smbconfoption name="browseable">yes</smbconfoption> +<smbconfoption name="guest ok">yes</smbconfoption> +<smbconfoption name="read only">yes</smbconfoption> +<smbconfoption name="write list">@ntadmin, root</smbconfoption> +</smbconfblock> +</example> + +<para> +Of course, you also need to ensure that the directory named by the +<smbconfoption name="path"/> parameter exists on the UNIX file system. +</para> + +</sect2> + +<sect2> +<title>[print$] Stanza Parameters</title> + +<para> +<indexterm><primary>special section</primary></indexterm> +<indexterm><primary>special stanza</primary></indexterm> +<indexterm><primary>potential printer</primary></indexterm> +<indexterm><primary>driver download</primary></indexterm> +<indexterm><primary>local print driver</primary></indexterm> +The <smbconfsection name="[print$]"/> is a special section in &smb.conf;. It contains settings relevant to +potential printer driver download and is used by Windows clients for local print driver installation. +The following parameters are frequently needed in this share section: +</para> + +<variablelist> + <varlistentry><term><smbconfoption name="comment">Printer Driver Download Area </smbconfoption></term> + <listitem><para> + The comment appears next to the share name if it is listed in a share list (usually Windows + clients will not see it, but it will also appear up in a <command>smbclient -L sambaserver + </command> output). + </para></listitem> + </varlistentry> + + <varlistentry><term><smbconfoption name="path">/etc/samba/printers </smbconfoption></term> + <listitem><para> + The path to the location of the Windows driver file deposit from the UNIX point of view. + </para></listitem> + </varlistentry> + + <varlistentry><term><smbconfoption name="browseable">no </smbconfoption></term> + <listitem><para> + Makes the <smbconfsection name="[print$]"/> share invisible to clients from the + <guimenu>Network Neighborhood</guimenu>. By excuting from a <command>cmd</command> shell: +<screen> +&dosprompt; <command>net use g:\\sambaserver\print$</command> +</screen> + you can still mount it from any client. This can also be done from the + <guimenu>Connect network drive menu></guimenu> from Windows Explorer. + </para></listitem> + </varlistentry> + + <varlistentry><term><smbconfoption name="guest ok">yes </smbconfoption></term> + <listitem><para> + Gives read-only access to this share for all guest users. Access may be granted to + download and install printer drivers on clients. The requirement for <parameter>guest ok + = yes</parameter> depends on how your site is configured. If users will be guaranteed + to have an account on the Samba host, then this is a non-issue. + </para> + + <note><para> + If all your Windows NT users are guaranteed to be authenticated by the Samba server + (for example, if Samba authenticates via an NT domain server and the user has already been + validated by the domain controller in order to log on to the Windows NT session), then guest + access is not necessary. Of course, in a workgroup environment where you just want + to print without worrying about silly accounts and security, then configure the share for + guest access. You should consider adding <smbconfoption name="map to guest">Bad User</smbconfoption> + in the <smbconfsection name="[global]"/> section as well. Make sure you understand what this + parameter does before using it. + </para></note> + </listitem> + </varlistentry> + + <varlistentry><term><smbconfoption name="read only">yes </smbconfoption></term> + <listitem><para> + Because we do not want everybody to upload driver files (or even change driver settings), + we tagged this share as not writable. + </para></listitem> + </varlistentry> + + <varlistentry><term><smbconfoption name="write list">@ntadmin, root </smbconfoption></term> + <listitem><para> + The <smbconfsection name="[print$]"/> was made read-only by the previous + setting so we should create a <parameter>write list</parameter> entry also. UNIX + groups are denoted with a leading <quote>@</quote> character. Users listed here are allowed + write-access (as an exception to the general public's read-only access), which they need to + update files on the share. Normally, you will want to name only administrative-level user + account in this setting. Check the file system permissions to make sure these accounts + can copy files to the share. If this is a non-root account, then the account should also + be mentioned in the global <smbconfoption name="printer admin"/> + parameter. See the &smb.conf; man page for more information on configuring file shares. + </para></listitem> + </varlistentry> +</variablelist> + +</sect2> + +<sect2> +<title>The [print$] Share Directory</title> + +<para> +In order for a Windows NT print server to support the downloading of driver files by multiple client +architectures, you must create several subdirectories within the <smbconfsection name="[print$]"/> +service (i.e., the UNIX directory named by the <smbconfoption name="path"/> +parameter). These correspond to each of the supported client architectures. Samba follows this model as +well. Just like the name of the <smbconfsection name="[print$]"/> share itself, the subdirectories +must be exactly the names listed below (you may leave out the subdirectories of architectures you do +not need to support). +</para> + +<para> +Therefore, create a directory tree below the +<smbconfsection name="[print$]"/> share for each architecture you wish +to support like this: +<programlisting> +[print$]--+ + |--W32X86 # serves drivers to Windows NT x86 + |--WIN40 # serves drivers to Windows 95/98 + |--W32ALPHA # serves drivers to Windows NT Alpha_AXP + |--W32MIPS # serves drivers to Windows NT R4000 + |--W32PPC # serves drivers to Windows NT PowerPC +</programlisting> +</para> + +<important><title>Required Permissions</title> + <para> + In order to add a new driver to your Samba host, one of two conditions must hold true: + </para> + + <itemizedlist> + <listitem><para> + The account used to connect to the Samba host must have a UID of 0 (i.e., a root account). + </para></listitem> + + <listitem><para> + The account used to connect to the Samba host must be named in the <emphasis>printer admin</emphasis> list. + </para></listitem> + </itemizedlist> + + <para> + Of course, the connected account must still have write access to add files to the subdirectories beneath + <smbconfsection name="[print$]"/>. Remember that all file shares are set to <quote>read-only</quote> by default. + </para> +</important> + +<para> +Once you have created the required <smbconfsection name="[print$]"/> service and +associated subdirectories, go to a Windows NT 4.0/200x/XP client workstation. Open <guiicon>Network +Neighborhood</guiicon> or <guiicon>My Network Places</guiicon> and browse for the Samba host. Once you +have located the server, navigate to its <guiicon>Printers and Faxes</guiicon> folder. You should see +an initial listing of printers that matches the printer shares defined on your Samba host. +</para> +</sect2> +</sect1> + +<sect1> +<title>Installing Drivers into [print$]</title> + +<para> +Have you successfully created the <smbconfsection name="[print$]"/> share in &smb.conf;, and have you forced +Samba to reread its &smb.conf; file? Good. But you are not yet ready to use the new facility. The client +driver files need to be installed into this share. So far, it is still an empty share. Unfortunately, it is +not enough to just copy the driver files over. They need to be correctly installed so that appropriate records +for each driver will exist in the Samba internal databases so it can provide the correct drivers as they are +requested from MS Windows clients. And that is a bit tricky, to say the least. We now discuss two alternative +ways to install the drivers into <smbconfsection name="[print$]"/>: +</para> + +<itemizedlist> + <listitem><para> + Using the Samba command-line utility <command>rpcclient</command> with its various subcommands (here, + <command>adddriver</command> and <command>setdriver</command>) from any UNIX workstation. + </para></listitem> + + <listitem><para> + Running a GUI (<guiicon>Printer Properties</guiicon> and <guiicon>Add Printer Wizard</guiicon>) + from any Windows NT/200x/XP client workstation. + </para></listitem> +</itemizedlist> + +<para> +The latter option is probably the easier one (even if the process may seem a little bit weird at first). +</para> + +<sect2> +<title>Add Printer Wizard Driver Installation</title> + +<para> +The printers initially listed in the Samba host's <guiicon>Printers</guiicon> folder accessed from a +client's Explorer will have no real printer driver assigned to them. By default this driver name is set +to a null string. This must be changed now. The local <guiicon>Add Printer Wizard</guiicon> (APW), run from +NT/2000/XP clients, will help us in this task. +</para> + +<para> +Installation of a valid printer driver is not straightforward. You must attempt to view the printer properties +for the printer to which you want the driver assigned. Open Windows Explorer, open <guiicon>Network +Neighborhood</guiicon>, browse to the Samba host, open Samba's <guiicon>Printers</guiicon> folder, right-click +on the printer icon, and select <guimenu>Properties...</guimenu>. You are now trying to view printer and +driver properties for a queue that has this default <constant>NULL</constant> driver assigned. This will +result in the following error message: <quote> Device settings cannot be displayed. The driver for the +specified printer is not installed, only spooler properties will be displayed. Do you want to install the +driver now?</quote> +</para> + +<para> +Do <emphasis>not</emphasis> click on <guibutton>Yes</guibutton>! Instead, click on <guibutton>No</guibutton> +in the error dialog. Now you will be presented with the printer properties window. From here, the way to +assign a driver to a printer is open. You now have the choice of: +</para> + +<itemizedlist> + <listitem><para> + Select a driver from the pop-up list of installed drivers. Initially this list will be empty. + </para></listitem> + + <listitem><para> + Click on <guibutton>New Driver</guibutton> to install a new printer driver (which will + start up the APW). + </para></listitem> +</itemizedlist> + +<para> +Once the APW is started, the procedure is exactly the same as the one you are familiar with in Windows (we +assume here that you are familiar with the printer driver installations procedure on Windows NT). Make sure +your connection is, in fact, set up as a user with <smbconfoption name="printer admin"/> +privileges (if in doubt, use <command>smbstatus</command> to check for this). If you wish to install +printer drivers for client operating systems other than <application>Windows NT x86</application>, +you will need to use the <guilabel>Sharing</guilabel> tab of the printer properties dialog. +</para> + +<para> +Assuming you have connected with an administrative (or root) account (as named by the +<smbconfoption name="printer admin"/> parameter), you will also be able to modify +other printer properties such as ACLs and default device settings using this dialog. For the default +device settings, please consider the advice given further in <link linkend="inst-rpc">Installing +Print Drivers Using <command>rpcclient</command></link>. +</para> +</sect2> + +<sect2 id="inst-rpc"> +<title>Installing Print Drivers Using <command>rpcclient</command></title> + +<para> +The second way to install printer drivers into <smbconfsection name="[print$]"/> and set them +up in a valid way is to do it from the UNIX command line. This involves four distinct steps: +</para> + +<orderedlist> + <listitem><para> + Gather information about required driver files and collect the files. + </para></listitem> + + <listitem><para> + Deposit the driver files into the <smbconfsection name="[print$]"/> share's correct subdirectories + (possibly by using <command>smbclient</command>). + </para></listitem> + + <listitem><para> + Run the <command>rpcclient</command> command-line utility once with the <command>adddriver</command> + subcommand. + </para></listitem> + + <listitem><para> + Run <command>rpcclient</command> a second time with the <command>setdriver</command> subcommand. + </para></listitem> +</orderedlist> + +<para> +We provide detailed hints for each of these steps in the paragraphs that follow. +</para> + +<sect3> +<title>Identifying Driver Files</title> + +<para> +<indexterm><primary>driver files</primary></indexterm> +<indexterm><primary>driver CDROM</primary></indexterm> +<indexterm><primary>inf file</primary></indexterm> +To find out about the driver files, you have two options. You can check the contents of the driver +CDROM that came with your printer. Study the <filename>*.inf</filename> files located on the CD-ROM. This +may not be possible, since the <filename>*.inf</filename> file might be missing. Unfortunately, vendors have now started +to use their own installation programs. These installations packages are often in some Windows platform +archive format. Additionally, the files may be re-named during the installation process. This makes it +extremely difficult to identify the driver files required. +</para> + +<para> +<indexterm><primary>W32X86</primary></indexterm> +Then you have the second option. Install the driver locally on a Windows client and +investigate which filenames and paths it uses after they are installed. (You need to repeat +this procedure for every client platform you want to support. We show it here for the +<application>W32X86</application> platform only, a name used by Microsoft for all Windows NT/200x/XP +clients.) +</para> + +<para> +<indexterm><primary>driver files</primary></indexterm> +A good method to recognize the driver files is to print the test page from the driver's +<guilabel>Properties</guilabel> dialog (<guilabel>General</guilabel> tab). Then look at the list of +driver files named on the printout. You'll need to recognize what Windows (and Samba) are calling the +<guilabel>Driver File</guilabel>, <guilabel>Data File</guilabel>, <guilabel>Config File</guilabel>, +<guilabel>Help File</guilabel>, and (optionally) <guilabel>Dependent Driver Files</guilabel> +(this may vary slightly for Windows NT). You need to note all filenames for the next steps. +</para> + +<para> +<indexterm><primary>rpcclient</primary></indexterm> +<indexterm><primary>enumdrivers</primary></indexterm> +<indexterm><primary>getdriver</primary></indexterm> +Another method to quickly test the driver filenames and related paths is provided by the +<command>rpcclient</command> utility. Run it with <command>enumdrivers</command> or with the +<command>getdriver</command> subcommand, each at the <filename>3</filename> info level. In the following example, +<emphasis>TURBO_XP</emphasis> is the name of the Windows PC (in this case it was a Windows XP Professional +laptop). I installed the driver locally to TURBO_XP from a Samba server called <constant>KDE-BITSHOP</constant>. +We could run an interactive <command>rpcclient</command> session; then we would get an +<command>rpcclient /></command> prompt and would type the subcommands at this prompt. This is left as +a good exercise for you. For now, we use <command>rpcclient</command> with the <option>-c</option> +parameter to execute a single subcommand line and exit again. This is the method you use if you +want to create scripts to automate the procedure for a large number of printers and drivers. Note the +different quotation marks used to overcome the different spaces between words: +</para> + +<para><screen> +&rootprompt;<userinput>rpcclient -U'Danka%xxxx' -c \ + 'getdriver "Heidelberg Digimaster 9110 (PS)" 3' TURBO_XP</userinput> +cmd = getdriver "Heidelberg Digimaster 9110 (PS)" 3 + +[Windows NT x86] +Printer Driver Info 3: + Version: [2] + Driver Name: [Heidelberg Digimaster 9110 (PS)] + Architecture: [Windows NT x86] + Driver Path: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\HDNIS01_de.DLL] + Datafile: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\Hddm91c1_de.ppd] + Configfile: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\HDNIS01U_de.DLL] + Helpfile: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\HDNIS01U_de.HLP] + + Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\Hddm91c1_de.DLL] + Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\Hddm91c1_de.INI] + Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\Hddm91c1_de.dat] + Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\Hddm91c1_de.cat] + Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\Hddm91c1_de.def] + Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\Hddm91c1_de.hre] + Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\Hddm91c1_de.vnd] + Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\Hddm91c1_de.hlp] + Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\HDNIS01Aux.dll] + Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\HDNIS01_de.NTF] + + Monitorname: [] + Defaultdatatype: [] +</screen></para> + +<para> +<indexterm><primary>Driver File</primary></indexterm> +<indexterm><primary>Driver Path</primary></indexterm> +<indexterm><primary>WIN40</primary></indexterm> +<indexterm><primary>W32X86</primary></indexterm> +You may notice that this driver has quite a large number of <guilabel>Dependent files</guilabel> +(there are worse cases, however). Also, strangely, the +<guilabel>Driver File</guilabel> is tagged here +<guilabel>Driver Path</guilabel>. We do not yet have support for the so-called +<application>WIN40</application> architecture installed. This name is used by Microsoft for the Windows +9x/Me platforms. If we want to support these, we need to install the Windows 9x/Me driver files in +addition to those for <application>W32X86</application> (i.e., the Windows NT 2000/XP clients) onto a +Windows PC. This PC can also host the Windows 9x/Me drivers, even if it runs on Windows NT, 2000, or XP. +</para> + +<para> +<indexterm><primary>UNC notation</primary></indexterm> +<indexterm><primary>Windows Explorer</primary></indexterm> +<indexterm><primary></primary></indexterm> +Since the <smbconfsection name="[print$]"/> share is usually accessible through the <guiicon>Network +Neighborhood</guiicon>, you can also use the UNC notation from Windows Explorer to poke at it. The Windows +9x/Me driver files will end up in subdirectory <filename>0</filename> of the <filename>WIN40</filename> +directory. The full path to access them is <filename>\\WINDOWSHOST\print$\WIN40\0\</filename>. +</para> + +<note><para> +More recent drivers on Windows 2000 and Windows XP are installed into the <quote>3</quote> subdirectory +instead of the <quote>2</quote>. The version 2 of drivers, as used in Windows NT, were running in kernel +mode. Windows 2000 changed this. While it still can use the kernel mode drivers (if this is enabled by +the Admin), its native mode for printer drivers is user mode execution. This requires drivers designed +for this purpose. These types of drivers install into the <quote>3</quote> subdirectory. +</para></note> +</sect3> + +<sect3> +<title>Obtaining Driver Files from Windows Client [print$] Shares</title> + +<para> +Now we need to collect all the driver files we identified in our previous step. Where do we get them +from? Well, why not retrieve them from the very PC and the same <smbconfsection name="[print$]"/> +share that we investigated in our last step to identify the files? We can use <command>smbclient</command> +to do this. We will use the paths and names that were leaked to us by <command>getdriver</command>. The +listing is edited to include line breaks for readability: +<screen> +&rootprompt;<userinput>smbclient //TURBO_XP/print\$ -U'Danka%xxxx' \ + -c 'cd W32X86/2;mget HD*_de.* hd*ppd Hd*_de.* Hddm*dll HDN*Aux.DLL'</userinput> + +added interface ip=10.160.51.60 bcast=10.160.51.255 nmask=255.255.252.0 +Got a positive name query response from 10.160.50.8 ( 10.160.50.8 ) +Domain=[DEVELOPMENT] OS=[Windows 5.1] Server=[Windows 2000 LAN Manager] +<prompt>Get file Hddm91c1_de.ABD? </prompt><userinput>n</userinput> +<prompt>Get file Hddm91c1_de.def? </prompt><userinput>y</userinput> +getting file \W32X86\2\Hddm91c1_de.def of size 428 as Hddm91c1_de.def +<prompt>Get file Hddm91c1_de.DLL? </prompt><userinput>y</userinput> +getting file \W32X86\2\Hddm91c1_de.DLL of size 876544 as Hddm91c1_de.DLL +[...] +</screen></para> + +<para> +After this command is complete, the files are in our current local directory. You probably have noticed +that this time we passed several commands to the <option>-c</option> parameter, separated by semicolons. +This ensures that all commands are executed in sequence on the remote Windows server before +<command>smbclient</command> exits again. +</para> + +<para> +<indexterm><primary>WIN40</primary></indexterm> +Remember to repeat the procedure for the <application>WIN40</application> architecture should you need to +support Windows 9x/Me/XP clients. Remember too, the files for these architectures are in the +<filename>WIN40/0/</filename> subdirectory. Once this is complete, we can run <command>smbclient. . +.put</command> to store the collected files on the Samba server's <smbconfsection name="[print$]"/> share. +</para> +</sect3> + +<sect3> +<title>Installing Driver Files into [print$]</title> + +<para> +We are now going to locate the driver files into the <smbconfsection name="[print$]"/> share. Remember, the +UNIX path to this share has been defined previously in your &smb.conf; file. You also have created +subdirectories for the different Windows client types you want to support. If, for example, your +<smbconfsection name="[print$]"/> share maps to the UNIX path <filename>/etc/samba/drivers/</filename>, your +driver files should now go here: +</para> + +<itemizedlist> + <listitem><para> + For all Windows NT, 2000, and XP clients, <filename>/etc/samba/drivers/W32X86/</filename> but + not (yet) into the <filename>2</filename> subdirectory. + </para></listitem> + + <listitem><para> + For all Windows 95, 98, and Me clients, <filename>/etc/samba/drivers/WIN40/</filename> but not + (yet) into the <filename>0</filename> subdirectory. + </para></listitem> +</itemizedlist> + +<para> +<indexterm><primary>smbclient</primary></indexterm> +<indexterm><primary>getdriver</primary></indexterm> +We again use smbclient to transfer the driver files across the network. We specify the same files +and paths as were leaked to us by running <command>getdriver</command> against the original +<emphasis>Windows</emphasis> install. However, now we are going to store the files into a +<emphasis>Samba/UNIX</emphasis> print server's <smbconfsection name="[print$]"/> share. +<screen> +&rootprompt;<userinput>smbclient //SAMBA-CUPS/print\$ -U'root%xxxx' -c \ + 'cd W32X86; put HDNIS01_de.DLL; \ + put Hddm91c1_de.ppd; put HDNIS01U_de.DLL; \ + put HDNIS01U_de.HLP; put Hddm91c1_de.DLL; \ + put Hddm91c1_de.INI; put Hddm91c1KMMin.DLL; \ + put Hddm91c1_de.dat; put Hddm91c1_de.dat; \ + put Hddm91c1_de.def; put Hddm91c1_de.hre; \ + put Hddm91c1_de.vnd; put Hddm91c1_de.hlp; \ + put Hddm91c1_de_reg.HLP; put HDNIS01Aux.dll; \ + put HDNIS01_de.NTF'</userinput> + +added interface ip=10.160.51.60 bcast=10.160.51.255 nmask=255.255.252.0 +Got a positive name query response from 10.160.51.162 ( 10.160.51.162 ) +Domain=[CUPS-PRINT] OS=[UNIX] Server=[Samba 2.2.7a] +putting file HDNIS01_de.DLL as \W32X86\HDNIS01_de.DLL +putting file Hddm91c1_de.ppd as \W32X86\Hddm91c1_de.ppd +putting file HDNIS01U_de.DLL as \W32X86\HDNIS01U_de.DLL +putting file HDNIS01U_de.HLP as \W32X86\HDNIS01U_de.HLP +putting file Hddm91c1_de.DLL as \W32X86\Hddm91c1_de.DLL +putting file Hddm91c1_de.INI as \W32X86\Hddm91c1_de.INI +putting file Hddm91c1KMMin.DLL as \W32X86\Hddm91c1KMMin.DLL +putting file Hddm91c1_de.dat as \W32X86\Hddm91c1_de.dat +putting file Hddm91c1_de.dat as \W32X86\Hddm91c1_de.dat +putting file Hddm91c1_de.def as \W32X86\Hddm91c1_de.def +putting file Hddm91c1_de.hre as \W32X86\Hddm91c1_de.hre +putting file Hddm91c1_de.vnd as \W32X86\Hddm91c1_de.vnd +putting file Hddm91c1_de.hlp as \W32X86\Hddm91c1_de.hlp +putting file Hddm91c1_de_reg.HLP as \W32X86\Hddm91c1_de_reg.HLP +putting file HDNIS01Aux.dll as \W32X86\HDNIS01Aux.dll +putting file HDNIS01_de.NTF as \W32X86\HDNIS01_de.NTF +</screen> +<indexterm><primary>PPD</primary></indexterm> +<indexterm><primary>PostScript driver</primary></indexterm> +<indexterm><primary>adddriver</primary></indexterm> +Whew &smbmdash; that was a lot of typing! Most drivers are a lot smaller &smbmdash; many have only three generic +PostScript driver files plus one PPD. While we did retrieve the files from the <filename>2</filename> +subdirectory of the <filename>W32X86</filename> directory from the Windows box, we do not put them +(for now) in this same subdirectory of the Samba box. This relocation will automatically be done by the +<command>adddriver</command> command, which we will run shortly (and do not forget to also put the files +for the Windows 9x/Me architecture into the <filename>WIN40/</filename> subdirectory should you need them). +</para> + +</sect3> + +<sect3> +<title><command>smbclient</command> to Confirm Driver Installation</title> + +<para> +<indexterm><primary>smbclient</primary></indexterm> +<indexterm><primary>SSH</primary></indexterm> +For now we verify that our files are there. This can be done with <command>smbclient</command>, too +(but, of course, you can log in via SSH also and do this through a standard UNIX shell access): +</para> + +<para><screen> +&rootprompt;<userinput>smbclient //SAMBA-CUPS/print\$ -U 'root%xxxx' \ + -c 'cd W32X86; pwd; dir; cd 2; pwd; dir'</userinput> + added interface ip=10.160.51.60 bcast=10.160.51.255 nmask=255.255.252.0 +Got a positive name query response from 10.160.51.162 ( 10.160.51.162 ) +Domain=[CUPS-PRINT] OS=[UNIX] Server=[Samba 2.2.8a] + +Current directory is \\SAMBA-CUPS\print$\W32X86\ +. D 0 Sun May 4 03:56:35 2003 +.. D 0 Thu Apr 10 23:47:40 2003 +2 D 0 Sun May 4 03:56:18 2003 +HDNIS01Aux.dll A 15356 Sun May 4 03:58:59 2003 +Hddm91c1KMMin.DLL A 46966 Sun May 4 03:58:59 2003 +HDNIS01_de.DLL A 434400 Sun May 4 03:58:59 2003 +HDNIS01_de.NTF A 790404 Sun May 4 03:56:35 2003 +Hddm91c1_de.DLL A 876544 Sun May 4 03:58:59 2003 +Hddm91c1_de.INI A 101 Sun May 4 03:58:59 2003 +Hddm91c1_de.dat A 5044 Sun May 4 03:58:59 2003 +Hddm91c1_de.def A 428 Sun May 4 03:58:59 2003 +Hddm91c1_de.hlp A 37699 Sun May 4 03:58:59 2003 +Hddm91c1_de.hre A 323584 Sun May 4 03:58:59 2003 +Hddm91c1_de.ppd A 26373 Sun May 4 03:58:59 2003 +Hddm91c1_de.vnd A 45056 Sun May 4 03:58:59 2003 +HDNIS01U_de.DLL A 165888 Sun May 4 03:58:59 2003 +HDNIS01U_de.HLP A 19770 Sun May 4 03:58:59 2003 +Hddm91c1_de_reg.HLP A 228417 Sun May 4 03:58:59 2003 + 40976 blocks of size 262144. 709 blocks available + +Current directory is \\SAMBA-CUPS\print$\W32X86\2\ +. D 0 Sun May 4 03:56:18 2003 +.. D 0 Sun May 4 03:56:35 2003 +ADOBEPS5.DLL A 434400 Sat May 3 23:18:45 2003 +laserjet4.ppd A 9639 Thu Apr 24 01:05:32 2003 +ADOBEPSU.DLL A 109568 Sat May 3 23:18:45 2003 +ADOBEPSU.HLP A 18082 Sat May 3 23:18:45 2003 +PDFcreator2.PPD A 15746 Sun Apr 20 22:24:07 2003 + 40976 blocks of size 262144. 709 blocks available +</screen></para> + +<para> +<indexterm><primary>Point'n'Print</primary></indexterm> +<indexterm><primary>printer driver files</primary></indexterm> +<indexterm><primary>print queue</primary></indexterm> +Notice that there are already driver files present in the <filename>2</filename> subdirectory (probably from a +previous installation). Once the files for the new driver are there too, you are still a few steps away from +being able to use them on the clients. The only thing you could do now is retrieve them from a client just +like you retrieve ordinary files from a file share, by opening print$ in Windows Explorer. But that wouldn't +install them per Point'n'Print. The reason is that Samba does not yet know that these files are something +special, namely <emphasis>printer driver files</emphasis>, and it does not know to which print queue(s) these +driver files belong. +</para> +</sect3> + +<sect3> +<title>Running <command>rpcclient</command> with <command>adddriver</command></title> + +<para> +<indexterm><primary>adddriver</primary></indexterm> +<indexterm><primary>register driver files</primary></indexterm> +<indexterm><primary>TDB database</primary></indexterm> +Next, you must tell Samba about the special category of the files you just uploaded into the +<smbconfsection name="[print$]"/> share. This is done by the <command>adddriver</command> +command. It will prompt Samba to register the driver files into its internal TDB database files. The +following command and its output has been edited for readability: +<screen> +&rootprompt;<userinput>rpcclient -Uroot%xxxx -c 'adddriver "Windows NT x86" \ + "dm9110:HDNIS01_de.DLL: \ + Hddm91c1_de.ppd:HDNIS01U_de.DLL:HDNIS01U_de.HLP: \ + NULL:RAW:Hddm91c1_de.DLL,Hddm91c1_de.INI, \ + Hddm91c1_de.dat,Hddm91c1_de.def,Hddm91c1_de.hre, \ + Hddm91c1_de.vnd,Hddm91c1_de.hlp,Hddm91c1KMMin.DLL, \ + HDNIS01Aux.dll,HDNIS01_de.NTF, \ + Hddm91c1_de_reg.HLP' SAMBA-CUPS</userinput> + +cmd = adddriver "Windows NT x86" \ + "dm9110:HDNIS01_de.DLL:Hddm91c1_de.ppd:HDNIS01U_de.DLL: \ + HDNIS01U_de.HLP:NULL:RAW:Hddm91c1_de.DLL,Hddm91c1_de.INI, \ + Hddm91c1_de.dat,Hddm91c1_de.def,Hddm91c1_de.hre, \ + Hddm91c1_de.vnd,Hddm91c1_de.hlp,Hddm91c1KMMin.DLL, \ + HDNIS01Aux.dll,HDNIS01_de.NTF,Hddm91c1_de_reg.HLP" + +Printer Driver dm9110 successfully installed. +</screen></para> + +<para> +<indexterm><primary>NT_STATUS_UNSUCCESSFUL</primary></indexterm> +<indexterm><primary>error message</primary></indexterm> +<indexterm><primary>adddriver</primary></indexterm> +After this step, the driver should be recognized by Samba on the print server. You need to be very +careful when typing the command. Don't exchange the order of the fields. Some changes would lead to +an <computeroutput>NT_STATUS_UNSUCCESSFUL</computeroutput> error message. These become obvious. Other +changes might install the driver files successfully but render the driver unworkable. So take care! +Hints about the syntax of the adddriver command are in the man page. +provides a more detailed description, should you need it. +</para> +</sect3> + +<sect3> +<title>Checking <command>adddriver</command> Completion</title> + +<para> +One indication for Samba's recognition of the files as driver files is the <computeroutput>successfully +installed</computeroutput> message. Another one is the fact that our files have been moved by the +<command>adddriver</command> command into the <filename>2</filename> subdirectory. You can check this +again with <command>smbclient</command>: +<screen> +&rootprompt;<userinput>smbclient //SAMBA-CUPS/print\$ -Uroot%xx \ + -c 'cd W32X86;dir;pwd;cd 2;dir;pwd'</userinput> + added interface ip=10.160.51.162 bcast=10.160.51.255 nmask=255.255.252.0 + Domain=[CUPS-PRINT] OS=[UNIX] Server=[Samba 2.2.7a] + + Current directory is \\SAMBA-CUPS\print$\W32X86\ + . D 0 Sun May 4 04:32:48 2003 + .. D 0 Thu Apr 10 23:47:40 2003 + 2 D 0 Sun May 4 04:32:48 2003 + 40976 blocks of size 262144. 731 blocks available + + Current directory is \\SAMBA-CUPS\print$\W32X86\2\ + . D 0 Sun May 4 04:32:48 2003 + .. D 0 Sun May 4 04:32:48 2003 + DigiMaster.PPD A 148336 Thu Apr 24 01:07:00 2003 + ADOBEPS5.DLL A 434400 Sat May 3 23:18:45 2003 + laserjet4.ppd A 9639 Thu Apr 24 01:05:32 2003 + ADOBEPSU.DLL A 109568 Sat May 3 23:18:45 2003 + ADOBEPSU.HLP A 18082 Sat May 3 23:18:45 2003 + PDFcreator2.PPD A 15746 Sun Apr 20 22:24:07 2003 + HDNIS01Aux.dll A 15356 Sun May 4 04:32:18 2003 + Hddm91c1KMMin.DLL A 46966 Sun May 4 04:32:18 2003 + HDNIS01_de.DLL A 434400 Sun May 4 04:32:18 2003 + HDNIS01_de.NTF A 790404 Sun May 4 04:32:18 2003 + Hddm91c1_de.DLL A 876544 Sun May 4 04:32:18 2003 + Hddm91c1_de.INI A 101 Sun May 4 04:32:18 2003 + Hddm91c1_de.dat A 5044 Sun May 4 04:32:18 2003 + Hddm91c1_de.def A 428 Sun May 4 04:32:18 2003 + Hddm91c1_de.hlp A 37699 Sun May 4 04:32:18 2003 + Hddm91c1_de.hre A 323584 Sun May 4 04:32:18 2003 + Hddm91c1_de.ppd A 26373 Sun May 4 04:32:18 2003 + Hddm91c1_de.vnd A 45056 Sun May 4 04:32:18 2003 + HDNIS01U_de.DLL A 165888 Sun May 4 04:32:18 2003 + HDNIS01U_de.HLP A 19770 Sun May 4 04:32:18 2003 + Hddm91c1_de_reg.HLP A 228417 Sun May 4 04:32:18 2003 + 40976 blocks of size 262144. 731 blocks available +</screen></para> + +<para> +Another verification is that the timestamp of the printing TDB files is now updated +(and possibly their file size has increased). +</para> +</sect3> + +<sect3> +<title>Check Samba for Driver Recognition</title> + +<para> +<indexterm><primary>registered</primary></indexterm> +Now the driver should be registered with Samba. We can easily verify this and will do so in a +moment. However, this driver is not yet associated with a particular printer. We may check the driver +status of the files by at least three methods: +</para> + +<itemizedlist> + <listitem><para> +<indexterm><primary>Network Neighborhood</primary></indexterm> +<indexterm><primary>Printers and Faxes</primary></indexterm> +<indexterm><primary>printer icon</primary></indexterm> +<indexterm><primary>Windows95/98/ME</primary></indexterm> +<indexterm><primary>Windows NT/2000/XP</primary></indexterm> + From any Windows client browse Network Neighborhood, find the Samba host, and open the Samba + <guiicon>Printers and Faxes</guiicon> folder. Select any printer icon, right-click and select + the printer <guimenuitem>Properties</guimenuitem>. Click the <guilabel>Advanced</guilabel> + tab. Here is a field indicating the driver for that printer. A drop-down menu allows you to + change that driver (be careful not to do this unwittingly). You can use this list to view + all drivers known to Samba. Your new one should be among them. (Each type of client will + see only its own architecture's list. If you do not have every driver installed for each platform, + the list will differ if you look at it from Windows95/98/ME or Windows NT/2000/XP.) + </para></listitem> + + <listitem><para> +<indexterm><primary>Network Neighborhood</primary></indexterm> + From a Windows 200x/XP client (not Windows NT) browse <guiicon>Network Neighborhood</guiicon>, + search for the Samba server, open the server's <guiicon>Printers</guiicon> folder, + and right-click on the white background (with no printer highlighted). Select <guimenuitem>Server + Properties</guimenuitem>. On the <guilabel>Drivers</guilabel> tab you will see the new driver + listed. This view enables you to also inspect the list of files belonging to that driver + (this does not work on Windows NT, but only on Windows 2000 and Windows XP; Windows NT does not + provide the <guimenuitem>Drivers</guimenuitem> tab). An alternative and much quicker method for + Windows 2000/XP to start this dialog is by typing into a DOS box (you must of course adapt the + name to your Samba server instead of <replaceable>SAMBA-CUPS</replaceable>): + <screen> + <userinput>rundll32 printui.dll,PrintUIEntry /s /t2 /n\\<replaceable>SAMBA-CUPS</replaceable></userinput> + </screen> + </para> + </listitem> + + <listitem><para> + From a UNIX prompt, run this command (or a variant thereof), where + <replaceable>SAMBA-CUPS</replaceable> is the name of the Samba host and xxxx represents the + actual Samba password assigned to root: + <screen> + <userinput>rpcclient -U'root%xxxx' -c 'enumdrivers' <replaceable>SAMBA-CUPS</replaceable></userinput> + </screen> + </para> + + <para> + You will see a listing of all drivers Samba knows about. Your new one should be among + them. But it is only listed under the <parameter>[Windows NT x86]</parameter> heading, not under + <smbconfsection name="[Windows 4.0]"/>, since you didn't install that part. Or did you? + In our example it is named <constant>dm9110</constant>. Note that the third column shows the other + installed drivers twice, one time for each supported architecture. Our new driver only shows up + for <application>Windows NT 4.0 or 2000</application>. To have it present for <application>Windows + 95, 98, and Me</application>, you'll have to repeat the whole procedure with the WIN40 architecture + and subdirectory. + </para></listitem> +</itemizedlist> +</sect3> + +<sect3> +<title>Specific Driver Name Flexibility</title> + +<para> +<indexterm><primary>adddriver</primary></indexterm> +You can name the driver as you like. If you repeat the <command>adddriver</command> step with the same +files as before but with a different driver name, it will work the same: +<screen> +&rootprompt;<userinput>rpcclient -Uroot%xxxx \ + -c 'adddriver "Windows NT x86" \ + "mydrivername:HDNIS01_de.DLL: \ + Hddm91c1_de.ppd:HDNIS01U_de.DLL:HDNIS01U_de.HLP: \ + NULL:RAW:Hddm91c1_de.DLL,Hddm91c1_de.INI, \ + Hddm91c1_de.dat,Hddm91c1_de.def,Hddm91c1_de.hre, \ + Hddm91c1_de.vnd,Hddm91c1_de.hlp,Hddm91c1KMMin.DLL, \ + HDNIS01Aux.dll,HDNIS01_de.NTF,Hddm91c1_de_reg.HLP' SAMBA-CUPS + </userinput> + +cmd = adddriver "Windows NT x86" \ + "mydrivername:HDNIS01_de.DLL:Hddm91c1_de.ppd:HDNIS01U_de.DLL:\ + HDNIS01U_de.HLP:NULL:RAW:Hddm91c1_de.DLL,Hddm91c1_de.INI, \ + Hddm91c1_de.dat,Hddm91c1_de.def,Hddm91c1_de.hre, \ + Hddm91c1_de.vnd,Hddm91c1_de.hlp,Hddm91c1KMMin.DLL, \ + HDNIS01Aux.dll,HDNIS01_de.NTF,Hddm91c1_de_reg.HLP" + +Printer Driver mydrivername successfully installed. +</screen></para> + +<para> +<indexterm><primary>print queue</primary></indexterm> +<indexterm><primary>rpcclient</primary></indexterm> +<indexterm><primary>adddriver</primary></indexterm> +You will be able to bind that driver to any print queue (however, you are responsible that +you associate drivers to queues that make sense with respect to target printers). You cannot run the +<command>rpcclient</command> <command>adddriver</command> command repeatedly. Each run consumes the +files you had put into the <smbconfsection name="[print$]"/> share by moving them into the +respective subdirectories, so you must execute an <command>smbclient ... put</command> command before +each <command>rpcclient ... adddriver</command> command. +</para> +</sect3> + +<sect3> +<title>Running <command>rpcclient</command> with <command>setdriver</command></title> + +<para> +<indexterm><primary>mapping printer driver</primary></indexterm> +<indexterm><primary>TDB</primary></indexterm> +Samba needs to know which printer owns which driver. Create a mapping of the driver to a printer, and +store this information in Samba's memory, the TDB files. The <command>rpcclient setdriver</command> command +achieves exactly this: +<screen> +&rootprompt;<userinput>rpcclient -U'root%xxxx' -c 'setdriver dm9110 mydrivername' <replaceable>SAMBA-CUPS</replaceable></userinput> + cmd = setdriver dm9110 mydrivername + +Successfully set dm9110 to driver mydrivername. +</screen></para> + +<para> +Ah, no, I did not want to do that. Repeat, this time with the name I intended: +<screen> +&rootprompt;<userinput>rpcclient -U'root%xxxx' -c 'setdriver dm9110 dm9110' <replaceable>SAMBA-CUPS</replaceable></userinput> + cmd = setdriver dm9110 dm9110 +Successfully set dm9110 to driver dm9110. +</screen></para> + +<para> +The syntax of the command is: +<screen> +<userinput>rpcclient -U'root%<replaceable>sambapassword</replaceable>' -c 'setdriver <replaceable>printername</replaceable> \ + <replaceable>drivername</replaceable>' <replaceable>SAMBA-Hostname</replaceable></userinput>. +</screen> +Now we have done most of the work, but not all of it. +</para> + +<note><para> +The <command>setdriver</command> command will only succeed if the printer is already known to Samba. A +bug in 2.2.x prevented Samba from recognizing freshly installed printers. You had to restart Samba, +or at least send an HUP signal to all running smbd processes to work around this: <userinput>kill -HUP +`pidof smbd`</userinput>. +</para></note> +</sect3> +</sect2> +</sect1> + +<sect1> +<title>Client Driver Installation Procedure</title> + +<para> +As Don Quixote said, <quote>The proof of the pudding is in the eating.</quote> The proof +for our setup lies in the printing. So let's install the printer driver onto the client PCs. This is +not as straightforward as it may seem. Read on. +</para> + +<sect2> +<title>First Client Driver Installation</title> + +<para> +Especially important is the installation onto the first client PC (for each architectural platform +separately). Once this is done correctly, all further clients are easy to set up and shouldn't need further +attention. What follows is a description for the recommended first procedure. You now work from a client +workstation. You should check that your connection is not unwittingly mapped to <emphasis>bad +user</emphasis> nobody. In a DOS box type: +</para> + +<para><userinput>net use \\<replaceable>SAMBA-SERVER</replaceable>\print$ /user:root</userinput></para> + +<para> +Replace root, if needed, by another valid <smbconfoption name="printer admin"/> user as given in +the definition. Should you already be connected as a different user, you will get an error message. There +is no easy way to get rid of that connection, because Windows does not seem to know a concept of logging +off from a share connection (do not confuse this with logging off from the local workstation; that is +a different matter). On Windows NT/200x, you can force a logoff from all smb/cifs connections by restarting the +<emphasis>workstation</emphasis> service. You can try to close all Windows file explorers and Internet Explorer for +Windows. As a last resort, you may have to reboot. Make sure there is no automatic reconnection set up. It may be +easier to go to a different workstation and try from there. After you have made sure you are connected +as a printer admin user (you can check this with the <command>smbstatus</command> command on Samba), +do this from the Windows workstation: +</para> + +<procedure> + <step><para> + Open <guiicon>Network Neighborhood</guiicon>. + </para></step> + + <step><para> + Browse to Samba server. + </para></step> + + <step><para> + Open its <guiicon>Printers and Faxes</guiicon> folder. + </para></step> + + <step><para> + Highlight and right-click on the printer. + </para></step> + + <step><para> + Select <guimenuitem>Connect</guimenuitem> (for Windows NT4/200x + it is possibly <guimenuitem>Install</guimenuitem>). + </para></step> +</procedure> + +<para> +A new printer (named <replaceable>printername</replaceable> on Samba server) should now have +appeared in your <emphasis>local</emphasis> Printer folder (check <guimenu>Start</guimenu> -> +<guimenuitem>Settings</guimenuitem> -> <guimenuitem>Control Panel</guimenuitem> -> <guiicon>Printers +and Faxes</guiicon>). +</para> + +<para> +<indexterm><primary>print test page</primary></indexterm> +Most likely you are tempted to try to print a test page. After all, you now can open the printer +properties, and on the <guimenu>General</guimenu> tab there is a button offering to do just that. But +chances are that you get an error message saying "<literal>Unable to print Test Page</literal>." The +reason might be that there is not yet a valid device mode set for the driver or that the <quote>printer +driver data</quote> set is still incomplete. +</para> + +<para> +You must make sure that a valid <parameter>device mode</parameter> is set for the +driver. We now explain what that means. +</para> +</sect2> + +<sect2 id="prt-modeset"> +<title>Setting Device Modes on New Printers</title> + +<para> +For a printer to be truly usable by a Windows NT/200x/XP client, it must possess: +</para> + +<itemizedlist> + <listitem><para> +<indexterm><primary>device mode</primary></indexterm> + A valid <emphasis>device mode</emphasis> generated by the driver for the printer (defining things + like paper size, orientation and duplex settings). + </para></listitem> + + <listitem><para> +<indexterm><primary>printer driver data</primary></indexterm> + A complete set of <emphasis>printer driver data</emphasis> generated by the driver. + </para></listitem> +</itemizedlist> + +<para> +<indexterm><primary>ntprinters.tdb</primary></indexterm> +<indexterm><primary>ntdrivers.tdb</primary></indexterm> +<indexterm><primary>printing.tdb</primary></indexterm> +<indexterm><primary>ntforms.tdb</primary></indexterm> +<indexterm><primary>TDB database files</primary></indexterm> +If either of these is incomplete, the clients can produce less than optimal output at best. In the +worst cases, unreadable garbage or nothing at all comes from the printer, or it produces a harvest of +error messages when attempting to print. Samba stores the named values and all printing-related information in +its internal TDB database files <filename>(ntprinters.tdb</filename>, <filename>ntdrivers.tdb</filename>, +<filename>printing.tdb</filename>, and <filename>ntforms.tdb</filename>). +</para> + +<para> +The device mode and the set of printer driver data are basically collections +of settings for all print queue properties, initialized in a sensible way. Device modes and +printer driver data should initially be set on the print server (the Samba host) to healthy +values so the clients can start to use them immediately. How do we set these initial healthy values? +This can be achieved by accessing the drivers remotely from an NT (or 200x/XP) client, as discussed +in the following paragraphs. +</para> + +<para> +Be aware that a valid device mode can only be initiated by a <smbconfoption name="printer admin"/> or root +(the reason should be obvious). Device modes can be correctly set only by executing the printer driver program +itself. Since Samba cannot execute this Win32 platform driver code, it sets this field initially to NULL +(which is not a valid setting for clients to use). Fortunately, most drivers automatically generate the +printer driver data that is needed when they are uploaded to the <smbconfsection name="[print$]"/> share with +the help of the APW or rpcclient. +</para> + +<para> +The generation and setting of a first valid device mode, however, requires some tickling from a client +to set it on the Samba server. The easiest means of doing so is to simply change the page orientation on +the server's printer. This executes enough of the printer driver program on the client for the desired +effect to happen and feeds back the new device mode to our Samba server. You can use the native Windows +NT/200x/XP printer properties page from a Window client for this: +</para> + +<procedure> +<title>Procedure to Initialize the Printer Driver Settings</title> + <step><para> + Browse the <guiicon>Network Neighborhood</guiicon>. + </para></step> + + <step><para> + Find the Samba server. + </para></step> + + <step><para> + Open the Samba server's <guiicon>Printers and Faxes</guiicon> folder. + </para></step> + + <step><para> + Highlight the shared printer in question. + </para></step> + + <step><para> + Right-click on the printer (you may already be here if you followed the last section's description). + </para></step> + + <step><para> + At the bottom of the context menu select <guimenu>Properties</guimenu> (if the menu still offers the + <guimenuitem>Connect</guimenuitem> entry further above, you + need to click on that one first to achieve the driver + installation, as shown in the last section). + </para></step> + + <step><para> + Go to the <guilabel>Advanced</guilabel> tab; click on <guibutton>Printing Defaults</guibutton>. + </para></step> + + <step><para> + Change the <guimenuitem>Portrait</guimenuitem> page setting to <guimenuitem>Landscape</guimenuitem> (and back). + </para></step> + + <step><para> + Make sure to apply changes between swapping the page orientation to cause the change to actually take effect. + </para></step> + + <step><para> + While you are at it, you may also want to set the desired printing defaults here, which then apply to all future + client driver installations. + </para></step> +</procedure> + +<para> +This procedure executes the printer driver program on the client platform and feeds back the correct +device mode to Samba, which now stores it in its TDB files. Once the driver is installed on the client, +you can follow the analogous steps by accessing the <emphasis>local</emphasis> <guiicon>Printers</guiicon> +folder, too, if you are a Samba printer admin user. From now on, printing should work as expected. +</para> + +<para> +<indexterm><primary>default devmode</primary></indexterm> +Samba includes a service-level parameter name <parameter>default devmode</parameter> for generating a default +device mode for a printer. Some drivers function well with Samba's default set of properties. Others +may crash the client's spooler service. So 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>Additional Client Driver Installation</title> + +<para> +<indexterm><primary>additional driver</primary></indexterm> +Every additional driver may be installed in the same way as just described. Browse <command>Network +Neighborhood</command>, open the <guiicon>Printers</guiicon> folder on Samba server, right-click on +<guiicon>Printer</guiicon>, and choose <guimenuitem>Connect...</guimenuitem>. Once this completes (should be +not more than a few seconds, but could also take a minute, depending on network conditions), you should find +the new printer in your client workstation local <guiicon>Printers and Faxes</guiicon> folder. +</para> + +<para> +You can also open your local <guiicon>Printers and Faxes</guiicon> folder by +using this command on Windows 200x/XP Professional workstations: +<screen> +<userinput>rundll32 shell32.dll,SHHelpShortcuts_RunDLL PrintersFolder</userinput> +</screen> +or this command on Windows NT 4.0 workstations: +<indexterm><primary>rundll32</primary></indexterm> +<screen> +<userinput>rundll32 shell32.dll,Control_RunDLL MAIN.CPL @2</userinput> +</screen> +</para> + +<para> +You can enter the commands either inside a <guilabel>DOS box</guilabel> window or in the <guimenuitem>Run +command...</guimenuitem> field from the <guimenu>Start</guimenu> menu. +</para> +</sect2> + +<sect2> +<title>Always Make First Client Connection as root or <quote>printer admin</quote></title> + +<para> +After you installed the driver on the Samba server (in its <smbconfsection name="[print$]"/> share), you +should always make sure that your first client installation completes correctly. Make it a habit for yourself +to build the very first connection from a client as <smbconfoption name="printer admin"/>. This is to make +sure that: +</para> + +<itemizedlist> + <listitem><para> + A first valid <emphasis>device mode</emphasis> is really initialized (see above <link + linkend="prt-modeset">Setting Device Modes on New Printers</link>) for more explanation details). + </para></listitem> + + <listitem><para> + The default print settings of your printer for all further client installations are as you want them. + </para></listitem> +</itemizedlist> + +<para> +Do this by changing the orientation to landscape, click on <guiicon>Apply</guiicon>, and then change it +back again. Next, modify the other settings (for example, you do not want the default media size set to +<guiicon>Letter</guiicon> when you are all using <guiicon>A4</guiicon>, right? You may want to set the +printer for <guiicon>duplex</guiicon> as the default, and so on). +</para> + +<para> +<indexterm><primary>runas</primary></indexterm> +To connect as root to a Samba printer, try this command from a Windows 200x/XP DOS box command prompt: +<screen> +&dosprompt;<userinput>runas /netonly /user:root "rundll32 printui.dll,PrintUIEntry /p /t3 /n + \\<replaceable>SAMBA-SERVER</replaceable>\<replaceable>printername</replaceable>"</userinput> +</screen> +</para> + +<para> +You will be prompted for <constant>root</constant>'s Samba password; type it, wait a few seconds, click on +<guibutton>Printing Defaults</guibutton>, and proceed to set the job options that should be used as defaults +by all clients. Alternatively, instead of root you can name one other member of the <smbconfoption +name="printer admin"/> from the setting. +</para> + +<para> +Now all the other users downloading and installing the driver the same way (using +<literal>Point'n'Print</literal>) will have the same defaults set for them. If you miss this step, you'll get a +lot of help desk calls from your users, but maybe you like to talk to people. +</para> +</sect2> +</sect1> + +<sect1> +<title>Other Gotchas</title> + +<para> +Your driver is installed. It is now ready for Point'n'Print installation by the clients. You may have tried to +download and use it on your first client machine, but wait. Let's make sure you are acquainted first with a +few tips and tricks you may find useful. For example, suppose you did not set the defaults on the printer, as +advised in the preceding paragraphs. Your users complain about various issues (such as, <quote>We need to set +the paper size for each job from Letter to A4 and it will not store it</quote>). +</para> + +<sect2> +<title>Setting Default Print Options for Client Drivers</title> + +<para> +The last sentence might be viewed with mixed feelings by some users and Admins. They have struggled for hours +and could not arrive at a point where their settings seemed to be saved. It is not their fault. The confusing +thing is that in the multitabbed dialog that pops up when you right-click on the printer name and select +<guimenuitem>Properties</guimenuitem>, you can arrive at two dialogs that appear identical, each claiming that +they help you to set printer options in three different ways. Here is the definitive answer to the Samba +default driver setting FAQ: +</para> + +<formalpara><title><quote>I can not set and save default print options +for all users on Windows 200x/XP. Why not?</quote></title> + +<para> +How are you doing it? I bet the wrong way. (It is not easy to find out, though.) There are three different +ways to bring you to a dialog that seems to set everything. All three dialogs look the same, but only one of +them does what you intend. You need to be Administrator or Print Administrator to do this for all users. Here +is how I reproduce it in an XP Professional: +</para> + +<orderedlist numeration="upperalpha"> + <listitem><para>The first <quote>wrong</quote> way: + <orderedlist numeration="arabic"> + <listitem><para>Open the <guiicon>Printers</guiicon> folder.</para></listitem> + + <listitem><para>Right-click on the printer (<emphasis>remoteprinter on cupshost</emphasis>) and + select in context menu <guimenu>Printing Preferences...</guimenu>.</para></listitem> + + <listitem><para>Look at this dialog closely and remember what it looks like.</para></listitem> + </orderedlist></para></listitem> + + <listitem><para>The second <quote>wrong</quote> way: + <orderedlist numeration="arabic"> + <listitem><para>Open the <guimenu>Printers</guimenu> folder.</para></listitem> + + <listitem><para>Right-click on the printer (<emphasis>remoteprinter on + cupshost</emphasis>) and select in the context menu + <guimenuitem>Properties</guimenuitem></para></listitem>. + + <listitem><para>Click on the <guilabel>General</guilabel> + tab.</para></listitem> + + <listitem><para>Click on the <guibutton>Printing + Preferences...</guibutton> button.</para></listitem> + + <listitem><para>A new dialog opens. Keep this dialog open and go back + to the parent dialog.</para></listitem> + </orderedlist> + </para></listitem> + + <listitem><para> + The third and correct way (should you do this from the beginning, just carry out steps 1 + and 2 from the second method above): + </para> + + <orderedlist numeration="arabic"> + <listitem><para>Click on the <guilabel>Advanced</guilabel> + tab. (If everything is <quote>grayed out,</quote> then you are not logged + in as a user with enough privileges.)</para></listitem> + + <listitem><para>Click on the <guibutton>Printing + Defaults</guibutton> button.</para></listitem> + + <listitem><para>On any of the two new tabs, + click on the + <guilabel>Advanced</guilabel> button.</para></listitem> + + <listitem><para>A new dialog opens. Compare + this one to the other. Are they + identical when you compare one from + <quote>B.5</quote> and one from A.3?</para></listitem> + </orderedlist> + </listitem> +</orderedlist> + +<para> +Do you see any difference in the two settings dialogs? I do not either. However, only the last one, which you +arrived at with steps C.1 through C.6 will permanently save any settings which will then become the defaults +for new users. If you want all clients to have the same defaults, you need to conduct these steps as +administrator (<smbconfoption name="printer admin"/>) before a client downloads the driver (the clients can +later set their own per-user defaults by following procedures A or B above). Windows 200x/XP allow per-user +default settings and the ones the administrator gives them before they set up their own. The parents of the +identical-looking dialogs have a slight difference in their window names; one is called +<computeroutput>Default Print Values for Printer Foo on Server Bar</computeroutput> (which is the one you +need) and the other is called <quote><computeroutput>Print Settings for Printer Foo on Server +Bar</computeroutput></quote>. The last one is the one you arrive at when you right-click on the printer and +select <guimenuitem>Print Settings...</guimenuitem>. This is the one that you were taught to use back in the +days of Windows NT, so it is only natural to try the same way with Windows 200x/XP. You would not dream that +there is now a different path to arrive at an identical-looking, but functionally different, dialog to set +defaults for all users. +</para></formalpara> + +<tip><para>Try (on Windows 200x/XP) to run this command (as a user with the right privileges): +<indexterm><primary>rundll32</primary></indexterm> +</para> + +<para><userinput> +rundll32 printui.dll,PrintUIEntry /p /t3 /n\\<replaceable>SAMBA-SERVER</replaceable>\<replaceable>printersharename</replaceable> +</userinput></para> + +<para> +To see the tab with the <guilabel>Printing Defaults</guilabel> button (the one you need), also run this command: +</para> + +<para><userinput> +rundll32 printui.dll,PrintUIEntry /p /t0 /n\\<replaceable>SAMBA-SERVER</replaceable>\<replaceable>printersharename</replaceable> +</userinput></para> + +<para> +To see the tab with the <guilabel>Printing Preferences</guilabel> +button (the one that does not set systemwide defaults), you can +start the commands from inside a DOS box or from <guimenu>Start</guimenu> -> <guimenuitem>Run</guimenuitem>. +</para> +</tip> + +</sect2> + +<sect2> +<title>Supporting Large Numbers of Printers</title> + +<para> +One issue that has arisen during the recent development phase of Samba is the need to support driver +downloads for hundreds of printers. Using Windows NT APW for this task is somewhat awkward (to say the least). If +you do not want to acquire RSS pains from the printer installation clicking orgy alone, you need +to think about a non-interactive script. +</para> + +<para> +If more than one printer is using the same driver, the <command>rpcclient setdriver</command> +command can be used to set the driver associated with an installed queue. If the driver is uploaded to +<smbconfsection name="[print$]"/> once and registered with the printing TDBs, it can be used by +multiple print queues. In this case, you just need to repeat the <command>setprinter</command> subcommand of +<command>rpcclient</command> for every queue (without the need to conduct the <command>adddriver</command> +repeatedly). The following is an example of how this can be accomplished: +</para> + +<para><screen> +&rootprompt;<userinput>rpcclient <replaceable>SAMBA-CUPS</replaceable> -U root%<replaceable>secret</replaceable> -c 'enumdrivers'</userinput> + cmd = enumdrivers + + [Windows NT x86] + Printer Driver Info 1: + Driver Name: [infotec IS 2075 PCL 6] + + Printer Driver Info 1: + Driver Name: [DANKA InfoStream] + + Printer Driver Info 1: + Driver Name: [Heidelberg Digimaster 9110 (PS)] + + Printer Driver Info 1: + Driver Name: [dm9110] + + Printer Driver Info 1: + Driver Name: [mydrivername] + + [....] +</screen> + +<screen> +&rootprompt;<userinput>rpcclient <replaceable>SAMBA-CUPS</replaceable> -U root%<replaceable>secret</replaceable> -c 'enumprinters'</userinput> + cmd = enumprinters + flags:[0x800000] + name:[\\SAMBA-CUPS\dm9110] + description:[\\SAMBA-CUPS\dm9110,,110ppm HiVolume DANKA Stuttgart] + comment:[110 ppm HiVolume DANKA Stuttgart] + [....] +</screen> + +<screen> +&rootprompt;<userinput>rpcclient <replaceable>SAMBA-CUPS</replaceable> -U root%<replaceable>secret</replaceable> -c \ + 'setdriver <replaceable>dm9110</replaceable> "<replaceable>Heidelberg Digimaster 9110 (PS)</replaceable>"'</userinput> + cmd = setdriver dm9110 Heidelberg Digimaster 9110 (PPD) + Successfully set dm9110 to driver Heidelberg Digimaster 9110 (PS). +</screen> + +<screen> +&rootprompt;<userinput>rpcclient <replaceable>SAMBA-CUPS</replaceable> -U root%<replaceable>secret</replaceable> -c 'enumprinters'</userinput> + cmd = enumprinters + flags:[0x800000] + name:[\\SAMBA-CUPS\dm9110] + description:[\\SAMBA-CUPS\dm9110,Heidelberg Digimaster 9110 (PS),\ + 110ppm HiVolume DANKA Stuttgart] + comment:[110ppm HiVolume DANKA Stuttgart] + [....] +</screen> + +<screen> +&rootprompt;<userinput>rpcclient <replaceable>SAMBA-CUPS</replaceable> -U root%<replaceable>secret</replaceable> -c 'setdriver <replaceable>dm9110</replaceable> <replaceable>mydrivername</replaceable>'</userinput> + cmd = setdriver dm9110 mydrivername + Successfully set dm9110 to mydrivername. +</screen> + +<screen> +&rootprompt;<userinput>rpcclient <replaceable>SAMBA-CUPS</replaceable> -U root%<replaceable>secret</replaceable> -c 'enumprinters'</userinput> + cmd = enumprinters + flags:[0x800000] + name:[\\SAMBA-CUPS\dm9110] + description:[\\SAMBA-CUPS\dm9110,mydrivername,\ + 110ppm HiVolume DANKA Stuttgart] + comment:[110ppm HiVolume DANKA Stuttgart] + [....] +</screen></para> + +<para> +It may not be easy to recognize that the first call to <command>enumprinters</command> showed the +<quote>dm9110</quote> printer with an empty string where the driver should have been listed (between +the two commas in the description field). After the <command>setdriver</command> command +succeeds, all is well. +</para> +</sect2> + +<sect2> +<title>Adding New Printers with the Windows NT APW</title> + +<para> +By default, Samba exhibits all printer shares defined in &smb.conf; in the <guiicon>Printers</guiicon> +folder. Also located in this folder is the Windows NT Add Printer Wizard icon. The APW will be shown only if: +</para> + +<itemizedlist> + <listitem><para> + The connected user is able to successfully execute an <command>OpenPrinterEx(\\server)</command> with + administrative privileges (i.e., root or <smbconfoption name="printer admin"/>). + </para> + + <tip><para> Try this from a Windows 200x/XP DOS box command prompt: + </para> + + <para><userinput> + runas /netonly /user:root rundll32 printui.dll,PrintUIEntry /p /t0 /n \\<replaceable>SAMBA-SERVER</replaceable>\<replaceable>printersharename</replaceable> + </userinput></para> + + <para> + Click on <guibutton>Printing Preferences</guibutton>. + </para></tip></listitem> + + <listitem><para>... contains the setting + <smbconfoption name="show add printer wizard">yes</smbconfoption> (the + default).</para></listitem> +</itemizedlist> + +<para> +The APW can do various things: +</para> + +<itemizedlist> + <listitem><para> + Upload a new driver to the Samba <smbconfsection name="[print$]"/> share. + </para></listitem> + + <listitem><para> + Associate an uploaded driver with an existing (but still driverless) print queue. + </para></listitem> + + <listitem><para> + Exchange the currently used driver for an existing print queue with one that has been uploaded before. + </para></listitem> + + <listitem><para> + Add an entirely new printer to the Samba host (only in conjunction with a working + <smbconfoption name="add printer command"/>. A corresponding + <smbconfoption name="delete printer command"/> for removing entries from the + <guiicon>Printers</guiicon> folder may also be provided). + </para></listitem> +</itemizedlist> + +<para> +The last one (add a new printer) requires more effort than the previous ones. To use the APW to successfully +add a printer to a Samba server, the <smbconfoption name="add printer command"/> must have a defined value. +The program hook must successfully add the printer to the UNIX print system (i.e., to +<filename>/etc/printcap</filename>, <filename>/etc/cups/printers.conf</filename> or other appropriate files) +and to &smb.conf; if necessary. +</para> + +<para> +When using the APW from a client, if the named printer share does not exist, smbd will execute the +<smbconfoption name="add printer command"/> and reparse to attempt to locate the new printer share. If the +share is still not defined, an error of "<errorname>Access Denied"</errorname> is returned to the client. The +<smbconfoption name="add printer command"/> is executed under the context of the connected user, not +necessarily a root account. A <smbconfoption name="map to guest">bad user</smbconfoption> may have connected +you unwittingly under the wrong privilege. You should check it by using the <command>smbstatus</command> +command. +</para> + +</sect2> + +<sect2> +<title>Error Message: <quote>Cannot connect under a different Name</quote></title> + +<para> +Once you are connected with the wrong credentials, there is no means to reverse the situation other than +to close all Explorer windows, and perhaps reboot. +</para> + +<itemizedlist> + <listitem><para> +<indexterm><primary>net use</primary></indexterm> + The <command>net use \\SAMBA-SERVER\sharename /user:root</command> gives you an error message: + <quote>Multiple connections to a server or a shared resource by the same user utilizing + several user names are not allowed. Disconnect all previous connections to the server, + esp. the shared resource, and try again.</quote> + </para></listitem> + + <listitem><para> + Every attempt to <quote>connect a network drive</quote> to <filename>\\SAMBASERVER\\print$</filename> + to <constant>z:</constant> is countered by the pertinacious message: <quote>This + network folder is currently connected under different credentials (username and password). + Disconnect first any existing connection to this network share in order to connect again under + a different username and password</quote>. + </para></listitem> +</itemizedlist> + +<para> +So you close all connections. You try again. You get the same message. You check from the Samba side, using +<command>smbstatus</command>. Yes, there are more connections. You kill them all. The client still gives you +the same error message. You watch the smbd.log file on a high debug level and try reconnect. Same error +message, but not a single line in the log. You start to wonder if there was a connection attempt at all. You +run ethereal and tcpdump while you try to connect. Result: not a single byte goes on the wire. Windows still +gives the error message. You close all Explorer windows and start it again. You try to connect &smbmdash; and +this times it works! Windows seems to cache connection information somewhere and does not keep it up to date +(if you are unlucky, you might need to reboot to get rid of the error message). +</para> + +<para> +The easiest way to forcefully terminate all connections from your client to a server is by executing: +<screen> +&dosprompt; net use * /delete +</screen> +This will also disconnect all mapped drives and will allow you create fresh connection as required. +</para> +</sect2> + +<sect2> +<title>Take Care When Assembling Driver Files</title> + +<para> +You need to be extremely careful when you take notes about the files belonging to a particular +driver. Don't confuse the files for driver version <quote>0</quote> (for Windows 9x/Me, going into +<filename>[print$]/WIN/0/</filename>), driver version <filename>2</filename> (kernel mode driver for Windows NT, +going into <filename>[print$]/W32X86/2/</filename>; may be used on Windows 200x/XP also), and +driver version <quote>3</quote> (non-kernel mode driver going into <filename>[print$]/W32X86/3/</filename>; +cannot be used on Windows NT). Quite often these different driver versions contain +files that have the same name but actually are very different. If you look at them from +the Windows Explorer (they reside in <filename>%WINDOWS%\system32\spool\drivers\W32X86\</filename>), +you will probably see names in capital letters, while an <command>enumdrivers</command> command from Samba +would show mixed or lowercase letters, so it is easy to confuse them. If you install them manually using +<command>rpcclient</command> and subcommands, you may even succeed without an error message. Only later, +when you try install on a client, you will encounter error messages like <computeroutput>This server +has no appropriate driver for the printer</computeroutput>. +</para> + +<para> +Here is an example. You are invited to look closely at the various files, compare their names and +their spelling, and discover the differences in the composition of the version 2 and 3 sets. Note: the +version 0 set contained 40 <parameter>Dependentfiles</parameter>, so I left it out for space reasons: +</para> + +<para><screen> +&rootprompt;<userinput>rpcclient -U 'Administrator%<replaceable>secret</replaceable>' -c 'enumdrivers 3' 10.160.50.8 </userinput> + + Printer Driver Info 3: + Version: [3] + Driver Name: [Canon iR8500 PS3] + Architecture: [Windows NT x86] + Driver Path: [\\10.160.50.8\print$\W32X86\3\cns3g.dll] + Datafile: [\\10.160.50.8\print$\W32X86\3\iR8500sg.xpd] + Configfile: [\\10.160.50.8\print$\W32X86\3\cns3gui.dll] + Helpfile: [\\10.160.50.8\print$\W32X86\3\cns3g.hlp] + + Dependentfiles: [\\10.160.50.8\print$\W32X86\3\aucplmNT.dll] + Dependentfiles: [\\10.160.50.8\print$\W32X86\3\ucs32p.dll] + Dependentfiles: [\\10.160.50.8\print$\W32X86\3\tnl32.dll] + Dependentfiles: [\\10.160.50.8\print$\W32X86\3\aussdrv.dll] + Dependentfiles: [\\10.160.50.8\print$\W32X86\3\cnspdc.dll] + Dependentfiles: [\\10.160.50.8\print$\W32X86\3\aussapi.dat] + Dependentfiles: [\\10.160.50.8\print$\W32X86\3\cns3407.dll] + Dependentfiles: [\\10.160.50.8\print$\W32X86\3\CnS3G.cnt] + Dependentfiles: [\\10.160.50.8\print$\W32X86\3\NBAPI.DLL] + Dependentfiles: [\\10.160.50.8\print$\W32X86\3\NBIPC.DLL] + Dependentfiles: [\\10.160.50.8\print$\W32X86\3\cpcview.exe] + Dependentfiles: [\\10.160.50.8\print$\W32X86\3\cpcdspl.exe] + Dependentfiles: [\\10.160.50.8\print$\W32X86\3\cpcedit.dll] + Dependentfiles: [\\10.160.50.8\print$\W32X86\3\cpcqm.exe] + Dependentfiles: [\\10.160.50.8\print$\W32X86\3\cpcspl.dll] + Dependentfiles: [\\10.160.50.8\print$\W32X86\3\cfine32.dll] + Dependentfiles: [\\10.160.50.8\print$\W32X86\3\cpcr407.dll] + Dependentfiles: [\\10.160.50.8\print$\W32X86\3\Cpcqm407.hlp] + Dependentfiles: [\\10.160.50.8\print$\W32X86\3\cpcqm407.cnt] + Dependentfiles: [\\10.160.50.8\print$\W32X86\3\cns3ggr.dll] + + Monitorname: [] + Defaultdatatype: [] + + Printer Driver Info 3: + Version: [2] + Driver Name: [Canon iR5000-6000 PS3] + Architecture: [Windows NT x86] + Driver Path: [\\10.160.50.8\print$\W32X86\2\cns3g.dll] + Datafile: [\\10.160.50.8\print$\W32X86\2\IR5000sg.xpd] + Configfile: [\\10.160.50.8\print$\W32X86\2\cns3gui.dll] + Helpfile: [\\10.160.50.8\print$\W32X86\2\cns3g.hlp] + + Dependentfiles: [\\10.160.50.8\print$\W32X86\2\AUCPLMNT.DLL] + Dependentfiles: [\\10.160.50.8\print$\W32X86\2\aussdrv.dll] + Dependentfiles: [\\10.160.50.8\print$\W32X86\2\cnspdc.dll] + Dependentfiles: [\\10.160.50.8\print$\W32X86\2\aussapi.dat] + Dependentfiles: [\\10.160.50.8\print$\W32X86\2\cns3407.dll] + Dependentfiles: [\\10.160.50.8\print$\W32X86\2\CnS3G.cnt] + Dependentfiles: [\\10.160.50.8\print$\W32X86\2\NBAPI.DLL] + Dependentfiles: [\\10.160.50.8\print$\W32X86\2\NBIPC.DLL] + Dependentfiles: [\\10.160.50.8\print$\W32X86\2\cns3gum.dll] + + Monitorname: [CPCA Language Monitor2] + Defaultdatatype: [] + +</screen></para> + +<para> +If we write the <quote>version 2</quote> files and the <quote>version 3</quote> files +into different text files and compare the result, we see this +picture: +</para> + +<para><screen> +&rootprompt;<userinput>sdiff 2-files 3-files</userinput> + +<![CDATA[ + cns3g.dll cns3g.dll + iR8500sg.xpd iR8500sg.xpd + cns3gui.dll cns3gui.dll + cns3g.hlp cns3g.hlp + AUCPLMNT.DLL | aucplmNT.dll + > ucs32p.dll + > tnl32.dll + aussdrv.dll aussdrv.dll + cnspdc.dll cnspdc.dll + aussapi.dat aussapi.dat + cns3407.dll cns3407.dll + CnS3G.cnt CnS3G.cnt + NBAPI.DLL NBAPI.DLL + NBIPC.DLL NBIPC.DLL + cns3gum.dll | cpcview.exe + > cpcdspl.exe + > cpcqm.exe + > cpcspl.dll + > cfine32.dll + > cpcr407.dll + > Cpcqm407.hlp + > cpcqm407.cnt + > cns3ggr.dll +]]> +</screen> + +Do not be fooled! Driver files for each version with identical +names may be different in their content, as you can see from this size +comparison: +</para> + +<para><screen> +&rootprompt;<userinput>for i in cns3g.hlp cns3gui.dll cns3g.dll; do \ + smbclient //10.160.50.8/print\$ -U 'Administrator%xxxx' \ + -c "cd W32X86/3; dir $i; cd .. ; cd 2; dir $i"; \ + done</userinput> + + CNS3G.HLP A 122981 Thu May 30 02:31:00 2002 + CNS3G.HLP A 99948 Thu May 30 02:31:00 2002 + + CNS3GUI.DLL A 1805824 Thu May 30 02:31:00 2002 + CNS3GUI.DLL A 1785344 Thu May 30 02:31:00 2002 + + CNS3G.DLL A 1145088 Thu May 30 02:31:00 2002 + CNS3G.DLL A 15872 Thu May 30 02:31:00 2002 +</screen></para> + +<para> +In my example were even more differences than shown here. Conclusion: you must be careful to select the +correct driver files for each driver version. Don't rely on the names alone, and don't interchange files +belonging to different driver versions. +</para> +</sect2> + +<sect2> +<title>Samba and Printer Ports</title> + +<para> +<indexterm><primary>LPT1:</primary></indexterm> +<indexterm><primary>COM1:</primary></indexterm> +<indexterm><primary>FILE:</primary></indexterm> +<indexterm><primary>available port</primary></indexterm> +Windows NT/2000 print servers associate a port with each printer. These normally take the form of +<filename>LPT1:</filename>, <filename>COM1:</filename>, <filename>FILE:</filename>, and so on. Samba must also +support the concept of ports associated with a printer. By default, only one printer port, named <quote>Samba +Printer Port</quote>, exists on a system. Samba does not really need such a <quote>port</quote> in order to +print; rather it is a requirement of Windows clients. They insist on being told about an available port when +they request this information; otherwise, they throw an error message at you. So Samba fakes the port +information to keep the Windows clients happy. +</para> + +<para> +<indexterm><primary>Printer Pooling</primary></indexterm> +Samba does not support the concept of <constant>Printer Pooling</constant> internally either. Printer +pooling assigns a logical printer to multiple ports as a form of load balancing or failover. +</para> + +<para> +If you require multiple ports to be defined for some reason or another (my users and my boss should not know +that they are working with Samba), configure the <smbconfoption name="enumports command"/>, +which can be used to define an external program that generates a listing of ports on a system. +</para> +</sect2> + +<sect2> +<title>Avoiding Common Client Driver Misconfiguration</title> + +<para> +So now the printing works, but there are still problems. Most jobs print well, some do not print at +all. Some jobs have problems with fonts, which do not look good. Some jobs print fast and some +are dead-slow. We cannot cover it all, but we want to encourage you to read the brief paragraph about +<quote>Avoiding the Wrong PostScript Driver Settings</quote> in <link linkend="CUPS-printing">CUPS Printing +Chapter</link>, <link linkend="cups-avoidps1">Avoiding Critical PostScript Driver Settings on the +Client</link>. +</para> +</sect2> +</sect1> + +<sect1> +<title>The Imprints Toolset</title> + +<para> +<indexterm><primary>Imprints</primary></indexterm> +The Imprints tool set provides a UNIX equivalent of the Windows NT APW. For complete information, please +refer to the <ulink url="http://imprints.sourceforge.net/">Imprints</ulink> Web site as well as the +documentation included with the Imprints source distribution. This section provides only a brief introduction +to the features of Imprints. +</para> + +<para> +Unfortunately, the Imprints toolset is no longer maintained. As of December 2000, the project is in +need of a new maintainer. The most important skill to have is Perl coding and an interest in MS-RPC-based +printing used in Samba. If you wish to volunteer, please coordinate your efforts on the Samba technical +mailing list. The toolset is still in usable form, but only for a series of older printer models where +there are prepared packages to use. Packages for more up-to-date print devices are needed if Imprints +should have a future. Information regarding the Imprints toolset can be obtained from the <ulink +url="http://imprints.sourceforge.net/">Imprints</ulink> home page. +</para> + +<sect2> +<title>What Is Imprints?</title> + +<para> +Imprints is a collection of tools for supporting these goals: +</para> + +<itemizedlist> + <listitem><para> + Providing a central repository of information regarding Windows NT and 95/98 printer driver packages. + </para></listitem> + + <listitem><para> + Providing the tools necessary for creating the Imprints printer driver packages. + </para></listitem> + + <listitem><para> + Providing an installation client that will obtain printer drivers from a central Internet (or intranet) Imprints Server + repository and install them on remote Samba and Windows NT4 print servers. + </para></listitem> +</itemizedlist> +</sect2> + +<sect2> +<title>Creating Printer Driver Packages</title> + +<para> +The process of creating printer driver packages is beyond the scope of this document (refer to Imprints.txt, +included with the Samba distribution for more information). In short, an Imprints driver package +is a gzipped tarball containing the driver files, related INF files, and a control file needed by the +installation client. +</para> +</sect2> + +<sect2> +<title>The Imprints Server</title> + +<para> +The Imprints server is really a database server that may be queried via standard HTTP mechanisms. Each +printer entry in the database has an associated URL for the actual downloading of the package. Each +package is digitally signed via GnuPG, which can be used to verify that +the package downloaded is actually +the one referred in the Imprints database. It is strongly recommended that this security check +not be disabled. +</para> +</sect2> + +<sect2> +<title>The Installation Client</title> + +<para> +More information regarding the Imprints installation client is available from the documentation file +<filename>Imprints-Client-HOWTO.ps</filename> that is included with the Imprints source package. The Imprints +installation client comes in two forms: +</para> + +<itemizedlist> + <listitem><para>A set of command-line Perl scripts.</para></listitem> + <listitem><para>A GTK+-based graphical interface to the command-line Perl scripts.</para></listitem> +</itemizedlist> + +<para> +The installation client (in both forms) provides a means of querying the Imprints database server for +a matching list of known printer model names as well as a means to download and install the drivers on +remote Samba and Windows NT print servers. +</para> + +<para> +The basic installation process is in four steps, and Perl code is wrapped around smbclient and rpcclient. +</para> + +<itemizedlist> + <listitem><para> + For each supported architecture for a given driver: + <orderedlist> + <listitem><para>rpcclient: Get the appropriate upload directory on the remote server.</para></listitem> + <listitem><para>smbclient: Upload the driver files.</para></listitem> + <listitem><para>rpcclient: Issues an AddPrinterDriver() MS-RPC.</para></listitem> + </orderedlist> + </para></listitem> + + <listitem><para>rpcclient: Issues an AddPrinterEx() MS-RPC to actually create the printer.</para></listitem> +</itemizedlist> + +<para> +One of the problems encountered when implementing the Imprints tool set was the namespace issues between +various supported client architectures. For example, Windows NT includes a driver named <quote>Apple LaserWriter +II NTX v51.8</quote>, and Windows 95 calls its version of this driver <quote>Apple LaserWriter II NTX</quote>. +</para> + +<para> +The problem is how to know what client drivers have been uploaded for a printer. An astute reader will +remember that the Windows NT Printer Properties dialog only includes space for one printer driver name. A +quick look in the Windows NT 4.0 system registry at: +</para> + +<para><filename> + HKLM\System\CurrentControlSet\Control\Print\Environment +</filename></para> + +<para> +will reveal that Windows NT always uses the NT driver name. This is okay because Windows NT always requires +that at least the Windows NT version of the printer driver is present. Samba does not have the +requirement internally; therefore, <quote>How can you use the NT driver name if it has not already been installed?</quote> +</para> + +<para> +The way of sidestepping this limitation is to require that all Imprints printer driver packages include both the Intel Windows NT and +95/98 printer drivers and that the NT driver is installed first. +</para> +</sect2> +</sect1> + +<sect1> +<title>Adding Network Printers without User Interaction</title> + +<para> +The following MS Knowledge Base article may be of some help if you need to handle Windows 2000 clients: +<emphasis>How to Add Printers with No User Interaction in Windows 2000,</emphasis> (<ulink +url="http://support.microsoft.com/default.aspx?scid=kb;en-us;189105">Microsoft KB 189105</ulink>). It also +applies to Windows XP Professional clients. The ideas sketched out in this section are inspired by this +article, which describes a command-line method that can be applied to install network and local printers and +their drivers. This is most useful if integrated in Logon Scripts. You can see what options are available by +typing in the command prompt (<command>DOS box</command>): +</para> + +<para><userinput>rundll32 printui.dll,PrintUIEntry /?</userinput></para> + +<para> +A window pops up that shows you all of the command-line switches available. An extensive list of examples +is also provided. This is only for Windows 200x/XP; it does not work on Windows NT. Windows NT probably has +some other tools in the respective Resource Kit. Here is a suggestion about what a client logon script +might contain, with a short explanation of what the lines actually do (it works if 200x/XP Windows +clients access printers via Samba, and works for Windows-based print servers too): +</para> + +<para><screen> +<userinput>rundll32 printui.dll,PrintUIEntry /dn /n "\\cupsserver\infotec2105-IPDS" /q</userinput> +<userinput>rundll32 printui.dll,PrintUIEntry /in /n "\\cupsserver\infotec2105-PS"</userinput> +<userinput>rundll32 printui.dll,PrintUIEntry /y /n "\\cupsserver\infotec2105-PS"</userinput> +</screen></para> + +<para> +Here is a list of the used command-line parameters: +</para> + +<variablelist> + <varlistentry><term>/dn</term> + <listitem><para>deletes a network printer.</para></listitem> + </varlistentry> + <varlistentry><term>/q</term> + <listitem><para>quiet modus.</para></listitem> + </varlistentry> + <varlistentry><term>/n</term> + <listitem><para>names a printer.</para></listitem> + </varlistentry> + <varlistentry><term>/in</term> + <listitem><para>adds a network printer connection.</para></listitem> + </varlistentry> + <varlistentry><term>/y</term> + <listitem><para>sets printer as default printer.</para></listitem> + </varlistentry> +</variablelist> + +<itemizedlist> + <listitem><para> + Line 1 deletes a possibly existing previous network printer <emphasis>infotec2105-IPDS</emphasis> + (which had used native Windows drivers with LPRng that were removed from the server that was + converted to CUPS). The <command>/q</command> at the end prevents confirm + or error dialog boxes from popping up. They should not be presented to the user logging on. + </para></listitem> + + <listitem><para> + Line 2 adds the new printer + <emphasis>infotec2105-PS</emphasis> (which actually is the same + physical device but is now run by the new CUPS printing system and associated with the + CUPS/Adobe PS drivers). The printer and its driver must have been added to Samba prior to + the user logging in (e.g., by a procedure as discussed earlier in this chapter or by running + <command>cupsaddsmb</command>). The driver is now autodownloaded to the client PC where the + user is about to log in. + </para></listitem> + + <listitem><para> + Line 3 sets the default printer to this new network printer (there might be several other + printers installed with this same method, and some may be local as well, so we decide for a + default printer). The default printer selection may, of course, be different for different users. + </para></listitem> +</itemizedlist> + +<para> +The second line only works if the printer <emphasis>infotec2105-PS</emphasis> has an already working +print queue on the <constant>cupsserver</constant> and if the +printer drivers have been successfully uploaded +(via the <command>APW</command>, <command>smbclient/rpcclient</command>, or <command>cupsaddsmb</command>) +into the <smbconfsection name="[print$]"/> driver repository of Samba. Some Samba versions +prior to version 3.0 required a restart of smbd after the printer install and the driver upload; +otherwise the script (or any other client driver download) would fail. +</para> + +<para> +Since there is no easy way to test for the existence of an installed network printer from the logon script, +do not bother checking. Just allow the de-installation/re-installation to occur every time a user logs in; +it's really quick anyway (1 to 2 seconds). +</para> + +<para> +The additional benefits for this are: +</para> + +<itemizedlist> + <listitem><para> + It puts in place any printer default setup changes automatically at every user logon. + </para></listitem> + + <listitem><para> + It allows for <quote>roaming</quote> users' login to the domain from different workstations. + </para></listitem> +</itemizedlist> + +<para> +Since network printers are installed per user, this much simplifies the process of keeping the installation +up to date. The few extra seconds at logon time will not really be noticeable. Printers can be centrally +added, changed, and deleted at will on the server with no user intervention required from the clients +(you just need to keep the logon scripts up to date). +</para> +</sect1> + +<sect1> +<title>The <command>addprinter</command> Command</title> + +<para> +The <command>addprinter</command> command can be configured to be a shell script or program executed by +Samba. It is triggered by running the APW from a client against the Samba print server. The APW asks +the user to fill in several fields (such as printer name, driver to be used, comment, port monitor, +and so on). These parameters are passed on to Samba by the APW. If the addprinter command is designed in a +way that it can create a new printer (through writing correct printcap entries on legacy systems or +by executing the <command>lpadmin</command> command on more modern systems) and create the associated share, +then the APW will in effect really create a new printer on Samba and the UNIX print subsystem! +</para> +</sect1> + +<sect1> +<title>Migration of Classical Printing to Samba</title> + +<para> +The basic NT-style printer driver management has not changed considerably in 3.0 over the 2.2.x releases +(apart from many small improvements). Here migration should be quite easy, especially if you followed +previous advice to stop using deprecated parameters in your setup. For migrations from an existing 2.0.x +setup, or if you continued Windows 9x/Me-style printing in your Samba 2.2 installations, it is more of +an effort. Please read the appropriate release notes and the HOWTO Collection for Samba-2.2.x. You can +follow several paths. Here are possible scenarios for migration: +</para> + +<itemizedlist> + <listitem><para> + You need to study and apply the new Windows NT printer and driver support. Previously used + parameters <parameter>printer driver file</parameter>, <parameter>printer driver</parameter>, + and <parameter>printer driver location</parameter> are no longer supported. + </para></listitem> + + <listitem><para> + If you want to take advantage of Windows NT printer driver support, you also need to migrate the + Windows 9x/Me drivers to the new setup. + </para></listitem> + + <listitem><para> + An existing <filename>printers.def</filename> file (the one specified in the now removed parameter + <parameter>printer driver file</parameter>) will no longer work with Samba-3. In 3.0, smbd attempts + to locate Windows 9x/Me driver files for the printer in <smbconfsection name="[print$]"/> + and additional settings in the TDB and only there; if it fails, it will <emphasis>not</emphasis> + (as 2.2.x used to do) drop down to using a <filename>printers.def</filename> (and all associated + parameters). The make_printerdef tool is removed and there is no backward compatibility for this. + </para></listitem> + + <listitem><para>You need to install a Windows 9x/Me driver into the + <smbconfsection name="[print$]"/> share for a printer on your Samba + host. The driver files will be stored in the <quote>WIN40/0</quote> subdirectory of + <smbconfsection name="[print$]"/>, and some other settings and information go + into the printing-related TDBs.</para></listitem> + + <listitem><para> + If you want to migrate an existing <filename>printers.def</filename> file into the new setup, the only current + solution is to use the Windows NT APW to install the NT drivers and the 9x/Me drivers. This can be scripted + using smbclient and rpcclient. See the Imprints installation client on the <ulink noescape="1" + url="http://imprints.sourceforge.net/">Imprints</ulink> web site for example. See also the discussion of + rpcclient usage in <link linkend="CUPS-printing">CUPS Printing</link>. + </para></listitem> +</itemizedlist> +</sect1> + +<sect1> +<title>Publishing Printer Information in Active Directory or LDAP</title> + +<para> +This topic has also been addressed in <link linkend="NetCommand">Remote and Local Management &smbmdash; The +Net Command</link>. If you wish to volunteer your services to help document this further, please contact +<ulink url="mail://jht@samba.org">John H. Terpstra</ulink>. +</para> +</sect1> + +<sect1> +<title>Common Errors</title> + +<sect2> +<title>I Give My Root Password but I Do Not Get Access</title> + +<para> +Do not confuse the root password, which is valid for the UNIX system (and in most cases stored in the +form of a one-way hash in a file named <filename>/etc/shadow</filename>), with the password used to +authenticate against Samba. Samba does not know the UNIX password. Root access to Samba resources +requires that a Samba account for root must first be created. This is done with the <command>smbpasswd</command> +command as follows: +<screen> +&rootprompt; smbpasswd -a root +New SMB password: secret +Retype new SMB password: secret +</screen> +</para> + +</sect2> + +<sect2> +<title>My Print Jobs Get Spooled into the Spooling Directory, but Then Get Lost</title> + +<para> +Do not use the existing UNIX print system spool directory for the Samba spool directory. It may seem +convenient and a savings of space, but it only leads to problems. The two must be separate. The UNIX/Linux +system print spool directory (e.g., <filename>/var/spool/cups</filename>) is typically owned by a +non-privileged user such as <literal>cups</literal> or <literal>lp</literal>. Additionally. the permissions on +the spool directory are typically restrictive to the owner and/or group. On the other hand, the Samba +spool directory must be world writable, and should have the 't' bit set to ensure that only a temporary +spool file owner can change or delete the file. +</para> + +<para> +Depending on the type of print spooling system in use on the UNIX/Linux host, files that the spool +management application finds and that are not currently part of job queue that it is managing can be deleted. +This may explain the observation that jobs are spooled (by Samba) into this directory and just disappear. +</para> + +</sect2> +</sect1> + +</chapter> |