PROPOSAL: New Online Responder Architecture

[Francis J. Lacoste]

Since release 20020415, Lire is now able to send reports by email in
other format than ASCII. It would be really interesting if we could
integrate this functionality to the online responder. I'll first outline
the current problems with the architecture and then outline my proposal
on how to fix those problems.

Current problems of the responder architecture:

1- Only ASCII format is supported.
2- Online responder is somewhat hard to install because
	a) No automatic setup: you need to create the spool directories
	   and setup the deliveries manually.
	b) Need to configure MTA/MDA to deliver to pseudo-maildir which
	   isn't common things users have to do.
	c) lr_spoold isn't a regular daemon
3- There's no real user accounting: i.e. a reliable way to track the 
various submissions to a particular user. That will be important once
merging is implemented to be able to send "merged" reports to the user.
We used to use the subject of the message for this purpose, but I don't
think this is reliable. Since the last release, we use the submitter's
address for that purpose.

4- We need to integrate the responder backend with other possible frontends 
like the HTTP upload form.

To solve those problems, I propose the following architecture for the
new responder.

The basic architecture would still be a daemon (lr_spoold) which
monitors a spool directory for jobs. The main difference would be that
this directory doesn't contains Maildir format mailbox containing
incoming messages but job control files similar to sendmail.

Those job control files would contains all necessarary information for
the job: superservice, service, submitter and path to log file or
path to email message, requested output format.

The entry point to the spool directory would be a lr_spool command
(nothing to do with the current lr_spool command). This command would
read a log file or email message on standard input and would create
a proper control file in the spool directory. For security, all the job
information (except the paths to email/log file which will be created by
the lr_spool command itself) will be taken from _the command line_
arguments. 

This means that for a email responder installation, the only
configuration needed would only to setup aliases for proper program
delivery (which is common across most MTA):

cisco-html: "|lr_spool -i -o html firewall cisco"
cisco-anon: "|lr_spool -o xml  firewall cisco"
cisco:      "|lr_spool firewall cisco"

Advantage of this kind of setup for the email responder are:
	- Easier setup (aliases can even be automatically generated)
	- Only configured aliases are accessible (no way to generate
	  a PDF report if it is not to be offered).
	- Altough a program is executed on each request, it's tasks
	  are really simple and performance shouldn't suffer too much.
etc.

The HTTP responder could just exec lr_spool with the proper parameters
to spool a job to the responder (instead of sending it by email like it
does now).

An initial version of this architecture isn't hard at all to implement.
This also becomes extensible since the job control file could contains 
new parameters. Also, command could update the job control file to store
other job related information. We could also eventually add a lr_status
command which could be used to query the status of a submitted job.

The other issue left is the user accounting issue. I'll only say that
the user accounting stuff will be relatively easy to integrate with the
job control file idea. But there are other issues relating to this issue
(configuration and archive mainly) that makes it better to treat in a separate
proposal.

Francis J. Lacoste

-- 
Francis J. Lacoste              . .           http://www.logreport.org
/^LogReport$/               . .               flacoste at logreport.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
Url : http://lists.logreport.org/pipermail/development/attachments/20020421/09d45288/attachment.bin