The CUPS Printing System

A basic introduction to what CUPS is and why you might want to use it rather than LPD.

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


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           # allow configuration from local host
Allow From 192.168.1.*         # allow configuration from any machine
                               # on the subnet
Allow From mybox.mydomain      # this is my desktop on another segment

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		# Should already be there
Listen servename:631		# Add your server name here
Listen		# You can also use your IP address

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

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.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

linux printing

r_secar's picture

how do config dot matrix ptinters

Old News - Keep up to date

Anonymous's picture

Recycled articles don't work. The facts get old because of this thing called progress. Linux Journal please take pride in Linux and your magazine. Don't hinder your readers, help them.

Regarding this article. Go to the CUPS site if you need help with CUPS, they have articles, reference guides, a friendly forum for questions, etc...:

IPP and Windows

Anonymous's picture

You don't need to set up a Samba Server to use printers on the server from Windows 2000 and Windows XP clients. These can use the IPP protocol, you basically need to use an address like http://server:631/Printername and it works.

RE: IPP and Windows

Peter Strasiniuk's picture

This is what i am looking for, thx. Saves me a lot of time.
i tried: http://server:631/HP-Laser it works,
cu, ps

CUPS Printer Access to Foreign Domain Win XP client

Naveen D's picture

If Samba is not configured then can a Win XP client access a foreign subnet CUPS printer?
e.g: CUPS printer location is a.b.c.d:631
Win XP IP is a.b.x.y (the difference here is only .x.y)

Please mail me a solution for this at

"Old" may still be good -- but it is *wrong* on many details

Anonymous's picture

I dont take objections about the perceived age of this piece -- but unfortunately, no-one seems to have looked at it before publication. It was wrong on many points in 2001 -- and it is wrong on the same points now.

Looking at their function as print *spoolers*, LPD doesnt care for PostScript, nor does CUPS. They'll both spool any data you send them -- PCL, raw, ASCII, PostScript, PDF.... even mp3, if configured to do so.

CUPS on top of being a spooler is also a print data *processor*. It can convert many file formats into printable streams -- and adapt those printable streams to the target printer (be it a PS one or a LJ or Inkjet or Matrix or whatever printer). {And of course, it can also *reject* certain data types...}

Unforch, the article doesnt even attempt to explain the crucial difference between mere spooling and job filtering to the reader. But for anyone with a slight practical experience in troubleshooting print problems, or training admins to do so it should be very clear that this is one of the first topics to teach in a printing primer.

Another thing of wrongness in this article is the configuration example shown: it is plain false to claim that the "<Location />...</Location>" allows *configuration*. It doesnt. It only allows *viewing* of the page. For allowing or disallowing of configuration, use the "<Location /admin>...</Location>" section of cupsd.conf.

I could go on and on and on.... but who is going to pay my time if I wrote a complete new article from scratch?

Another great primer

Peter B's picture

I agree!! This is NOT old news for newbies like me.. and the best news is the newbie population is growing everyday as more and more people are discovering Linux. Please keep up with similar type articles because there is heaps of people like me out here who are really hungry for information aimed at the introduction/primer level.

Thanks for the info

Anonymous's picture

With all due respect to the previous commenter (and copyright issues aside), a joke is only old if you haven't heard it before. As Linux has become more newbie-friendly lately, there are scores of new users (like myself) trying out Linux who are eager for this kind of material.


Kind of old, isn't it?

Fred Sanford's picture

CUPS has been standard on Linux distributions for dog's years now. Why is LJ recycling old Linux Gazette articles, anyway? This is at least the third one. Can't you afford new material?

It's a good article- it's just old. One nit- it should be made clear that you must edit cupsd.conf for any kind of network printing. You cannnot configure it from the CUPS web interface.

You'll be able to be in CUPS

Anonymous's picture

You'll be able to in CUPS 1.2:

Re: Kind of old, isn't it?

Nathan Bargmann's picture

I network print and haven't ever touched cupsd.conf at any time. I have a Gigafast router that provides an LPR server for an attached printer. I use the Device URI: lpd:///lp (lp is the LPD printer name) and it works perfectly. I administer my printers from the web interface.

With CUPS and the Gutenprint library I get higher quality print from my aging Lexmark 4039-10R than even Windows XP can provide. CUPS is great technology and much needed. I switched a year ago from lpr-ng with various filters and haven't looked back.

Arcane uri's...

sgr's picture

This highlights one of the objections of Eric Raymond's rant of a couple of years ago on CUPS -- it's a nice tool, but for a web based configuration utility, why do they rely on the user to know these magic URI's to use? It'd be nice if they at least had some examples in the web configuration interface, or heck, even some pulldown tabs with the various options listed, along with a button that allows you to test that there's actually a server at the uri.

I love cups, but as Eric wrote, this is typical of the type of expertise that using Linux requires, and is something that keeps great software like this out of the hands of the non-professionals.

On LJ "stealing" Linux Gazette's content: Why shouldn't they, they stole the domain, why shouldn't they steal the content?


M. Miling's picture

If you're using fedora (and possibly other distros) and you want to modify the cupsd.conf file and not use the GUI, remember to comment out the line "cups-config-daemon" in /etc/init.d/cups, or else this daemon will overwrite your changes with a default per your security settings.