On 04/12/10 04:17, Devraj Mukherjee wrote:
Obviously you are not considering people using "proxies" get around IP
subnets. I would recommend the use of fail2ban and other tools like
that to block them on a per case basis, rather than blocking the whole
country off.
Since this is not an ethics li
On 04/03/2010 12:59 AM, Nick Kew wrote:
On 2 Apr 2010, at 22:29, The Gaijin wrote:
Why would you expect to find anything specific?
Past experience (and the ESR article the sign-up page points to) suggest
that in most cases, someone else has already encountered an issue, or
done what you're
Obviously you are not considering people using "proxies" get around IP
subnets. I would recommend the use of fail2ban and other tools like
that to block them on a per case basis, rather than blocking the whole
country off.
Since this is not an ethics list, I will leave this discussion here.
The we
Just to verify my suspicion about the payload I set the authorization header
to my name. It works well. I mean it went well fore small pay load.
However, with the token it determines that it is a bad request before it get
the full header.
An example of tcpdump
14:33:57.928844 IP blueye.cis.foo
On 04/10/10 13:53, Devraj Mukherjee wrote:
Hi Nilesh,
Deny and Allow option override can be globally configured as such
http://httpd.apache.org/docs/2.0/mod/core.html#allowoverride
I was wondering how and more importantly WHY you plan to block users
from particular countries?
On Wed, Apr 7, 20
will %{error-notes}n work on https too. I am asking it as I am getting
following statement in ssl_error.log
[Sun Apr 11 07:34:40 2010] [error] [client 192.168.128.122] request failed:
error reading the headers
[Sun Apr 11 07:34:40 2010] [debug] ssl_engine_kernel.c(1884): OpenSSL:
Write: SSL negoti
