Document Actions
5.6. CUPS
CUPS (Common UNIX Printing System) is used as server for all printing operations. The nearest printer and local printer support functions are implemented as extensions to CUPS.
CUPS is a modern modularized printer server. The modularized design helps CUPS in solving some of the flaws that older printer system suffered from. It also makes it possible to extend the printer functionality to meet new demands. This is what we have done in ThinLinc.
Simplified, CUPS uses a chain of three different kinds of modules. When a printer job is sent to CUPS it is first received by a frontend module. The frontend module implements a way of "talking" with CUPS. The normally used frontend modules implements IPP (Internet Printing Protocol) and LPD (Line Printer Daemon).
After receiving a job CUPS looks at the contents. It compares the job format with the formats handled by the selected output printer. It uses PPD files (PostScript Printer Description) to see what formats the printer can handle. If the printer can handle the actual job format then everything is fine and it does nothing. If the printer can't directly handle the job format then CUPS will start a rewrite. CUPS uses external applications, the most important being the Ghostscript suite, to handle a lot of different formats.
When the document has a format compatible with the requested printer CUPS uses a backend module to make the physical transfer of the job from CUPS to the printer. The backend modules implement different protocols and connection types that can be used to send data to a printer. Examples of possible backends are the LPD protocol, IPP, USB printing, HP JetDirect, parallel port, serial port, and so on.
The local and nearest printer support that ThinLinc provides are implemented as CUPS backends. When ThinLinc is installed there are two special queues, one for each service, added to the list of CUPS printers. The ThinLinc backends examine the printing request and figure out where to send them. In the case of local printing support it uses the LPD protocol to send the job to the ThinLinc client over an encrypted tunnel. The nearest printer backend looks in its configuration for the printer closest to the printing terminal. It then reprints the job to that printer.
The most fundamental CUPS settings are made in config files in /etc/cups/. Normal Linux distributions already have sane configuration files, so you shouldn't need to do any larger changes. Printer additions and management should be made from the web interface. When CUPS is installed the interface can be reached at http://hostname:631/.
Access permissions are configured in /etc/cups/cupsd.conf. At the end of the file there is a section called Security Options. Here you can define permissions for different parts of the CUPS interface. IPP uses the same URI:s as the web interface, so all changes here will affect the IPP protocol as well.
The HTTP and IPP interface uses different paths to reach different functions. You can set specific permissions for each of these paths to control access to a specific function. Below follows a list with common paths and their use. Observe that if you don't explicitly set permissions for a specific subpath it will have the permissions defined by the parent.
Table 5.1. CUPS Locations on server
| Path | Description |
|---|---|
| / | The path for all get operations (get-printers, get-jobs, etc.) |
| /admin | The path for all administration operations (add-printer, delete-printer, start-printer, etc.) |
| /admin/conf | The path for access to the CUPS configuration files (cupsd.conf, client.conf, etc.) |
| /classes | The path for all classes |
| /classes/name | The resource for class name |
| /jobs | The path for all jobs (hold-job, release-job, etc.) |
| /jobs/id | The resource for job id |
| /printers | The path for all printers |
| /printers/name | The path for printer name |
| /printers/name.ppd | The PPD file path for printer name |
Each location block has its own list of permissions. You can explicitly specify hosts that should be denied and you can explicitly specify hosts that should be allowed. Access can be denied and granted based on hostname, domain, IP address, network, or interface. Both "Allow" and "Deny" accept the following notations for addresses:
All None *.domain.com .domain.com host.domain.com nnn.* nnn.nnn.* nnn.nnn.nnn.* nnn.nnn.nnn.nnn nnn.nnn.nnn.nnn/mm nnn.nnn.nnn.nnn/mmm.mmm.mmm.mmm @LOCAL @IF(name)
A location block that allows only connections from localhost could look like the one following below. Observe that the permission order is set to first deny and then allow connections. This is the normal order and for security reasons the most common one. In this case we first deny all connections and then explicitly allow connections from 127.0.0.1.
<Location /> Order Deny,Allow Deny From All Allow From 127.0.0.1 </Location>
To allow connections from other hosts you can add additional Allow lines. The example following below allows connections from localhost and machines with IP numbers from the free 10.47.nnn.nnn series.
<Location /> Order Deny,Allow Deny From All Allow From 127.0.0.1 Allow From 10.47.0.0/16 </Location>
You can additionally configure CUPS to require a valid username and password to be able to reach functions. This is made by defining AuthClass and AuthType lines. AuthClass is used to select which user privilege the user must have to access the location and AuthType is used to select which kind of authentication that should be used. More informaiton on this is available in the CUPS Software Administrators Manual.
To allow print jobs from other hosts you have to give access to the /printers paths. For more information about setting up permissions, look at Section 5.6.4.1, “ Allowing connections from other computers than localhost ” above.
Since you, when you use the nearest printer or local printer support, can't always be really sure about what printer type the job finally will reach it's convenient to have a generic PostScript printer driver installed in Windows. The CUPS system handles PostScript well and in cases where a destination printer doesn't handle PostScript it will convert the job to a format supported by the printer.
There are at least two possible generic PostScript printer drivers available for Windows. One from Adobe and one from the CUPS project.