Hi,
I don't think this can/must be fixed on Koha side.
It's a sysadmin duty to take care of that.
I would take a look at fail2ban to parse the web server access logs. But
make sure not to block your X librarians using the same ip ;)
On Wed, 26 Oct 2016 at 12:28 Pedro Amorim
Hi!
If this is actually related to Zebra I wonder if the problem will persist when
the switch to Elasticsearch is made? And if so: is there anything that could be
done about it now while work is done on Elastic anyway? It’s always easier to
get it right from the start.
If I understand the
Just FYI, we run Koha behind the open source version of nginx, and it
has lots of flexibility for rate-limiting by client ip and doing
pretty sophisticated cache handling.
On Thu, Oct 27, 2016 at 7:50 AM, Pedro Amorim wrote:
> Hello all,
>
> As I said before, the Koha I'm
Hello all,
As I said before, the Koha I'm currently working on is behind a proxy
server, namely HAProxy (http://www.haproxy.org/).
My solution for this was adding the following lines in the frontend of my
haproxy.cfg:
# Table definition
stick-table type ip size 100k expire 30s store
Thank you to everyone who replied, I appreciate you taking the time.
I understand that this is not a Koha specific problem, I understand the
solution is a sys admin responsibility and I understand that there is
probably not a 'one size fits all' solution given the many different
system
Even though "sharing" is not obligatory, I had the impression that this
is a somewhat "sharing community".
If someone is willing he/she could share his solution-experience-howto
or what ever.
Probably this is the wrong place to ask for this kind of help ...
Look into places like SHOREWALL
Koha isn't offered 'out of the box'... there is extensive setup required
and the most basic portion(a webserver) is a requirement, and that would
be the responsibility of the server's administrator, not a function of a
Koha developer.
On 10/26/2016 5:52 AM, Philippe Blouin wrote:
I disagree.
I disagree. If Koha is offered out of the box, and we take time to fix
security issues, then it's normal for users to expect "basic" attacks to
be taken care of.
More so, blocking IP is not a possibility if genuine users are involved
using a station from within the library.
I'm not saying
Hi,
I don't think this can/must be fixed on Koha side.
It's a sysadmin duty to take care of that.
I would take a look at fail2ban to parse the web server access logs. But
make sure not to block your X librarians using the same ip ;)
On Wed, 26 Oct 2016 at 12:28 Pedro Amorim
I have tested this and the stress caused on the server is very severe. It
seems that for every request, a new zebra process is created and the server
will only respond when the last one is finished. This ofc will result in
time outs and eventually a crash in the server.
This is a major critical
I have had this issue appear today. I have attempted to set up
mod_evasive for apache but it doesn't seem to have solved the problem.
I would really appreciate some advice.
Clint.
rfblanchard wrote:
Assume a basic opac search:
Assume a basic opac search:
http:///cgi-bin/koha/opac-search.pl?q=dog_group_limit=branch%3A349
This would take about 10 seconds to return the first time.
Assume the user refreshes the results using f5 and keep there finger there a
moment to long (3s):
This would kill my server for about 1
12 matches
Mail list logo