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 [2006/11/09 14:53] – Re-phrased several pieces of text for better understanding. Thanks Bruce. 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 7: Line 7:
 CUPS (the //Common UNIX Printing System//) is now the default printing subsystem in Slackware, after years of faithful service by the //lprng// package which is no longer part of Slackware. The commandline //lpr// program that some of you use is in fact part of CUPS, but it emulates the old lpr program that has been known in Linux/UNIX for ages and which was the way to print if you had //lprng// installed in Slackware. But a set of commandline tools is not all that CUPS installs on your system. CUPS (the //Common UNIX Printing System//) is now the default printing subsystem in Slackware, after years of faithful service by the //lprng// package which is no longer part of Slackware. The commandline //lpr// program that some of you use is in fact part of CUPS, but it emulates the old lpr program that has been known in Linux/UNIX for ages and which was the way to print if you had //lprng// installed in Slackware. But a set of commandline tools is not all that CUPS installs on your system.
  
-CUPS has a browser-based graphical user interface (check out yours at [[http://localhost:631/|http://localhost:631/]]) for administering the service, like creating print queues, monitoring, deleting and restarting print jobs and such. CUPS servers in network can be configured to talk to each other, so that printing from one CUPS machine (the client) to another CUPS machine (a CUPS server with attached printer) works automagically.\\ +CUPS has a browser-based graphical user interface (check out yours at [[http://localhost:631/|http://localhost:631/]]) for administering the service, like creating print queues, monitoring, deleting and restarting print jobs and such.\\ Not everything can be done through the graphical interface though. The basic initial setup of the CUPS service is still matter of hand-editing certain configuration files.  
-Not everything can be done through the graphical interface though. The basic initial setup of the CUPS service is still a matter of hand-editing certain configuration files.+ 
 +CUPS can act as a server (when it has a queue configured that prints to a physical device) or a client (when there is no local printer configured but instead your job submissions are sent to a CUPS server on the network). The big plus of networked CUPS services is that they are able to talk to each other, so that printing from one CUPS machine (the client) to another CUPS machine (a CUPS server with attached printer) works automagically the client machine will pick up the server print queues that are advertised on the network without you needing to configure anything. 
  
 ===== Setting up the CUPS service ===== ===== Setting up the CUPS service =====
  
-Slackware comes with a functional CUPS server out of the box. All you have to do is make the file ''/etc/rc.d/rc.cups'' executable and start the server. After that you can point your browser to [[http://localhost:631/|http://localhost:631/]] for the administratitive interface, and start adding printer queues. <code>+Slackware comes with a functional CUPS service out of the box. All you have to do is make the file ''/etc/rc.d/rc.cups'' executable and start the server. After that you can point your browser to [[http://localhost:631/|http://localhost:631/]] for the administratitive interface, and start adding queues for local printers or remote CUPS servers. <code>
 chmod +x /etc/rc.d/rc.cups chmod +x /etc/rc.d/rc.cups
 /etc/rc.d/rc.cups start /etc/rc.d/rc.cups start
-</code>+</code> If you need to setup a CUPS network server (other PC's should be able to print to your machine) then there is some extra work ahead. 
 + 
 +The way Slackware runs CUPS out of the box is that only access from the ''localhost'' is allowed. The print queues which you define will not be advertised on your network.\\ Access to ''localhost'' is safe - no one else but you on your computer can talk to the ''localhost'' address (which is tied to the //loopback interface// or "//lo//" interface). 
 <note tip>If ''localhost'' does not work for you when you type the URL in the browser, try the IP address for localhost which is ''127.0.0.1''. The URL would then look like this: [[http://127.0.0.1:631/|http://127.0.0.1:631/]]. But in any case, this would indicate that you messed up your ''/etc/hosts'' file which should contain (among others) the line <code>127.0.0.1       localhost</code> If that line is not present, you should add it. It's absence will break quite many network services. <note tip>If ''localhost'' does not work for you when you type the URL in the browser, try the IP address for localhost which is ''127.0.0.1''. The URL would then look like this: [[http://127.0.0.1:631/|http://127.0.0.1:631/]]. But in any case, this would indicate that you messed up your ''/etc/hosts'' file which should contain (among others) the line <code>127.0.0.1       localhost</code> If that line is not present, you should add it. It's absence will break quite many network services.
 </note> </note>
  
-In a later section I will show you how you can prevent other people on the network from accessing your computer's CUPS administrative interfaceIt would be silly if all of a sudden your print queue would be disabled by a jokerAccess to ''localhost'' is safe - no one else but you on your computer can talk to the ''localhost'' address (which is tied to the //loopback interface// or "//lo//" interface).+For the sake of this article, I will present several examples containing IP addresses. Our example network will be as follows: 
 + 
 +  * Network hosts have IP addresses in the range **''192.168.0.1''** to **''192.168.0.254''**, i.e. an address range described by the network/netmask values of **''192.168.0.0/255.255.255.0''** (or the equivalent notation **''192.168.0.0/24''**). 
 +  * Our own computer is configured with the IP address **''192.168.0.5''** 
 +  * Another computer running a network-accessible CUPS server has the IP address **''192.168.0.1''** 
  
 ==== /etc/cups/cupsd.conf ==== ==== /etc/cups/cupsd.conf ====
 +
 +The ''/etc/cups/cupsd.conf'' file is the //server configuration file// for CUPS. It determines how the job scheduler will run. The default content of this file (stripped of - very useful - comments and empty lines) looks like this: <code>
 +LogLevel info
 +Port 631
 +<Location />
 +Order Deny,Allow
 +Deny From All
 +Allow From 127.0.0.1
 +</Location>
 +<Location /admin>
 +AuthType Basic
 +AuthClass System
 +Order Deny,Allow
 +Deny From All
 +Allow From 127.0.0.1
 +</Location>
 +</code>
 +
 +I will briefly go through the most important lines.
 +  * The listen address: <code>Port 631</code> This tells that the CUPS server will listen at TCPIP port 631 for incoming print job submissions, and also runs the administrative Web interface at the port. Port 631 is the //IPP// port, which stands for //Internet Printing Protocol//.
 +
 +  * Print service access control <code>
 +<Location />
 +Order Deny,Allow
 +Deny From All
 +Allow From 127.0.0.1
 +</Location>
 +</code> This tells us that access to the root URL (//Location / // i.e. [[http://localhost:631/|http://localhost:631/]]) is limited to the ''127.0.0.1'' IP address exclusively. Remember, ''127.0.0.1'' is the IP address for the ''localhost'' interface. Essentially this statement means that no one can access your CUPS print service from the network. If you **do** want to grant access, you will have to add another //Allow// line here. Remember the example network layout from the first section? We will allow all computers in our local network access to the CUPS printing service by adding the line **Allow From 192.168.0.%%*%%** so that the previous section will become <code>
 +<Location />
 +Order Deny,Allow
 +Deny From All
 +Allow From 127.0.0.1
 +Allow From 192.168.0.*
 +</Location>
 +</code>
 +
 +  * Administration interface access control: <code>
 +<Location /admin>
 +AuthType Basic
 +AuthClass System
 +Order Deny,Allow
 +Deny From All
 +Allow From 127.0.0.1
 +</Location>
 +</code> The location ''/admin'' (i.e. the URL [[http://localhost:631/admin|http://localhost:631/admin]]) is protected using //Basic Authentication// - the well-known username/password dialog of your browser when you attempt to access this URL for the first time.\\ By default, the only username/password combination that works here is that of the **root** account!\\ 
 +Since Basic Authentication sends passwords unencrypted to the server, it makes sense that access to the admin interface is restricted to the local host - this is what the line "//Allow From 127.0.0.1//" is for. If you want access to your CUPS server's administrative interface across the network, it is desirable to protect your password from network sniffers by using //SSL encryption// (i.e.using %%https://%% URLs instead of http:%%//%%). I will show you how to secure your access in the [[#securing_the_admin_web_interface|Securing the admin web interface]] section.
 +
 +Now, I told you that CUPS services can talk to each other - they use the //IPP// protocol for that. Print queues on one CUPS server will automatically be available for use on another computer running CUPS. An example: you take your Slackware laptop with you and plug it into the network of your exmployer. If there is a CUPS server on that network, the queues on that server will suddenly pop up on your local CUPS server! Zero config here people. The big question is of course: how does one CUPS program find other CUPS programs in the network?\\ 
 +The answer is, you must make the CUPS server advertise itself on the network. These are the two lines you will add to your ''cupsd.conf'' file to make that happen: <code>
 +BrowseAddress @LOCAL
 +BrowseAllow 192.168.0.*
 +</code> Meaning that your CUPS server will use all interfaces that it considers local. Any point-to-point interfaces (ppp, dial-up lines for instance) are //not// considered local. Also it will accept and answer browse requests from computers in our example IP range. A //browse request// is a query from another CUPS program, looking for peers on the network. Our server will now answer those browse requests, thereby making it's own print queues available for use by other CUPS clients in the network. The complete ''cupsd.conf'' file would look like <code>
 +LogLevel info
 +Port 631
 +BrowseAddress @LOCAL
 +BrowseAllow 192.168.0.*
 +<Location />
 +Order Deny,Allow
 +Deny From All
 +Allow From 127.0.0.1
 +Allow From 192.168.0.*
 +</Location>
 +<Location /admin>
 +AuthType Basic
 +AuthClass System
 +Order Deny,Allow
 +Deny From All
 +Allow From 127.0.0.1
 +</Location>
 +</code> You'll notice that I also added that line **Allow From 192.168.0.%%*%%** otherwise network connections from outside would still be refused. I leave access to the ''/admin'' URL restricted to ''localhost'' for now. Later on, we will add some security by means of SSL encryption.
 +
 +==== /etc/cups/client.conf ====
 +
  
 ==== Creating print queues ==== ==== Creating print queues ====
 +
 +
  
 ==== Securing the admin web interface ==== ==== Securing the admin web interface ====
  
 +In this section I will show you how you can prevent other people on the network from accessing your CUPS server's administrative interface by password protecting it and using encryption. It would be silly if all of a sudden your print queue would be disabled by a joker...
 +
 +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.\\ 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 ===
 +
 +FIXME
 +
 +TODO
  
 ===== Configuring CUPS clients ===== ===== Configuring CUPS clients =====
  
 TODO TODO
 +
  
 ===== Making CUPS work with Samba ===== ===== Making CUPS work with Samba =====
  
-TODO+Samba will pick up the CUPS printers and make them available to your Windows computers in the LAN when you have these lines in the ''[global]'' section of your ''/etc/samba/smb.conf'' file: 
 +<code> 
 +   load printers = yes 
 +   printcap name = cups 
 +   printing = cups 
 +   print command = lpr -oraw -r -P'%p' %s 
 +   lpq command = /usr/bin/lpq -P%p 
 +</code> You should also have a ''[printers]'' section in ''smb.conf'' that would look like this: <code> 
 +[printers] 
 +   comment = All Printers 
 +   path = /var/spool/samba 
 +   browseable = no 
 +   # Set public = yes to allow user 'guest account' to print 
 +   # A synonym for 'public = yes' is: 'guest ok = yes' 
 +   public = yes 
 +   writable = no 
 +   printable = yes 
 +</code> The print spool directory which Samba uses (///var/spool/samba//) must be different from the CUPS spool directory! Check if the directory exists (usually it should) and if it is writable by all: <code> 
 +# ls -l /var/spool | grep samba 
 +drwxrwxrwt   2 root   root    4096 2007-12-09 18:26 samba/ 
 +</code> The //'t'// in ''drwxrwxrwt'' means that every user can write in this directory but their files cannot be deleted by anyone but themselves. If the directory does not exist, or it's permissions are incorrect, you can run the following three commands to fix that: <code> 
 +mkdir -p /var/spool/samba 
 +chown -R root:root /var/spool/samba 
 +chmod 1777 /var/spool/samba 
 +</code> 
 + 
 +When print jobs from the Windows computers never show up in CUPS, you should increase the debug level for your CUPS server: <code> 
 +LogLevel debug 
 +</code> and restart the CUPS server by running: <code> 
 +/etc/rc.d/rc.cups restart 
 +</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'
 +    I [11/Nov/2004:20:30:25 +0100] Hint: Do you have the raw file printing rules enabled? 
 +    D [11/Nov/2004:20:30:25 +0100] Sending error: client-error-document-format-not-supported 
 +</code> To resolve this, you need to edit two files (you will find the affected lines at the end) and afterwards restart CUPS: 
 +  * In file ''/etc/cups/mime.types'' uncomment ''application/octet-stream'' 
 +  * In file ''/etc/cups/mime.convs'' uncomment ''application/octet-stream  application/vnd.cups-raw 0 - '' 
 + 
 +<note> Sometimes you will find that Samba does not pick up changes to your CUPS configuration, especially when you edited the ''smb.conf'' file. If you have computers connected to Samba shares and do not want to disconnect them, you can force the ''smbd'' processes on the Linux server to re-read their configuration while running. The following command will do that by sending a SIGHUP or //hangup signal// to these running processes: <code> 
 +killall -HUP smbd</code> Even though it uses the command ''killall'' this does __not__ mean that any process gets killed!</note>
  
 ===== A PDF printer for CUPS ===== ===== A PDF printer for CUPS =====
Line 70: 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 92: 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.
  
Line 111: Line 252:
  
 If you have a network with Windows computers, the best thing is to setup a Samba server on the CUPS server and let Samba use CUPS for printing. That way, our "pdfprinter" will automatically become available to these Windows computers as a network printer. Windows machines should install this network printer queue using a //Generic PostScript// driver.  If you have a network with Windows computers, the best thing is to setup a Samba server on the CUPS server and let Samba use CUPS for printing. That way, our "pdfprinter" will automatically become available to these Windows computers as a network printer. Windows machines should install this network printer queue using a //Generic PostScript// driver. 
- 
  
 ===== PDF Printer Scripts ===== ===== PDF Printer Scripts =====
Line 155: Line 295:
     OUTPUTFILENAME="$PDFDIR/$PRINTTIME.pdf"     OUTPUTFILENAME="$PDFDIR/$PRINTTIME.pdf"
   fi   fi
-  echo "PDF file: $OUTPUTFILENAME placed in: $PDFDIR" >> $LOGFILE 
 fi fi
 # run ghostscript # run ghostscript
 Printing with CUPS ()
SlackDocs