The CUPS Printing System

CUPS is what its name says: a common UNIX printing system. It is aimed
at providing a common printing interface across a
local network, masking differences among the printing systems on each
computer. I am not sure that such a system is needed in a
pure Linux environment, where the standard Berkely LPD provides this
functionality, but CUPS does provide interactivity with SMB and Windows
printers. CUPS also allows dynamic printer detection and grouping.

CUPS is licensed under the GPL by a company called Easy Software Products.
Besides providing CUPS itself as free software, the company also provides
commercial add-ons and support. You can get CUPS from www.cups.org, and it is available as
an RPM package for most distributions. I've seen it for Mandrake, Red
Hat and SuSE.
How Does It Work?
CUPS can be seen as a replacement for the LPD printing system. It
replaces the lpr command with its own and the LPD printer drivers with
its own versions. However, CUPS is similar to LPD in that it uses PostScript
as its underlying language for page descriptions. Linux (and UNIX)
programs don't know the difference between CUPS and LPD.

CUPS contains a list of printer drivers that include most printers with
a parallel port, USB and even serial connections. A note about serial
connections: connecting a printer with a null-modem serial line is slow
and more difficult to set up than a parallel line. But, it is sufficient
for a matrix printer--for bulk printing or multiple copies--and makes
an easy way to build a print server from a pile of older hardware. A hint
to schools!
Dynamic Printer Detection
CUPS shares a characteristic with Windows systems that is not too common in
the UNIX world: it broadcasts the printers available on the local
computer to all other computers on the network. In this way, every
computer on the local IP segment gets to know in real time which
printers are available and what the status is for each one. Naturally,
this characteristic is configurable. You can tell CUPS, in the
cupsd.conf configuration file, if it should broadcast, where to broadcast
to and how often the information should be refreshed.
Grouping Printers
A printer group, called a "class" in CUPS, is a group of printers
that appears as a single printer to user programs. For example, you
could create a group called ColorPrinters that included all your color
printers. A user then could tell his program to print on printer
ColorPrinters, and the output would be on one of these printers. Which
printer would depend on user rights or which printer currently is available.

The fact that a printer is a member of a group does not mean, in itself,
that users cannot use that printer directly. At CUPS access control
level, however, you can make individual printers reject jobs while groups
accept them. The end result is users can use printer groups, not
printers. It depends a bit on the policy on printer use you intend to
implement.
Example 1
I have a workshop with five computers running Linux, all running CUPS.
When changing a printer on one of them, I take the old printer off of CUPS
and put in the new printer by using the CUPS Web interface, all in under
30 seconds. That is all the configuration required; the other computers
get their default printing routes updated in another 30 seconds. It
takes less than one minute for the whole change--less time than a laser
printer takes to warm up.
Example 2
For my school network, I like to provide:

• A laser B/W printer class that anybody can print
  on.
• A draft Color class that anybody can print on, but with
  restrictions on volume.
• A precision Color class that is unblocked only under my
  supervision.

Most of these printers hang off Windows boxes and would be available directly
for other computers under Windows. However, by providing them
through CUPS on a central bridge/router, I:

• provide a means of centralizing printers; users only have to look
  for a printer in a single place
• provide a means of printing on another Ethernet segment without
  allowing normal Windows broadcast traffic to get across and
  clutter up network bandwidth
• make sure that the teacher printing from his classroom up there on
  the third floor of the other building doesn't get stuck because
  the departmental printer on the ground floor of this building has
  run out of paper; his print job got redirected to the standby
  printer

Integrating with Windows
To use a Windows printer under Linux or the other way round, you
need to have a Samba server working. Set it up and test it before
going on. As a normal user, try viewing your home directory on the Linux
computer from a Windows box. Remember to turn password encryption on
in /etc/samba/smb.conf if you are using Windows 98 or a more recent
version.

CUPS can use printers shared from computers under Windows and network
printers using the SMB protocol. You configure a "Windows printer using
Samba". Basically, all you have to tell CUPS is the address of the
printer, as in smb://server/printer.

Windows can use a CUPS printer shared by Samba. Proceed in the normal
way to share your printers with Samba; that is, do not do anything. Your
printers generally are shared by default. If this is not the case, edit
smb.conf to create the necessary share. All the Samba share options
are applicable, because Samba treats a CUPS printer in the same manner
as it does an LPD printer.
Network Printers
Network printers, a printer with a network interface that
doesn't need a host computer to be made available to the network, can
use any of a variety of protocols:

• SMB protocol - you can see it in your Windows network environment
  browsing screen
• LPD protocol - several models of Epson printers integrate a TPC/IP
  stack and the LPD protocol. You then can access them on port 515,
  just like a Linux box. Try using default queue lp
• A proprietary protocol - not good

In the first two cases, proceed as with a printer hosted by a computer.
In the third case, you probably are at a dead end. This happened to me with a
Lexmark: I ended up sharing it from a Windows box.
Configuration
There are two ways to configure CUPS. One is to edit the
configuration file /etc/cups/cupsd.conf. The other is to sue a classic
Web-based interface that you can access on port 631. This method is similar to
the Web-based configuration of many network-capable printers and should
be intuitive for all.

Generally, you can access the Web interface only from the localhost
interface, not from other computers. However, you can change this by
changing the following lines in the configuration file cupsd.conf and
restarting CUPS:

<Location />                   # this location is the main screen
Order Deny, Allow
Deny From All
Allow From 127.0.0.1           # allow configuration from local host
Allow From 192.168.1.*         # allow configuration from any machine
                               # on the 192.168.1.0/24 subnet
Allow From mybox.mydomain      # this is my desktop on another segment
</Location>

You also can specify one by one which menu items, called Locations in
CUPS terms, are accessible from any particular IP address. This doesn't
mean that other computers will not be able to connect to the server;
they simply won't be able to access contents.

If your Linux box is acting both as a print server and a bridge between
two or more IP segments, you also can specify on which network interfaces
it will listen for requests:

Listen 127.0.0.1:631		# Should already be there
Listen servename:631		# Add your server name here
Listen 192.168.1.1:631		# You can also use your IP address

In the above example, the Web interface is visible through my eth0
interface with IP address 192.168.1.1, but not through the eth1
interface with IP address 172.16.0.1 .

Although user identification is required through basic login/password
authentication, note that you can use SSL to connect to the Web
interface using HTTPS. This also is relatively easy to configure in the cupsd.conf file.

The Web interface comes with a comprehensive help system with plenty of
documentation about what CUPS is and how to configure it.

Copyright (c) 2003, Alan Ward. Originally published in Linux Gazette
issue 90. Copyright (c) 2003, Specialized Systems Consultants, Inc.

Alan teaches CS in Andorra at high-school and university levels.
His hobbies include science photography, both digital and traditional;
trekking; and rock and processor collecting.