Welcome! Log In Create A New Profile


Snippets from the reprap-admin list

Posted by Traumflug 
Snippets from the reprap-admin list
April 12, 2013 08:37AM
Administration of the reprap.org domain and its server is pretty well hidden so far. But it exists! There's a invitation-only reprap-admin mailing list and with the recent dropouts, this list became pretty active quickly. To give the RepRap community a better feeling about what happens, I'll post here a snippet from this list. With agreement from the list members, of course.


On 12 April 2013 14:47, bill2or3 wrote:

I did a round of server tuning, here are the changes I made:

- added robots.txt files to the wiki and forums, to tell msnbot, bingbot
and YandexBot not to request > 2 pages per minute. Those 3 bots combined
were accounting for *thirty percent* of the hits to the wiki, but
refer only a handful of visitors. This has made a huge difference.

- one-month 'Expires:' headers for the icon images on forums.reprap.org.
This will let those icons persist in client browser caches, across browser
restarts. Saves hits to the server, speeds up load times for return visitors.

- made the forum 'update viewcount' queries LOW_PRIORITY, so that actual
useful SELECT queries will happen first.

- set apache ssl session cache to the minimum size, 8k. It was set to
512k before, entirely unused. I think we can disable mod_ssl entirely,
which should free up a few megs.

- tiny fix to ReCaptcha.php, to avoid about 9 megs of errors messages per day
hitting /var/log/messages

The Munin cpu and network graphs are pretty flat since these changes.
Before, they were very inconsistent, occasionally spiking up by %400 or
just missing big chunks where the server was too busy to collect the graph

I'm guessing that what was happening was that bingbot came to visit,
from several different IP's at once. All those bingbot crawlers were hitting
forums, making lots of mostly identical requests. All those queries eventually
hit the 'messages' table, causing the sql table to lock, and grinding
everything to a crawl.

The graphs show that apache hits/apache traffic/ethernet traffic all dropped
by about 1/3, and CPU seems to have a lot more breathing room.

If nobody has any objections, I'd like to let it run for a few days, just to
be sure everything is stable, and then enable mod_gzip and disable mod_ssl,
in Apache.

Depending how it looks after that, perhaps investigate using APC php caching,
and/or parsing php code via fastcgi instead of with mod_php.

Overall, I'm pretty happy with these results, and expect to quit hearing
"is it down?" asked in IRC.


Generation 7 Electronics Teacup Firmware RepRap DIY
Re: Snippets from the reprap-admin list - part 2.
April 22, 2013 10:21PM
More updates, discovered some rogue web clients repeated reloading a large file.

Stopping these hits reduced the outbound wiki bandwidth by somewhere around %25.

The reprap.org server is looking happier each week.

Re: Snippets from the reprap-admin list
April 23, 2013 02:20AM
Hi Bill,

good job done smileys with beer

Can you 'put your finger' on location and time the majority of this 'unwanted' requests occure?

But I think, the databases are so big now and totally overwhelmed with high frequent queries, so we should look for better hardware/software anyhow ...

Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]
Re: Snippets from the reprap-admin list
April 23, 2013 05:20AM
Re: Snippets from the reprap-admin list
April 23, 2013 11:46AM
This last culprit was a handful of different IP's, but all using a browser-id string that doesn't get used by any legitimate browsers. I suspect some kind of buggy download manager.

In any case, they gave up shortly after I removed their access to the file they kept requesting.

Re: Snippets from the reprap-admin list
June 02, 2013 09:45AM
In an attempt to open doors to more legitimate users I've cut down the wiki block list drastically. Removed all blocks older than 6 months and changed the younger ones to expire after 6 months. Formerly there were about 1200 blocks, now there are 130.

Two months ago I removed a a few hundred blocks already as sort of a test-balloon. The raise of daily spam was, if there was a raise at all, not noticeable. Obviously, spammers have plenty of addresses to use, so blocking a few of them hurts only the legitimate users which happen to be in the same IP address pool of their internet service provider.

Another experience is, only few spammers try to re-use their accounts for multiple edits. Accordingly I regularly block only those accounts where I see repeated re-appearances. And always with a 6 month expiry.

Generation 7 Electronics Teacup Firmware RepRap DIY
Re: Snippets from the reprap-admin list
June 03, 2013 06:29PM
Is it worth considering a dynamic generated block list such as the ones at [www.iblocklist.com] perhaps? I know some of those are paid subscription lists, but there are others that aren't, such as "forumspam", "dshield" and the like, which are useful while allowing you to test the setup without the need to pay for list subscription first. I'd also expect that there would be some manual blocks regardless, as I'm sure there are a few places that just target us specifically (mainly just bad clients and web spiders).

Note: I'm not expecting that these would be updated every day or something, but say once a month, or manually by an admin (eg: "Force an update").
Re: Snippets from the reprap-admin list
June 29, 2013 07:14AM
> On 28/06/13 19:49, Viktor Dirks wrote:
>> Hi Admins,
>> ... regarding the forum -- in the last time the spammers get much more
>> nasty with registering or
>> spamming even without a valid account.

Am 29.06.2013 02:39, schrieb Adrian Bowyer:
> We certainly shouldn't allow posting without an account. I've disabled
> the reply option for public users, which should cut the problem down.
> Best wishes

Generation 7 Electronics Teacup Firmware RepRap DIY
Re: Snippets from the reprap-admin list
June 30, 2013 09:19PM
Hrm, was that applied just to a specific sub-forum, or to all forums? I just noticed what appeared to be a posting without an account in this sub-forum.

Note: I did report it, so it may be gone by the time you see this.

Edited 1 time(s). Last edit at 06/30/2013 09:19PM by Cefiar.
Re: Snippets from the reprap-admin list
July 01, 2013 04:14AM
... it's the same thing in all forums -- Adrian did the same as I did some time ago, but the options in the forums software seems to be overriden on server-level.

Seems I have to force some specific actions from the server-level admins confused smiley

Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]
Re: Snippets from the reprap-admin list
August 24, 2013 09:00AM
Am 24.08.2013 01:05, schrieb Bill:
> I have (mostly) installed the latest Mediawiki version 1.21.1, at
> [reprap.org]. It's using a separate database &
> db user, so should have zero overlap with the production Wiki.
> It seems to run fine, I've updated a few of the extensions, and a
> few still need updating. Also, the themes need an update & copy,
> and the image files need to be copied over. Right now it's just
> symlinking the image directory, and has uploads disabled.

Generation 7 Electronics Teacup Firmware RepRap DIY
spam-post permissions adjustments.
September 05, 2013 01:06PM
I've made some adjustments to the forum permissions, posts from unregistered users are no longer allowed, anywhere.

Re: Snippets from the reprap-admin list
October 13, 2013 10:49PM
Blogging time :-)

Notified by a lot of error messages in /var/log/forum_error_log I found images embedded into forum posts didn't work the way they should. Forum admins tended to disable the embed_images module, which doesn't match with some other part of the configuration.

The problem was, /usr/bin/convert insists on additionally writing a file when told to send the output to stdout. That's clearly a bug. As it didn't have privileges to write (what a luck!), it failed.

To fix this, I canged /data/www/forums/htdocs/includes/api/images.php to write this file to /dev/null. This workaround might break when 'convert' removes its bug. Nevertheless, it's the first time I see properly thumbnailed image boxes in our forum.

Time needed to find the right place and the right type of this one-line fix: about 6 hours. :-)

As always, I made a copy of images.php before patching. A person doing a wiki or forum upgrade may please watch out for files with a date appended (or "2013" in it's name), they're originals of patched files.

You see?

Generation 7 Electronics Teacup Firmware RepRap DIY

open | download - Stuttgart 21 - Rosensteinpark.jpeg (560.2 KB)
Wiki user cleanup
June 22, 2014 01:01PM
FWIW, I've just deleted 33'890 inactive accounts in the wiki using this maintenance script: [www.mediawiki.org] That's about 84% of the previously 40'544 ones. Unused accounts are ones with zero edits and older than 100 days.

I hope this script didn't catch more accounts than expected. In case you're human and your account got lost, please recreate it and add at least one edit, e.g. by creating a user page for yourself. In case you had edits and the account is gone anyways, please report here.

What's left is 6'657 users, 2'200 of which are probably still spammers, but not for longer than 100 days. Active user count is 149. Users, which have edited something in the last 30 days.

Edited 1 time(s). Last edit at 06/22/2014 01:02PM by Traumflug.

Generation 7 Electronics Teacup Firmware RepRap DIY
Re: Snippets from^H^H^H^H for the reprap-admin list
July 11, 2014 02:46PM
Just upgraded the Widgets extension of the Wiki from v0.8.something to v1.1. If you see issues, please report. If you want to use it, see [reprap.org] and [www.mediawiki.org]

Generation 7 Electronics Teacup Firmware RepRap DIY
Re: Snippets from the reprap-admin list
July 18, 2014 06:21AM
A genius at work!

I've edited the forum file at /data/www/forums/htdocs/include/phorum_get_url.php to set it so the javascript.php requests don't have the forum id added.

GET /javascript.php?225
GET /javascript.php

The javascript doesn't vary by forum, so having that forum-id on the request was causing the file to be re-requested when a user switched between forums, rather than just using the javascript file it'd already downloaded.
A spot-check of yesterdays access_log shows that it transfered 3121 megs of javascript.php, but it'd be 1387 megs if there were no duplicate javascript.php traffic.

Generation 7 Electronics Teacup Firmware RepRap DIY
Re: Snippets from the reprap-admin list
July 20, 2014 09:49PM
Definitely a good thing.

Q: Are we using mod_expires at all, and if not, could we consider setting it up?

We can then improve the amount of client side caching that is done on things like images, javascript, css, etc, by forcing their cache expiry times to be longer than they currently are.

This should reduce the amount of fetched traffic everywhere.

eg: [www.inmotionhosting.com]
Re: Snippets from the reprap-admin list
July 21, 2014 06:07AM
Pictures & co. currently expire after 30 days.

And If I see Bill's work correctly, he's currently in progress with abandoning Apache entirely in favour of Nginx. Progress so far about 80%, files; pictures and wiki PHP are served by Nginx and php-fpm already.

One funny tidbit: I forwarded the above enhancement to Phorums bug tracker, but they refused to accept it. It's considered to be a feature, because there might be people which want to serve a different JavaScript for each forum section. Which confirms my opinion that software developers have a strong tendency to make things complicated smiling smiley

Generation 7 Electronics Teacup Firmware RepRap DIY
Sorry, only registered users may post in this forum.

Click here to login