This release has some new functionality added,
but is soooo compatible that it is really not part of a new change.

I seriously considered making this 3.7.1,  and may do this
yet on the next release.   

Patrick Powell                 Astart Technologies,
[EMAIL PROTECTED]            9475 Chesapeake Drive, Suite D,
Network and System             San Diego, CA 92123
  Consulting                   858-874-6543 FAX 858-279-8424 
LPRng - Print Spooler (http://www.astart.com)

Release LPRng 3.6.23 - Fri Aug 11 08:03:23 PDT 2000

 The Linux Printing Summit was held from July 27-28, 2000
  in San Jose,  and was sponsored by VA Linux.  There was an
  extremely enjoyable interchange of views between all of the
  various interested factions.  You will see some additional changes
  in LPRng as a result of these meetings and the input from users
  and developers.

 Support for status caching has been incorporated in LPRng.
  In addition, 'spool queue lookup throttling' has been
  added in order to improve the speed of status gathering.
  And there are now facilities to control the format of returned
  status.

  This is implemented as follows:

    a) Each queue has a file containing keys corresponding to
       status queries.  For example, if you do 'lpq' then the
       query key would be "4_"  corresponding to the "\004\n"
       query sent to the server.  If you do 'lpq this that'
       you have the key "4_this_that_" and so forth.

    b) Corresponding to each query is a file containg the status
       for the query.  If the status is 'stale', that is,
       older than 'lpq_status_stale' seconds,  then the lookup
           is redone.

    c) When a job is submitted to a queue,  or the status of a job
       changes,  or a control operation is performed on the queue,
       then the cache is flushed.  Currently,  this means that
       the status has to be regenerated for all queries.

    d) If the queue status was changed less than 'lpq_status_interval'
       seconds ago,  then the cached status (if any) will be used.

    e) If the process needs to update the print queue, it will
       attempt to lock the status file.  This means that at most
       one process will be scanning the print queue for status
       at a time.  This has had an extremely good improvement on
       status reporting, especially under high load conditions
       and multiple processes attempting to scan the queue.
       This locking actually improved throughput much to my
       surprise.  A careful analysis showed that by having only
       one or two processes scanning the directory at a time,
       the OS was better able to cache and buffer data.  In actual
       fact,  the second process would then find the files that
       it was looking for already in memory or in the buffer cache.
       Also,  if the two processes were getting the same data
       (lpq -a),  the first one would set up the data in the cache
       and the next one would simply read the cached data.

  The 'lpc flush' command has been added to flush all of the
    cached status.  This was added for testing and for administrative
    purposes.

  A new Super Secret option (well, it is documented now) has
    has been added to the 'lpq' facility.  The following
    only works with LPRng servers (as of this release, of course):

        lpq -- -lines=N   (in general: lpq -- -opt=v,opt=v)

    The '-lines=N' is passed directly through to the LPRng
    lpd server,  where used to set the size of the returned status.
    It is NOT propagated to other servers,  BUT it is used to
    truncate status returned from them.  This will effectively
    give you a VERY compressed status extremely quickly when
    combined with the caching facility.

    The -- is used to indicate that the -lines=N is actually an
    option to be passed through to the server.  This capability
    has been in LPRng,  but this is the first documented use
    of it that will be supported.

    The addition of this facility has some interesting implications.
    You can now have a VERY lightweight lpq facility,  for getting
    the status of one printer,  if you know the server it is on:

    echo "\004printer -lines=2 xx xx xx" > nc host 515
     (nc is the 'netcat' program written by [EMAIL PROTECTED])

    Of course you do not have authentication,  etc., but this is
    One Of Those Tradeoffs.  YOU ARE WARNED: USE THE SOCKET CONNECTION
    METHOD AT YOUR OWN RISK AND DON'T WHINE WHEN YOU DISCOVER THAT
    THE LACK OF AUTHENTICATION IS CAUSING YOU PROBLEMS.  If this
    is a problem, use the 'lpq' application and turn on authentication.

    On the other hand,  you can now get printer status WITHOUT the
    use of an 'lpq' process to format it.  I expect the various
    folks building WebServer interfaces for LPRng print status will
    be more than happy now, as this works well in a multi-threaded
    environment,  is strictly socket/connection based.

    Another benifit is that NonLPRng (can you say Microsoft?)
    based applications can now use the -lines=N entry to select
    the amount of status that they want returned.  This allows
    remote clients not LPRng based to select the level of verbosity.

  This work was inspired by the Samba Developers, especially Andrew
  Tridgell, John Terpstra, and Jeremy Allison,
  <http://www.samba.org/samba/team.html>,  and their presentations
  and discussions at the Linux Printing Summit held in San Jose,
  July 26-31, Sponsored by VALinux.

 You can now specify a filter for your input files at the user level.
  This is to support the requirements and/or desires of the various
  users of print spooling software to have a filter applied at the
  application end.

  The syntax is:
     lpr -X /path file1 file2
  equivalent to:
     for each file in filelist; do
       tempfile=maketempfile;
       /path <$file >$tempfile
     end
     lpr $tempfile1 $tempfile2 ...

  The filter is invoked once per job file,  on each job file.
  The options passed to the filter are the usual ones for all
  LPRng filters.  Some will not have any meaning,  such as job
  number, etc., and will not be present or have a '0' value.
  The filter will run as the user's id, and will not have root
  capabilities.  If this is needed,  then the filter must have
  the capability of acquiring them.

  This work was inspired by the GIMP Project presentation of Robert
  Krawitz <[EMAIL PROTECTED]> http://www.tiac.net/users/rlk/ Project
  lead for The Gimp Print --  http://gimp-print.sourceforge.net at
  the Linux Printing Summit held in San Jose, July 26-31, Sponsored
  by VALinux.

  I ran into problems with the SysV to LPRng option passing. Apparently
   different versions of SysV printing pass options as S, O, or
   whathave you values in the control file.  The prefix_o_to_z
   option has been replaced by the more general 'prefix_option_to_option'
   facililty.  This specifies the control file option lines to
   prefix to a control file option line.  For example:

    prefix_option_to_option=S,O Z  will prefix S and O to Z
    prefix_option_to_option=Z O    will prefix Z to O.

    This now appears to cover all cases,  and the LPRng HOWTO
    has been modified as well.

  The simple minded 'send mail to user' facility had some problems.
   I fixed them up,  and added a 'sendmail_to_user' flag that allows
   the facility to be disabled for sending mail to users,  but still
   sends mail to operator.  I have also updated the HOWTO with some
   notes about using this facility.
   (Patches sent by: Maja Gorecka-Wolniewicz <[EMAIL PROTECTED]>)

  Several calls to Print_job(...) assumed that a file will respond with
   status information,  as would a real printer.  Not a good assumption.
   I wonder where my mind is at somedays...
  The 'Network Grace' timeout should only be used when a server is trying
   to connect - clients should not have to wait.

  I have once again changed the checkpc code to be very very very
   conservative in what it removes from the spool queues.  This will make the
   folks who use netatalk,  etc.  very happy.  The bad news is that files
   put into these directories by other tools will not get removed.  C'est
   la vie,  C'est la guerre...
   (Patches inpiring the changes sent by: "William R. Knox" <[EMAIL PROTECTED]>)

  pclbanner had a stupid typeo left over from debugging.
   It wrote debugging information out to /tmp/before
  The 'lpr_bounce' code did not work after the last fix to solve problems
   with Print_job closing files.  Now you can use filters again from lpr.

  I have added the 'wildcard' print queue names and 'incoming_control_filter'
   options.  Together, they implement a way to put options and
   other information into the control file when a job is submitted.
   This method was exploited by Adeel Khurshid <[EMAIL PROTECTED]>
   while at Fujitsu Network Communications,  and is used by the
   'apsfilter' by Andreas Klemm and Thomas Bueschgens.

     Example:
      lp|lp_*:lp=%P@server
      lp|lp_*:server
        :incoming_control_filter=/.../update_z
        :...

   When you use lpr -Plp_landscape_ledger you will actually end up
   sending the job to the lp queue, with the queue name (Q control
   file line) set to lp_landscape_ledger.  This information can be
   used to update the various control file lines.  The LPRng/UTILS/update_z
   file has an example of a script that will do this.  Note that this
   makes the use of the apsfilter utility even easier.
   (Inpired by a control filter by: Adeel Khurshid <[EMAIL PROTECTED]>)

  I removed a couple of bogus entries that I was putting into the
   job control file.  These appear to be holdovers from some testing.
   They were put in but never used.  Strange, that.

  The append_z, prefix_z, and other related Z operations are done
   only when the job is received.  This now allows the job to be
   processed by filters and not have the work undone.  sigh.
   Documentation cleaned up as well.

  The control file processing has been cleaned up and the redunant
   and erroneous (sigh) copy of the control file in the job{} data
   structure has been ruthlessly purged.  I sure wish Ruth worked
   for me,  I seem to be doing so much ruthless cleanup.
   I see the hand of testing and debugging in much of this stuff,
   and the tracking down of memory leaks as well.

  You can now use [^x] in the glob patterns.  Sigh...  The things
   people do when they get the bit in their teeth.

  The LPD support for 'lpq' and 'lprm' requests has been modified so that
   if there are chained queues and each queue is on the server THEN
   I simply call a routine and do not fork a process.  This solves a
   problem with process exhaustion when somebody had a loop in their
   printcap.  I also put in some tests for this.  However, without
   adding Yet Another Option to the LPRM and LPQ stuff I don't see
   how I can do it.

  You can now send up to 'max_jobfiles' (default 52) to the server.
   Note:  you can actually only send 52*52 = 2704
   The data files are given names
     dfAnn -> dfZnn -> dfann -> dfznn ->
     dgAnn -> dgZnn -> dgann -> dgznn ->
     dzAnn -> dzZnn -> dzann -> dzznn ->
     daAnn -> daZnn -> daann -> daznn ->
     deAnn -> deZnn -> deann -> deznn ->
     dAAnn -> dAZnn -> dAann -> dAznn ->
     dZAnn -> dZZnn -> dZann -> dZznn

  There is now support for the HP extensions:
  (Courtesy of Richard Hart USG <[EMAIL PROTECTED]>,
    who sent me the following information)

     Summary of HP's Extensions to RFC-1179
     
     1. 4-Digit Job Numbers
     HP preserves the System V-style 4-digit sequence number, or job number, in
     file names and attributes, while BSD uses 3-digit job numbers.
     
     2. Control and Data File Naming Conventions
     Control files are named in the following format:
        cA<seqn><host>
        <seqn> is the 4-digit sequence number (aka job number).
        <host> is the originating host name.
     The data file naming sequence format is:
         dA<seqn><host>   through   dZ<seqn><host>     followed by...
         da<seqn><host>   through   dz<seqn><host>     followed by...
         eA<seqn><host>   through   eZ<seqn><host>     followed by...
         ea<seqn><host>   through   ez<seqn><host>     ... etc. ...
     So the first data file name in a request begins with "dA", the second with
     "dB", the 27th with "da", the 28th with "db", and so forth.
     
     3. HP-Specific BSD Job Attributes (Control File Lines)
     The following control file lines are extensions of RFC-1179:
        R<login>
           Write to the named login's terminal when the job is complete.  This is
           an alternate to the RFC-1179-style e-mail completion notification.
           This notification is selected via the lp "-w" option.
  -- R line -> M line
        A<priority>
           Specifies the System V-style priority of the request, a single digit
           from 0-7.
  -- A value -> priority
        N B<banner>
           Note that this line begins with an "N", a space, and then a "B".  The
           argument is the banner page title requested via the lp "-t" option.  If
           that option was not given then the argument is null.
  -- banner -> T banner
        N O<options>
           Note that this line begins with an "N", a space, and then an "O".  The
           argument contains the System V-style "-o" options specified in the lp
           command line.  The option names appear without a leading "-o".  The
           first option name begins in the fourth character of the line; each
           option is separated by a blank.  If no "-o" options were given then the
           argument is null.
  -- <options> -> appended to Zvalue <options>

     The following control file lines are generated differently than in standard
     BSD:
        J<jobname>
           The argument is the System V-style request-ID, for example,
           "printer-42".  Note that leading zeros are not present in the sequence
           number.  If a System V-style title is requested then it is sent using a
           "N B" attribute, and not the "J" attribute.

  There is now a new and improved error message for fumble fingers:
   h4: {1185} % lpq -Pxx
   Printer: xx@h4 - ERROR: spool queue for 'xx' does not exist on server h4.private
      non-existent printer or you need to run 'checkpc -f'
   h4: {1186} % lprm -Pxx
    ERROR: spool queue for 'xx' does not exist on server h4.private
      non-existent printer or you need to run 'checkpc -f'
   h4: {1187} % lpc -Pxx status
    Printer           Printing Spooling Jobs  Server Subserver Redirect Status/(Debug)
   xx@h4: spool queue for 'xx' does not exist on server h4.private
      non-existent printer or you need to run 'checkpc -f'
   I hope that this cuts down on the problems reported by people who do not
   RTFM about 'checkpc -f'.

  I have added code to track the maximum open file descriptor so that
    the 'cleanup' code is a little more intelligent.

Patrick Powell                 Astart Technologies,
[EMAIL PROTECTED]            9475 Chesapeake Drive, Suite D,
Network and System             San Diego, CA 92123
  Consulting                   858-874-6543 FAX 858-279-8424 
LPRng - Print Spooler (http://www.astart.com)

-----------------------------------------------------------------------------
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.
-----------------------------------------------------------------------------

Reply via email to