--On April 24, 2014 at 10:26:07 PM +0400 Maxim Dounin <mdounin@mdounin.ru>
wrote:

>> Yes, that is true, but why only implement a partial solution? With CGN,
>> only logging the IP is fairly useless in all cases. To truly get useful
>> information going forward, the IP + PORT of the client should logged in
>> all cases.
>
> Access log certainly can be configured to provide enough
> enformation to match any given error log message to a port if
> needed. There is no need to implement anything, solution is
> already here.

The error log currently only provides the IP. While I'm guessing you could
do things like correlate timestamps, it's still going to be a pain. Having
the port readily available everywhere makes tracking a specific user much
easier to do.

> And, by asking about "why implement a partical solution" you are
> overlooking the fact that proposed solution is partial as well -
> it doesn't change c->addr_text to ensure proper logging in all
> places (this would be a bad idea for other reasons, but it's
> another question), but rather tries to hack on the http error
> logging code to introduce remote port logging. This is far from
> being a complete solution.

I'm certainly willing to address any deficiencies, but I'd want to make
sure it would follow whatever you want in the product before investing more
time on it. ;) For now it meets the needs of our customer in Belgium who
has to start dealing with the legal requirements of client port logging
sooner than later.

--Quanah

--
Quanah Gibson-Mount
Server Architect
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration

_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel