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.
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!
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.
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.
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.
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
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, 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 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.
|Nativ Disc||Sep 23, 2016|
|Android Browser Security--What You Haven't Been Told||Sep 22, 2016|
|The Many Paths to a Solution||Sep 21, 2016|
|Synopsys' Coverity||Sep 20, 2016|
|Naztech's Roadstar 5 Car Charger||Sep 16, 2016|
|RPi-Powered pi-topCEED Makes the Case as a Low-Cost Modular Learning Desktop||Sep 15, 2016|
- Android Browser Security--What You Haven't Been Told
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- The Many Paths to a Solution
- Nativ Disc
- Naztech's Roadstar 5 Car Charger
- Synopsys' Coverity
- Securing the Programmer
- RPi-Powered pi-topCEED Makes the Case as a Low-Cost Modular Learning Desktop
- Glass Padding
- Identity: Our Last Stand
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide