Samba prints, in principle, by making a copy of your print data on a
server and passing a resulting file as an argument to whatever is used
for printing there. The simplest way to achieve that effect is to use
a "canned" [printers]
section in a conjunction with load
printers = yes
directive as described on the manpage for
smb.conf
.
There are a few details which have to be taken into account. If your
server print command is lpr
then most likely you want to
set printing = bsd
in the configuration file. If this is
lp
then printing = sysv
. HP-UX and AIX have their
own hpux
and respectively aix
printing styles.
If none of the above applies, or does not work as expected, you have
to configure your print command
, lpq command
and lprm command
in an explicit manner. See also
the section
I am getting only an initial fragment of my printout; why?
for more ideas.
Make also sure that the path
given in print services points
to a world writable directory, as Samba will copy the print data into
there. Using your print spool directories here is not a good idea,
as, on a properly configured system, this write access requirement is
not satisfied.
Automatic configuration via [printers]
section works only in
the presence of an /etc/printcap
, or equivalent, file.
Sometimes (e.g. NEXTSTEP or Solaris) such a file does not exist. You
may either provide a "dummy printcap" (basically only printer names
are needed there) or configure print services by creating a
configuration section for every printer. This can actually be
preferable, even if /etc/printcap
does exist, especially if
you need finer control of how the printers are configured. For
example, if you do not want to show all your printers, or if you want
to give access to some printers only from some machines (with the help
of include
), or by certain users only (valid users
can be useful here).
See also load printers
in the smb.conf
manpage. If
you prefer to show globally as shares only some printers from your
/etc/printcap
file then you may want to use auto
services
list instead.
This can be a problem when there are multiple printers on a network, in multiple locations, and "what is what" is not clear from the names.
If you specify your print services explicitly then the matter is
simple. Add a comment
in your service and it will show up
in browsers. Otherwise you may add comment strings in the
/etc/printcap
file. For example, if your printer entry
reads like:
lp4js|lp12|LaserJet on the third floor by the coffee machine:\ .....(other stuff)...then a name with blanks in it, the third one in this case, will be taken by Samba as a comment on the service. If such a name does not exist then something else will be picked ( hard to tell what...).
ATTENTION! Share names, legal across various subprotocols of
SMB, cannot be longer than eight characters. If all names in your
printcap entry are longer than that then Samba will silently skip such
entry and the corresponding printer will remain hidden to your
clients. This does not apply to printer shares specified explicitely
in smb.conf
(you will get complaints for names too long but
they will be there if your clients can handle them).
Temporarily replace your print command
with something like
this:
print command = cat %s > /tmp/print.%m.$$ ; rm -f %sThis will create a "print" file marked by the name of a sending client and a writer process number. Now you may try to figure out if your printer will really like it.
:-)
At least for Windows and NT it is possible to find software (commercial and not) which will make a printer connected to a client into a "regular" network printer. It can then be configured for any Unix machine as a remote printer.
If you do not have such software but a printer is exported by the
client as a "share" you may use smbclient
with the -P option
to connect to it. The following sample shell script should get you started.
#!/bin/sh # Print from Unix on a printer on SMB network. An assumption is that # 'printer' was posted as a passwordless "share" # client="myclient" # client name here... pshare="printer" # and here printer share name printfile="/tmp/smbspool.$$" cat > $printfile if [ -s $printfile ] ; then ( echo "translate" ; echo "print $printfile" ; echo "quit" ) \ | smbclient \\\\$client\\$pshare -P -N fi rm -f $printfile exit 0
/dev/null
, and with
this script as a default print filter for it. Details of doing that
vary between different print models, so check your docs. Subsequently
you will use "normal" print commands from your server to print on your
client printer (lpr -Psmb
, or something like that), spooling
and printing from stdin
will work, etc. In such settings
you may want to print with a command which creates a symbolic link to
an original file (lpr -s
in "bsd model"), especially for
bigger files. Otherwise you will end up, for a short time, with three
copies of your input (an original, a copy in a printer spool directory
and the "smbspool" copy to be sent on the network).
Historically, print software, by default, was limiting the size of
accepted input. Usually this would be something like 1 MB, which is
something like five hundred pages of straight text and looks
reasonable enough. Nowadays, with graphic printouts (and even text is
usually sent in a graphics mode as well ) this no longer makes sense.
You may change this limit by editing the value of mx
in your
/etc/printcap
or equivalent; :mx#0:
means "no
limit". You may still want to be careful with that, however, unless
you have infinite amounts of storage and paper!
Another possibility, if your print software allows it, is to print using a symbolic link instead of a copy into a printer spool directory. For example, with bsd-style print software
print command = lpr -s -r -P %p %swill do this, and it will remove the input file, placed by Samba, once it is done. This configuration can be to your advantage even with
:mx#0:
since you avoid creating two copies (one by Samba, the
other one in a spool directory) for potentially big data files. If you
have a lot of clients printing big jobs, this may save you a lot of
disk.
The output send by Windows printer drivers is only "more-or-less"
Postscript. Various Postscript interpreters try to deal with that but
do not always succeed. Samba has postscript = True
which
attempts to help. Unfortunately this is not a good idea, globally, in
[printers]
section, if you have printers which are capable of
Postscript and some non-Postscript printers and you are not
configuring them individually, or you have printers like some HP
models which would accept both Postscript and non-Postscript (HPGL)
jobs.
A better approach is to try to configure your Windows printer drivers to not send the initial "control-D from hell". If you look at many of the Windows printer drivers, they send this is a default. Fortunately this may be turned off! This will help with the most blatant standard violations, but alas, not always. For some examples see the next question.
This is an example of "nearly Postscript but not quite" problems. The trouble is that some initialization and cleanup which should be in the document header and trailer is packed by Windows into the first and last page comments. NeXT normally prints in reverse page order (collated), and things do not happen at the right time, and, therefore, nothing works properly.
Here are possible suggestions for how do deal with this:
*DefaultOutputOrder: Reverse
by putting `%'
after `*'. It works but you will have to collate all your
print jobs by hand (sigh...).
niload
for that) and print Windows jobs on it. We have not
tested this in a real-life situation, but hopefully it should work.
print command
to strip as much as you
dare of the comments. Piping through a simple
sed '/^%%/d'may work. The Postscript interpreter will be not able to reverse pages and files will print. Check with Shon Vella,
shon@novell.com
, for details.
/dev/null
for an output device and a filter like this:
sed '/^%%/d' | lprExport with Samba only this printer. (This uses a standard Unix trick for adding filters to printers where you otherwise cannot; like to remote ones).
On the other hand Eugene Mah, eugene@raddi.uah.ualberta.ca
,
reports that he prints with a NEXTSTEP server by telling PCs that they
print on an HP Laserjet III with Postscript and with postscript =
yes
in the configuration file. Your mileage may vary.
Why not? On the Unix side every peripheral device, for example a tape
drive, looks like a file (possibly "special", with a limited set of
valid operations on it). If you can export it as a Samba service
writable to a client then a client may type
to it (or from
it) on its side. A weird variation on backup services, and not one
for the faint-of-heart.
Next Chapter, Previous Chapter
Table of contents of this chapter, General table of contents
Top of the document, Beginning of this Chapter