Welcome to the new location of Alien's Wiki, sharing a single dokuwiki install with the SlackDocs Wiki.

Welcome to Eric Hameleers (Alien BOB)'s Wiki pages.

If you want to support my work, please consider a small donation:

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
slackware:cups [2007/12/15 16:01] – Add instructions for getting CUPS to work with Samba alienslackware:cups [2010/02/14 21:46] (current) – Set the pfd script executable for all users (including user 'lp' which cupsd uses nowadays) alien
Line 107: Line 107:
  
 ==== Creating print queues ==== ==== Creating print queues ====
 +
  
  
Line 115: Line 116:
 You've probably noticed the line "//AuthClass System//" in the definition of the "''/admin''" location. This line defines the "class" of users (in fact a Linux group taken from the ''/etc/group'' file) which CUPS considers as being "System users". By default, CUPS will require the authenticating user to be a member of the "''sys''", "''system''", or "''root''" groups (the check is done in that order). That requirement fits only the ''root'' account, so that explains my statement of one of the previous sections. You can change the name of this group by uncommenting the line **''#SystemGroup sys''** in the ''cupsd.conf'' file, and changing the work ''sys'' to some other existing group. Alternatively, you can add your own acccount to the ''sys'' group of course. You've probably noticed the line "//AuthClass System//" in the definition of the "''/admin''" location. This line defines the "class" of users (in fact a Linux group taken from the ''/etc/group'' file) which CUPS considers as being "System users". By default, CUPS will require the authenticating user to be a member of the "''sys''", "''system''", or "''root''" groups (the check is done in that order). That requirement fits only the ''root'' account, so that explains my statement of one of the previous sections. You can change the name of this group by uncommenting the line **''#SystemGroup sys''** in the ''cupsd.conf'' file, and changing the work ''sys'' to some other existing group. Alternatively, you can add your own acccount to the ''sys'' group of course.
  
-Belonging to the right group is not enough though. FIXME+Belonging to the right group is not enough though.\\ Suppose you have added "**''SystemGroup wheel''**" to ''cupsd.conf'' so that anyone in the ''wheel'' group can administer CUPS (I like to use //wheel// for administrative tasks). You will now have to create a password file for CUPS which holds your user account and an associated password. CUPS cannot read your Linux account/password (it needs PAM for that, and Slackware does not use PAM). If the password file does not yet exist, we create it as follows, assuming your user account is "alien": <code> 
 +lppasswd -g wheel -a alien 
 +</code> If the password file existed, then a line for the //alien// account would have been appended to it.\\ The contents of that file look like this now: <code> 
 +# cat /etc/cups/passwd.md5 
 +     alien:wheel:01234567890abcde1234567890abcde12 
 +</code>
  
 === SSL encryption === === SSL encryption ===
 +
 +FIXME
  
 TODO TODO
Line 157: Line 165:
 LogLevel debug LogLevel debug
 </code> and restart the CUPS server by running: <code> </code> and restart the CUPS server by running: <code>
-/etc/rc.d/rc/cups restart +/etc/rc.d/rc.cups restart 
-</code> You will see the following error messages in ''/var/log/cups/errorlog'': <code>+</code> You will see the following error messages in ''/var/log/cups/error_log'': <code>
     E [11/Nov/2004:20:30:25 +0100] print_job: Unsupported format 'application/octet-stream'!     E [11/Nov/2004:20:30:25 +0100] print_job: Unsupported format 'application/octet-stream'!
     I [11/Nov/2004:20:30:25 +0100] Hint: Do you have the raw file printing rules enabled?     I [11/Nov/2004:20:30:25 +0100] Hint: Do you have the raw file printing rules enabled?
Line 203: Line 211:
   * Next, we are going the create the file that provides or "pdf backend" functionality. Defining a new backend is really no more than creating an executable file called in CUPS's backends directory ''/usr/lib/cups/backend'' - this file's name will become the name of the backend. So, for the "pdf" backend we create the file ''/usr/lib/cups/backend/pdf'' and make this a shellscript, the contents of which you can find in the section below - [[#pdf_printer_scripts|PDF Printer Scripts]]. Do not forget to make this new "pdf" script executable: <code>   * Next, we are going the create the file that provides or "pdf backend" functionality. Defining a new backend is really no more than creating an executable file called in CUPS's backends directory ''/usr/lib/cups/backend'' - this file's name will become the name of the backend. So, for the "pdf" backend we create the file ''/usr/lib/cups/backend/pdf'' and make this a shellscript, the contents of which you can find in the section below - [[#pdf_printer_scripts|PDF Printer Scripts]]. Do not forget to make this new "pdf" script executable: <code>
 chmod 755 /usr/lib/cups/backend/pdf chmod 755 /usr/lib/cups/backend/pdf
-</code> This backend will in turn call two other scripts which we shall place in the library directory ''/usr/lib/cups/pdf'' - see next bullet point.+</code> This backend will in turn call two other scripts which we shall place in the library directory ''/usr/lib/cups/pdf'' - see next bullet point.\\ The reason the script did not get world-executable permissions, is that the backend program needs to be run as the //root// user - CUPS will only do that if the program is not world-executable. Otherwise, the backend would be run using the unprivileged user account, typically "lp". //The script needs to run as root in order to be able to change ownership of the resulting PDF file to the user who printed it.//
  
-  * Now that we have the ''pdf'' backend file in place, the next step is to create the two helper scripts that our ''pdf'' script uses. One script does the conversion of PostScript to PDF, while the second does the actual email delivery. \\Install these two files called "''ps2pdf.cups''" and "''sendpdf''" into the cups library directory which we just created: ''/usr/lib/cups/pdf''. You can find these scripts in the section below called [[#pdf_printer_scripts|PDF Printer Scripts]]. Do not forget to make these files executable: <code>+  * Now that we have the ''pdf'' backend file in place, the next step is to create the two helper scripts that our ''pdf'' script uses. One script does the conversion of PostScript to PDF, while the second does the actual email delivery.\\ Install these two files called "''ps2pdf.cups''" and "''sendpdf''" into the cups library directory which we just created: ''/usr/lib/cups/pdf''. You can find these scripts in the section below called [[#pdf_printer_scripts|PDF Printer Scripts]]. Do not forget to make these files executable: <code>
 chmod 755 /usr/lib/cups/pdf/ps2pdf.cups chmod 755 /usr/lib/cups/pdf/ps2pdf.cups
 chmod 755 /usr/lib/cups/pdf/sendpdf chmod 755 /usr/lib/cups/pdf/sendpdf
Line 225: Line 233:
 <note>__Reminder__: If you don't use the email delivery feature, you do not need to install the '' sendpdf'' script, and you don't have to deal with the Perl software requirements!</note> <note>__Reminder__: If you don't use the email delivery feature, you do not need to install the '' sendpdf'' script, and you don't have to deal with the Perl software requirements!</note>
  
-  * CUPS uses //PPD// files (PostScript Printer Definition files) for the conversion of a submitted print job into PostScript print data which is correctly formatted for the printer backend. Usually the backend is a physical device (a printer) and the PPD file describes the device's capabilities. For our PDF backend which is not a physical device at all, we just need generic PPD file that can output color information in PostScript format (if you prefer grey-scale PDF files, you should of course get an appropriate non-colour PPD file).\\ Adobe wrote a PPD file ''distiller.ppd'' which you can freely download [[http://www.adobe.com/support/downloads/detail.jsp?ftpID=204|at their web site]]. The Adobe site is often inaccessible, but fortunately there are many mirrors of that PPD file. Here is one: [[http://www.linux-als-server.de/download/destiller.ppd|destiller.ppd]]; note that for some unknown reason this file is called "d**e**stiller.ppd" instead. \\ \\ Another (really free) PPD file can be found on the [[http://www.physik.uni-wuerzburg.de/~vrbehr/cups-pdf/|cups-pdf]] web site, where you can find another implementation of a CUPS PDF print solution which I have not yet tried. The URL to this PPD file is [[http://www.physik.uni-wuerzburg.de/~vrbehr/cups-pdf/cups-pdf-CURRENT/extra/PostscriptColor.ppd|PostscriptColor.ppd]] \\ \\ Save either of those files in the CUPS ppd-collection directory, under the name of ''/usr/share/cups/model/pdfcolor.ppd'' - the name does not really matter, you can keep the original filename if you wish, but since I am using that name ''pdfcolor.ppd'' in the rest of this example, I refer to it here as well to avoid confusion. CUPS PPD files are gzipped - probably to save space. It is not a requirement to do so for our own PPD file, but we will do it anyway: <code>+  * CUPS uses //PPD// files (PostScript Printer Definition files) for the conversion of a submitted print job into PostScript print data which is correctly formatted for the printer backend. Usually the backend is a physical device (a printer) and the PPD file describes the device's capabilities. For our PDF backend which is not a physical device at all, we just need generic PPD file that can output color information in PostScript format (if you prefer grey-scale PDF files, you should of course get an appropriate non-colour PPD file).\\ Adobe wrote a PPD file ''distiller.ppd'' which you can freely download [[http://www.adobe.com/support/downloads/detail.jsp?ftpID=204|at their web site]]. The Adobe site is often inaccessible, but fortunately there are many mirrors of that PPD file. Here is one: [[http://alien.slackbook.org/files/distiller.ppd.gz|distiller.ppd.gz]]. A copy of the file is available in this Wiki as well: {{:slackware:distiller.ppd.gz|distiller.ppd.gz}}\\ \\ Another (really free) PPD file can be found on the [[http://www.physik.uni-wuerzburg.de/~vrbehr/cups-pdf/|cups-pdf]] web site, where you can find another implementation of a CUPS PDF print solution which I have not yet tried. The URL to this PPD file is [[http://www.physik.uni-wuerzburg.de/~vrbehr/cups-pdf/cups-pdf-CURRENT/extra/PostscriptColor.ppd|PostscriptColor.ppd]] \\ \\ Save either of those files in the CUPS ppd-collection directory, under the name of ''/usr/share/cups/model/pdfcolor.ppd'' - the name does not really matter, you can keep the original filename if you wish, but since I am using that name ''pdfcolor.ppd'' in the rest of this example, I refer to it here as well to avoid confusion. CUPS PPD files are gzipped - probably to save space. It is not a requirement to do so for our own PPD file, but we will do it anyway inncase you did not download the "//.gz//" file: <code>
 gzip /usr/share/cups/model/pdfcolor.ppd</code> This creates the file ''/usr/share/cups/model/pdfcolor.ppd.gz'' which we will use in the ''lpadmin'' command further down. gzip /usr/share/cups/model/pdfcolor.ppd</code> This creates the file ''/usr/share/cups/model/pdfcolor.ppd.gz'' which we will use in the ''lpadmin'' command further down.
  
 Printing with CUPS ()
SlackDocs