لطفا منتظر باشید ...
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
align=left border=0> 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, "
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 modelthat 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
align=left border=0> 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
align=left border=0> PostScript was originally created by Adobe (
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.
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.
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 (
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 target="_blank">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,
"
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: lp|hp4000|raw:\ :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 printersa 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.
