On Fri, 9 Feb 2001, Daniel E. Singer wrote:
I also am about to rebuild our print server and there were two things I
noticed about ifhp. If a user prints from a windows computer the driver
generates PJL code which ifhp rejects. In windows I printed to a file and
but when I print this file thru ifhp the only output is the banner page.
However if I print directly to the printer using lpr -Praw@printer I get
the correct output. I have been testing LPRng under both RedHat Linux 7
and Solaris 8 and found that a2ps functions differently on the two
systems. Under Linux troff files are converted to man page readable
format, but under Solaris the troff file is wrapped in postscript and
printed. Other than this ifhp works great.
> Well we *finally* got LPRng all set up at our site. And now that the
> kinks have been (mostly) worked out, it's running very nicely.
> (Converting over from our several-years-old LPRng installation was a
> pain!)
>
> Some of what we did might be useful to a few people, so I'm going to
> share some of our scripts and such that we used to customize the
> setup, mostly ifhp issues. To provide some context, our site is a
> couple hundred machines (workstations and servers, mostly Solaris)
> that send print jobs to a single central print server. The printers
> are mostly networked HP's (and one pesky SparcPrinter E, ack!). We
> also run SAMBA so that PC's and other machines not on our main network
> can send jobs to our printers. We are currently running LPRng-3.7.4
> and ifhp-3.4.4.
>
> [Note: If you notice that we went to trouble to implement things that
> are supported by built-in LPRng and/or ifhp features, please let me
> know.]
>
> To start with, we are using the file conversion features in ifhp.conf
> to intelligently handle most print jobs. One problem we noticed was
> that "unknown" print jobs were quietly discarded (a config option?).
> In order to send an email back to the user to notify them that their
> job had failed, we designated a2ps as a "filter", and supplied a
> wrapper script (attached) for a2ps. If a2ps fails (in the conversion),
> then the wrapper returns some binary junk and a successful return
> code, the file_util command returns "data", and our "oddjob.sh" script
> (attached) is invoked. (Is there more direct support for this sort of
> thing in ifhp?)
>
> # excerpt from ifhp.conf
> file_output_match = [
> *gzip_compressed* filter \%s{gzip_decompress}
> *compress*data* filter \%s{gzip_decompress}
> *pdf* ps \%s{pdf_converter}
> *postscript* ps \%s{ps_converter}
> *tex_dvi* ps \%s{dvi_converter}
> *ascii_text* pcl \%s{text_converter}
> *pcl* pcl \%s{pcl_converter}
> data pcl \%s{unknown_converter}
> *pjl* pjl \%s{pjl_converter}
> *printer*job*language* pjl \%s{pjl_converter}
> * filter \%s{a2ps_converter}
> ]
> a2ps_options= -q -B -1 -M \%M{papersize} --borders=no -o-
> a2ps_converter= /auto/global/lprng/libexec/filters/a2ps-wrapper.sh
>\%s{a2ps_options}
> pdf_converter= /auto/global/lprng/libexec/filters/acroread-wrapper.sh
> dvi_converter= /auto/global/lprng/libexec/filters/dvips-wrapper.sh
> unknown_converter= /auto/global/lprng/libexec/filters/oddjob.sh \%s{ARGV}
> gzip_decompress = /usr/local/bin/gunzip -c
> ps_converter=
> pcl_converter=
> pjl_converter=
> text_converter=
>
> Acroread (for PDF conversions) on our (Solaris) system leaves its data
> files in /tmp (ie, it doesn't clean up), so to get around this, we
> made it a special case and provided a wrapper (attached).
>
> DVI conversions also seem to be problematic due to I/O expectations,
> so yet another wrapper (attached) was added for appropriate I/O
> support. (dvips did not seem to work properly thru a2ps.)
>
> Another problem was that our printcap contains client and server
> entries, and this seemed to confuse SAMBA (were we doing something
> wrong?). So we added a filter (attached) (to be run by hand) that
> will convert our unified printcap file into an abbreviated version
> that SAMBA can digest. Certain assumptions are builtin, but the
> script could be enhanced.
>
> Also, we do some informational printer accounting. The accounting.sh
> sample script supplied with ifhp seems very inefficient, since it has
> to call external programs to parse each command line option. So we
> wrote a perl version (attached) which also deals with an ifhp bug
> (repeated options).
>
> Lastly, I've included our PJL/PCL banner script (perl).
>
> If anyone else has any interesting ways to handle these or other
> issues, I'd appreciate seeing them posted to this list.
>
> Regards,
>
> -Dan
>
> --
> Daniel E. Singer, System Administrator
> Dept. of Computer Science, Duke University, Durham NC 27708 USA
> [EMAIL PROTECTED], www.cs.duke.edu/~des, (919)660-6577
>
Rob Fausey.
These are not the droids you're looking for. Move along. Move along.
-----------------------------------------------------------------------------
YOU MUST BE A LIST MEMBER IN ORDER TO POST TO THE LPRNG MAILING LIST
The address you post from MUST be your subscription address
If you need help, send email to [EMAIL PROTECTED] (or lprng-requests
or lprng-digest-requests) with the word 'help' in the body. For the impatient,
to subscribe to a list with name LIST, send mail to [EMAIL PROTECTED]
with: | example:
subscribe LIST <mailaddr> | subscribe lprng-digest [EMAIL PROTECTED]
unsubscribe LIST <mailaddr> | unsubscribe lprng [EMAIL PROTECTED]
If you have major problems, send email to [EMAIL PROTECTED] with the word
LPRNGLIST in the SUBJECT line.
-----------------------------------------------------------------------------
