[Samba] Re: Version 0.90beta8 of Printing Chapter for Samba 3.0
gerth at stanford.edu
Fri May 9 02:08:39 GMT 2003
I apologize for the long delay in responding, but I suddenly was flooded
with problems that needed immediate attention. I hope my comments aren't
arriving too late.
First, I want to say that I'm very impressed with both chapters 6 and 7.
They are both terrific and will undoubtedly be a great aid to many people.
I particularly like the detailed explanations of the various types of
print pipelines because when you're trying to isolate a problem it's
important to know where things might go wrong.
What I intend to do with this note is to offer a few additional things
which we have encountered here at Stanford. This is probably due to
our desire to have a reasonably centralized set of printers for use
in a Computer Graphics Lab:
a) which is fairly evenly divided between Unix/Linux and Windows
b) where the vagaries of doing research mean that we can't enforce
uniform versions of any operating system
c) whose people often install/administer their own machines
We have been using Samba for many years, but with the advent of
the SPOOLSS support and CUPS, we find that printers are much
easier to configure and use. We are also making some progress
at understanding how to use printers in a more mobile world as
many people now carry their notebook computers from campus to
home to conferences.
In what follows, I will not attempt to actually submit paragraphs
for the HOWTO document. Rather I will write about the topics
and trust you to incorporate the information as you see fit.
Finally, if what I send is unclear or incomplete, please do not
hesitate to ask me for additional input.
John Gerth gerth at stanford.edu (650) 725-3273 fax 723-0033
********** Printing in our heterogeneous Unix/Windows environment
Our environment consists of a few hundred machines mostly running
Win2K/XP and Redhat 7/8 Linux, but with several dozen legacy Unix
systems (largely SGI), a number of Apple Mac OS/X machines, and
the odd Win98, WinNT, HP/UX, etc. system. Users typically have an
identically named id in Unix world and in a single, traditional
Windows NT domain (with a Windows PD
We force all printing to go through Samba 2.2.8a and CUPS 1.17 server
on single server running RedHat Linux 8.0. CUPS is configured to allow
remote IPP and lpr printing. The legacy Unix machines use lpr and
Windows machines use either SMB printing via Samba or IPP to CUPS
I will explain later why we do both.
Our stock of printers changes every year and consists of roughly
two dozen machines which are now all driven by JetDirect protocols.
The current inventory includes various HP and Epson inkjets, a number
of B/W and color HP laserjets, an HP 3500 DesignJet plotter, and
a Kodak dyesub.
*********** Samba and CUPS configuration
A standard Samba/CUPS configuration with "disable spoolss = no" and
"use client driver = no". The print server has a disk share
for "print$" and also a "drivers" share which contains vendor packages
of drivers for those who must install local versions. Two users
have "printer admin" status to set printing defaults and upload
drivers. Since we have no need for page accounting and because
we had problems with "cupsaddsmb" in earlier releases, Windows
machines are virtually all using the vendor drivers. The only
non-obvious smb.conf setting was that we found that APW
sometimes takes the value of "server string = ..." as path.
Setting "server string = /" seemed to keep APW from getting
confused and hanging.
For consistency, the CUPS definitions for the PS printers come
from the same vendor PPDs. Of course, we do use the full CUPS
pipeline when printing to Epson inkjet printers from Linux/Unix.
Since CUPS will honor any /etc/cups/*.types file, we can configure
raw printing for our Epsons by adding a new file rather than
changing mime.types. In our case, it contains:
This is a useful feature since it insulates us when updating CUPS from rpms.
Although the CUPS developers are understandably reluctant to distribute
a lot of extraneous mime.types, I think it might be a good idea for
Samba to provide a sample "samba.types" file which contains the
signatures for popular raw types like Epson.
************ Seeing print server properties
As you've noted, it's very tricky to get the drivers uploaded correctly
to the Samba Server using the Windows GUI tools. One thing we found
that seemed to help was to navigate to \\samba-server\Printers and
then use File->Server Properties to get to the various dialogs.
This has the advantage of letting you not only look at a list of
all the installed drivers, forms, ports, etc. but you can use
the Properties of each driver to see all the files and where they
are stored under the print$ directories. This can be useful
when debugging and also when looking at forms definitions.
************ Setting defaults for spoolss printers
Of course the real nice thing about spoolss printers is that a
"printer admin' can use the "Device Settings" tab and then
the "Advanced -> Printing Defaults" dialog to make sensible
settings (like duplex for printers with duplexors) or to have
the correct default forms. This is a real advantage over the
old client driver days when you had to remember to configure
each printer each client.
************ When to use IPP or lpr printing on Windows
Sometimes it's better not to use networked SMB printers on Windows.
The main reason is that Windows is easily put in states of contacting
printers to check on the queue. If you have a notebook computer
which is often off the network or attached to separate networks
without WINS service, then you have to endure many mysterious
hangs as the print systme waits for network timeouts. This can
be particularly nasty for some Windows applications which will
try to check *all* printers when constructing their print menu.
In situations where SMB networks might not always be available,
you can make things better by using IPP or lpr ports to talk
to the CUPS system. I believe the reason is that these ports
look "local" to the print spooler and so it doesn't keep polling
them for queue data and/or the print monitors are smarter about
With IPP ports, you have more control over the authentication ids.
And since the non-SMB ports are "local", the printers appear
for all users which is nice for a public machine (not as nice
as your logon scripts, but useful when we can't enforce a
More information about the samba