Trying to get one Samba server to serve several printers through CUPS and host a virtual PDF "printer" at the same time. I've gotten them working separately, but not together, and I think I know why. In the smb.conf man page under "print command": "With printing = cups, and if SAMBA is compiled against libcups, any manually set print command will be ignored." My PDF printer relies on a print command field (print command = /usr/bin/printpdf %s) as recommended in the PDF printer howto here: http://www.linuxgazette.com/issue72/bright.html So is it possible to use CUPS and a "print command" in the same Samba server? Why are print commands ignored anyway? Thanks in advance for any responses. -Tom
> http://www.linuxgazette.com/issue72/bright.html > > So is it possible to use CUPS and a "print command" in the same Samba > server? Why are print commands ignored anyway? Thanks in advance for any > responses. > > -TomThe political correct way in this case is to create a pdf-backend for cups. Doing that, both linux and windows boxes can print pdfs and samba can handle that with no probs. Sorry for not having a link, but i guess if you google something like "cups pdf backend", you'll get some results. cya jk
Tom wrote on samba-digest:> > Trying to get one Samba server to serve several printers through CUPS > and host a virtual PDF "printer" at the same time. I've gotten them > working separately, but not together, and I think I know why. > > In the smb.conf man page under "print command": > > "With printing = cups, and if SAMBA is compiled against libcups, any > manually set print command will be ignored."If you want to regain your control over the print command(s), set "printing = sysv". You'll loose all the convenient Samba/CUPS interoperation, though.> My PDF printer relies on a print command field (print command = > /usr/bin/printpdf %s) as recommended in the PDF printer howto here: > > http://www.linuxgazette.com/issue72/bright.htmlThis is only *one* of the many options to create a "PDF printer". It is geared towards working with a legacy, old-fashioned spooling system. It will only serve your Windows clients. Should you need to support Unix/Linux/MacOSX clients too with your print server, you'd need to set up a separate PDF printer for these type of clients. A better way to set up a PDF generation service for print clients is to use the PDF creating CUPS "backend" as provided on http://printing.kde.org/downloads/ You need the backend provided there plus a PPD for a generic PostScript printer (best, use the distiller.ppd as was provided once for Acrobat 3 by Adobe -- it still floats around in various dl areas on the internet). If you set up a printer using this backend, the PDF printer will be shared to all print clients, Linux, Unix, Mac OS X and Windows. Samba's Point and Print capabilities will even make possible to download the "driver" to all Windows clients (Unix clients get the "driver" through CUPS native capabilities). It means you can send all formats supported by CUPS to this PDF printer: ASCII, image files, PS, PDF... and CUPS will take care to convert everything to PostScript and the PDF backend will generate the PDF...> So is it possible to use CUPS and a "print command" in the same Samba > server?See above.> Why are print commands ignored anyway?Samba is linked against libcups and therefor "knows" how to talk to a (local or remoute) CUPS server. In a way, Samba has inherited IPP functions through this library link...> Thanks in advance for any > responses. > > -TomCheers, Kurt
Yes, it is. In my opinion it is the easyest way is, to execute the script within cups. What does this mean: You can write your own printer processors in Cups. The create a printer which uses these processor. A description can be found at: http://slowest.net/docs/howtos/print/freepdf.html Another usefull description about integrating hylafax via cups without having a fax client can be found at: http://www.purpel3.com/sambafax/samba_samcups_4m.html Regrads JJ ----------------------------------------------------------------------------------------------- J?rg Junge EDV-Koordinator Parit?tischer Wohlfahrtsverband Landesverband Th?ringen e.V. Bergstr. 11 99192 Neudietendorf Deutschland Tel : +49 36202 26 204 Fax: +49 36202 26 234 So is it possible to use CUPS and a "print command" in the same Samba server? Why are print commands ignored anyway? Thanks in advance for any responses.
Everything goes smoothly with the installation... drop 'pdfdistiller'
into /usr/lib/cups/backend, chmod +x, restart cups service. Add a
printer in cups with:
'lpadmin -p PDF -E -v pdf:/tmp/'
...and voila! Nothing happens. Doesn't give any errors, but it won't
print ('lpr -P PDF foo.ps'). Delete the printer ('lpadmin -x
PDF'),
download distiller.ppd (found here:
http://www.pentondigitalads.com/downloads/adist4.zip). Copy new ppd file
to /usr/share/cups/model. Re-add printer with:
'lpadmin -p PDF -E -v pdf:/tmp/ -m distiller.ppd'
...and there we go! Still nothing prints. :(
I dig the simplicity of the solution at
http://printing.kde.org/downloads/
but given that it doesn't seem to work for me, I can hardly recommend
it. Perhaps I'm missing something. Is there any documentation out there
that's more in depth than the pdfdistiller file itself and this thread?
Thanks to all who responded to the original post!
-Tom
Kurt Pfeifle wrote:
> This is only *one* of the many options to create a "PDF printer".
It is
> geared towards working with a legacy, old-fashioned spooling system.
> It will only serve your Windows clients. Should you need to support
> Unix/Linux/MacOSX clients too with your print server, you'd need to set
> up a separate PDF printer for these type of clients.
>
> A better way to set up a PDF generation service for print clients is to
> use the PDF creating CUPS "backend" as provided on
>
> http://printing.kde.org/downloads/
>
> You need the backend provided there plus a PPD for a generic PostScript
> printer (best, use the distiller.ppd as was provided once for Acrobat 3
> by Adobe -- it still floats around in various dl areas on the internet).
>
> If you set up a printer using this backend, the PDF printer will be
> shared to all print clients, Linux, Unix, Mac OS X and Windows. Samba's
> Point and Print capabilities will even make possible to download the
> "driver" to all Windows clients (Unix clients get the
"driver" through
> CUPS native capabilities).
>
> It means you can send all formats supported by CUPS to this PDF printer:
> ASCII, image files, PS, PDF... and CUPS will take care to convert
> everything
> to PostScript and the PDF backend will generate the PDF...
>
>
> Cheers,
> Kurt
>
> Tom samba-lists at fleet.ucdavis.edu wrote on Samba-Digest:> Mon Mar 31 11:57:58 GMT 2003 > > > Everything goes smoothly with the installation... drop 'pdfdistiller' > into /usr/lib/cups/backend,I hope you didn't use "copy'n'paste" from your browser, but "Save as..." to get it?> chmod +x, restart cups service. Add a > printer in cups with: > > 'lpadmin -p PDF -E -v pdf:/tmp/' > > ...and voila! Nothing happens.Of course not. You have not yet associated a PPD with it, which means you are running it as a "raw" printer.> Doesn't give any errors, but it won't > print ('lpr -P PDF foo.ps'). Delete the printer ('lpadmin -x PDF'), > download distiller.ppd (found here: > http://www.pentondigitalads.com/downloads/adist4.zip). Copy new ppd file > to /usr/share/cups/model. Re-add printer with: > > 'lpadmin -p PDF -E -v pdf:/tmp/ -m distiller.ppd' > > ...and there we go! Still nothing prints. :(OK. Did you re-start cupsd after dropping the "distiller.ppd" into "/usr/share/cups/model/" ? This is required to allow CUPS to rebuild its cache of available PPDs from that directory. Only if there is a valid cache, you can install the PPD using the "-m" parameter without the path. Otherwise use the absolute path; then you don't need to re-start cupsd after updating your PPD "model" directory: 'lpadmin -p PDF -E -v pdf:/tmp/ -P /usr/share/cups/model/distiller.ppd' Do you see a "/etc/cups/ppd/PDF.ppd" ? To check if CUPS is recogizing the newly available backend, let root run "lpinfo -v" and grep for "pdf". To check if it basically works as a backend, first run it with no arguments: "/usr/lib/cups/backend/pdfdistiller" and it should output 'direct pdf "Unknown" "PDF Writing"' Then run it with a wrong number of arguments (use 1, 2, 3, or 4 dummy arguments) "/usr/lib/cups/backend/pdfdistiller 1 2 a b" and it should output "Usage: pdf job-id user title copies options [file]" The PDF should go to "/tmp/", according to your installation. Backends are running as root, and for paranoid security you may not want to write files as root into "/tmp/". Better use a separate directory with access rights you need: "lpadmin -p PDF -E -v pdf:/home/username/pdfs/ -P /usr/share/cups/model/distiller.ppd" Further, the script relies on "ps2pdf" to be present on your system. Do you get an answer to this: "which ps2pdf" Last: If you want to get some more debugging info into the CUPS error_log (in "/var/log/cups/error_log"), insert this line "set -x" into the "pdfdistiller" as the right after the first line. Set cupsd.conf to "LogLevel debug" and re-start cupsd.> I dig the simplicity of the solution at > http://printing.kde.org/downloads/ > but given that it doesn't seem to work for me, I can hardly recommend > it.You don't need to recommend it -- *I'll* be doing it... ;-)> Perhaps I'm missing something. Is there any documentation out there > that's more in depth than the pdfdistiller file itself and this thread?Hmmm... I just checked and the detailled README I once put there has gone. Need to dig it out again.> Thanks to all who responded to the original post! > > -Tom > > Kurt Pfeifle wrote: > >> This is only *one* of the many options to create a "PDF printer". It is >> geared towards working with a legacy, old-fashioned spooling system. >> It will only serve your Windows clients. Should you need to support >> Unix/Linux/MacOSX clients too with your print server, you'd need to set >> up a separate PDF printer for these type of clients. >> >> A better way to set up a PDF generation service for print clients is to >> use the PDF creating CUPS "backend" as provided on >> >> http://printing.kde.org/downloads/ >> >> You need the backend provided there plus a PPD for a generic PostScript >> printer (best, use the distiller.ppd as was provided once for Acrobat 3 >> by Adobe -- it still floats around in various dl areas on the internet). >> >> If you set up a printer using this backend, the PDF printer will be >> shared to all print clients, Linux, Unix, Mac OS X and Windows. Samba's >> Point and Print capabilities will even make possible to download the >> "driver" to all Windows clients (Unix clients get the "driver" through >> CUPS native capabilities). >> >> It means you can send all formats supported by CUPS to this PDF printer: >> ASCII, image files, PS, PDF... and CUPS will take care to convert >> everything >> to PostScript and the PDF backend will generate the PDF... > >> >> >> Cheers, >> Kurt >> >
PDF printing through CUPS backend: Got it to work. Gory details follow. Kurt Pfeifle wrote:>> Tom samba-lists at fleet.ucdavis.edu wrote on Samba-Digest: > > >> Mon Mar 31 11:57:58 GMT 2003 >> >> >> Everything goes smoothly with the installation... drop 'pdfdistiller' >> into /usr/lib/cups/backend, > > > I hope you didn't use "copy'n'paste" from your browser, but "Save as..." > to get it?I didn't. That file was fine.> >> chmod +x, restart cups service. Add a printer in cups with: >> >> 'lpadmin -p PDF -E -v pdf:/tmp/' >> >> ...and voila! Nothing happens. > > > Of course not. You have not yet associated a PPD with it, which means you > are running it as a "raw" printer.Gentle readers, remember this lesson. A PPD file is necessary even for printing to PDF files.> >> Doesn't give any errors, but it won't print ('lpr -P PDF foo.ps'). >> Delete the printer ('lpadmin -x PDF'), download distiller.ppd (found >> here: http://www.pentondigitalads.com/downloads/adist4.zip). Copy new >> ppd file to /usr/share/cups/model. Re-add printer with: >> >> 'lpadmin -p PDF -E -v pdf:/tmp/ -m distiller.ppd' >> >> ...and there we go! Still nothing prints. :( > > > OK. > > Did you re-start cupsd after dropping the "distiller.ppd" into > "/usr/share/cups/model/" ? This is required to allow CUPS to rebuild > its cache of available PPDs from that directory. Only if there is a > valid cache, you can install the PPD using the "-m" parameter without > the path. > > Otherwise use the absolute path; then you don't need to re-start cupsd > after updating your PPD "model" directory: > > 'lpadmin -p PDF -E -v pdf:/tmp/ -P /usr/share/cups/model/distiller.ppd' > > Do you see a "/etc/cups/ppd/PDF.ppd" ? > > To check if CUPS is recogizing the newly available backend, let root run > > "lpinfo -v" > > and grep for "pdf". > > To check if it basically works as a backend, first run it with no > arguments: > > "/usr/lib/cups/backend/pdfdistiller" > > and it should output > > 'direct pdf "Unknown" "PDF Writing"' > > Then run it with a wrong number of arguments (use 1, 2, 3, or 4 dummy > arguments) > > "/usr/lib/cups/backend/pdfdistiller 1 2 a b" > > and it should output > > "Usage: pdf job-id user title copies options [file]" > > The PDF should go to "/tmp/", according to your installation. Backends > are running > as root, and for paranoid security you may not want to write files as > root into > "/tmp/". Better use a separate directory with access rights you need: > > "lpadmin -p PDF -E -v pdf:/home/username/pdfs/ -P > /usr/share/cups/model/distiller.ppd" > > Further, the script relies on "ps2pdf" to be present on your system. Do > you get > an answer to this: > > "which ps2pdf"I did restart, I did get all of those messages, 'which ps2pdf' comes up fine, everyone works great according to your docs up to this point.> > Last: If you want to get some more debugging info into the CUPS error_log > (in "/var/log/cups/error_log"), insert this line > > "set -x" > > into the "pdfdistiller" as the right after the first line. Set cupsd.conf > to "LogLevel debug" and re-start cupsd.This is what fixed it for me... adding "set -x" in pdfdistiller and "LogLevel debug" into cupsd.conf gave me much better info to dig through in /var/log/cups/error_log. Here's a chunk of what I found: D [31/Mar/2003:14:19:22 -0800] StartJob: backend = "/usr/lib/cups/backend/pdf" D [31/Mar/2003:14:19:22 -0800] StartJob: filterfds[1] = -1, 9 D [31/Mar/2003:14:19:22 -0800] start_process("/usr/lib/cups/backend/pdf", 0xbfffb730, 0xbfffabe0, 10, 9, 7) I [31/Mar/2003:14:19:22 -0800] Started backend /usr/lib/cups/backend/pdf (PID 4179) for job 155. E [31/Mar/2003:14:19:22 -0800] PID 4179 stopped with status 22! D [31/Mar/2003:14:19:22 -0800] [Job 155] /usr/lib/cups/backend/pdf: No such file or directory It was looking for "/usr/lib/cups/backend/pdf" as the backend instead of "/usr/lib/cups/backend/pdfdistiller", which is what the file was named. I made a copy called "/usr/lib/cups/backend/pdf" and it worked fine. I do not yet know why cups was looking for the file as "pdf" instead of "pdfdistiller", but this was the entirety of the issue.> >> I dig the simplicity of the solution at >> http://printing.kde.org/downloads/ >> but given that it doesn't seem to work for me, I can hardly recommend it. > > > You don't need to recommend it -- *I'll* be doing it... ;-)Ok, now that makes two of us! :) Thanks Kurt! -Tom
> Tom samba-lists at fleet.ucdavis.edu wrote on Samba-Digest:> Mon Mar 31 15:00:22 GMT 2003 > > > PDF printing through CUPS backend: Got it to work. Gory details follow. > > Kurt Pfeifle wrote: >>> Tom samba-lists at fleet.ucdavis.edu wrote on Samba-Digest: >> >> >>> Mon Mar 31 11:57:58 GMT 2003 >>> >>> >>> Everything goes smoothly with the installation... drop 'pdfdistiller' >>> into /usr/lib/cups/backend, >> >> >> I hope you didn't use "copy'n'paste" from your browser, but "Save as..." >> to get it? > > I didn't. That file was fine. > >> >>> chmod +x, restart cups service. Add a printer in cups with: >>> >>> 'lpadmin -p PDF -E -v pdf:/tmp/' >>> >>> ...and voila! Nothing happens. >> >> >> Of course not. You have not yet associated a PPD with it, which means you >> are running it as a "raw" printer. > > Gentle readers, remember this lesson. A PPD file is necessary even for > printing to PDF files.It needs to be a PPD for a real PostScript printer, best a very generic one, with little or now device-specific settings contained. The reason is this: it makes CUPS to convert anything it accepts as print input to PostScript (because it thinks a PostScript printer is hanging at the end). Then our backend is guaranteed to receive PostScript (the only input it can process) and can do its ps-to-pdf cconversion work. In theory, you could run it without the PPD too -- but then you can only send PostScript files to the PDF-converter. If you use the suggested "distiller.ppd", you can set for instance the "media size" and the "resolution" parameters in any GUI (such as "kprinter", "gtklp" or "xpp"). If you offer this driver for download to the Windows clients and make them print the driver test page, you can see how the setting of the resolution takes effect on the MS flag in the upper left corner, because this originally is a vector graphic (You won't see it in fonts...)>>> Doesn't give any errors, but it won't print ('lpr -P PDF foo.ps'). >>> Delete the printer ('lpadmin -x PDF'), download distiller.ppd (found >>> here: http://www.pentondigitalads.com/downloads/adist4.zip). Copy new >>> ppd file to /usr/share/cups/model. Re-add printer with: >>> >>> 'lpadmin -p PDF -E -v pdf:/tmp/ -m distiller.ppd' >>> >>> ...and there we go! Still nothing prints. :( >> >> >> OK. >> >> Did you re-start cupsd after dropping the "distiller.ppd" into >> "/usr/share/cups/model/" ? This is required to allow CUPS to rebuild >> its cache of available PPDs from that directory. Only if there is a >> valid cache, you can install the PPD using the "-m" parameter without >> the path. >> >> Otherwise use the absolute path; then you don't need to re-start cupsd >> after updating your PPD "model" directory: >> >> 'lpadmin -p PDF -E -v pdf:/tmp/ -P /usr/share/cups/model/distiller.ppd' >> >> Do you see a "/etc/cups/ppd/PDF.ppd" ? >> >> To check if CUPS is recogizing the newly available backend, let root run >> >> "lpinfo -v" >> >> and grep for "pdf". >> >> To check if it basically works as a backend, first run it with no >> arguments: >> >> "/usr/lib/cups/backend/pdfdistiller" >> >> and it should output >> >> 'direct pdf "Unknown" "PDF Writing"' >> >> Then run it with a wrong number of arguments (use 1, 2, 3, or 4 dummy >> arguments) >> >> "/usr/lib/cups/backend/pdfdistiller 1 2 a b" >> >> and it should output >> >> "Usage: pdf job-id user title copies options [file]" >> >> The PDF should go to "/tmp/", according to your installation. Backends >> are running >> as root, and for paranoid security you may not want to write files as >> root into >> "/tmp/". Better use a separate directory with access rights you need: >> >> "lpadmin -p PDF -E -v pdf:/home/username/pdfs/ -P >> /usr/share/cups/model/distiller.ppd" >> >> Further, the script relies on "ps2pdf" to be present on your system. Do >> you get >> an answer to this: >> >> "which ps2pdf" > > I did restart, I did get all of those messages, 'which ps2pdf' comes up > fine, everyone works great according to your docs up to this point. > >> >> Last: If you want to get some more debugging info into the CUPS error_log >> (in "/var/log/cups/error_log"), insert this line >> >> "set -x" >> >> into the "pdfdistiller" as the right after the first line. Set cupsd.conf >> to "LogLevel debug" and re-start cupsd. > > This is what fixed it for me... adding "set -x" in pdfdistiller and > "LogLevel debug" into cupsd.conf gave me much better info to dig through > in /var/log/cups/error_log. > > Here's a chunk of what I found: > > D [31/Mar/2003:14:19:22 -0800] StartJob: backend = > "/usr/lib/cups/backend/pdf" > D [31/Mar/2003:14:19:22 -0800] StartJob: filterfds[1] = -1, 9 > D [31/Mar/2003:14:19:22 -0800] > start_process("/usr/lib/cups/backend/pdf", 0xbfffb730, 0xbfffabe0, 10, 9, 7) > I [31/Mar/2003:14:19:22 -0800] Started backend /usr/lib/cups/backend/pdf > (PID 4179) for job 155. > E [31/Mar/2003:14:19:22 -0800] PID 4179 stopped with status 22! > D [31/Mar/2003:14:19:22 -0800] [Job 155] /usr/lib/cups/backend/pdf: No > such file or directory > > It was looking for "/usr/lib/cups/backend/pdf" as the backend instead of > "/usr/lib/cups/backend/pdfdistiller", which is what the file was named. > I made a copy called "/usr/lib/cups/backend/pdf" and it worked fine. I > do not yet know why cups was looking for the file as "pdf" instead of > "pdfdistiller", but this was the entirety of the issue.D'oooh! I forgot to mention this. CUPS looks for the backend name as is shown in the output of "lpinfo -v". (I have it symlinked on my other box from the short "pdf", and thusly forgot to mention, because I had no direct access for a check at the time of writing. Sorry.)>>> I dig the simplicity of the solution at >>> http://printing.kde.org/downloads/ >>> but given that it doesn't seem to work for me, I can hardly recommend it. >> >> >> You don't need to recommend it -- *I'll* be doing it... ;-) > > Ok, now that makes two of us! :)OK then... Now let's chase the 3rd... ;-)> > Thanks Kurt! > > -Tom >Bye, Kurt
This should be the last mesage in the thread, the be-all end-all
mini-howto. :)
Using CUPS backend to create PDF virtual printer
------------------------------------------------------------------------
1. Get a un*x box with CUPS and ghostscript set up on it.
2. Go here: http://printing.kde.org/downloads/ and download this backend
script: http://printing.kde.org/downloads/pdfdistiller
3. Log in as root, put it in /usr/lib/cups/backend or wherever
cups/backend lives.
4. 'chmod +x' the file (should be 755: rwxr-xr-x).
5. Restart CUPS ('service cups restart' or appropriate).
6. To check if CUPS recognizes it as a usable backend, let root run:
'lpinfo -v | grep pdf'
should output "direct pdf"
7. Test the pdfdistiller backend:
a. '/usr/lib/cups/backend/pdf'
should output 'direct pdf "Unknown" "PDF
Writing"'
b. "/usr/lib/cups/backend/pdf 1 2 a b"
should output: "Usage: pdf job-id user title copies options
[file]"
8. Test existence of Ghostscript's ps2pdf with 'which ps2pdf'.
Output
should be a path like "/usr/bin/ps2pdf" or similar
9. Download a PPD file for cups to print with. An Adobe Distiller PPD is
a great choice. I used the one from this page:
http://www.pentondigitalads.com/PentonDigitalAds/creating_postscript_files.htm
("Acrobat Distiller PPD for Windows")
If this link is dead, search Google/web for "distiller ppd" and
find a suitable file.
10. Put the PPD file in /usr/share/cups/model or wherever your CUPS
model PPDs are stored.
11. Restart CUPS.
12. Add the printer to CUPS with the command:
'lpadmin -p <Chosen Name> -E -v pdf:<out folder> -m
<ppd-file>'
i.e.:
'lpadmin -p PDFprinter -E -v pdf:/pub/pdf_out -m distiller.ppd'
13. Test the PDF output by manually printing to the new printer:
'lpr -P PDFprinter test.txt'
Troubleshooting each step:
1. If you're stuck on #1, find a more appropriate howto.
2. If that file is missing, beg someone for a copy.
7. I got stuck on this one. without renaming it "pdf", it didn't
work at
all. No clue why. Try copying the file "pdfdistiller" the file to
"pdf"
in the same folder. ('cp pdfdistiller pdf'). If these aren't
working, go
no further. Make sure CUPS is installed properly and work on this first.
8. If this doesn't work, you'll need to install the latest "ESP
Ghostscript". It's available at:
http://www.cups.org/software.php
9. Adobe doesn't distribute this file, so it could be tricky to find.
10. Same as #3. PPD files made for Macintosh and Windows computers will
need to be re-saved in un*x format.
11. There should be a number of PPD files in that folder already. Search
for "laserjet.ppd" if you have no idea where to find them.
12. If this fails, make sure you're specifying a valid PPD file from the
model folder in the "-m" part. Alternatively, you may use '-P
<ppd>'
instead of '-m', but you must specify the entire path.
13. No go? Time to start logging everything. After the first line of
your backend file (pdf or pdfdistiller), add the line "set -x". Edit
your cupsd.conf and set "LogLevel debug". Restart CUPS and peruse the
information in /var/log/cups/error_log for good debugging info.
Enjoy!
Thanks to Kurt Pfeifle [kpfeifle (at) danka (dot) de] for all the help,
comments and editing this mini-howto with me.