Sander Striker wrote:
On Tue, 2003-12-30 at 19:52, Ben Laurie wrote:
I realise that having the value of getpid() and time() to hand is useful
for forensic purposes, but a getpid():time():next_id++ will result in
duplicates accross even small clusters.
Ah, I see :-) does mod_unique_id handle that?
Jeff Trawick wrote:
Ben Laurie wrote:
If it does nothing unless a file is specified, why not enable by default?
to avoid silent growth in the set of code built into somebody's
server... when does somebody have to add --disable-foo to create a
build compatible with what they had with the
Colm MacCarthaigh wrote:
On Mon, Dec 29, 2003 at 01:39:28PM +, Ben Laurie wrote:
So, I've written a forensic logging module. What this does is log the
request as soon as all the headers have been read, then log again when
its complete. Any request that doesn't complete should be viewed
Colm MacCarthaigh wrote:
On Mon, Dec 29, 2003 at 01:39:28PM +, Ben Laurie wrote:
So, I've written a forensic logging module. What this does is log the
request as soon as all the headers have been read, then log again when
its complete. Any request that doesn't complete should be
* David Reid [EMAIL PROTECTED] wrote:
Colm MacCarthaigh wrote:
On Mon, Dec 29, 2003 at 01:39:28PM +, Ben Laurie wrote:
So, I've written a forensic logging module. What this does is log the
request as soon as all the headers have been read, then log again when
its complete.
David Reid wrote:
Colm MacCarthaigh wrote:
On Mon, Dec 29, 2003 at 01:39:28PM +, Ben Laurie wrote:
So, I've written a forensic logging module. What this does is log the
request as soon as all the headers have been read, then log again when
its complete. Any request that doesn't complete
On Tue, Dec 30, 2003 at 11:49:37AM +, Ben Laurie wrote:
Could the forensic_id be tied in with mod_unique_id? It seems confusing
to have two different methods to generate unique id's for requests. Also
with unique_id, I can see it being useful to make CGI's aware of their
tracking code via
Ben Laurie wrote:
Bill Stoddard wrote:
Ben Laurie wrote:
If it does nothing unless a file is specified, why not enable by
default?
Like Jeff, I am more interested in this for debugging process crashes
that are not necessarily related to attacks. Might be useful to enable
this function by
Bill Stoddard wrote:
Ben Laurie wrote:
Bill Stoddard wrote:
Ben Laurie wrote:
If it does nothing unless a file is specified, why not enable by
default?
Like Jeff, I am more interested in this for debugging process crashes
that are not necessarily related to attacks. Might be useful to
Bill Stoddard wrote:
Bill Stoddard wrote:
Ben Laurie wrote:
Bill Stoddard wrote:
Ben Laurie wrote:
If it does nothing unless a file is specified, why not enable by
default?
Like Jeff, I am more interested in this for debugging process
crashes that are not necessarily related to attacks.
Colm MacCarthaigh wrote:
On Tue, Dec 30, 2003 at 11:49:37AM +, Ben Laurie wrote:
Could the forensic_id be tied in with mod_unique_id? It seems confusing
to have two different methods to generate unique id's for requests. Also
with unique_id, I can see it being useful to make CGI's aware of
On Tue, 2003-12-30 at 19:52, Ben Laurie wrote:
I realise that having the value of getpid() and time() to hand is useful
for forensic purposes, but a getpid():time():next_id++ will result in
duplicates accross even small clusters.
Ah, I see :-) does mod_unique_id handle that?
/me sees a
On Tue, Dec 30, 2003 at 06:52:07PM +, Ben Laurie wrote:
I realise that having the value of getpid() and time() to hand is useful
for forensic purposes, but a getpid():time():next_id++ will result in
duplicates accross even small clusters.
Ah, I see :-) does mod_unique_id handle that?
It
Ben Laurie wrote:
One of the problems that crops up depressingly often is that someone
gets owned, and they can't find out why. This is generally because the
offending request didn't get logged, because the server died before it
logged it.
far more often than getting owned are the
Jeff Trawick wrote:
Ben Laurie wrote:
One of the problems that crops up depressingly often is that someone
gets owned, and they can't find out why. This is generally because the
offending request didn't get logged, because the server died before it
logged it.
far more often than getting
Ben Laurie wrote:
Jeff Trawick wrote:
Ben Laurie wrote:
One of the problems that crops up depressingly often is that someone
gets owned, and they can't find out why. This is generally because
the offending request didn't get logged, because the server died
before it logged it.
far more
On Mon, Dec 29, 2003 at 07:57:09PM +, Ben Laurie wrote:
Jeff Trawick wrote:
+1 (concept)
Excellent, do I hear more?
fwiw +1 from me too. This is a valuable module, and I can't see any harm
in making it available.
I think you should have to specify a log file name for it to do
Ben Laurie wrote:
If it does nothing unless a file is specified, why not enable by default?
to avoid silent growth in the set of code built into somebody's server... when
does somebody have to add --disable-foo to create a build compatible with
what they had with the 1.3.(n-1) release?
(I
On Mon, Dec 29, 2003 at 01:39:28PM +, Ben Laurie wrote:
So, I've written a forensic logging module. What this does is log the
request as soon as all the headers have been read, then log again when
its complete. Any request that doesn't complete should be viewed with
great suspicion!
On Mon, 2003-12-29 at 20:57, Ben Laurie wrote:
Jeff Trawick wrote:
I propose that we should include this as a standard module.
+1 (concept)
Excellent, do I hear more?
Yes, +1 (concept). Actually, I'm in full agreement with Jeff on all
points ;).
Sander
20 matches
Mail list logo
