Premise: now at least stock demo works (temporary domain)

Attempt number 4.

First of all:

Unrelated note, the Apache HTTPd is under-loaded:

I kind of restarted this upgrade from scratch last week. I will be a bit verbose soon.

Interestingly the memcached's protocol is super documented. Lovely!

Let's declare this as concluded. We can still comment and update the description. The situation is clearer now.

I've created this curtesy wildcard domain record to test things in Wikimini:

Some progress here.

Our cute "spammer-obliviater" is starting to run dry without being able to identify more spam. And I'm not creative enough to put additional keywords. Anyway we gained +20 GB free disk space and that's enough \o/

And, DicoAdo is online with 1.39.5 \o/

BTW, Wikimini.org has the most beautiful maintenance page ever. Change my mind.

Indeed it queries PageAssessments so it depends by the current usage by every specific community.

Situation of 2024-02-12 (Monday) morning:

Status update:

BTW the "Wikimini spam killer" script was completed and it's running since minutes \o/

Note that there are false-positives after May 2016. Example

Thanks Lorangeo. I'm considering "May 2016" as a raw cut line and I'm proceeding in releasing a wipe script and use that, ASAP.

If I have done everything correctly, the DicoAdo skin is now published on Wikimedia GitLab:

Interestingly it's 2024 and it still does not exist an internal PHP official method call to block a specific user.

BTW the Nuke extension is not feasible since it works on recent changes, and it's not the case. Also other extensions would be lovely but they DO NOT work for MediaWiki 1.26. And we should really do not try to upgrade and only after cleanup.

I'm once again a bit surprised that there is not any maintenance script to delete pages from a list of page IDs, instead of having a complicated and not-reliable generation of namespace names from an SQL query.

Some potential root problems:

I've found suspicious requests to these binary file:

New priority

Before 2024-01-07, our Switzerland service provider reported a spike in the traffic on the server wmch-mores-demo-01 hosting Wikimini.org and another minor MediaWiki demo, specifically on ports 80 and 443. The unwanted traffic spike is coming mainly from Amazon AWS. Unclear if this is a denial of service or another thing. I can start looking at this in some minutes.

I'm very happy because I've found a SURPRISINGLY-KISS solution \o/

This is not completed. The testing databases are not adopted by the test wiki.

First, see:

For the records the domain choosen for this was fr.test.wikimini.org and only works with a local DNS poison, associating that domain to the IPv4 89.207.237.59.