You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Ben Laurie <be...@algroup.co.uk> on 2003/12/29 14:39:28 UTC
Forensic Logging
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.
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!
I also include a script that parses the log and reports on incomplete
requests.
I propose that we should include this as a standard module. I think we
should also enable it by default. The 1.3 module and script are enclosed
for review. I'm about to embark on porting it to 2.x.
As always, comments/questions welcome.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: Forensic Logging
Posted by André Malo <nd...@perlig.de>.
* "David Reid" <da...@jetnet.co.uk> wrote:
> > Colm MacCarthaigh wrote:
> >
> > > On Mon, Dec 29, 2003 at 01:39:28PM +0000, 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!
> > >
> > > Cool, extremely useful in a lot of circumstances. Just one or two
> > > questions though. Is next_id deliberately random? It doesn't seem
> > > to get initialised anywhere, though that may be a feature.
> >
> > Static variables are initialised to zero.
>
> That's not true on all platforms, sadly :(
It's not platform dependent but compiler dependent, since it's a C standard
compliance thing. I'm wondering if someone uses a compiler, which breaks
half of the software out there?
nd
Re: Forensic Logging
Posted by Ben Laurie <be...@algroup.co.uk>.
David Reid wrote:
>>Colm MacCarthaigh wrote:
>>
>>
>>>On Mon, Dec 29, 2003 at 01:39:28PM +0000, 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!
>>>
>>>Cool, extremely useful in a lot of circumstances. Just one or two
>>>questions though. Is next_id deliberately random? It doesn't seem
>>>to get initialised anywhere, though that may be a feature.
>>
>>Static variables are initialised to zero.
>
> That's not true on all platforms, sadly :(
Then those platforms are broken. K&R, ed. 2, A8.7 p.219:
"A static object not explicitly initialized is initialized as if it (or
its members) were assigned the constant 0."
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: Forensic Logging
Posted by David Reid <da...@jetnet.co.uk>.
> Colm MacCarthaigh wrote:
>
> > On Mon, Dec 29, 2003 at 01:39:28PM +0000, 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!
> >
> > Cool, extremely useful in a lot of circumstances. Just one or two
> > questions though. Is next_id deliberately random? It doesn't seem
> > to get initialised anywhere, though that may be a feature.
>
> Static variables are initialised to zero.
That's not true on all platforms, sadly :(
david
Re: Forensic Logging
Posted by Ben Laurie <be...@algroup.co.uk>.
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?
>
> /me sees a previous problem in a different form...
>
> Hey Ben, wouldn't it be nice to be able to use the apr uuid functions
> now?
Umm. Yes? Of course, that's problematic in 1.3 - roll on 1.4!
As you know, the barrier is select(). I'm beginning to think we should
just make the API for select, we know what its got to look like, and let
Windoze catch up when it can. Or mark it experimental and subject to change.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: Forensic Logging
Posted by Sander Striker <st...@apache.org>.
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 previous problem in a different form...
Hey Ben, wouldn't it be nice to be able to use the apr uuid functions
now?
Sander
Re: Forensic Logging
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Tue, Dec 30, 2003 at 06:52:07PM +0000, 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 does indeed :)
> Well, the most obvious answer is to prepend a box id, which could either
> be done when I generate the logs or when you collate them.
... which is getting more and more like the mod_unique_id approach,
which is why I think they may well be worth consolidating. Purely from
an avoiding replication point-of-view, but also from a tracability point
of view. Imagine a mod_[php|perl|script] is used to own a machine,
it would be super-useful if that scripts logs could correlated with
the forensic logs easily.
So I might see an incomplete request in the forensic log, I can take
the forensic_id, and grep for it in my script logs and perhaps get more
details there.
But I guess if you feel the special uuencode overhead is overkill for
a forensic_id (which is unlikely to ever have to be in a URL), then
o.k. - leave it out by default.
> >Though if mod_unique_id can be used if present that'll solve any
> >problems I'd have :)
>
> I can easily do that in 2.0 - I can call a "give me a unique ID" hook,
> and if mod_unique ID is present, it can give me its. I could also do it
> by making sure mod_unique_id is run first if present and fishing the ID
> out of the environment, though that's a bit tacky.
The first option, and adding a new conversion specification for
having the mod_unique_id id in a log string would definitely
be a solution that would scale well (think 20-node clusters
using syslog!).
So I guess in summary; 1) No matter what, there should be some means of
the forensic ID being unique accross cluster nodes, which is trivial to do
:) 2) It'd be supercool to be able to log the unique_id for tracability.
> >Actually that reminds me, these days mod_unique_id's algorithim isn't
> >clever enough for some systems which use L4 switching or anycast
> >balancing, I have an experimental patch here somewhere which can help
> >fix that, must submit it.
>
> I'd advocate making the unique bit configurable, that must surely fix it
> in all cases?
Yep, well excepting for the lousy-admin case, I'll dig out the patch
- I was using it to get around the IPv6 messiness a long time ago.
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: Forensic Logging
Posted by Ben Laurie <be...@algroup.co.uk>.
Colm MacCarthaigh wrote:
> On Tue, Dec 30, 2003 at 11:49:37AM +0000, 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 the environment variable. That way a developer can
>>>use the same id to track ingress, processing and egress.
>>
>>Well, it would be possible to make it use the unique ID if present. I'm
>>not in favour of requiring it, though, because it appears add a good
>>deal of unnecessary overhead.
>
> 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's not unusual to be dealing
> with many millions of requests per day in a single logfile. From a cursory
> check here; accross 4 boxes, with a total of 17,000 httpd processes,
> only 3,000 pids are unique. With about 80 requets/sec, that gives me a
> probability of about 1/30625 of a request going to two different machines
> but getting the same pid within one second. Unless I'm reading it wrong,
> the bounds of next_id is more or less a function of MaxRequestsPerChild,
> in my example - it's set to 20, so I can expect a mess-up once every
> 612,500 requests, that's a bit of a pain :/
Well, the most obvious answer is to prepend a box id, which could either
be done when I generate the logs or when you collate them.
> But more than that, it still seems confusing to have two different methods
> of achieving the same task. If mod_unique_id is too much overhead, then
> it needs to be rewritten. To my mind, both modules need to generate
> reliable unique id's for request tracking purposes. Now either there's
> a good way of doing that, or there's not - but having two different
> methods and defining two different levels of uniqueness doesn't make
> sense to me. I have mod_unique_id turned on for my servers, and don't
> notice much overhead. MTA's like exim, postfix and so on have even more
> complicated means of generating unique message id's, and they achieve
> excellent throughput.
>
> Though if mod_unique_id can be used if present that'll solve any
> problems I'd have :)
I can easily do that in 2.0 - I can call a "give me a unique ID" hook,
and if mod_unique ID is present, it can give me its. I could also do it
by making sure mod_unique_id is run first if present and fishing the ID
out of the environment, though that's a bit tacky.
>>>Or at least, could a host-specific part be added to the forensic id?
>>>A lot of people collate logs (myself included ;) from clusters or whatever
>>>and this would make life much easier there.
>>
>>Hmmm. You should only be looking at requests that didn't complete, and
>>since it includes the whole header, the host is in there anyway.
>
>
> The headers arnt host-specific in a cluster, since typically each
> node is configured to answer for the same hostname. mod_unique_id
> uses apr_gethostname and the ip address of the node to get around this
> problem :)
I had the wrong end of the stick.
> Actually that reminds me, these days mod_unique_id's algorithim isn't
> clever enough for some systems which use L4 switching or anycast
> balancing, I have an experimental patch here somewhere which can help
> fix that, must submit it.
I'd advocate making the unique bit configurable, that must surely fix it
in all cases?
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: Forensic Logging
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Tue, Dec 30, 2003 at 11:49:37AM +0000, 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 the environment variable. That way a developer can
> >use the same id to track ingress, processing and egress.
>
> Well, it would be possible to make it use the unique ID if present. I'm
> not in favour of requiring it, though, because it appears add a good
> deal of unnecessary overhead.
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. It's not unusual to be dealing
with many millions of requests per day in a single logfile. From a cursory
check here; accross 4 boxes, with a total of 17,000 httpd processes,
only 3,000 pids are unique. With about 80 requets/sec, that gives me a
probability of about 1/30625 of a request going to two different machines
but getting the same pid within one second. Unless I'm reading it wrong,
the bounds of next_id is more or less a function of MaxRequestsPerChild,
in my example - it's set to 20, so I can expect a mess-up once every
612,500 requests, that's a bit of a pain :/
But more than that, it still seems confusing to have two different methods
of achieving the same task. If mod_unique_id is too much overhead, then
it needs to be rewritten. To my mind, both modules need to generate
reliable unique id's for request tracking purposes. Now either there's
a good way of doing that, or there's not - but having two different
methods and defining two different levels of uniqueness doesn't make
sense to me. I have mod_unique_id turned on for my servers, and don't
notice much overhead. MTA's like exim, postfix and so on have even more
complicated means of generating unique message id's, and they achieve
excellent throughput.
Though if mod_unique_id can be used if present that'll solve any
problems I'd have :)
> >Or at least, could a host-specific part be added to the forensic id?
> >A lot of people collate logs (myself included ;) from clusters or whatever
> >and this would make life much easier there.
>
> Hmmm. You should only be looking at requests that didn't complete, and
> since it includes the whole header, the host is in there anyway.
The headers arnt host-specific in a cluster, since typically each
node is configured to answer for the same hostname. mod_unique_id
uses apr_gethostname and the ip address of the node to get around this
problem :)
Actually that reminds me, these days mod_unique_id's algorithim isn't
clever enough for some systems which use L4 switching or anycast
balancing, I have an experimental patch here somewhere which can help
fix that, must submit it.
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: Forensic Logging
Posted by Ben Laurie <be...@algroup.co.uk>.
Colm MacCarthaigh wrote:
> On Mon, Dec 29, 2003 at 01:39:28PM +0000, 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!
>
> Cool, extremely useful in a lot of circumstances. Just one or two
> questions though. Is next_id deliberately random? It doesn't seem
> to get initialised anywhere, though that may be a feature.
Static variables are initialised to zero.
> 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 the environment variable. That way a developer can
> use the same id to track ingress, processing and egress.
Well, it would be possible to make it use the unique ID if present. I'm
not in favour of requiring it, though, because it appears add a good
deal of unnecessary overhead.
> Or at least, could a host-specific part be added to the forensic id?
> A lot of people collate logs (myself included ;) from clusters or whatever
> and this would make life much easier there.
Hmmm. You should only be looking at requests that didn't complete, and
since it includes the whole header, the host is in there anyway.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: Forensic Logging
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Mon, Dec 29, 2003 at 01:39:28PM +0000, 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!
Cool, extremely useful in a lot of circumstances. Just one or two
questions though. Is next_id deliberately random? It doesn't seem
to get initialised anywhere, though that may be a feature.
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 the environment variable. That way a developer can
use the same id to track ingress, processing and egress.
Or at least, could a host-specific part be added to the forensic id?
A lot of people collate logs (myself included ;) from clusters or whatever
and this would make life much easier there.
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: Forensic Logging
Posted by Ben Laurie <be...@algroup.co.uk>.
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 1.3.(n-1) release?
>
> (I don't feel very strongly about it; it just seems like the right
> approach to me; over and out)
I guess if its disabled by default it doesn't hurt much to have it also
not compiled by default.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: Forensic Logging
Posted by Jeff Trawick <tr...@attglobal.net>.
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 don't feel very strongly about it; it just seems like the right approach to
me; over and out)
Re: Forensic Logging
Posted by Ben Laurie <be...@algroup.co.uk>.
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. Might be useful
>>>> to enable this function by default in a mode where it records
>>>> information in an in-process buffer that can easily be sniffed out
>>>> of a core file (tag the buffer with an eye catcher).
>>>
>>>
>>>
>>>
>>> Hmmm. The information is easily retrieved from the request structure,
>>> why not just find that?
>>>
>>
>> It can be difficult to find the request that caused the problem in a
>> threaded mpm.
>>
>> Bill
>>
> More explanation needed... I've seen too many core dumps with unusable
> backtraces due to stack corruption (nearly always traced to code for
> which I don't have the source, unfortunately). So, yea this idea is
> probably a bit out of scope for mod_forensic. Just thinking out loud.
There's certainly a variant on it that does what you describe, yeah. Not
really the same thing, though.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: Forensic Logging
Posted by Bill Stoddard <bi...@wstoddard.com>.
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
>>> enable this function by default in a mode where it records
>>> information in an in-process buffer that can easily be sniffed out of
>>> a core file (tag the buffer with an eye catcher).
>>
>>
>>
>> Hmmm. The information is easily retrieved from the request structure,
>> why not just find that?
>>
>
> It can be difficult to find the request that caused the problem in a
> threaded mpm.
>
> Bill
>
More explanation needed... I've seen too many core dumps with unusable backtraces due to stack corruption
(nearly always traced to code for which I don't have the source, unfortunately). So, yea this idea is
probably a bit out of scope for mod_forensic. Just thinking out loud.
Bill
Re: Forensic Logging
Posted by Bill Stoddard <bi...@wstoddard.com>.
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 default in a mode where it records information in an
>> in-process buffer that can easily be sniffed out of a core file (tag
>> the buffer with an eye catcher).
>
>
> Hmmm. The information is easily retrieved from the request structure,
> why not just find that?
>
It can be difficult to find the request that caused the problem in a threaded mpm.
Bill
Re: Forensic Logging
Posted by Ben Laurie <be...@algroup.co.uk>.
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 default in a mode where it records information in an
> in-process buffer that can easily be sniffed out of a core file (tag the
> buffer with an eye catcher).
Hmmm. The information is easily retrieved from the request structure,
why not just find that?
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: Forensic Logging
Posted by Bill Stoddard <bi...@wstoddard.com>.
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 often than getting owned are the run-of-the-mill crashes,
>> where this would save a bit of time too
>
>
> Sure thing.
>
>>> I propose that we should include this as a standard module.
>>
>>
>> +1 (concept)
>
>
> Excellent, do I hear more?
>
+1 (concept)
>>
>>> I think we should also enable it by default.
>>
>>
>> then simply building new Apache with previous configure invocation
>> will result in this fresh piece of code inside the server writing
>> logs... this doesn't sound very safe to me ;)
>
>
> OK, I live in hope :-)
>
>> I think you should have to specify a log file name for it to do anything
>
>
> Agreed.
>
>> and:
>>
>> 2.1: fine with me if module is built/loaded by default
>>
>> 1.3, 2.0: I suggest enabling with --enable-modules={most|all} but not
>> by default
>
>
> 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 default in a mode where it records information in an
in-process buffer that can easily be sniffed out of a core file (tag the buffer with an eye catcher).
Bill
Re: Forensic Logging
Posted by Mads Toftum <ma...@toftum.dk>.
On Mon, Dec 29, 2003 at 07:57:09PM +0000, 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 anything
>
> Agreed.
>
> >and:
> >
> >2.1: fine with me if module is built/loaded by default
> >
> >1.3, 2.0: I suggest enabling with --enable-modules={most|all} but not by
> >default
>
> If it does nothing unless a file is specified, why not enable by default?
>
Yes, lets make it available in the default build even - that way it will be
simple for anyone who cares about security to enable the module, and for
those who don't care for the quite significant added overhead, it will be
easy to turn on if they suspect a problem.
vh
Mads Toftum
--
`Darn it, who spiked my coffee with water?!' - lwall
Re: Forensic Logging
Posted by Sander Striker <st...@apache.org>.
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
Re: Forensic Logging
Posted by Ben Laurie <be...@algroup.co.uk>.
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 owned are the run-of-the-mill crashes, where
> this would save a bit of time too
Sure thing.
>> I propose that we should include this as a standard module.
>
> +1 (concept)
Excellent, do I hear more?
>
>> I think we should also enable it by default.
>
> then simply building new Apache with previous configure invocation will
> result in this fresh piece of code inside the server writing logs...
> this doesn't sound very safe to me ;)
OK, I live in hope :-)
> I think you should have to specify a log file name for it to do anything
Agreed.
> and:
>
> 2.1: fine with me if module is built/loaded by default
>
> 1.3, 2.0: I suggest enabling with --enable-modules={most|all} but not by
> default
If it does nothing unless a file is specified, why not enable by default?
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: Forensic Logging
Posted by Jeff Trawick <tr...@attglobal.net>.
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 run-of-the-mill crashes, where this
would save a bit of time too
> I propose that we should include this as a standard module.
+1 (concept)
> I think we
> should also enable it by default.
then simply building new Apache with previous configure invocation will result
in this fresh piece of code inside the server writing logs... this doesn't
sound very safe to me ;)
I think you should have to specify a log file name for it to do anything and:
2.1: fine with me if module is built/loaded by default
1.3, 2.0: I suggest enabling with --enable-modules={most|all} but not by default