Client or client program refers to a program that sends print jobs to a print daemon. A print daemon is a local service that accepts print jobs to forward them or to process them locally. Server refers to a daemon able to deliver print data to one or more printers. Each server functions as a daemon at the same time. In most cases, however, there is no special distinction to make between a server and a daemon, neither from the developer or from the user standpoint.
Print jobs are sent to servers by CUPS-based programs, such as lpr, kprinter, or xpp, and with the help of the Internet Printing Protocol, IPP. IPP is defined in RFC-2910 and RFC-2911 (see http://www.rfc-editor.org/rfc.html). IPP is somewhat similar to HTTP with identical headers but different content data. It also uses its own dedicated communication port 631, which has been registered with IANA (the Internet Authority for Number Allocation).
With the help of the broadcast function of the CUPS daemon, locally managed printers can be made available elsewhere in the network (using UDP port 631). They then appear as print queues on all other daemons configured to accept and use these broadcast packets. This makes it possible to see printers on other hosts after booting without configuring them locally, something that may be quite useful in corporate networks. On the other hand, this feature may pose a security risk if the host is connected to the Internet. When enabling printer broadcasting, make sure the daemon broadcasts into the local network only, access is limited to clients on the LAN, and the public IP address (the one used for the Internet connection) is not within the local IP range. Otherwise, remote users relying on the same ISP would be able to see and use the broadcast printers as well. In addition to that, such broadcasts mean more network traffic so may increase connection costs. Prevent a local printer from broadcasting IPP packets into the Internet by configuring the SUSE Firewall (SUSEfirewall2) accordingly. No extra configuration is needed to receive broadcast IPP packets. A broadcast address must only be specified for outgoing print jobs. This may be configured with YaST, for example.
IPP is used for the communication between a local and a remote CUPS daemon or server. More recent network printers also have built-in support for this protocol (there are a number of models from different makers). Find more information about this on the web pages of manufacturers or in your printer's manual. IPP is also supported by Windows 2000 and newer Microsoft systems, although originally the implementation was somewhat flawed. These problems may have disappeared or it may be necessary to install a Service Pack to repair them.
There are many ways to set up a printer with CUPS and to configure the daemon: with command-line tools, with YaST, with the KDE Control Center, or even through a web browser interface. The following sections are limited to the command-line tools and YaST.
When using the web browser interface for CUPS configuration, be aware that there is a risk of compromising the root password. The password will be transmitted as plain text if the URL specified includes the real host name. Therefore, you should always use http://localhost:631/ as the host address.
For the above reason, the CUPS daemon can only be accessed for administration if addressed as localhost (which is identical to the IP address 127.0.0.1) by default. Entering a different address returns an error message, even if it is valid.
To configure a locally connected printer, first set up a CUPS daemon on the local host. To do so, install cups together with the PPD files provided by SUSE as included in cups-drivers and cups-drivers-stp. After that, start the server as root with the command /etc/rc.d/cups restart. If you configure it with YaST, the above steps are already covered by selecting CUPS as the printing system and installing a printer.
PPD (PostScript Printer Description) files contain options for printer models in the form of a standard set of PostScript commands. They are required for printer installation under CUPS. SUSE LINUX comes with precompiled PPD files for many printers from a number of manufacturers. Manufacturers may also offer PPD files for their PostScript printers on web sites and installation CDs (often in an area called something like Windows NT Installation).
The local daemon can also be started so printers of all broadcasting servers are available locally, although there is no local printer. This simplifies the use of these printers from within KDE applications and OpenOffice.org, for example.
Broadcasting can be enabled with YaST. Alternatively, enable it by setting the Browsing directive to On (the default) and the BrowseAddress directive to a sensible value, like 192.168.255.255, in the file /etc/cups/cupsd.conf. After that, tell the CUPS daemon explicitly to grant access to incoming packets, either under <Location /printers> or, preferably, under <Location />, where you would have to include a line like Allow From some-host.mydomain (see file:/usr/share/doc/packages/cups/sam.html). When finished editing the file, tell the daemon to reread its configuration by entering the command /etc/rc.d/cups reload as root.
Network printers are printers that have a built-in print server interface (such as the JetDirect interface in some HP printers) or printers connected to a print server box or a router box enabled as a print server. Windows machines offering printer shares are not print servers in the strict sense (although CUPS can handle them easily in a way similar to print servers).
In most cases, a network printer supports the LPD protocol, which uses port 515 for communication. Check lpd availability with the command:
netcat -z <hostname>.<domain> 515 && echo ok || echo failed
If such a server is available, CUPS can be configured to access it under a device URI, an address in the form lpd://server/queue. Read about the concept of device URIs in file:/usr/share/doc/packages/cups/sam.html.
However, you should probably not use the LPD protocol for a network printer, but rather the printer's built-in port 9100 if available (HP, Kyocera, and many others) or port 35 (QMS). In this case, the device URI must have the form socket://Server:Port/.
To use printers made available through Windows, install samba-client first and configure this package — enable the correct work group and make other settings. A device URI for Windows printers may be specified in several ways, but the most frequent one has the syntax smb://user:password@host/printer. For other configurations, see file:/usr/share/doc/packages/cups/sam.html and man smbspool.
If you have a small network consisting of several (Linux) machines and have set up a print server for it, avoid configuring the printer for each and every client host by enabling the broadcast function of the daemon (see above). Thus, when you modify the configuration (for instance, to use the new standard paper size Letter), it is sufficient to do this once on the server side (also see Section 220.127.116.11. “Specifying Options for Queues”). Although the configuration is saved locally on the server side, it is propagated to all clients in the network with the help of the CUPS tools and the IPP protocol.
Basically the CUPS daemon should be able to handle any file type, although PostScript is always the safest bet. CUPS processes non-PostScript files by identifying the file type according to /etc/cups/mime.types first then converting the file into PostScript by calling the appropriate conversion tool for it as defined in /etc/cups/mime.convs. With CUPS, files are converted into PostScript on the server side rather than on the client side. This feature was introduced to ensure that special conversion operations necessary for a particular printer model are only performed on the corresponding server machine.
After conversion into PostScript, CUPS calculates the number of pages for each print job. This is done with the help of pstops (an internal version of the program located at /usr/lib/cups/filter/pstops). The accounting data for print jobs is written to /var/log/cups/page_log. Each line in this file contains the following information:
printer name (for example, lp)
user name (for example, root)
date and time (in square brackets)
current page number
number of copies
CUPS can also use other, special filters, if the corresponding printing options have been enabled. These are the most important ones:
Allows limiting the printout to certain pages of a document.
Allows printing several pages on one sheet.
Read file:/usr/share/doc/packages/cups/sum.html for information about how to enable the various options.
The next step is the launch of the filter needed for generating printer-specific data. These filters are located in /usr/lib/cups/filter/. The suitable filter is determined in the PPD file in the *cupsFilter entry. If this entry does not exist, the print system assumes that the printer is a PostScript model. All device-specific printing options, such as the resolution and paper size, are processed in this filter.
Writing a custom printer-specific filter script is not a trivial task; see the SDB article Using Your Own Filters to Print with CUPS (keywords: cups + filter).
As the final step, CUPS calls one of its back-ends. A back-end is a special filter that transfers print data to a device or to a network printer (see file:/usr/share/doc/packages/cups/overview.html). The back-end maintains the communication with the device or network printer (as specified through a device URI during configuration). If the back-end is usb, for example, CUPS runs /usr/lib/cups/backend/usb, which in turn opens (and locks) the corresponding USB device file, initializes it, and passes the data coming from the print filter. When the job is finished, the back-end closes the device and unlocks it.
The following back-ends are currently available: parallel, serial, usb, ipp, lpd, http, socket (included in cups). Also available are canon and epson, included in cups-drivers-stp, and smb, included in samba-client.
To print files without any filtering, use the lpr command with -l or use the lp command with the -oraw option. Usually, the printout will not work, as no printer-specific conversion is performed or other important filters are omitted. The options are similar for other CUPS tools.
When printing from OpenOffice.org applications, CUPS is supported such that a running CUPS daemon is autodetected and queried for available printers and options (this is different from StarOffice 5.2, where it was still necessary to perform a setup for each printer). An extra CUPS setup from within OpenOffice.org should not be necessary.
Printers connected to a Windows machine can be addressed through a device URI, such as smb://server/printer. To print from a Windows machine to a CUPS server, set the entries printing = CUPS and printcap name = CUPS in the Samba configuration file /etc/samba/smb.conf (this is preset in SUSE LINUX). Following modifications in /etc/samba/smb.conf, the Samba server must be restarted. See file:/usr/share/doc/packages/cups/sam.html for details.
A raw printer can be set up by leaving out the PPD file during configuration, which effectively removes all filtering and accounting features from CUPS. For this purpose, the data must be sent in the printer-specific data format.
The configuration options, such as a different default resolution, can be modified and saved for each user. The configuration is saved in the file ~/.lpoptions. If such a reconfigured printer is removed on the server side, it will still be visible in various tools, such as kprinter and xpp. You can still select it even if it no longer exists, which causes problems. Experienced users can easily remove the superfluous lines from ~/.lpoptions with an editor. Refer to the Support Database article Print Settings with CUPS as well as Section 18.104.22.168. “Specifying Options for Queues”.
CUPS can also receive print jobs from LPR systems. The needed configuration in /etc/xinetd.d/cups-lpd can be handled manually or with YaST.
By default, the configuration file /etc/cups/cupsd.conf contains the following section:
# LogLevel: controls the number of messages logged to the # ErrorLog file and can be one of the following: # # debug2 Log everything. # debug Log almost everything. # info Log all requests and state changes. # warn Log errors and warnings. # error Log only errors. # none Log nothing. # LogLevel info
To detect errors in CUPS, set LogLevel debug and use rccups restart to have cupsd use the modified configuration file. Subsequently, /var/log/cups/error_log contains detailed messages that assist in detecting the cause of problems.
With the following command, print a label before starting to run the test:
echo "LABEL $(date)" | tee -a /var/log/cups/error_log
This label will be entered in /var/log/cups/error_log. This makes it easier to find the messages after the test.