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

List:       lprng
Subject:    Re: LPRng: Environment for filters
From:       Sam Noble <ns () shadow ! org>
Date:       2002-12-19 8:07:44
[Download RAW message or body]

	Yuck -- although I'm not sure that we're necessarily on the same
page. Certainly a filter itself executes at least once per job. 

http://www.lprng.com/LPRng-HOWTO-Multipart/filteroptions.htm

seems to indicate (in a manner consistent with my reading of the code)
that a filter is going to be given an environment where certain variables
contain certain data. For example, this part of the HOWTO says that the
filter's environment will contain values for CONTROL, DATAFILES, HOME,
IFS, LD_LIBRARY_PATH, LOGDIR, LOGNAME PATH, PRINTCAP_ENTRY, SHELL,
SPOOL_DIR, TZ, and USER. 

Some limited testing seems to indicate that CONTROL is in fact the
CONTENTS of the control file, rather than its name (as specified on the
web page).

	My proposal is not to take data from the environment of the LPRng
lpd process but rather to supply data from the job->info string/value list
into the environment of the filter process. If you're telling me that the
job data structure is not trustworthy, then I'm not really sure that ANY
data that the filter receives can be used -- certainly not anything
from the control file, which gets given to the filter via this same
data member.

	I'm under the impression (not based on a close reading of the
code) that the job->info data comes from another file in the queue (not
the control file). If the job itself is in dfA###<hostname>, the control
file is cfA###<hostname>, then this other data seems to live in hfA###

	As far as the existence of the control file is concerned, well,
hmmm. It seems to be a convenient place to store *user specified* job
settings, but not data you need to be able to know that you can trust.

	In any case, I'll look into it more tomorrow.

/* Sam */

On Wed, Dec 18, 2002 at 08:44:21PM -0500, Rick Cochran wrote:
> Sam,
> 
> Great goal.  Bad implementation.
> 
> Job reception is done by lpd which then starts a process to handle it. 
> That process will inherit the environment of the master daemon, however 
> if additional jobs get queued before it is finished with the first, it 
> will continue to process the additional jobs WITH THE SAME ENVIRONMENT.
> 
> The only safe way to pass data to a filter is through the control file. 
>   That's why it exists.
> 
> Unfortunately, there seem to be some constraints as to what sort of 
> things you can stick in the control file.  I'm a bit fuzzy on this, but 
> not fuzzy at all about using environment to pass data to filters.  Hurts 
> when you do that.
> 
> -Rick
> 
> Sam Noble wrote:
> > 	I want to write a routing filter which makes its decision based on
> > information about (primarily) the authentication state of a print job. Did
> > we receive it from a host we trust? From a reserved port? Is some sort of
> > "strong" authentication involved in the job submission (ie Kerberos)?
> > 
> > 	It seems that much of this information might be useful for any
> > filter (although I don't have a concrete example at the moment). A filters
> > environment gets initialized via the following:
> > 
> > Filter_file() --> Make_passthrough() --> Setup_env_for_process()
> > 
> > 	So if this information is to be made available to all filters, it
> > ought to be done in one of those places. My current thinking is in
> > Setup_env_for_process(). I am not overly familiar with the philosophy
> > behind the LPRng architecture, however one way I can see to accomplish my
> > goal is just to add Find_str_value()/Set_str_value() pairs.
> > 
> > 	I'd like such functionality to become a standard part of the LPRng
> > filter mechanism. To that end, if there is a more general way to get the
> > information I want, I'm willing to do a little more work to implement
> > it. If anybody (Patrick?) has a suggestion/comment, I'm interested in some
> > feedback.
> > 
> > 	I'm aware of the lpd.perms mechanism, but it is not useful for
> > redirecting a job. It may or may not be appropriate to try to extend the
> > permissions checking code.
> > 
> > /* Sam */
> > 
> > -----------------------------------------------------------------------------
> > 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 majordomo@lprng.com (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 majordomo@lprng.com
> > with:                           | example:
> > subscribe LIST <mailaddr>       |  subscribe lprng-digest myname@host.org
> > unsubscribe LIST <mailaddr>     |  unsubscribe lprng myname@host.org
> > 
> > If you have major problems,  send email to papowell@astart.com with the word
> > LPRNGLIST in the SUBJECT line.
> > -----------------------------------------------------------------------------
> > 
> 
> 
> -- 
> |Rick Cochran                                   phone: 607-255-7618|
> |Cornell CIT - Systems & Operations - Net-Print   FAX: 607-255-8521|
> |730 Rhodes Hall, Ithaca, N.Y. 14853        email: rcc2@cornell.edu|
> 
> 
> -----------------------------------------------------------------------------
> 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 majordomo@lprng.com (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 majordomo@lprng.com
> with:                           | example:
> subscribe LIST <mailaddr>       |  subscribe lprng-digest myname@host.org
> unsubscribe LIST <mailaddr>     |  unsubscribe lprng myname@host.org
> 
> If you have major problems,  send email to papowell@astart.com with the word
> LPRNGLIST in the SUBJECT line.
> -----------------------------------------------------------------------------

-----------------------------------------------------------------------------
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 majordomo@lprng.com (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 majordomo@lprng.com
with:                           | example:
subscribe LIST <mailaddr>       |  subscribe lprng-digest myname@host.org
unsubscribe LIST <mailaddr>     |  unsubscribe lprng myname@host.org

If you have major problems,  send email to papowell@astart.com with the word
LPRNGLIST in the SUBJECT line.
-----------------------------------------------------------------------------
[prev in list] [next in list] [prev in thread] [next in thread]