diff options
Diffstat (limited to 'docs/docbook/projdoc/Printing.sgml')
| -rw-r--r-- | docs/docbook/projdoc/Printing.sgml | 398 |
1 files changed, 398 insertions, 0 deletions
diff --git a/docs/docbook/projdoc/Printing.sgml b/docs/docbook/projdoc/Printing.sgml new file mode 100644 index 0000000000..cb7e5cdfb7 --- /dev/null +++ b/docs/docbook/projdoc/Printing.sgml @@ -0,0 +1,398 @@ +<chapter id="printing_debug"> +<chapterinfo> + <author> + <firstname>Patrick</firstname><surname>Powell</surname> + <affiliation> + <address><email>papowell@lprng.org</email></address> + </affiliation> + </author> + <pubdate>11 August 2000</pubdate> +</chapterinfo> + +<title>Debugging Printing Problems</title> + +<sect1> +<title>Introduction</title> + +<para> +This is a short description of how to debug printing problems with +Samba. This describes how to debug problems with printing from a SMB +client to a Samba server, not the other way around. For the reverse +see the examples/printing directory. +</para> + +<para> +Ok, so you want to print to a Samba server from your PC. The first +thing you need to understand is that Samba does not actually do any +printing itself, it just acts as a middleman between your PC client +and your Unix printing subsystem. Samba receives the file from the PC +then passes the file to a external "print command". What print command +you use is up to you. +</para> + +<para> +The whole things is controlled using options in smb.conf. The most +relevant options (which you should look up in the smb.conf man page) +are: +</para> + +<para><programlisting> + [global] + print command - send a file to a spooler + lpq command - get spool queue status + lprm command - remove a job + [printers] + path = /var/spool/lpd/samba +</programlisting></para> + +<para> +The following are nice to know about: +</para> + +<para><programlisting> + queuepause command - stop a printer or print queue + queueresume command - start a printer or print queue +</programlisting></para> + +<para> +Example: +</para> + +<para><programlisting> + print command = /usr/bin/lpr -r -P%p %s + lpq command = /usr/bin/lpq -P%p %s + lprm command = /usr/bin/lprm -P%p %j + queuepause command = /usr/sbin/lpc -P%p stop + queuepause command = /usr/sbin/lpc -P%p start +</programlisting></para> + +<para> +Samba should set reasonable defaults for these depending on your +system type, but it isn't clairvoyant. It is not uncommon that you +have to tweak these for local conditions. The commands should +always have fully specified pathnames, as the smdb may not have +the correct PATH values. +</para> + +<para> +When you send a job to Samba to be printed, it will make a temporary +copy of it in the directory specified in the [printers] section. +and it should be periodically cleaned out. The lpr -r option +requests that the temporary copy be removed after printing; If +printing fails then you might find leftover files in this directory, +and it should be periodically cleaned out. Samba used the lpq +command to determine the "job number" assigned to your print job +by the spooler. +</para> + +<para> +The %>letter< are "macros" that get dynamically replaced with appropriate +values when they are used. The %s gets replaced with the name of the spool +file that Samba creates and the %p gets replaced with the name of the +printer. The %j gets replaced with the "job number" which comes from +the lpq output. +</para> + +</sect1> + +<sect1> +<title>Debugging printer problems</title> + +<para> +One way to debug printing problems is to start by replacing these +command with shell scripts that record the arguments and the contents +of the print file. A simple example of this kind of things might +be: +</para> + +<para><programlisting> + print command = /tmp/saveprint %p %s + + #!/bin/saveprint + # we make sure that we are the right user + /usr/bin/id -p >/tmp/tmp.print + # we run the command and save the error messages + # replace the command with the one appropriate for your system + /usr/bin/lpr -r -P$1 $2 2>>&/tmp/tmp.print +</programlisting></para> + +<para> +Then you print a file and try removing it. You may find that the +print queue needs to be stopped in order to see the queue status +and remove the job: +</para> + +<para><programlisting> + +h4: {42} % echo hi >/tmp/hi +h4: {43} % smbclient //localhost/lw4 +added interface ip=10.0.0.4 bcast=10.0.0.255 nmask=255.255.255.0 +Password: +Domain=[ASTART] OS=[Unix] Server=[Samba 2.0.7] +smb: \> print /tmp/hi +putting file /tmp/hi as hi-17534 (0.0 kb/s) (average 0.0 kb/s) +smb: \> queue +1049 3 hi-17534 +smb: \> cancel 1049 +Error cancelling job 1049 : code 0 +smb: \> cancel 1049 +Job 1049 cancelled +smb: \> queue +smb: \> exit +</programlisting></para> + +<para> +The 'code 0' indicates that the job was removed. The comment +by the smbclient is a bit misleading on this. +You can observe the command output and then and look at the +/tmp/tmp.print file to see what the results are. You can quickly +find out if the problem is with your printing system. Often people +have problems with their /etc/printcap file or permissions on +various print queues. +</para> +</sect1> + +<sect1> +<title>What printers do I have?</title> + +<para> +You can use the 'testprns' program to check to see if the printer +name you are using is recognized by Samba. For example, you can +use: +</para> + +<para><programlisting> + testprns printer /etc/printcap +</programlisting></para> + +<para> +Samba can get its printcap information from a file or from a program. +You can try the following to see the format of the extracted +information: +</para> + +<para><programlisting> + testprns -a printer /etc/printcap + + testprns -a printer '|/bin/cat printcap' +</programlisting></para> + +</sect1> + +<sect1> +<title>Setting up printcap and print servers</title> + +<para> +You may need to set up some printcaps for your Samba system to use. +It is strongly recommended that you use the facilities provided by +the print spooler to set up queues and printcap information. +</para> + +<para> +Samba requires either a printcap or program to deliver printcap +information. This printcap information has the format: +</para> + +<para><programlisting> + name|alias1|alias2...:option=value:... +</programlisting></para> + +<para> +For almost all printing systems, the printer 'name' must be composed +only of alphanumeric or underscore '_' characters. Some systems also +allow hyphens ('-') as well. An alias is an alternative name for the +printer, and an alias with a space in it is used as a 'comment' +about the printer. The printcap format optionally uses a \ at the end of lines +to extend the printcap to multiple lines. +</para> + +<para> +Here are some examples of printcap files: +</para> + +<para> +<orderedlist> +<listitem><para> +pr just printer name +</para></listitem> +<listitem><para> +pr|alias printer name and alias +</para></listitem> +<listitem><para> +pr|My Printer printer name, alias used as comment +</para></listitem> +<listitem><para> +pr:sh:\ Same as pr:sh:cm= testing + :cm= \ + testing +</para></listitem> +<listitem><para> +pr:sh Same as pr:sh:cm= testing + :cm= testing +</para></listitem> +</orderedlist> +</para> + +<para> +Samba reads the printcap information when first started. If you make +changes in the printcap information, then you must do the following: +</para> + +<orderedlist> + +<listitem><para> +make sure that the print spooler is aware of these changes. +The LPRng system uses the 'lpc reread' command to do this. +</para></listitem> + +<listitem><para> +make sure that the spool queues, etc., exist and have the +correct permissions. The LPRng system uses the 'checkpc -f' +command to do this. +</para></listitem> + +<listitem><para> +You now should send a SIGHUP signal to the smbd server to have +it reread the printcap information. +</para></listitem> +</orderedlist> + +</sect1> + +<sect1> +<title>Job sent, no output</title> + +<para> +This is the most frustrating part of printing. You may have sent the +job, verified that the job was forwarded, set up a wrapper around +the command to send the file, but there was no output from the printer. +</para> + +<para> +First, check to make sure that the job REALLY is getting to the +right print queue. If you are using a BSD or LPRng print spooler, +you can temporarily stop the printing of jobs. Jobs can still be +submitted, but they will not be printed. Use: +</para> + +<para><programlisting> + lpc -Pprinter stop +</programlisting></para> + +<para> +Now submit a print job and then use 'lpq -Pprinter' to see if the +job is in the print queue. If it is not in the print queue then +you will have to find out why it is not being accepted for printing. +</para> + +<para> +Next, you may want to check to see what the format of the job really +was. With the assistance of the system administrator you can view +the submitted jobs files. You may be surprised to find that these +are not in what you would expect to call a printable format. +You can use the UNIX 'file' utitily to determine what the job +format actually is: +</para> + +<para><programlisting> + cd /var/spool/lpd/printer # spool directory of print jobs + ls # find job files + file dfA001myhost +</programlisting></para> + +<para> +You should make sure that your printer supports this format OR that +your system administrator has installed a 'print filter' that will +convert the file to a format appropriate for your printer. +</para> + +</sect1> + +<sect1> +<title>Job sent, strange output</title> + +<para> +Once you have the job printing, you can then start worrying about +making it print nicely. +</para> + +<para> +The most common problem is extra pages of output: banner pages +OR blank pages at the end. +</para> + +<para> +If you are getting banner pages, check and make sure that the +printcap option or printer option is configured for no banners. +If you have a printcap, this is the :sh (suppress header or banner +page) option. You should have the following in your printer. +</para> + +<para><programlisting> + printer: ... :sh +</programlisting></para> + +<para> +If you have this option and are still getting banner pages, there +is a strong chance that your printer is generating them for you +automatically. You should make sure that banner printing is disabled +for the printer. This usually requires using the printer setup software +or procedures supplied by the printer manufacturer. +</para> + +<para> +If you get an extra page of output, this could be due to problems +with your job format, or if you are generating PostScript jobs, +incorrect setting on your printer driver on the MicroSoft client. +For example, under Win95 there is a option: +</para> + +<para><programlisting> + Printers|Printer Name|(Right Click)Properties|Postscript|Advanced| +</programlisting></para> + +<para> +that allows you to choose if a Ctrl-D is appended to all jobs. +This is a very bad thing to do, as most spooling systems will +automatically add a ^D to the end of the job if it is detected as +PostScript. The multiple ^D may cause an additional page of output. +</para> + +</sect1> + +<sect1> +<title>Raw PostScript printed</title> + +<para> +This is a problem that is usually caused by either the print spooling +system putting information at the start of the print job that makes +the printer think the job is a text file, or your printer simply +does not support PostScript. You may need to enable 'Automatic +Format Detection' on your printer. +</para> + +</sect1> + +<sect1> +<title>Advanced Printing</title> + +<para> +Note that you can do some pretty magic things by using your +imagination with the "print command" option and some shell scripts. +Doing print accounting is easy by passing the %U option to a print +command shell script. You could even make the print command detect +the type of output and its size and send it to an appropriate +printer. +</para> + +</sect1> + +<sect1> +<title>Real debugging</title> + +<para> +If the above debug tips don't help, then maybe you need to bring in +the bug guns, system tracing. See Tracing.txt in this directory. +</para> +</sect1> +</chapter> |