Leveraging Linux Printers | Windows And Linux Integration Hands-on Solutions for a Mixed Environment

The LPD (Line Printer Daemon protocol) and the associated lpr command formed the core of the Linux print spooling system for many years . Even today, the lpr command and the LPD remote printing protocol are still available as part of the modern Linux/Unix printing system.

This more modern system is called CUPS (Common Unix Printing System). CUPS is implemented by the cupsd daemon, and it also speaks the more modern IPP protocol (Internet Printing Protocol). To understand how Linux printing works today, it is necessary to understand a few things about the history of printing on Linux and Unix systems.

Understanding Linux Printing

For many years Unix printing facilities were heavily oriented toward plain-text, 80-column printing. Later, Adobe's Postscript language became the standard Unix answer to the question of attractively formatted printing. Those who wanted to print attractive documents in a portable way were advised to purchase a Postscript printer with a built-in interpreter for the Postscript language. The popularity of Postscript printers for use with Macintoshes made this a reasonable choice, and Unix systems were generally high-end workstations, so the higher price of Postscript printers was not an issue.

At the time when Postscript printers were most popular, placing the smarts to interpret the Postscript language in the printer made sense because Postscript is a high-level, human-readable language that can describe a page in a very sophisticated way. Ten years ago, translating that language into dots on a page required a large percentage of any computer's resources.

Printing to Network Print Servers

Of course, in today's office environment and even in the home, printers are not always connected directly to a Linux or Windows server. Instead, printers are often connected directly to the network via a device called a dedicated print server. The sole function of a dedicated print server is to accept a stream of printer commands from print clients and to communicate those commands to the attached printer.

However, even though a printer has a dedicated print server, it still needs support from a general purpose computer running Windows or Linux to provide temporary print job storage and to host additional management features too complex to store in the limited memory of the network print device.

Printing to a dedicated print server from Windows is generally straightforward because manufacturers provide Microsoft with drivers for their network print devices along with drivers for their printers. But what about Linux?

IPP-Compatible Print Servers

As it turns out, most print server manufacturers today support IPP in their latest products, and they support it in just the way Fedora Linux expects: on port 631. That means that we can add a queue for such a printer using the "Networked Unix (CUPS)" queue type in Fedora's printer configuration tool. Not all such boxes advertise themselves on the local network, so you will usually need to enter the print server's IP address and a printer path. Windows users also need to do this using the Internet Printing feature of the Add Printer Wizard. The exact server IP and printer path information to use is readily available in the documentation of each print server. Standalone print servers offer a web-based configuration interface, which can be operated with equal ease from Linux- and Windows-based web browsers.

Examples of IPP-compatible print servers on the market as of this writing include the Linksys WPS54GU2, which offers a wireless network interface and support for both parallel and USB printers. Another similar unit is the Netgear PS101NA, a less expensive device with a wired Ethernet interface and a parallel printer port.

HP Jetdirect Print Servers

One type of dedicated print server requires special mention, the Hewlett-Packard Jetdirect printer server. It's possible to print to newer Jetdirect print servers using IPP, but you can also print from Linux to a Jetdirect print server using HP's own Jetdirect protocol.

Newer models of Jetdirect printer servers offer a browser-based configuration interface that can be accessed from any operating system. Once the printer server has been configured, you can click the "New" button in the Fedora printer configuration tool and select the "Networked Jetdirect" queue type on the first page of the wizard. When prompted, enter the IP address of the Jetdirect box in the "Printer" field and leave the port number set to 9100 to talk to a standard Jetdirect box. The rest of the steps are identical to those for a local printer.

Of course, not all printers understood Postscript even at the height of its popularity. Cheaper printers in general rarely had Postscript interpreters built in. These printers instead "spoke" much simpler languages like HP's PCL (Printer Command Language) or Epson's ESCP2 (named for the escape sequence of characters that enabled it). These languages were interpreted at the host computer so that only control characters were sent to the printer itself. Using these printers on a Linux system required an open -source page rendering solution.

Matters grew worse with the introduction of Winprinters, which were (and sometimes still are) printers that, to save a few pennies, do not offer even the rudimentary smarts to handle a language like PCL or ESCP2. Instead, the computer to which they are attached is required to micromanage printing, right down to the precisely timed transmission of rows of pixels. The specifications for these printers were rarely made available to open source developers. Generally speaking, no one much cared for Winprinters because they put considerable and largely unnecessary demands on the host computer. They also couldn't be easily moved to computers running alternative operating systems.

Today, computers have CPU and memory to spare, and an open-source Postscript interpreter, called Ghostscript, is a standard part of every Fedora Linux system. Ghostscript supports many different printer languages on the back end, including hundreds of printers that do not speak Postscript natively (and even quite a few Winprinters!). Ghostscript accepts Postscript as input and renders a bitmap of the actual pages. Then it feeds the results to the printer in its native control language. If Ghostscript supports your printer, or it speaks Postscript natively, then you can attach that printer to a Linux system.

Why Linux Printing and Windows Printing Are Different

All Windows applications use a single interface to the operating system to create graphics called the GDI (Graphics Device Interface) . GDI draws stuff on the screen, and it's also what's used to help stuff get printed on the page.

While it's true that there can be differences between printer drivers and on-screen graphics drivers, in a general sense Windows programmers can write one set of code both for the screen and the printer.

Because Windows is so popular, it wasn't difficult for Microsoft to convince printer manufacturers to create GDI printer drivers. Even Postscript printers have GDI drivers, which translate GDI API requests to Postscript commands. We'll take advantage of that fact later, when we wish to print from Windows clients to Linux servers without the need for a printer-specific print driver on each Windows client.

On the Linux side, the situation is different. Linux applications draw to the screen using the X Window System or libraries, like GNOME's gtk library, which are built on top of it.

However, the X Window System was not originally intended for printing (although some support for printing was added very recently). Linux and other Unix systems use Adobe's Postscript printer language for printing tasks . Applications, or the development libraries they rely on, must provide separate code for on-screen graphics and Postscript printer graphics. That's why Postscript-compatible printers, as well as the free Ghostscript interpreter software that permits non-Postscript printers to handle Postscript, hold such key roles in Linux printing.

Linux-Compatible (and Not-So-Compatible) Printers

Does this mean that every printer works with Linux? Well, no. Some Winprinters continue to provide only a proprietary and undocumented interface. Since their manufacturers will not release information to the Ghostscript developers, nothing can be done to support those printers.

The good news is that virtually all "business-class" printers (such as most modern laser printers) work well with Linux. In addition, certain printer manufacturers have been particularly generous in their support of Linux. Thanks to HP's thorough and detailed support, virtually all of HP's printers are highly Linux-compatible, even including home-oriented multifunction inkjet models such as the HP PSC 2175. HP provides a driver called hpijs that does the back-end work to make this possible, and hpijs is a standard part of Fedora Linux.

Epson has made a similar effort, and most current Epson printers are also highly Linux-compatible via Epson's gnome-print driver. And although most of the low-end inkjet Lex-mark printers are not particularly Linux-friendly, Lexmark's business-class laser printers are thoroughly supported.

Of course, we need more precise information to decide whether a specific printer is suitable for Linux. How can we most easily sort out the compatible printers from the rest? The website www.linuxprinting.org offers both a compatibility database and a list of recommended printers for Linux at:

www.linuxprinting.org/printer_list.cgi

If you're shopping for a new printer specifically for your Linux system, compatibility should be your first consideration. You can find Linux printer recommendations at:

www.linuxprinting.org/suggested.html

How Linux Printing Works Today

Nearly all modern Linux applications generate Postscript code when asked to print a document. Sometimes they do this directly, other times via printing APIs supported by gtk or KDE's Qt library. The Postscript code is then sent to CUPS, often via the lpr command. If the printer does not reside on the same computer, the Postscript code is delivered to the print server via IPP.

CUPS maintains a queue of print jobs for each printer. This way, the application can continue operating in the foreground while printing tasks are carried out in the background. In the background, CUPS then launches a printer driver.

Printer drivers consist of a .ppd file and, if the printer does not natively speak Postscript, a filter program as well. The filter program is usually a simple wrapper shell script that launches Ghostscript with appropriate parameters for the printer. The filter program is responsible for translating Postscript (or occasionally simple plaintext) input to the native language of the printer. Finally, this raw printer-friendly data is fed to the printer by CUPS, either via the USB port or an old-fashioned parallel port interface. See Figure 5.11 for a diagram of the Linux printing architecture.

Figure 5.11: The Linux printing architecture

Printing from Windows: Postscript vs. Native Drivers

Figure 5.11 shows how Linux printing works in a pure Linux environment. But Linux can also accept print jobs from Windows clients. Windows print jobs can arrive via LPD, IPP, or SMB. LPD and IPP are natively supported by CUPS with no additional configuration. SMB is supported by Samba, which passes all printing requests through to CUPS.

Individual Windows clients have printer drivers that output the native language of the printer, or an intermediate, Windows-specific language that is more compact for transmission over the network. Windows print servers then interpret the intermediate language and pass the result to the printer. So what happens when Windows clients talk to Linux print servers? There are two ways to approach the problem.

Postscript Printing from Windows to Linux

A Windows client can print to a Linux server using a Postscript driver, just as a Linux client would. This means that you can load any ol' Postscript printer driver on all your Windows systems (like an Apple Color LaserWriter 12/600), instead of the "real" printer model name and number and you're off to the races. This assumes that your printer has similar physical capabilities to the Postscript printer the driver is intended for, especially the same paper size .

We'll do this later in several steps and talk more about the process as we do it. However, the best news is that once one Windows client system is all set up, we can automatically tell our Linux server what to tell new Windows clients when they want to print. In other words, other clients will pick up the printer type information saved on the server and avoid even the need to pick a driver.

Additionally, you might have some old-and-crusty printer that doesn't have proper "networking" drivers available. If the printer is supported by Ghostscript, then the printer can always be shared over the network. For instance, you could take that $50 low-end inkjet printer and get it on your network. That's cool.

Raw Printing from Windows to Linux

Using a Postscript driver does have one disadvantage . Sometimes printer drivers offer special features, like specifying the printer resolution or how much ink is available in the ink well or stapling options. Those features can't usually be supported if we use the Postscript approach.

When these features are essential for our application, we need to use the correct native Windows printer driver. To do that reliably with a Linux print server, we've found it is best to create a separate raw printer queue with the Fedora printer configuration tool. Creating a raw queue, instead of a queue for a specific model of printer, tells CUPS not to try to interpret the data it receives from the client in any way. Instead of trying to determine whether the data is Postscript code, CUPS will pass it directly to the printer without modification. In this chapter, we'll demonstrate the raw queue approach with SMB, but bear in mind that we could also use it with IPP or LPD.

Understanding Linux Printer Device Names

Last but not least, before we start configuring printer queues on a Linux server, you should understand how physical printer devices are labeled in Linux. Since we're using a parallel printer that is not automatically detected by Fedora Linux, we'll need to tell Fedora to which port we've connected it. Windows calls the first parallel printer port LPT1, the second port LPT2, and so on.

Linux calls these devices /dev/lp0, /dev/lp1 , and so forth. Just remember that the Linux printer device names start from zero, not from one, and you'll be in great shape.

As for USB, Fedora Linux can automatically detect quite a few USB printers when they are connected. For instance, Fedora Core 3 automatically detects an HP PSC 2175 printer and offers to create a queue for it. However, it is sometimes useful to add a second queue for the same printer. In fact, we need this capability to support both a raw queue for Windows clients with native drivers and a Postscript queue for Linux clients, so it does help to be able to recognize a USB printer device name when you see one in the printer configuration tool.

USB printer devices are called /dev/usb/lp0, /dev/usb/lp1 , and so forth. And because USB devices can identify themselves by name, the printer configuration tool will also display the model name to the right of the device name.

Setting Up a Linux Printer

Now that you know what's going on "under the hood" and why, we're ready to start printing via a Linux server. We'll begin by attaching a printer to our Linux domain member server, adsambafp1.ad.corp.com (refer back to Figure 5.1).

Here are the short- term goals for this section:

We'll configure CUPS and Samba to support IPP, LPD, and SMB (Windows) printing on two queues, one a typical CUPS queue expecting Postscript, the other a raw queue intended for use with Windows clients.
We'll demonstrate Linux-to-Linux printing via IPP over the Postscript-friendly queue.
Finally, we'll "go for the gold" and demonstrate Windows-to-Linux printing by all three methods . Here, we'll show how to use both the Postscript-based queue and the raw printer queue. For those interested in the raw approach, we'll also look at how to support Windows click-and-print automatic downloading of printer drivers via SMB with Samba, and we'll show how to publish Samba SMB printers in Active Directory.

First, we'll physically attach our printer to our Linux server's parallel port. However, unlike in our Windows examples, the printer we'll use is a Canon i560. We use this printer because we want to demonstrate click-and-print driver downloading. Since the driver for the BJC-7000 printer we used earlier is standard in Windows XP, there is nothing to download, so the i560 is a much better demonstration of that feature.

However, Fedora Linux doesn't ship with a driver specifically for the Canon i560, so how will we support it on the Linux side in the CUPS-and-Postscript case? The answer is that the Canon i560 is backward compatible with the Canon BJC-7000, so we'll use the BJC-7000 driver on Linux. However, on the Windows side, when we're ready to demonstrate SMB printing with a native printer driver and a raw queue, we'll use the "real" i560 driver to create an interesting test case for automatic driver downloading.

Now we need to tell the server about the printer we've attached to it. We'll also need to deal with the sharing issues just mentioned. We'll do this in three main steps:

We'll use the Fedora printer configuration tool to add a new queue, or spool , for the printer we've just connected. We'll tell Fedora that the printer is connected to the local parallel port, /dev/lp0, and we'll configure this queue to translate Postscript print jobs to the printer's native language. At the same time, we'll enable sharing of the printer via IPP and LPD. Later, we'll demonstrate IPP with both Windows and Linux clients and LPD with a Windows client.
We'll add an additional raw spool that accepts raw printer data and forwards it directly to the printer. We'll configure Samba to offer SMB printing via this raw spool; we'll do this using Webmin. Later, we'll demonstrate how to use this printer share with a Windows client.
We'll configure the Linux server to support click-and-print driver downloading. Later, we'll demonstrate that capability with two Windows clients: one to upload the driver for the first time and another to show that driver downloading works.

Adding a Postscript Spool for Our Printer

To add and share a new spool for the Canon i560 printer that accepts Postscript print jobs, just follow these steps. Bear in mind that we must use the older (but compatible) Canon BJC-7000 driver. That's because no driver specifically for the Canon i560 is included with Fedora or available on www.linuxprinting.org as of this writing.

Note

What if we needed to use a printer that wasn't supported by Fedora? We'd check www.linuxprinting.org for an appropriate driver. www.linuxprinting.org offers PPD files for many printers. These can then be imported into the CUPS printing system using the "Import PPD" option on the "Actions" menu of the Fedora printer configuration tool.

Pull down the "Applications" menu and drill down to System Settings Printing. Wait for the printer configuration tool to appear.
Click the "New" button to add a new print queue.
Click "Forward" on the explanatory page that follows .
On the "Queue name" page, enter LinPrinter1 in the "Name" field. In the "Short description" field, enter Linux Printer One or another descriptive name that you like. Click "Forward."
On the "Queue type" page, pull down the "Select a queue type" menu and pick "Locally-connected" as shown in Figure 5.12.
In the list box beneath that menu, select "/dev/lp0." Then click "Forward."
On the "Printer model" page, pull down the "Manufacturer" menu and pick "Canon." Then scroll through the list of models and pick "BJC 7000." Click "Forward."
The "Finish, and Create the New Print Queue" page appears. Click "Finished."
When asked whether you wish to print a test page, click the "Yes" button. A test page will emerge after a short delay.
Leave the printer configuration tool on the screen in order to continue with the next section.

Figure 5.12: Adding a local printer to a Linux server

Adding a Raw Spool for Our Printer

The spool we just created is useful for Linux clients, as well as for Windows clients using Post-script printer drivers. However, sometimes we want to use special features of a native Windows printer driver. Here are the steps to create a raw spool that accepts print jobs from Windows clients using the native Canon i560 printer driver:

Pull down the "Applications" menu and drill down to System Settings Printing. Wait for the printer configuration tool to appear.
Click the "New" button to add a new print queue.
Click "Forward" on the explanatory page that follows.
On the "Queue name" page, enter LinPrinter1Raw in the "Name" field. In the "Short description" field, enter Linux Printer One Raw Spool or another descriptive name that you like. Click "Forward."
On the "Queue type" page, pull down the "Select a queue type" menu and pick "Locally-connected."
In the list box beneath that menu, select "/dev/lp0." Then click "Forward."
On the "Printer model" page, pull down the "Manufacturer" menu and pick "Generic." Then scroll through the list of generic printer types and print "Raw Queue." Click "Forward."
The "Finish, and Create the New Print Queue" page appears. Click "Finished."
When asked whether you wish to print a test page, click the "Yes" button. A test page will emerge after a short delay.
Leave the printer configuration tool on the screen in order to continue with the next section.

Sharing Printers via IPP and LPD with CUPS

The Common Unix Printing System (CUPS) is now aware of the printer and ready to accept jobs for it in two formats, raw and Postscript. Now, it's time to share the printer via IPP. We will also lock this printer down so only specific client computers can print to it. We will choose to only allow local computers to print to this printer.

Lastly, we'll enable old-fashioned LPD printing as well, just in case we have some old Unix machine that needs to print.

To configure our Linux server to enable printing via IPP and LPD:

Pull down the "Applications" menu and drill down to System Settings Printing. Wait for the printer configuration tool to appear.
Make sure "LinPrinter1" is selected in the list of printer queues in the printer configuration tool's main window.
Pull down the "Action" menu and pick "Sharing".
The "Sharing Properties" dialog appears. Make sure the "Queue" tab is selected. Check the box labeled "This queue is available to other computers." This enables IPP printer sharing.
To lock the printer down so that only certain client computers can print to it, select the "Allowed Hosts" list box and make sure "All Hosts" is selected. Then click "Remove," followed by "Add" to display the "Add allowed hosts " dialog.
Click the "Network Address" radio button.
Now we'll specify the local network address to prohibit computers on other networks from printing to this printer. In the first field beneath "Network Address," enter 192.168.2.0 . This is the network address that is allowed to access the printer.
In the second field, to the right of the first, enter 255.255.255.0 . This is the network mask. A zero for the last byte means that clients with addresses beginning with 192.168.2 and ending with any byte are allowed to print.
Click "OK."
Click the "General" tab.
Click the radio box labeled "Enable LPD protocol."
Click "OK."
Choose "Quit" from the "Action" menu or just click the "X" button in the upper-right corner to close the printer configuration tool.
When the message "Do you want to save the changes you have made to your printer configuration?" appears, be sure to click "Save."
Repeat steps 114 for LinPrinter1Raw. Be sure to select "LinPrinter1Raw" rather than "LinPrinter1" when repeating step 2.

Sharing Printers via SMB with Samba

Now that the Fedora printer configuration tool has configured CUPS to drive the printer, we'll add support for native Windows SMB printing via LinPrinter1Raw. Samba takes care of this chore for us, and Webmin provides a friendly way to set it up. Samba makes it especially easy by allowing us to set up a special "all printers" share that is automatically understood to mean "share all of the connected printers in the same way."

Note

Why do we share both of the print spools? Isn't LinPrinter1Raw the only appropriate spool for Windows clients? Well, no. We can use a Postscript queue with Windows SMB clients if we want to. All we have to do is choose a Postscript printer driver instead of the Canon i560 driver on the client side. In this chapter, though, we'll use Postscript drivers for LPD and IPP printing and the native Canon i560 driver for SMB printing. Just bear in mind that you're not required to do it that way.

Samba needs a spool directory to store print jobs in. Conveniently, Fedora ships Samba with a ready-made directory for this purpose: /var/spool/samba . We'll just specify this directory when prompted for the spool directory.

Follow these steps to complete the process:

Log into Webmin with the username root and the password p@ssw0rd at the URL:
- https ://adsambafp1.ad.corp.com:10000/ .
Click "Servers."
Click "Samba Windows File Sharing."
On the "Samba Windows File Sharing" page, click "Create a new printer share."
On the "Create Printer Share" page, select "All Printers Share."
Leave the "Unix Printer" menu set to "Default."
Set "Spool Directory" to /var/spool/samba
Set "Available" to "Yes."
Set "Browseable" to "Yes."
Set "Share Comment" to "All Printers."
Click "Save."

LinPrinter1, LinPrinter1Raw, and any other printer queues you add to the server are now set up to be automatically shared via SMB so that Windows clients can use them in a familiar way. But before we demonstrate that, we'll improve matters even more by adding support for click-and-print printer driver uploading and downloading.

Setting Up Samba to Enable Windows Click-And-Print Driver Downloads

Microsoft's click-and-print system is a neat trick: clients can automatically download drivers from the server. Windows servers simply dish out the driver when the client asks. It all happens in the background and it's magical .

Samba has the same ability. All we have to do is create a Samba file share called print$ and create a single subdirectory in it. We call that subdirectory W32X86 because Windows XP clients understand this to mean "drivers for Windows 2000 and/or Windows XP."

We'll map the share to the local directory /usr/local/samba/windrivers on the server. As mentioned previously, /usr/local is the correct parent directory for a directory created by the local administrator for a purpose not specific to one user . We'll also create the W32X86 subdirectory to actually house the Windows XP drivers.

We can create the whole subdirectory path in a single command, thanks to the -p option of mkdir . The -p option causes mkdir to create any parent directories that do not already exist, instead of generating an error.

We will also need to secure the share properly. We don't want ordinary domain users to be able to delete or tamper with drivers, but we do need to allow the administrator user to upload drivers. We will arrange this by restricting write access to the share only to administrator . Webmin provides a friendly way to set this up. Samba implements these settings "under the hood" through settings in the file named /etc/samba/smb.conf .

There are a few more steps that must be taken, just once, from a Windows client to actually upload the drivers to the print$ share. We'll show those steps later when we demonstrate SMB printing to Linux from a Windows client.

To prepare the Samba server to accept Windows print drivers:

At the command line, execute the following command:
```
 mkdir -p /usr/local/samba/windrivers/W32X86 
```
Log into Webmin with the username root and the password p@ssw0rd at the URL:
- https://adsambafp1.ad.corp.com:10000/ , if you haven't already.
If you are not already at the Windows File Sharing page, click "Servers," then "Samba Windows File Sharing."
Click the "Create a new file share" link. The "Create File Share" page appears.
Make sure the radio box next to "Share name" is selected. In the "Share name" text field, enter print$ .
In the "Directory to share" field, enter /usr/local/samba/windrivers/W32X86 .
Click the "No" box for "Automatically create directory?"
Click the "Yes" box for "Available?"
Click the "Yes" box for "Browseable?"
In the "Share Comment" field, enter Click And Print Drivers .
Click "Save."
print$ should appear in the list of shares. Click print$ .
The "Edit File Share" page appears. Click "Security and Access Control."
Make sure "Writable" is set to "No."
On the "Read/Write Users" line, enter AD\administrator .
Verify that "Guest Access" is set to "None" and "Limit to possible list" is set to "No."
Click "Save." The "Samba Windows File Sharing" page will reappear.
Scroll to the bottom of the page and click "Restart Samba Servers."

That's itthe server is configured! Time to test our new printing capabilities.

Performing Printing Tests

Our Linux server is now ready and willing to accept print jobs from both Windows and Linux clients. Let's test that out.

Printing from Linux Clients

Printing from Linux to Linux is, of course, very straightforward. The process is made especially easy because a CUPS server broadcasts its existence to systems on the local network. That makes CUPS IPP printing as convenient on Linux as SMB printing is on Windows. We don't have to use the Add a New Queue Wizard at all.

We're going to use adsambafp1 , our Linux Active Directory domain member server, for our printing tests. We'll use adlincli1 , our Linux domain member client, for our client-side tests. But bear in mind that Active Directory plays no role in this and the procedure would be exactly the same in a pure Linux environment.

Everything we need to do can be accomplished with the Fedora printer configuration tool on adlincli1 .

To configure our Linux client to print to a Linux server:

Pull down the "Applications" menu and drill down to System Settings Printing. Wait for the printer configuration tool to appear.
Click the "New" button to add a new print queue.
Click "Forward" on the explanatory page that follows.
Double-click the right-pointing arrow next to "Browsed queues."
LinPrinter1 appears in the list. Select it with the mouse.
Pull down the "Test" menu and pick "CUPS Test Page." Click "Yes" after the page appears successfully.

As before, we suggest using OpenOffice Writer to carry out a more interesting test. Select "LinPrinter1" as the printer to use. Notice that we didn't have to explicitly add this printer, since it is automatically detected on the local network.

Before we move on, there are two scenarios that we're not going to specifically cover in step-by-steps, and you might be asking yourself why not.

CUPS can only automatically find printers on the same subnet. What if I need to print to a CUPS printer that isn't on the same LAN? It is possible to set up automatic relaying of printer browsing information between CUPS hosts on separate subnets. However, the relevant options, BrowsePoll and BrowseRelay, are not currently supported by the Fedora GUI. Currently configuration files must be edited by hand to implement this. We simply don't have space to address this in detail in this book, but you can learn more with this command:

 man cupsd.conf

We can also, of course, add a CUPS printer manually. To do that, we would follow the same steps used earlier to add a queue for a Windows Internet Printing shared printer. The only difference would be in the "Server" field, which would not require the :80 at the end. That's because the CUPS IPP server listens on port 631, the default IPP port, instead of port 80. This is also good to know in certain types of VPN environments and other situations where "broad-casting" does not work.

What about printing from Linux clients to Linux servers using LPD or SMB? We don't really recommend either when you have control over both the client and the server. IPP is both modern and an open standard. However, when an older Unix server that cannot be upgraded offers an LPD server, you may find it useful to follow exactly the same procedure we demonstrated earlier to print to a Windows server using LPD. Printing from Linux to Linux with SMB is not the best option, but it can be accomplished following the same procedure we used to print from Linux to Windows using LPD.

Printing from Windows Clients

Printing from Windows clients to Linux servers can be accomplished in three ways:

We'll examine printing from Windows clients to Linux servers via IPP first. This requires minimal effort to set up and can be done in no time flat. We think, over the long haul, you'll use this option the most.
Next, we'll examine printing from Windows clients to Linux servers via the native SMB printing protocol of Windows. Since we're here anyway, we'll also show how to upload printer drivers to enable click-and-print functionality for other clients on the network.
The last method demonstrates something you likely won't use much. That is, you'll force your Windows client into talking the "old and crusty" LPD-style of printing, and your Linux print server will happily oblige. We demonstrate this primarily to show how Windows clients can print to legacy Unix LPD print servers that can't be upgraded to CUPS. It's also handy for those with archaic Unix LPD clients , although this book naturally focuses on Windows-and-Linux combinations.

Windows Clients Printing via IPP to Linux

Printing via IPP from Windows to Linux isn't difficult. We just need to know the correct URL for the printer. A Windows client can't automatically detect the URL using the web browser as it would if the server were running Windows Internet Printing.

There's a simple way to specify the right URL. When printing to a CUPS server via IPP, the correct URL will always look like this:

http:// servername :631/printers/ printername

servername , in our case, is adsambap1. and printername should be LinPrinter1, so the correct URL is:

http://adsambafp1:631/printers/LinPrinter1

Communicating with a printer via IPP to a Linux CUPS server also requires that we manually select a printer driver on the Windows side. When we do, we need to make a choice. We can choose a Postscript printer, which will work well with the LinPrinter1 spool, or we can choose to install the Canon i560 driver software from Canon's website or driver CD-ROM, which will work correctly with the LinPrinter1Raw spool.

For this example, we'll go with Postscript. This is always a good bet when talking to a Linux print server. To convince Windows to use a Postscript driver, we select Apple from the Manufacturer list. Then we select Apple Color LaserWriter 12/600 from the Printers list. The Apple Color LaserWriter 12/600 is a true Postscript printer, one that accepts Postscript as its native language. So Windows will send Postscript to CUPS, believing it is destined for a true Postscript printer, and CUPS will automatically recognize it and translate it to the native language of our actual printer using Ghostscript.

Now you know everything you need to know to make IPP work between Windows and a Linux CUPS server. To configure our Windows client to print via IPP to a Linux server with a generic Postscript driver:

Open the "Printers and Faxes" applet in Control Panel and select "Add a printer." This launches the "Add Printer Wizard" as we've seen before.
At the "Local or Network Printer" screen, select "A network printer, or a printer attached to another computer." Then click "Next."
On the page that follows, select the radio box labeled "Connect to a printer on the Internet or on a home or office network." In the "URL" field, enter the following:
- http://adsambafp1:631/printers/LinPrinter1
Click "Next." The client will talk to the server for a moment and then the "Select the manufacturer and model of your printer" dialog will appear.
Select "Apple" from the manufacturers list. Select "Apple Color LaserWriter 12/600" from the Printers list. Click "Next" to move on.
You will be asked whether to make this the default printer; click "Yes" or "No" as suits your preference.
Click "Finish" on the confirmation screen to end the wizard.
You can now test actual printing using the "Print" option on the "File" menu of an application such as Microsoft Word. Just select "LinPrinter1" from the list of printers available when printing.

Windows Clients Printing via SMB to Linux

SMB is, of course, the traditional, native printing protocol of Windows. Not surprisingly, convincing Windows clients to print via SMB to a Linux server running Samba isn't hard to do. However, for a bit of "extra credit," we'll set up click-and-print . That way, when other Windows clients stumble on this printer, they will automatically download the drivers and be good to go!

How does click-and-print work? When a Windows client prints to a Windows print server, the client automatically downloads the printer drivers from the print server. This happens transparently to the user. Very elegant.

But what if a client running Windows 98 tries to print to a print server running Windows Server 2003? After all, the new Windows XP / Windows 2003 printer drivers won't work with old Windows 98.

Windows provides a practical workaround. An administrator can install the printer on a Windows 98 machine then configure the client to print to the Windows 2003 server. This causes the server to automatically upload the Windows 98 drivers. From that point on, the Windows 98 drivers are available to any Windows 98 client who uses that print queue on the server.

Linux print servers use a similar trick to support Windows clients. Think of a Linux Samba print server as a Windows server that runs an exotic version of Windows that doesn't support regular Windows XP / Windows 2003 printer drivers. Just as in the Windows 98 / Windows 2003 scenario, the answer is to upload the drivers from a Windows XP client. You as the administrator can install a printer on a Windows machine, then upload the drivers to the Linux print server where they are available to any other Windows clients who print to that print server.

So here, we'll do the job in two steps, as shown in Figure 5.13.

Figure 5.13: We'll leverage a Windows workstation to upload any required printer drivers to our Linux server. Then we'll log on to another Windows workstation and watch the drivers automatically download.

First, we'll log on to a client workstation as a domain administrator in order to install the driver locally on that one workstation and then upload it to the Linux print server to be shared. Next, we'll log on to a separate client workstation as an ordinary user, who will discover that the driver automatically downloads when they first access the printer via the print server. All other users will experience the same benefit. That's click-and-print .

Of course, to demonstrate driver uploading, we need to use a printer driver that doesn't come with Windows as "standard" equipment. So for this test, we'll use a real Canon i560 driver that we downloaded from Canon's website. We'll have to install this driver on our first Windows client. To do this, we'll run Canon's installation program, then quit at the point where it would otherwise begin searching for a printer connected directly to the client. It's a bit confusing, but the installation program does install the driver before that point, and that's all we need.

Printer driver installation programs can be a bit baffling when it comes to installing a driver you intend to upload to a network server. That's not surprising, since with a true Windows print server you would run the installation program on the server itself. If step 2 later in this section doesn't work well for your model of printer, we suggest connecting the printer directly to the first client and fully installing the driver software. Then you can move the printer to the server and continue with the steps.

Note

Keep in mind that we could have chosen to use a Postscript printer driver for SMB as well. If we had, there would be no need to set up click-and-print because the Postscript driver ships as standard equipment with Windows. However, since printer drivers occasionally have desirable features that can't be reached conveniently through the Postscript driver, it's worthwhile to demonstrate how to use native drivers and click-and-print as well.

Ideally, before you begin, we suggest that you configure a second XP client system if you don't have one just lying around. It's on this new XP client system that we'll actually witness the proper downloading of the driver (which we're initially loading on xppro1 and uploading to our Linux Samba server).

If you want to have another machine handy, here are our suggestions. Follow exactly the same procedure you followed for xppro1 except:

The hostname should be xppro2 .
The IP address should be 192.168.2.115.

Once xppro2 is ready, we can demonstrate SMB printing and click-and-print driver downloading.

First things first: let's get our printer drivers loaded on our first client machine ( xppro1 ). Then, we'll upload them via Samba for our other clients, such as xppro2 , to utilize.

To load our printer drivers onto our Windows XP system:

Make sure you are logged in as AD\Administrator .
Install the Canon i560 driver software on xppro1 from the printer manufacturer's CD or website. When you reach the point where the installation program says it is trying to detect a printer connected to the local computer, click "Cancel."
Open the "Printers and Faxes" applet in Control Panel and select "Add a printer." This launches the "Add Printer Wizard" as we've seen several times before.
At the "Local or Network Printer" screen, select "A network printer, or a printer attached to another computer." Then click "Next."
On the page that follows, select the radio box "Connect to this printer (or to browse, for a printer, select this option and click "Next")." Then click "Next" to browse for the printer.
A list of print servers will appear, including ADSAMBAFP1. Double-click ADSAMBAFP1 to make LinPrinter1Raw visible and select it with the mouse as shown in Figure 5.14. Then click "Next."
A message box will appear saying that "the server for the printer does not have the correct driver installed." Click "OK" to manually select the correct driver on this first client.
The "Select the manufacturer and model of your printer" dialog will appear. Select "Canon" from the manufacturers list. Select "i560" from the Printers list. Click "Next" to move on.
You will be asked whether to make this the default printer; click "Yes" or "No" as suits your preference.
Click "Finish" on the confirmation screen to end the wizard.
You can now test actual printing using the "Print" option on the "File" menu of an application such as Microsoft Word. Just select "LinPrinter1" from the list of printers available when printing.

Figure 5.14: Selecting LinPrinter1Raw from the Samba server via SMB browsing on a Windows client

Using xppro1 , we've added the printer queue to ADSAMBAFP1but we're not done yet. Next, we need to take advantage of click-and-print by uploading the Canon i560 driver to the Samba print server. We do this via the "Sharing" tab of the "Properties" dialog for LinPrinter1Raw. While we're there, we can also list the printer in Active Directory to enable searches for the printer. Just follow these steps:

Open the "Printers and Faxes" applet in Control Panel.
Right-click "LinPrinter1Raw" and pick "Properties."
Click the "Sharing" tab.
If you wish, enable the "List in the directory" setting. This enables searches for this printer in Active Directory. We'll talk more about enabling searching for Active Directory in the next major section.
In the "Drivers" box, click "Additional Drivers."
From the list of driver types, check the box for "Intel Windows 2000 or XP" (Intel-compatible processors are in all typical Windows office PCs).
Click "OK."
A "Copying Files" progress box will appear while the drivers are uploaded to the server.
Click "Close."

Our first client is now ready to print to LinPrinter1Raw. More importantly, we can now add a second client without the need to manually install the Canon i560 driver. It's time to demonstrate that.

Now we're ready to try a new client and see if it will automatically download the drivers from our Samba server. To test the automatic driver downloads from our Samba server:

Log in as any domain user. AD\salesperson1 is a reasonable choice.
Open the "Printers and Faxes" applet in Control Panel and select "Add a printer" to launch the "Add Printer Wizard."
At the "Local or Network Printer" screen, select "A network printer, or a printer attached to another computer." Then click "Next."
On the page that follows, select the radio box labeled "Connect to this printer (or to browse, for a printer, select this option and click "Next")." Then click "Next" to browse for the printer.
A list of print servers will appear, including ADSAMBAFP1. Double-click ADSAMBAFP1 to make LinPrinter1Raw visible and select it with the mouse as shown in Figure 5.14. Then click "Next."
A "Copying Files" progress box will appear. The driver software will download from the server automatically. This is click-and-print at work.
You will be asked whether to make this the default printer; click "Yes" or "No" as suits your preference.
Click "Finish" on the confirmation screen to end the wizard.
You can now test actual printing using the "Print" option on the "File" menu of an application such as Microsoft Word. Just select "LinPrinter1Raw" from the list of printers available when printing.

Again, the amazing thing here is that we're using a Linux Samba print server to serve up Windows print drivers to Windows boxes. Now that's slick.

Windows Clients Printing via LPD to Linux

Before we can print via LPD from a Windows client, we need to install the "Print Services for Unix"exactly as we performed earlier as shown in Figure 5.5.

LPD support in the Windows "Add Printer Wizard" has a strange approach. That is, we must add the printer as a "Local printer attached to this computer," and then we set up a remote LPD port. That's because, technically, the initial spooling of the print job happens hereon this local system. This isn't very intuitive, but it does work well.

Here's the procedure:

Be sure to have the "Print Services for Unix" installed. Again, this is found in the Add/Remove Programs applet and is described earlier in Figure 5.5.
Select Start Control Panel Printers and Faxes Add Printer to initiate the Add Printer Wizard. Once the wizard starts, click "Next."
At the "Local or Network Printer" screen, select "Local printer attached to this computer" and be sure to de-select the "Automatically detect and install my Plug-and-Play printer" box. Then click "Next."
On the "Select a Printer Port" page, click the "Create a new port" box and select "LPR Port" from the menu. Click "Next" to move on.
The "Add LPR compatible printer" dialog appears. Enter adsambafp1.ad.corp.com in the "Name or address of server providing lpd" field. Enter linprinter1 in the "Name of printer or print queue on that server" field. Then click "OK."
At the "Install Printer Software" dialog, select the Manufacturer and Printer model. We'll stick to our Postscript approach in this example, so select Apple as the manufacturer and Apple Color LaserWriter 12/600 as the model. Then click "Next."
At the "Name your Printer" screen, you can enter a name for the printer. Replace the suggested name with LinPrinter1ViaLPR , then click "Next."
At the "Printer Sharing" screen, you can give a share name for others to see. This might seem strange, but it's actually a fine idea if you wish to "re-export" the printer via SMB. Well, it might not be a fine idea from a Windows XP machine, but if this were a Windows 2003 print server, this might be a fun idea. Once you do so, other clients can access the printer via traditional SMB Windows network printing without the need to additionally go through the hassle of installing the "Print Services for Unix" LPD driver.
At the "Location and Comment" screen enter what you like. When ready, click "Next."
At the "Print Test Page" prompt, select "Yes" to verify that we added the printer successfully.

What We Accomplished with Linux Printers

We've done quite a few nifty things with our Linux printer.

We shared it via IPP, using CUPS. That's the best way to share the printer with Linux clients, and it can also be used with Windows.

We also shared the printer via SMB, the traditional method of sharing printers with Windows clients. We showed how to use a raw queue to make sure print jobs from native Windows drivers are passed without modification to the printer. We also demonstrated how to list the printer in Active Directory and deliver native drivers automatically over SMB using click-and-print. Not bad for a free operating system!

We also made it available via LPD, which is convenient for archaic Unix clients and demonstrates what Windows clients need to do when talking to an archaic Unix server.