Understanding the export printer driver feature

[Kurt Pfeifle]

Kurt Pfeifle wrote:

> Michael Goffioul wrote:
> 
>>> OK, I've now got a copy of all the files in the list, but am having a 
>>> slight
>>> problemw ith the export bit. In my case I'm running cups & samba on 
>>> an old
>>> P150, and am running KDE on my laptop. Does KDEPrint require that the 
>>> wizard
>>> and cups/samba servers be running on the same system? If not, where 
>>> do I put
>>> the files on my laptop so that KDEPrint will find them to export them?
>>
>>
>>
>> I don't think CUPS server must be running,
> 
> 
> No -- cupsd *must* be running too; but not necessarily on the same 
> system. In
> the case of the "KDE Export Driver Wizard" on the laptop, it only needs the
> CUPS and Samba client parts of the programs installed. [I bet Michael knows
> this, because his KDEPrint Wizards work....  ;-)  but his remarks might not
> be understood fully because of their brevity...]
> 
> NOTE, that there could be not just 2, but 3 different hosts 
> participating in
> the execution of the command(s) [or even 4, if you count the printing Win
> clients too]:
> 
>    * the one where "cupsaddsmb" is executed (which at least needs CUPS 
>      client commands and Samba client commands installed);
> 
>    * the CUPS server with the actual printer (and a Ghostscript or other 
>      CUPS driver) -- specified with "-h cupsservername" (CUPS server needs 
>      Samba installed too);

Hmmmm -- this last sentence should *of course* have read "CUPS server needs
*not* Samba installed too" (as I made clear in the mail at all other places).
Sorry.

>    * the Samba server which offers the (PS-) Win driver for download 
>      from its [print$]-share  --  specified with "-H sambaservername" 
 >      (*this*  Samba server doesn't necessarily require a CUPS installation).
> 
> If you don't give "-h" or "-H" options it is assumed that everything 
> concerns
> localhost only.
> 
> 
>> but samba server should be
>> running 
> 
> 
> On the notebook you don't necessarily need a Samba *daemon* running...
> 
>> as cupsaddsmb (and KDEPrint) uses smbclient and rpcclient
>> are used internally.
> 
> 
> Before smbclient and rpcclient are doing their work, cupsaddsmb uses IPP
> calls to retrieve the real PPD for the printer ("from /etc/cups/ppd/") from
> the CUPS server. This part of the cupsaddsmb command is not visible from
> the "-v" verbose output (see for an example what the output looks like at
> http://de.samba.org/samba/docs/Samba-HOWTO-Collection.html#AEN1089 -- 
> note that
> it looks a bit different in more recent versions of CUPS and Samba.).
> 
> This is then copied to "/var/spool/cups/tmp/some-random-name" of the host
> where the cupsaddsmb command runs, and used by smbclient to "put" it to the
> intended Samba-Server's [print$]-share for download:
> 
>    smbclient //sambaservername/print\$ -N -U'root%secret' \
>       -c 'mkdir W32X86;put /var/spool/cups/tmp/3cd1cc66376c0 
> W32X86/infotec_IS2027.PPD...
> 
> and later "rpcclient" enables and activates the drivers and initializes
> the correct "device mode". (This stuff is required by the Windows clients;
> basically it is s.th. which emulates what a MS Win NT print server would
> retrieve from its registry when a Win client asks for it during driver
> installation... [That's why a simple copying of the files to the
> [print$]-share doesn't work. Samba stores this info in various *.tdb
> files -- "ntdrivers.tdb", "ntprinters.tdb" and "printing.tdb"]):
> 
>    rpcclient sambaservername -N -U'root%secret' \
>       -c 'adddriver "Windows NT x86" \
>       
> "infotec_IS2027:ADOBEPS5.DLL:infotec_IS2027.PPD:ADOBEPSU.DLL:ADOBEPSU.HLP:NULL:RAW:NULL"' 
> 
> 
>    rpcclient localhost -N -U'root%secret' -c 'setdriver infotec_IS2027 
> infotec_IS2027'
> 
> At this stage all the files should be in the [print$]-share for download.
> The clients "see" a shared printer on the Samba server with the driver
> files possibly as "printername@cupsserver" (if the CUPS server had
> "BrowseShortNames Off"). When they download the driver, the printer is
> installed as "printername@cupsserver on sambaserver", where
> "printername@cupsserver" is the name of the printer and "on sambaserver"
> is automatically added. (This has been tested with Win 2K and XP
> clients by me -- dunno about Win 9x/NT clients, where it might not work
> at all or where the indicated printername might be different).
> 
> An actual print job would get spooled to the Samba server first (using
> MS RPC printing calls), then transferred to the CUPS server (using the CUPS
> API, because Samba is compiled against libcups), whereupon CUPS does the
> rest of the job. (NOTE, that Samba doesn't need to be running on the
> CUPS server because the primary Samba server is able to transfer the job
> to the CUPS server using the CUPS API (with IPP).
> 
> I hope I didn't confuse you too much. (For me, it actually helped to
> understand the whole network transparent mechanism better, once I thought
> of the the procedure taking place on three different hosts [or four, once
> you counted the Win clients in]...).

[ I am not sure if the ASCII art drawing which I included here was
   readable for everyone receiving it or if it was garbled...]

> Once a Win client downloads the driver from the Samba server and prints,
> the CUPS server does *not* need a running Samba server  --  because 
> Samba is
> compiled against "libcups" it is a perfect CUPS IPP client and can transfer
> the jobfile remotely (by using CUPS IPP functions) into the CUPS spool 
> directory.
> 
> 
> 
>> The location where to put the files is the
>> same as for cupsaddsmb, chech manual page.
> 
> 
> IIRC, this also works with KDEPrint (long time since I tested this.). 
> However,
> it is a bit less comfortable than the commandline. While you can type in 
> the
> (remote) Samba server directly in the "Export driver..." dialog, you need
> to specify the (remote) CUPS server by using the "Configure Manager" -->
> "CUPS server" dialog first. (And BTW, this part of KDEPrint has working
> "What's this?" quickhelps...)
> 
>> Michael.
> 
> 
> Cheers,
> Kurt