Serving Printers with Samba

SMB/CIFS treats printer shares much like file shares. To print, a client sends a file to a share. The server then processes that file through its own printing system. Given this model, it should come as no surprise that Samba printer shares closely resemble Samba file shares. In fact, the parameters just discussed in reference to file shares, such as access control features, apply equally well to printer shares. Of course, some of these features, like filename case handling, aren't terribly important in printer shares.

Much of the challenge of handling Samba printer shares comes in passing Windows print jobs through the Linux queue in a way that modifies or does not modify them correctly given the type of queue you've configured. You may need to create very different configurations for PostScript as opposed to non-PostScript printers.

NOTE

This section assumes that your printer already works in Linux, or at least that you can send data to the printer from Linux. (Some printers lack Linux Ghostscript drivers, but can still be shared via Samba.)

Creating a Printer Share

The main difference between file and printer shares is the presence of the printable = Yes or print ok = Yes parameter (the two are synonymous). The directory you specify is a temporary spool directory (but it's not the Linux print spool directory, typically located in /var/spool/lpd ). The default value is /tmp , which generally works acceptably, although many Linux distributions create and use a directory called /var/spool/samba or the like. In either case, this directory should generally have its "sticky bit" set, which prevents users from deleting files in the directory they didn't create. You can configure a directory in this way by typing chmod 1777 / path /to/dir or chmod o+t /path/to/dir , where /path/to/dir is the directory in question. (The former option also makes the directory writeable to all users, which is often desirable for a printer queue directory.) Multiple Samba printer queues can share a single spool directory. An example of a functional printer share definition is as follows :

 [laser]     comment = Laser printer in Room 7     path = /var/spool/samba     printable = Yes 

The comment parameter simply provides a comment that's associated with the share name ( LASER ) on clients . (This parameter may also be used with file shares.) This share will work if your system has a local printer queue called laser . If your local printer queue name is something other than the share name, you should use the printer name parameter to specify it, as in printer name = lp , which tells the system to use the local queue called lp .

Linux distributions use a variety of printing systems. Currently, the original BSD lpr is quite common, but the more up-to-date LPRng is gaining ground, and the Common Unix Printing System (CUPS) is also becoming popular. Syntax details for these systems vary, and Samba must be able to adjust itself appropriately. Therefore, Samba provides an option called printing that lets you specify the printing system your computer uses. Set this to BSD , LPRng , or CUPS , as appropriate. (Several other options are available, but are quite uncommon on Linux systems.) If you use a Samba package that came with your distribution, it was probably compiled to use the appropriate package by default. If your system uses a truly oddball printing system, you may be able to rescue matters with the print command parameter, which lets you adjust the print command used by Samba to anything you specify. When you specify a command, %s is a variable that stands for the print job's filename. You may need to explicitly delete this file after you've passed it to the printing system. This parameter is actually extremely flexible, and can be a key to using Samba in some extremely unusual ways, as described in the upcoming section, "Using Pseudo-Printers."

Just as Samba's file-sharing features allow you to specify a single share that allows all users of the system to access their files, Samba's printer sharing allows you to create a single printer share that provides access to all the system's printers. This share name is [printers] . When this share is present, Samba scans the computer's /etc/printcap file for printer names and creates one share for each of the names it finds. As with the [ homes ] share, the [printers] share normally includes a browseable = No parameter to keep a share called PRINTERS from showing up on Windows clients. Even with this parameter set, the individual printer names appear in Windows browse lists.

Sharing a PostScript Printer

The preceding description has largely bypassed one of the most important issues (and potential sources of problems) in sharing printers via Samba: printer drivers. Windows systems use printer drivers that interact with application programs to generate output that a specific model of printer can understand. Therefore, the file that a Samba printer share receives for printing will be preformatted by whatever printer driver was installed on the client. Linux, by contrast, generally uses printer queues that are configured to accept PostScript output. Depending on the type of printer that's attached to the computer, the queue may output the original file in unchanged form, or it may pass the file through print filters, which convert PostScript into a form that can be understood by a non-PostScript printer. The result of these two differing print models is that a clash sometimes develops. If the Windows clients feed Samba non-PostScript files, they may get garbled. Just as bad, some Windows PostScript drivers create output that can confuse Linux print filters into thinking the output is not PostScript, which can also produce garbled output. Fortunately, there are a handful of rules and Samba parameters that can help immensely in fixing these problems, but you may need to do some experimentation to learn what works best.

The simplest case is usually if the printer you're sharing is a PostScript model ”that is, if it understands and processes PostScript output itself. This feature is common on high-end laser printers, and is available on some mid-range laser printers. It's rare on low-end laser printers and inkjets, although there are a handful of inkjet printers that understand PostScript. Consult your printer's documentation if you're unsure if it supports PostScript.

WARNING

Some printers claim to support PostScript, but that support is provided by a PostScript interpreter that resides in Windows. Such printers are not PostScript printers for the purposes of this discussion. They may be perfectly good printers, and your Windows clients may be able to use the Windows PostScript interpreter via Samba, but they are not configured as PostScript printers.

NOTE

PostScript was originally created by Adobe (http://www.adobe.com), which has traditionally licensed PostScript for inclusion in printers. Other companies have also produced PostScript interpreters, and these are currently common on many printers, including some models from such major manufacturers as Hewlett Packard and Lexmark. Although some early PostScript clones were far from perfect, more recent PostScript clones generally do a good job. For purposes of Samba configuration, whether your printer uses a genuine Adobe PostScript or a clone is unimportant.

If your printer supports PostScript directly, you should be able to install a Windows PostScript driver, either from the Windows CD-ROM or from the printer manufacturer. (Adobe also has PostScript drivers available, although they're licensed only for use with printers that have Adobe- created PostScript interpreters.) This driver will generate PostScript output, which Samba will pass to the Linux printer queue, which should then send the file to the printer. If all goes well, the file will print without problems.

The most common source of problems in such a configuration arises because many Windows PostScript drivers precede their output with a Ctrl+D character. Most PostScript printers ignore this character, but it confuses the Linux print queue. Specifically, Linux print filters look for certain strings at the start of a print job to identify PostScript jobs. The Ctrl+D interferes with this identification, so the print filter assumes the file is plain ASCII text. Some PostScript printers can't cope with plain ASCII text, so the print filter converts the PostScript (that the filter believes to be plain text) into a PostScript file that prints the PostScript code. The result is a printout of PostScript code, rather than the page you'd expected. There are two possible solutions to this problem.

First, you can locate the option in the Windows print driver that generated the Ctrl+D. This option can usually be found in the Properties dialog box for the printer, or in a dialog box obtained by clicking an Advanced button in that dialog box. Figure 7.4 shows an example. The Send CTRL+D Before Job option should be unchecked. (The Send CTRL+D After Job option is less likely to cause problems.) Disabling the Ctrl+D at the source is a good plan if you want to use the queue with both PostScript and non-PostScript drivers (say, if the printer understands PostScript and some other printer language), but it can be tedious if you have many clients that need correcting.

Figure 7.4. You can usually disable the Ctrl+D character that causes problems for many Linux printer queues.

The second solution to the Ctrl+D problem is to use the Samba parameter postscript = Yes . This parameter causes Samba to add the PostScript identification code to the start of the print job, before the Ctrl+D character. The end result is that the job prints fine, since the printer will then ignore both the Ctrl+D and the second PostScript identification code. This solution is easier if you have many clients that would need reconfiguring, but if you also want to be able to print using another type of driver, you'll need to create a second queue for that purpose, which may clutter your network share list.

Sharing a Non-PostScript Printer

You have two options for configuring a non-PostScript printer for sharing via Samba. The first is to use a PostScript driver on the clients and configure the Linux printer queue to convert PostScript to the printer's native language, as you'd do if using the printer locally. The second option is to use the printer's native drivers on the client and share the printer with a raw queue, which passes data to the printer unchanged. Each option has its advantages and disadvantages, and each requires its own configuration.

Using Ghostscript

If you can print to a non-PostScript printer from Linux applications that generate PostScript output, such as Netscape, then your system is configured to pass printed output through Ghostscript (http://www.cs.wisc.edu/~ghost/), which is a PostScript interpreter that runs on the computer rather than the printer. The GNU version of Ghostscript ships with all major Linux distributions and supports most printers. In a few cases, you may need to locate special drivers or the Aladdin version of Ghostscript, which is more up-to-date. For information on printer compatibility with Ghostscript, check the Linux Printing database at http://www.linuxprinting.org/printer_list.cgi.

A Linux printer queue that's configured to use Ghostscript uses a print filter to detect the type of the file, just as does a queue that feeds a PostScript printer. This filter, however, passes the input through Ghostscript. Configuring this setup usually entails using distribution-specific printer configuration tools or following the instructions that came with the filter package. Once it's set up, the queue works almost identically to a queue for a PostScript printer. You should therefore read the preceding section, "Sharing a PostScript Printer," to learn how to set this up in Samba and its clients. You'll need to choose a generic PostScript driver on Windows (Apple LaserWriter drivers usually work well for laser printers driven in this way, and the QMS magicolor driver usually works well for color inkjets). The Ctrl+D issue mentioned in the earlier section can occur with these queues, and the solutions are the same as for PostScript printers.

Some Windows PostScript drivers produce PostScript files that include embedded commands to display progress information on certain printers' built-in displays. This information usually produces an extra page of output with messages like %%[ LastPage ]%% . If you have this problem, one solution is to use a different Windows printer driver. Another option is to locate the file that calls Ghostscript and add >/dev/null to the end of the gs command line. This action redirects the error messages from Ghostscript's usual output device of the printer to /dev/null . In Caldera, this file is /var/spool/lpd/ queuename /printfilter (where queuename is the name of the printer queue). In Red Hat, Mandrake, and TurboLinux, this file is /usr/lib/rhs/rhs-printfilters/ps-to-printer.fpi .

Creating a Non-PostScript Queue

If you want to use a non-PostScript driver on the client, you may do so, but you'll need to create a Linux printer queue that doesn't attempt to interpret or modify the data being sent to the printer. Some Linux print filters can recognize certain printer languages and send the results through untouched, so it's possible you'll be able to use a regular queue for this. If you try it and your print jobs disappear or come out in some garbled or unintelligible form, though, you'll need to create a raw queue.

You can create a raw queue by creating a printer queue as you normally would and then editing the /etc/printcap file ( assuming your system uses the BSD or LPRng printing system). Specifically, you should remove the if= line from that queue's definition, or set it to point to nothing. This line specifies the Linux print filter, and removing it ensures that the print job will pass from the input queue to the printer without being altered . Such a queue might resemble the following:

 lphp4000raw:\         :lp=/dev/lp0:\         :sd=/var/spool/lpd/lp:\         :mx#0:\         :sh:\         :if=: 

This queue definition creates a printer that goes by three names: lp , hp4000 , and raw . It prints to the printer located at /dev/lp0 and uses /var/spool/lpd/lp as its spool directory. (Note that this directory is not the same as Samba's spool directory; the file resides first in Samba's spool directory, and then moves to /var/spool/lpd/lp .) The mx#0 option disables any limit on print file size and sh disables any header page. Because the if= line doesn't point to a print filter file, the filter is empty, so the queue always passes data through unchanged.

In defining the Samba printer share for a raw queue, you should be sure that the postscript option is not included, or that it's set to postscript = No . Preceding a non-PostScript print job with a PostScript identification is likely to confuse most printers, resulting in a garbled printout.

Choosing an Approach

If you have a non-PostScript printer, you must decide whether to use a PostScript driver or a native driver on the client systems. These are not, however, mutually exclusive options. You can create two Linux and Samba print queues, or possibly even use a single queue if your Linux print filter recognizes native print jobs for what they are. (If you create two Linux printer queues, a single Samba [printers] share will detect and share both of them.) You can then install two printer drivers on the clients and choose between them.

One of the important distinctions between these two approaches is where the text or image data is converted into a bitmap. When using Ghostscript and a PostScript driver on the client, the client generates what is essentially a text file describing the text in the document (if it's primarily a text document). This file is small and is usually easy for the client to produce. It therefore imposes little CPU load on the client and generates little network traffic, but it requires CPU power on the print server to convert to a bitmap form. If you use a native driver on the client, by contrast, the client's CPU load will probably be higher, and the file it transmits to Samba will usually be larger; but the Samba server won't need to exert much CPU power to process the file. Thus, the Ghostscript approach is good for minimizing client CPU and network loads, whereas the native driver approach is good for minimizing server CPU loads. These differences are much less important when printing graphics than when printing text, though, because graphics files are large whether they're in PostScript or native printer formats.

Another difference between these approaches relates to the quality of the output. When you use Ghostscript, you rely upon Ghostscript to generate the final output image. In some cases, Ghostscript does a very good job of this, but in other cases, Ghostscript's drivers aren't as good as native Windows drivers. This is particularly true for some of the more obscure and recent color inkjets. Indeed, some of these printers don't have Ghostscript drivers at all, which means you can't use the Ghostscript approach, although you may be able to share the printer using a raw queue and native Windows drivers. In a few cases, Ghostscript's output can be superior to that of native client drivers. This is particularly likely if you have applications that work best with PostScript printers, such as some desktop publishing packages or if you need to print Encapsulated PostScript (EPS) files. In fact, Ghostscript can be a great way to get PostScript compatibility at low cost. Furthermore, by standardizing on one PostScript driver for many printers, you can minimize changes in formatting you might otherwise get when switching between printers ”a serious problem with some programs.

Related to the print quality issues are issues of driver flexibility. When using Ghostscript, you set the printer's resolution and other print quality features via Ghostscript settings. In Linux, these are generally set in the printer setup utility when you define a print queue. To change resolutions , you must create multiple queues and switch between them. If you use native client drivers, though, those drivers typically include resolution-setting options and options to control other printout features. It's therefore usually easier to control an inkjet printer's resolution by using native drivers.

You'll have to balance all these factors based on your own network's capabilities and needs; there is no single best answer to the question of whether to use Ghostscript or native client drivers. You may want to experiment with both approaches to learn which works best on your network and with your printers. Indeed, you might find that one approach works best for some printers, while the other works better for other printers.