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).

Print data is transferred to a CUPS daemon, which is also acting as a local server in most cases. Other daemons can be addressed using the environment variable CUPS_SERVER.

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.

	Warning
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 5.7.1.4. “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.