[prev in list] [next in list] [prev in thread] [next in thread] 

List:       lprng
Subject:    Re: [LPRng] When is next version target date
From:       papowell () astart ! com
Date:       1999-03-22 21:58:32
[Download RAW message or body]

> From majordomo-owner@iona.com Mon Mar 22 12:24:09 1999
> From: jjaddiss@mmm.com
> To: lprng@iona.com
> Date: Mon, 22 Mar 1999 14:39:01 -0500
> Subject: [LPRng] When is next version target date
>
>
>
> We've been using LPRng and CTI-ifhp for several years and are quite happy
> with it. But we're now back-rev a bit (LPRng-3.2.6 and CTI-ifhp-2.1.9). I'm
> planning to upgrade to the latest and greatest to achieve Y2K complience
> but don't want to compile and test the current version if a new one is
> about to be released. I know that ifhp is rumored to be heading for a new
> release soon.
>
> I really appreciate all the work that you put into this package Patrick.
> It's been very useful to us in our mixed environment. I don't want to imply
> that I'm pushing for a new release - I'm absolutely not. But if these's one
> likely to happen soon it'd be helpful to know.
>
> Thanks - Justus Addiss
>
>
>

Right now I am trying to put out an interm (3.6.1) release that has a
fairly large number of changes.   I am stuck on getting some code tested
(I don't have the setup here to do this).

I also ran into some wierd porting issues with Solaris that stopped me
dead in my tracks - it appears that the GCC compiler does not set the
magic flags in the include files right - see my comments about curses.h.

Here is the working CHANGES for the next release.

Note that I am currently bringing the documentation up to the same rev level.

Release LPRng 3.6.1 Mon Mar 22 09:42:07 PST 1999

  This release is a total rewrite of the LPRng software and uses more
  dynamic memory allocation and as few static variables as possible.
  This is intended to simplify the porting of the LPRng software
  to a multi-threaded environment. In addition,  substantial
  cleanup of much of the code was done.

  Due to time constraints,  some functionality that is present in other
  test versions was not put into this release.  This includes
  setting user information by originating IP address.
  The 4.x.x release will have support for the new IPP print protocol,
  SNMP MIB,  and a HTTP server interface.

  As far as possible, existing functionality has been preserved,
  with the following notable exceptions.  These are divergent enough
  to cause a new major release number to be used, i.e. - 3.6.x

  License

    Due to various technical legal reasons,  the License for this
  release of LPRng has been changed from the GNU to the slightly
  different but similar in intent Public.license.

    The main intent of this license was to allow several different
  versions of LPRng to exist,  some with proprietary software,
  that could be distributed and not have the proprietary software
  fall under terms of the GNU license.   Note that distributing
  LPRng with other operating systems,  binary distributions,  etc.,
  is still permitted, and in fact encouraged.

  Load Balance Queues and Class types

    Assume: a load balance queue with several printers, say
       master -> S1, S2;
    You can now set the class types accepted by S1 and S2, and
    the Master Queue will check the job types against the class
    types before sending the job to the appropriate queue.

    What is this all about? If S1 has blue paper you can set the
  currently printing class to blue (lpc class blue).

    Now do lpr -Pmaster -Cblue and your job will be routed to printers
  which currently are printing class 'blue'.  Clearly this can be
  extended to other things besides paper.

    Note that when you use this option you should set the master
  queues ignore_requested_user_priority flag so that the first
  letter of the class type is not used as the priority.

  Bounce Queues and LPR Side Filtering

    The entire job is passed through the various filters,
  and the entire output is now sent as a single file to the
  next queue.  The format of this file is set by the
  bq_output=X option.
    This now allows the full use of leaders, trailers,
  banner page generation, etc., to be used.
    You can also set bounce queue with the :lpd_bounce printcap
  flag,  instead of using bq=pr@host.

  Permissions List File:
    You can now say XXX=<filename and the whitespace separated
  contents of the file are used as the options value.

  Example:
    ACCEPT REMOTEHOST=</usr/local/etc/lpd_hosts
   and have /usr/local/etc/lpd_hosts contain:

    *.site.com
    10.0.0.1/24  pc.*.mystuff.org

  LPC Permissions Checking

  You can now use:
    ACCEPT LPC=hold,remove,topq
  If you are doing an LPC operation, then this matches the operation.
  This replaces the lpc_user=.... printcap abomination.

  For example, to allow user X on the server to do hold operations,
  use:

    ACCEPT LPC=hold USER=x SERVER

  The 'ms', 'sy' and 'ty' serial port configuration options are now
  the single option 'stty' which makes more sense and is compatible
  with other LPRng software.

  The 'rt' and 'send_try' options were accidentally aliased - removed
  the 'rt'.

  There is now finer control for remote LPQ queries.

   force_lpq_status=KEY=hostlist;KEY=hostlist
     Specifies a set of hosts and the format for lpq status queries,
     overridding the requested format.
      KEY = l (long) or s (short)
      hostlist = list of IPaddress/Mask or GLOB patterns for hostnames
     Example:  force_lpq_status=s=*pc.site.com,10.0.25.0/24;l=sunsystem.site.com

   reverse_lpq_format=hostlist
     Reverse l and s query formats when a request arrives from these
     hosts.

   return_short_status=hostlist
     Return short_status_length status lines when a request arrives from
     these hosts

  short_status_length=N
     Number of status lines to return when return_short_status matched
     

  AUTHENTICATION

     The entire authentication interface has been redone,  and PGP,
  Kerberos 5, and MIT Kerberos 4 Print System compatibility has
  been added.  The permissions checking method has been changed as
  follows,  with respect to the following keys:
    AUTH       match or TRUE  if authenticated transfer done
    AUTHTYPE   matches the authentication type
    AUTHUSER   client or user's authentication id
    AUTHFROM   originating server's authentication id when forwarding job
    AUTHSAMEUSER   match if the client id in the request and the
               (saved) client ID used to spool a job are identical.

  Options have been redone to put a bit of consistency into things

    auth=xxx                   authentication type for client to server
    auth_client_filter=/path   client to server authentication filter
    auth_forward=xxx           authentication type for forwarding
    auth_forward_id=xxx        authentication id for remote end when forwarding
    auth_forward_filter=/path  server to server authentication remote server id
    auth_recieve_filter=/path  server filter to recieve authentication
    auth_server_id=xxx         client to server - id of server
                               receiving server - id for reception
                               server to server - id for origination
    pgp_path=/path     path to pgp program for auth=pgp
    pgp_passphrase=clientkey   file in $(PGPPATH) or $(HOME)/.pgp
                               holding client passphrase
    pgp_server_key=~daemon/.pgp/serverkey   file holding LPD server passphrase

  Bug fixes:
    Gadzillions.  Many.  Some were not bugs but simply inconsistencies with
  documentation.  Sometimes documentation changed, sometimes the code.


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

[prev in list] [next in list] [prev in thread] [next in thread]