Re: Log file and databases

[Randy Terbush <ra...@dsndata.com>]

>    I have implemented a Perl-CGI approach and can log the CGI
>    environment to dbm logfiles.  However this requires the
>    index.cgi approach in every directory.
> 
> Hmmm... if external Perl code is involved, I'm not sure how requests
> which don't go through some external CGI script get logged.  

Exactly, which is why the overhead could be severe. The Perl "Minisvr"
app mentioned below would be a way to have a "small" server process
following the session and logging requests, etc..  Here again, not
cheap.


>    With some recent discussion regarding logging and security issues,
>    would it not make sense to let the parent process running as root
>    handle all of the logging? (non-forker)
> 
> This would be a potential bottleneck.  (Besides which, one nice
> feature of the current non-forking code is that the parent process,
> which runs as root, is not involved in handling transactions at all;
> this makes it simply impossible for skillfully constructed requests to
> abuse its privileges).

Naive question warning:
Would it not be possible for the children to open a socket back to the
parent for logging transactions?

It has been mentioned before that the parent doesn't really have much
to do asside from handing jobs to the children.

IF this could be done, this would possibly solve some of the current
security issues. It would be relativly easy to write the logging
modules for different database formats.


>    Related to the Perl-CGI approach, there is an interesting API
>    developing that can spawn "Minisvr" processes to provide some
>    statefulness to the session. Comments?
> 
> Don't know about this.  References?

This is a Perl5 dynamic module. There has been some reference
to it on Roy's cgi-lib mailing list.  I understand that the current
source can be found at http://web.nexor.co.uk/contrib/perl/.
Nexor is unreachable so I cannot verify that.

>    Should the logger be a separate program?
> 
> I would prefer for it not to be --- it's more efficient to have the
> processes serving requests write whatever they would have written to
> the "separate logger" to a flat file instead, and to process the
> contents of that file off-line.

Which might be the argument for feeding the data to the database
through a named pipe or something.