Trac/SVN services are down. The problem VM seems to be "TracsvnVM" https://wiki.osgeo.org/wiki/TracsvnVM
-jeff
--
Jeff McKenna
President Emeritus, OSGeo Foundation
http://wiki.osgeo.org/wiki/Jeff_McKenna
I cannot access tracsvn(dot)osgeo(dot)osuosl(dot).org I will request a reboot of this VM from the OSUOSL team.
-jeff
On 2017-01-06 10:40 AM, Jeff McKenna wrote:
Trac/SVN services are down. The problem VM seems to be "TracsvnVM"
https://wiki.osgeo.org/wiki/TracsvnVM-jeff
On Jan 6, 2017 4:10 PM, “Jeff McKenna” <jmckenna@gatewaygeomatics.com> wrote:
I cannot access tracsvn(dot)osgeo(dot)osuosl(dot).org I will request a reboot of this VM from the OSUOSL team.
Maybe just the internet connection is down? It happened a few times recently.
Markus
On 2017-01-06 11:39 AM, Markus Neteler wrote:
I cannot access tracsvn(dot)osgeo(dot)osuosl(dot).org I will
request a reboot of this VM from the OSUOSL team.
Maybe just the internet connection is down? It happened a few times
recently.
Could be. But they didn't announce issues through their announce list or IRC or Twitter. I've been given a ticket ID for this.
-jeff
The OSUOSL team rebooted the tracsvn VM. Trac/SVN back online.
-jeff
On 2017-01-06 10:40 AM, Jeff McKenna wrote:
Trac/SVN services are down. The problem VM seems to be "TracsvnVM"
https://wiki.osgeo.org/wiki/TracsvnVM-jeff
Hi,
2017-01-06 17:25 GMT+01:00 Jeff McKenna <jmckenna@gatewaygeomatics.com>:
The OSUOSL team rebooted the tracsvn VM. Trac/SVN back online.
thanks! Martin
--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
On Fri, Jan 06, 2017 at 12:25:24PM -0400, Jeff McKenna wrote:
The OSUOSL team rebooted the tracsvn VM. Trac/SVN back online.
From the logs it seems that Apache and fail2ban were both killed by the
OOM Killer between 06:28 and 06:49 PST (should be UTC-8).
Not sure what was going wrong.
--strk;
On Fri, Jan 06, 2017 at 10:31:18PM +0100, Sandro Santilli wrote:
On Fri, Jan 06, 2017 at 12:25:24PM -0400, Jeff McKenna wrote:
> The OSUOSL team rebooted the tracsvn VM. Trac/SVN back online.From the logs it seems that Apache and fail2ban were both killed by the
OOM Killer between 06:28 and 06:49 PST (should be UTC-8).Not sure what was going wrong.
Looking at the server today, as it was being slow, I see
requests taking lots of CPU time made to these trac.osgeo.org
URI:
/mapguide/browser/trunk?rev=9112&format=zip HTTP/1.1
/mapguide/browser/trunk?rev=5605&format=zip HTTP/1.1
The first one results in ~40MB of transfer and is requested
multiple times per minute by the same IP with no Referer and
a MSIE 7.0 user agent.
Should we disable zip downloads ?
https://groups.google.com/forum/#!topic/trac-users/pWXR6Ib59NM
--strk;
On Jan 7, 2017 6:08 PM, “Sandro Santilli” <strk@kbt.io> wrote:
On Fri, Jan 06, 2017 at 10:31:18PM +0100, Sandro Santilli wrote:
On Fri, Jan 06, 2017 at 12:25:24PM -0400, Jeff McKenna wrote:
The OSUOSL team rebooted the tracsvn VM. Trac/SVN back online.
From the logs it seems that Apache and fail2ban were both killed by the
OOM Killer between 06:28 and 06:49 PST (should be UTC-8).Not sure what was going wrong.
Looking at the server today, as it was being slow, I see
requests taking lots of CPU time made to these trac.osgeo.org
URI:/mapguide/browser/trunk?rev=9112&format=zip HTTP/1.1
/mapguide/browser/trunk?rev=5605&format=zip HTTP/1.1The first one results in ~40MB of transfer and is requested
multiple times per minute by the same IP with no Referer and
a MSIE 7.0 user agent.
That could be solved with a fail2ban filter.
Should we disable zip downloads ?
Please no.
At least not for all trac instances. AFAIK the GRASS GIS add-on management needs it.
Markus
On Sat, Jan 07, 2017 at 06:30:20PM +0100, Markus Neteler wrote:
On Jan 7, 2017 6:08 PM, "Sandro Santilli" <strk@kbt.io> wrote:
> /mapguide/browser/trunk?rev=9112&format=zip HTTP/1.1
> /mapguide/browser/trunk?rev=5605&format=zip HTTP/1.1
>
> The first one results in ~40MB of transfer and is requested
> multiple times per minute by the same IP with no Referer and
> a MSIE 7.0 user agent.That could be solved with a fail2ban filter.
Could you give it a try ?
The logs show that the transfer size is different for the different
downloads, so maybe the client interrupts before end of operations
--strk;
On Sun, Jan 8, 2017 at 1:00 PM, Sandro Santilli <strk@kbt.io> wrote:
On Sat, Jan 07, 2017 at 06:30:20PM +0100, Markus Neteler wrote:
On Jan 7, 2017 6:08 PM, "Sandro Santilli" <strk@kbt.io> wrote:
> /mapguide/browser/trunk?rev=9112&format=zip HTTP/1.1
> /mapguide/browser/trunk?rev=5605&format=zip HTTP/1.1
>
> The first one results in ~40MB of transfer and is requested
> multiple times per minute by the same IP with no Referer and
> a MSIE 7.0 user agent.That could be solved with a fail2ban filter.
Could you give it a try ?
The logs show that the transfer size is different for the different
downloads, so maybe the client interrupts before end of operations
.. this case we cannot catch. AFAIK we could only block that IP.
Perhaps not what we want?
Markus