The Common UNIX Printing System (CUPS) works great when used on a stand-alone workstation. It works even better when used to provide network-wide printing capabilities. That’s when the power and flexibility of this printing system really becomes evident.

This Daily Drill Down will provide the information you need to implement CUPS for network-wide printing.

What you need
The latest version of CUPS is available from the CUPS Web site. For this article, version 1.1.14 was used. The file to download is in source code form and is called cups-1.1.14-source.tar.gz.

Installing CUPS
The CUPS source code package is installed in three steps. The first step is to unpack the source code with the command tar -zxvf cups-1.0.5-source.tar.gz. This command will create a directory named cups-1.1.14 where all source code will be unpacked. Change into the new directory with the command cd cups-1.1.14.

The second step is to configure the source code for the local system with the command, ./configure. When CUPS is installed, any printing commands that currently exist in the /usr, /etc, and /var directories on the server will be overwritten. It is possible to specify the installation directories for CUPS when the source code is configured. This can prevent any existing print configuration from being overwritten, and also allows another printing system to be used while the CUPS installation is tested. Table A lists some of the installation options and default values used when CUPS is configured. For a complete list of configuration options, run the following command, ./configure –help before configuring CUPS.

Table A
Option Function Default
–exec-prefix This allows you to define the location of executable files. /usr
–libexecdir This directory contains server executable files. /usr/lib /usr/libexec
–libdir This directory contains library files. /usr/lib
–sysconfdir This directory contains CUPS configuration files. /etc
–mandir This directory contains CUPS man pages. /usr/man /usr/share/man

A test installation for CUPS might require that the binaries and libraries for CUPS be installed in /usr/local/cups, the configuration files be placed in /usr/local/etc, and the CUPS libraries be placed in /usr/local/lib. All CUPS log files will be placed in /usr/local/var.The following series of commands will install CUPS for this test installation.

First, use the commands in Listing A to create any required directories, if they don’t already exist.

Next, run the configure script with the options shown in Listing B.

Once the CUPS source code is configured, the next step is to build CUPS by running the make command as root.

To test the compiled source code prior to installation, run the make test command. If the test process reports any errors, the best source for help is the CUPS Web site. If no errors are reported, CUPS may be installed with the make install command.

Selecting the printing system
Now that CUPS is installed, and is able to co-exist with the printing system previously installed on the server, the next step is to select which printing system will be used. The first step to switching printing systems is to shut down the printing system already being used. To stop the current system, use the /sbin/service lpd stop command.

Now, start CUPS with the /sbin/service cups start command. If CUPS is running correctly, the printing system may be permanently switched to CUPS by running the following command:
/usr/sbin/alternatives –config print

After running this command, the printing options installed on your system will be displayed. Listing C shows an example of how this might look.

The options shown in Listing C will be made available when your run the alternatives –config print command. Select lpr.cups (or 1 in the example shown in Listing C) to make CUPS the default print system.

Server configuration
The CUPS server is configured through several configuration files located in the /etc/cups directory. Each of these files uses a format similar to the format used by the Apache Web Server configuration files. This format is:
<directive  directive-name>

There are four configuration files that are normally edited by the CUPS administrator. Table B lists these files and their functions.

Table B
Files Function
cupsd.conf This file controls the operation of the CUPS server (cupsd).
printers.conf This file controls the configuration for each printer.
classes.conf This file is used to configure each printer class.
client.conf This file sets the default server for each client connected to the CUPS system.

Implementing printer classes
Printer classes are simply groups or collections of printers. Printer classes provide efficiency and redundancy by sending print jobs to the first available printer in a class. Printer classes are created by using the -c option with the /usr/sbin/lpadmin command. In the example shown below, the finance department for an organization needs three HP DeskJet printers connected to a CUPS server. Each of these printers will be added to the finance_lasers class.

The format used for the /usr/sbin/lpadmin command is shown in Listing D.

To add the first printer, and to create the finance_lasers class, use the command shown in Listing E.

To add the next two printers to the same class, use the commands in Listing F.

If a printer must be removed from a class, the -r option is used with the lpadmin command. To remove finance_laser2 from the finance_lasers class, use the command in Listing G.

To completely remove the finance_lasers class from the CUPS server, use the command shown in Listing H.

Configuring the CUPS client
A client is any computer that sends a print job to another computer for printing. A client may communicate with a printer connected to another printer or to a printer connected directly to the local system.

Configuring printer queues manually
On networks with a small number of client machines, each client may be configured manually, using the /usr/sbin/lpadmin command. When the client is configured manually, the lpadmin command is used with the syntax shown in Listing I.

To configure a client to use DeskJet1 on the CUPS server, the lpadmin command is used, as shown in Listing J.

The command shown in Listing J sets the following values:

  • ·        The printer name (finance_laser1)
  • ·        The printer is enabled. (-E option)
  • ·        The Printer model(-m)—In this case, the DeskJet postscript printer description file is used.
  • ·        The Uniform Resource Identifier—In this case, the Internet printing protocol (IPP) is used to specify the IP address of the server.
  • ·        The path to the appropriate printer queue on the server—In this case, printers/finance_laser1

Configuring printer queues automatically
The /etc/cups/cupsd.conf file controls the operating parameters for the CUPS server. The administrator normally edits this file using a text editor. Operating parameters are passed to CUPS though configuration file directives. This article focuses only on the directives used to configure a basic network printing solution. The complete list of configuration directives is available on the CUPS Web site.

The BrowseAddress configuration is used to automatically configure clients on the same subnet. To ensure that all clients see all available printers on the same subnet, set the BrowseAddress in the /etc/cups/cupsd.conffile. Some examples of how the BrowseAddress may be specified are shown in >Listing K.

Using multiple CUPS servers
When CUPS servers are implemented on different subnets, client computers may be configured to poll each server. In these situations, the BrowsePoll directive is used to specify each server to be polled. The BrowsePoll directive is specified in the /etc/cups/cupsd.conf file.

The BrowsePoll directive uses the format:
BrowsePoll <ip-address-of 1st cups-server>
BrowsePoll <ip-address-of-2nd-cups-server>

To configure the client machine at address to poll the CUPS severs at and, use the following directives:

One potential problem with polling is the high traffic generated when each client on several subnets is polling a large number of servers and printers. To reduce the amount of traffic generated by polling, one client on each subnet may be used to poll all CUPS servers on the network, and this information may then be relayed to all clients on the same subnet. This reduction is achieved using the BrowseRelay directive.

To achieve browse relaying, the client used for polling is first supplied with the IP addresses of the servers to be polled through the BrowsePoll directive, and the BrowseRelay is then used to specify which clients the polling information is sent to. In the example shown in >Listing L, the client computer at uses the BrowsePoll directive to poll the CUPS severs at, and, and the polling results are then relayed to all hosts on the subnet. Lines beginning with the # sign are comments.

When the client at discovers CUPS printers, the polling information will be relayed to all hosts on the subnet. The client at is the only computer on the subnet requiring this configuration.

Working with implicit printer classes
When server polling is implemented, CUPS clients are capable of combining identical printers on different servers into one implicit class. When CUPS creates an implicit class, the client assumes that the printers on each server are actually the same printer being served by queues on more than one server.

For example, if the server at serves an HP DeskJet, and there is another HP DeskJet served by the CUPS server at, an implicit class named deskjet will be created on any client that uses both printers. If there is also a DeskJet printer connected directly to the client, CUPS will instead create an implicit class named anydeskjet.

Implicit classes provide redundancy by allowing clients to stop sending print jobs to the first available printer in the implicit class when one of the servers or printers is unavailable. Figure A shows an example of an implicit class created when two DeskJet printers are connected to CUPS servers at and

Figure A
Using implicit classes allows for simple printer sharing.

In Figure A, there is no printer connected directly to the workstation at This workstation uses the deskjet implicit class, allowing print jobs to be forwarded to the first available printer on either server.

The workstation at does have a direct connection to a DeskJet printer, and this workstation uses the implicit anydeskjet, allowing print jobs to be sent to the local printer, or to the first available printer on either CUPS server.

While CUPS does support printing from lpd clients, CUPS does not provide automatic configuration or configuration of printer options for lpd clients. On Most Linux systems, this support is made available through the xinetd daemon. To enable CUPS support for lpd printing, add the following section to the /etc/xinetd.conf file or create the /etc/xinetd.d/cups file, and add this section:
   service printer
   protocol = tcp
   wait = no
   user = lp
   server = /usr/lib/cups/daemon/cups-lpd

Printing from Windows/SAMBA clients
All versions of SAMBA from 2.0.6 up support CUPS printing. With 2.2.x versions of SAMBA, edit the smb.conf file, and replace the printing configuration with the following entries:
printing = cups     
printcap = cups

Next, run the following command to add any printer(s) to be shared:
/usr/sbin/cupsaddsmb  <printer-name>

Using the Internet Printing Protocol with Windows clients
The Internet Printing Protocol (IPP) is available from Microsoft. To configure a network printer using IPP from a Windows client, the syntax shown in >Listing M is used to specify the printer.

To send print jobs from a Windows client to a DeskJet printer on the CUPS server at, use the following entry:

By default
CUPS is a solid solution for administrators dealing with a variety of clients and operating systems on their network. Although the older UNIX lpd system is still the default on some Linux distributions (RedHat being the primary example), the CUPS printing system is finding its way as the default for distributions such as Mandrake and SuSE. So if you’re looking for a Linux distribution that uses CUPS by default, you don’t have to look any further than your local Linux distributor.