Hello, Am Dienstag, 29. März 2016, 22:24:16 CEST schrieb Christian Boltz:
good news: after a month of hunting a) spammers and b) server admins, the needed wiki extensions to prevent and delete wiki spam finally got installed and the database updated so that those extensions can work.
Two weeks later, I have another update - hopefully the final one on this topic. We deleted all spam from the english wiki, and have set up filter rules (using the AbuseFilter extension) to prevent new spam. "All spam" means: we had to delete 6612 spam files, 513 pages in the main namespace and and about 50 pages spread over the other namespaces. I had the most fun with deleting about 5000 pages and files, and Micah (one of the Admins in Provo who is also a good Mail/IRC to SSH relay ;-) deleted the remaining 2200 spam files after cleaning up the recentchanges table (see the "Nuke" section below). While working on this, some funny things happened - as usual when I use or touch some code the first time, it breaks into parts ;-) and someone needs to fix it. AbuseFilter was my first victim - it worked fine for blocking spam pages, but it didn't block uploading of spam files with similar titles. It turned out that AbuseFilter used a wrong variable name for file uploads, making it impossible to filter for upload filenames. This was fixed (after I poked some people on #mediawiki) in https://gerrit.wikimedia.org/r/#/c/281234/2 I applied this fix to the openSUSE wiki. This bug might also explain why the spammers prefer file uploads - lots of wikis around the world don't have this fix yet and therefore make it easy to upload spam files. (Dear spammers, sorry for finding this bug and making your life harder *g,d&r*) My second victim was the Nuke extension - after deleting some of the spam, I noticed that it offered the same files for deletion over and over again, even if they were already deleted. (This happened only for files, not for "normal" pages.) It turned out that Nuke works based on the "recentchanges" table. This works fine for normal pages because Mediawiki deletes their "create" event from recentchanges when you delete them. However, it doesn't do this with "upload" events when deleting a file. (I'll re-check this behaviour with a newer version of MediaWiki, and open a bugreport if it's still the same.) As a workaround, we used a manual delete query on the recentchanges table. Not too nice, but it worked.
(Done in the english wiki, the others will follow.)
Micah deployed the Nuke and AbuseFilter extensions on the non-english staging wikis (for example destage.o.o), and will push them to all production wikis next week. This means the admins of the non-english wikis will be able to use Special:Nuke and Special:Abusefilter soon. (See my previous mail on this topic for some links and instructions.) My request from the lat mail still stands:
If you reply to this mail, please answer only to one list. Cross-posting the announcement is enough ;-)
Regards, Christian Boltz -- Wenn derjenige hinterher herumjammert, "Zwar hängt jetzt das Bild, aber ich habe ein Loch in der Wand und ein Nagel steht hervor...", dann habe ich große Zweifel daran ob es so gut war, dass derjenige einen Hammer und Nagel in die Hand bekommen hat. [Igor Sverkos in postfixbuch-users] -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org