[Samba] PDF printing problem - can't find Samba's spool file?

[Kurt Pfeifle]

David Brodbeck wrote:

>>I guess anybody here on the list who is slightly interested in printing
>>thought when reading your first mail: "Well, if Dave is System Admin,  he'll
>>surely know *which* printing system he upgraded, and to *which version*. If he
>>doesn't want to tell us -- we can't help him. Maybe he realizes the gap
>>in the info he's provided and and he'll deliver it in an afterglow. Let's
>>wait until he comes forward with it..."
> 
> If you had actually looked at the information I posted,

I'm reading Samba-digest, so I am not always current. It is more difficult to
go back and read previous messages in a thread. I just looked at the one you
pasted beneath. It said you upgraded your printing system (not which one) and
your problems started then....

> you'd have noticed
> that I had decided to do what everyone else seems to be doing with their PDF
> printers, and avoided the printing system altogether.

*Seems*...

I tell you what mine is doing: It *uses* the printing system. My printing
system is CUPS, the most flexible one of them all. I use a bash shell
script which is made to work as a CUPS "backend". This backend essentially
passes the job file to "ps2pdf" (part of Ghostscript). I have a printer
named "PDFGenerator", tied to that backend. The printer uses a "distiller.ppd"
to describe the options available for that printer. All clients can use this
"printer" automatically, with the possibility to set some options of their
own (like resolution), because it is included by the CUPS server when it
sends out its "browsing" information to the clients. Even Windows clients
can use it (they have the "CUPS PostScript Driver for WinNT/2K/XP" installed
associated with the very same distiller.ppd) -- the driver downloaded to them
with the help of the Samba "point and print" functionality. All PDF jobs (may
be any printable file format) can be send from all applications, from all
clients and are subject to all the CUPS features (accounting, quotas,
authentication, encryption...) if I want. It uses the CUPS filtering system
to create a PostScript from the original file (which may be any graphic
format, text, PDF or PostScript). Clients can send jobs via SMB, IPP,
LPR/LPD, AppleTalk or whatever is set up on the CUPS server to serve the
clients.

This PDF-generating CUPS backend is based on Michael Goffioul's (KDEPrint
programmer of fame) little script as is published at

   http://printing.kde.org/downloads/

My version is heavily extended and customized: The name of the PDF file is
a concatenation of the submitting username, the original file name and
the time of "printing". It is used to print the file(s) on paper on a
certain printer and create the PDF as a reference. (Also you could easily
use just the PDF creation).

> I didn't post that
> information because it didn't seem relevent to the question.

You yourself indicated that it is relevant because you said after
the upgrade your script stopped working...

>>>[pdf2]
>>>        path = /export/spool
>>>        printable = yes
>>>        guest ok = yes
>>>        print command = /usr/local/bin/mkpdf2.pl %s %U %I >>tmp/pdf.log 2>&1
>>>        lpq command =
>>>        lprm command =
> 
> This won't go through the printing system at all, will it, since I've
> specified a 'print command' entry?

You don't reveal to us what your "mkpdf2.pl" script does, so no-one can
tell from the info you first gave. But if you say so: no, then it won't
go thru the print system.

> My problem is that Samba never seems to
> create the job file in the /export/spool directory.  It just isn't there
> when my script is called by Samba.
> 
> However, if the information will satisfy your sarcasm reflex,

No, it satisfies the info request I asked from you.

And, BTW, you shouldn't call people any names, who are giving their
private time for free to help people who seem to have problems in their
profession -- or be prepared to get no answer at all. See, I get a lot
of private mail asking similar questions (which I don't answer any more,
but send a "copied and pasted standard answer" explaining it and asking
them to go to a newsgroup, but enrich their request with info about
their system. And you don't believe how often some shipwrecked guys
describe nothing about their setup and how they seem to expect we're
able to read from the crystal balls ans help them within the next hour....

> I was
> previously using LPRng, but a RedHat security update seems to have changed
> me over to CUPS 1.1.14.

OK -- now it would be great if you could confirm that you have *in
fact* CUPS in use... (instead of "seem to have"). It probably *is*
important to your problem:

As was pointed out on this list a few times (and can be read in "man
smb.conf"), CUPS is the printing system most closely integrated into
Samba. In fact, Samba by default links against the "libcups" library,
if it is discovered on the system during compile-time.

So, the situation is....

   ...*if* you have Samba linked against "libcups" (check by issuing
      "ldd `which smbd`"), and
   ...*if* you have set "printing = cups" in smb.conf, and
   ...*if* you have set "printing = printcap"

*then* Samba should know everything about the available printers and
the appropriate print commands (and lpq commands, lppause commands
etc.) already, because it is using the CUPS API directly. In fact it
is even *ignoring* *all* *manually* *set* *print* *commands* in
"smb.conf".

If this is the case for you, you have 4 options:

* set "printing = bsd" in smb.conf and see if your own print
   command is now working.

* modify your script to run as a CUPS backend (similar to the
   one I quoted above).

* go try the "PDF distiller script" by Michael Goffioul (with
   your custom adaptions if you need).

* go back to LPRng which seems to have kept you and your
   script happy.

Other than that, here are a few more general troubleshooting
hints, which could be used for all sorts of problems with Samba
involved:

* look into the Samba log files to discover traces of your
   PDF job(s) and see what Samba is doing with them. Probably
   you have "debuglevel 0" and will not find anything. Increase
   the loglevel and look again.

* Samba has a great little utility, which lets you increase
   and decrease the debuglevel "on the fly", without editing
   and reloading the smb.conf or stopping and starting the
   daemon:

    "smbcontrol smbd debuglevel"  # tells you the current debuglevel
    "smbcontrol smbd debug 3"     # set the debuglevel to 3

Please keep us informed about your success (or lack of). I hate
most to read on this (and other) lists a great many good
advices and hints by other participants, but people who asked
just go away with the answer(s) and don't tell if it helped or
not. This keeps me sometimes curious forever. I myself like to
know if I sent to or left people in "Broken-Setup-Nowhereland",
or if my advice did work. Because I am not a guru and I
keep learning through these exchanges and feedback...

Cheers,
Kurt