Modifying lp & lp sched

Modifying lp & lp sched

Post by I.Le » Wed, 04 Jul 2001 20:10:51



Hi all,

I have a summer placement at Exeter (UK) University to explore the
following:

1.      Modify or find a substitute for the lp command in order to provide
simplex or duplex printing options from the command line.

2.      Modify the lp sched command in order to trap non-postscript jobs sent
to the postscript printer & non-text jobs sent to the text printer.
There is the possibility here of giving users the option to convert
plain text to postscript in order to facilitate awareness of printer
issues (ie printer malfunction caused by incorrect file types being
received).  However, this could be bypassed by converting jobs without
notification.

I wondered if anyone had implemented any such modifications & if so, how
did you go about it?

Regards

Ian

--------------------------------
Ian Lee
Undergraduate Scum

c/o
Department of Computer Science
School of Engineering and Computer Science
University Of Exeter
Exeter EX4 4PT
United Kingdom

 
 
 

Modifying lp & lp sched

Post by Logan Sh » Wed, 04 Jul 2001 23:27:29



>1.  Modify or find a substitute for the lp command in order to provide
>simplex or duplex printing options from the command line.

This shouldn't be terribly hard.  The lp command allows you to pass
printer-specific options when submitting a job by using the "-o"
command line argument.  Example:

        lp foo.txt              # print foo.txt with no options
        lp -o abc foo.txt       # print foo.txt with option "abc" turned on

Of course, making this actually *do* something on the other end
will be interesting.  There are two challenges here:

1.  You ahve to figure out how to get your printer to do that.  It
    depends on the printer.

2.  You have to figure out how to get the lp system to interpret
    your custom command-line option as described above.  I believe you
    do this by modifying the interface script for the print queue.  The
    default interface script is normally /usr/lib/lp/model/standard,
    but you have a print queue use a custom interface script, if I
    remember correctly.

    The interface script, by the way, is what the print system uses
    when it's done queueing and converting formats and all that good
    stuff, and it's actually time to send the job to the printer.  That
    is, the interface script is the "send it to the printer for me"
    script.

Quote:>2.  Modify the lp sched command in order to trap non-postscript jobs sent
>to the postscript printer & non-text jobs sent to the text printer.

Hmm...  It doesn't do this already?  Normally, the Solaris print system
is set up so that it knows what content type each printer can handle,
and it has a number of filters which can convert between content
types.  Then, it determines what type of content has been submitted and
automatically determines which filter to use.

The one difficulty you may find here is that, as far as I have been
able to determine, the print system gives you no control over detecting
what type of content a print job has.  The rules for determining this
are apparently hard-coded, and they may not recognize every format
you're interested in.

I think you will want to get familiar with some documentation:

        (the regular System V print system)
        man lp
        man lpadmin
        man lpfilter
        man lpsched
        man lpsystem
        man lpusers

        (SunSoft Print Client stuff)
        man printers.conf
        man lpset
        man lpget

        http://docs.sun.com/
        http://docs.sun.com/ab2/coll.47.11/SYSADV2/   (the parts about
                                                       setting up printers)

The task before you is actually somewhat involved.  It's not terribly
difficult, but the print system is sort of complex and the
documentation isn't the clearest, so it may take a while to grasp how
it all fits together.  Also, since you may need to customize an
interface script, you may need to do some Bourne shell programming.  If
you don't know any/much shell programming, I recommend the book "Unix
Shell Programming" by Kochan and Wood.  It's about 10 years old, but it
is good anyway.

Have fun.  :-)

  - Logan
--
my  your   his  her   our   their   _its_
I'm you're he's she's we're they're _it's_

 
 
 

Modifying lp & lp sched

Post by Greg Andre » Thu, 05 Jul 2001 00:27:37



>I have a summer placement at Exeter (UK) University to explore the
>following:

>1.  Modify or find a substitute for the lp command in order to provide
>simplex or duplex printing options from the command line.

There's no need to modify the lp binary.  You simply need to install
an interface script that knows how to take the "-o duplex" or "-o simplex"
option to the lp command and send the corresponding command codes to the
printer at the start of the print job.

The HP Jetdirect software installs those kinds of interface scripts
for use with HP Laserjet printers (particularly ones on the network).
Lexmark provides MarkVision for their printers, and Xerox has one or
two similar software packages for their printers.  Some other printer
manufacturers provide interface (aka "model") scripts on their web
sites or through their tech support departments.

The lp and lpr print commands scan the command line for -o option
keywords, and when the print server is a Solaris machine, any of
those options are passed to the print server along with the print
job.  The Solaris print server (lpsched) then invokes the printer's
interface script and passes those option keywords in one of the
arguments to the script.  It's up to the interface script to parse
the option keywords and send the initialization commands for those
options to the printer.  (some option keywords can be commands to
the interface script itself, such as "nobanner")

The two interfaces provided with Solaris ("standard" and "netstandard")
are bourne shell scripts, as are the ones provided by HP's Jetdirect
software, but they don't have to be.  They can be compiled programs,
perl scripts, or whatever seems the right programming medium in your
work environment.

Quote:

>2.  Modify the lp sched command in order to trap non-postscript
>jobs sent to the postscript printer & non-text jobs sent to the text
>printer.

No need to modify lpsched.  It already has the ability to trap jobs
that are not in the right format and either reject them or automatically
send them through a print filter to convert them to the proper format
for the printer.  The print filter can be a program or script of your
own devising to accomplish the goal.

The "automatically send jobs through a print filter" mechanism can be
utilized to send all print jobs through a sophisticated script or program
that decides if the format is correct (and writes the job to its output
so it will reach the printer), or if it's incorrect.  When the job is
incorrect, the print filter can cause the job to fail, which sends a
notice back to the user who submitted the job, or the filter can convert
the data to the right format, or the filter can invoke an lp command
to send the job to another printer.

The print job can be run through a filter before the interface script
is invoked.  This is what happens when lpsched determines that the
filter that needs to run is a "slow" filter.  The print job can be run
through a filter that's invoked by the interface script itself.  This
happens when lpsched determines the proper filter is a "fast" filter.

Lpsched has a mechanism for automatically detecting the format of a
print job, but it only detects whether or not the file is Postscript.
Files that are not in Postscript format are considered "simple" (text).
Other formats (PCL, gif, tiff, database, etc.) are not detected.
However, the user submitting the print job can use the -T argument to
the lp command to declare the format of the file, and lpsched will use
that information to make filter decisions.

So you have two points at which you can trap the print job and decide
whether it's in the wrong format and whether to convert, redirect, or
reject the print job.  If the printer's content type is set to a specific
format (instead of "any"), then lpsched will invoke a print filter on
those jobs that aren't in the same format.  Also, the interface script
(or program) can perform similar tests on the file and make similar
decisions on how to respond to files in the wrong formats.

Quote:

>There is the possibility here of giving users the option to convert
>plain text to postscript in order to facilitate awareness of printer
>issues (ie printer malfunction caused by incorrect file types being
>received).  However, this could be bypassed by converting jobs without

             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Quote:>notification.

^^^^^^^^^^^^^

Solaris supplies a filter to do this.  It's the "postprint" filter,
and the file that tells lpsched how to use it as a print filter is
/etc/lp/fd/postprint.fd.

So pretty much everything you've mentioned can be performed by the
interface script and print filters (which can also be scripts).
There's no need to hack the lp or lpsched programs.  The designers
of the SVR4 print system anticipated these kinds of needs and
created the hooks where you could customize it in these ways.

The docs.sun.com web server has system admin guides with pretty good
tutorial and reference material on the print system.

  -Greg
--

I have a map of the United States that's actual size
                 -- Steven Wright

 
 
 

Modifying lp & lp sched

Post by Greg Andre » Thu, 05 Jul 2001 03:39:46



>    The interface script, by the way, is what the print system uses
>    when it's done queueing and converting formats and all that good
>    stuff, and it's actually time to send the job to the printer.  That
>    is, the interface script is the "send it to the printer for me"
>    script.

Unfortunately, the SVR4 printing system is a bit more complex
than that.

You're right that the interface script is the thing that's responsible
for reading the print file(s) from the queue and sending them to the
printer.  However, the interface script can be involved in converting
formats.

There are two types of print filters:  slow and fast.  Slow filters
are invoked while the print job is in the queue, before the interface
script is invoked to deliver the job.  The idea is that conversions
which take a long time don't need to tie up the queue.  Other print
jobs that don't need conversion can jump ahead and be printed without
waiting for the one that's being converted.  Fast filters don't take
a long time (or need to interact directly with the printer), so they
are passed to the interface script in the TERM environment variable.
The interface script is invoked and is expected to pipe the print
files through the comand in the TERM variable as the files are being
sent to the printer.

So the interface script is involved in invoking any fast filters
needed for converting print jobs.

Quote:

>The one difficulty you may find here is that, as far as I have been
>able to determine, the print system gives you no control over detecting
>what type of content a print job has.  The rules for determining this
>are apparently hard-coded, and they may not recognize every format
>you're interested in.

The usual workaround for this is to create a printer queue that will
force EVERY print job to be run through a slow filter, and write a
filter to perform the desired file type checking.  That filter can then
invoke programs to convert the data and/or send the files to other
printer queues via lp commands.

  -Greg
--

I have a map of the United States that's actual size
                 -- Steven Wright

 
 
 

1. lp(1) suid to lp-Secure files fail.

We run an environment where some of our files are 'secure', and don't
have world read access. Such files can't be printed with lp, but can be
printed with lpr. For complex reasons, we can't use lpr on these systems.

hermes:/users/johnk/bar> ll foo
-rw-rw----   1 johnk    ee         36454 Feb 17 16:51 foo
hermes:/n/hermes/johnk/bar> lp -dhp4_text foo
request id is hp4_text-2078 (1 file)

lp is suid lp, and thus can't read the file, which hangs out in the queue
forever.

hermes:/n/hermes/johnk/bar> which lp
/usr/bin/lp
hermes:/n/hermes/johnk/bar> ll /usr/bin/lp
-rwsr-xr-x   1 lp       sys        81968 Jul 31  1993 /usr/bin/lp*
hermes:/n/hermes/johnk/bar>

A workaround is to pipe all print jobs into lp, but this is a pain for
users to remember, and doesn't work well with other programs that expect
to be able to give file arguments to lp.

I suppose I could make lp suid root, but this opens the spectre of all
sorts of security problems (up to, and possibly including allowing
anyone to print any file on the system)

Any ideas on how to get lp working in such an environment?

                -John Kalucki

2. Help with elmrc

3. #$%@! lp:Solaris remote lp failing

4. NIS error : Secure mode sunos 3.x servers rejected

5. lp: unable to get major 6 - Initialization of lp failed

6. Solaris equivalent of dkinfo?

7. lp-init: no lp devices found

8. C prototype of DoSyscall routine

9. HPLJ4l lp init: no lp devices found

10. Starting lpd: Warning - lp: cannot stat lp device '/dev/lp0'

11. LP doesn't work after lp jumbo patch

12. jumbo lp patch breaks lp ???

13. How to 100% flush lp's buffers? I've rm'd spool-files, lp stop, lp start