Deployed via SWAT
Mar 7 2019
Mar 6 2019
I have scheduled this for the EU Midday SWAT on March 7th.
Feb 23 2019
Sorry if I was a bit too hasty or budged in but I've submitted a patch.
Jan 14 2019
Oct 18 2018
Odd. I heard that some functions were to be restricted to Trusted-Contributors (such as security task flagging) so that may be the case with Herald logs. Is there any way for me to be able to view the logs like I used to? It can be quite useful at times.
@Krenair Even if I get a recently closed task such as Task 207343 and attempt to view the transcript at https://phabricator.wikimedia.org/herald/transcript/2815487 (which can undoubtedly not be garbage collected) I still get an unable to view error as demonstrated above. As a user before today I could view such transcripts when logged in. Why can I not do so now?
Sep 14 2018
If this is on master version of Mediawiki maybe the new interface-admin group has stricter password policies.
Jul 18 2018
I wish that in the future I can get a delete.py readable list of users and pass them into a block.py script which mass blocks them. Any progress towards any form of block/unblock script yet?
Jul 17 2018
Jul 16 2018
Jul 15 2018
Jul 12 2018
I created a patch to allow sysops & bureaucrats to add the new rights. Apologies to Martin for intruding on his patch. I will request that someone puts this patch in their SWAT queue (I am unable to make it to the deployment windows due to timezone issues)
Jun 17 2018
Jun 7 2018
@Urbanecm I'm afraid my timezone is incompatible with the deploy windows. I will therefore ask that you help me take care of it. I have seen your review and have edited the patch accordingly.
Jun 6 2018
I've made a change that will hopefully let you have the user group activated. It still needs to be approved by system administrators and put on the server but that should happen inside a week. Hopefully @Urbanecm or someone else will help you make this change live. I honestly have no idea on that process
Jun 5 2018
May 25 2018
Apr 17 2018
Sorry it's not a script error. I'll make that more clear in the description
Apr 16 2018
Apr 3 2018
I understand. The tiny problem is that I'm currently borrowing a friend's VM on an occasional basis from them for my development. I can bear with this if absolutely needed but the reasoning is that I'd like to be able to be able to have a cloud install because I do not have appropriate access to a local VM. If I had enough access to one I would not be requesting this. I would also like to point out the additional fact that my friend's VM that I can use only has around 2-3GBs of RAM so certain roles like CentralAuth seem slow or laggy at times with the friend attributing them to the VM hanging up.
Mar 27 2018
I suggest that you email ca@wikimedia through the email linked to your account. In the past they have remove 2FA from people who can do that when there is no other way apart from IRC. Reference this task in the email so they know that it is a real task.
Well you will need to probably post a method of confirming your ID for sure on here and email ca (at) wikimedia.org stuff like committed ID answer as per wikitech. Adding James Alexander and Joe Sutherland since they seem to be the ones who handle this.
Mar 23 2018
WMF PR merged
PR updated. Requesting review, merge + task closure.
Mar 19 2018
Docker merged + updated. Need WMF approval for theirs.
Mar 5 2018
Mar 4 2018
Also while you're on it could please downgrade my global user page protection on the beta meta and set it to autoconfirmed editing (changing nothing else). When I got desysopped I could not edit it any further
PR filed @ https://github.com/wikimedia/mediawiki-docker/pull/46 (WMF readme) and https://github.com/docker-library/docs/pull/1165 (dockerhub).
I am also getting a bug after this (the only role) is enabled. When I visit Special:SpecialPages it throws an error about undefined function ldap_bind() on line 92 of ldapAuthPlugin.php
I think @Zppix also has a working anti open proxy bot that appears to work. Do correct me if I'm wrong.
I had a poke around in the checkuser repo and it appears that we are missing checkuser.php. I'll attempt to get a patch out if I can so that it works.
All right then.
Mar 2 2018
Deleting the main page has historically had some caché. It seems like a no-brainer that if there is a relatively straightforward way to prevent this, it would be better than not preventing it. If it's too hard for you to deal with, that's disappointing, but I guess we'll live with it.
As per this link there appears to be consensus regarding no need to move the main page. Therefore if I'm correct this should be ready to merge. Could someone have that arranged possibly? Thank you.
Mar 1 2018
@Paladox As an afterthought I'll make clear that I had the other email registered and could just not switch to it.
Must be a momentary server glitch of some sort. Issue appears to be resolved
I can't tell it to use the one I wish to use or delete my old one (that I don't want to use). Is there an active ID toggle somewhere?
Sorry I updated them out of the package defaults to the official (latest) debs/apt referenced on their official install page. Issue appears to be OK for now
Feb 25 2018
There's a custom hook somewhere that Tim Starling put which aborts the deletion or move actions on enwiki. Maybe import that for enwiki if the community really wants it.
What exactly needs to be discussed before this can go ahead? "Under discussion" can mean a lot of stuff and isn't specific enough (maybe something like "there are technical issues related to this" or something similar would be better).
We have a lot of bugged accounts like that. Some with special symbols may not be able to log in at all. Personally I would remove them since they can not be used at all due to system limitations.
Feb 2 2018
Mass adding people who may need a notification about this
Jan 24 2018
Jan 6 2018
Seems to work (for now)
Any updates from anyone about this?
Thanks. I'll try it again
Dec 13 2017
OK. I think this needs fixing since only people with shell access to that server are able to log in while people like me who do not have shell access can't even log in (yet the server is advertised as being a test server).
Such a shame that lots of log and status hosts are shifting towards a private option without even a limited public panel. Really decreases community accountability and removes the positive effects of "Wikis use community ownership".
Nov 26 2017
Email sent. Awaiting response
Nov 17 2017
Yes I will when I get time and then we can negotiate a new time if it isn't convenient.
Nov 16 2017
@greg I am willing to talk using IRC as it is most convenient for me. Its breakfast for me very soon so let me get it first then we can discuss err what we are meant to discuss. Thank you for being more open minded than some other people I've met and interacted with (no names mentioned)
Sorry @Paladox but the form went poof too. Maybe disable ldap connections and use an SQL database if possible?
Nov 4 2017
Oct 22 2017
Preferably if this affects the main code ideally a site admin who uses it on another site (i.e. not wikipedia or not wanting this log enabled) should be able to toggle a variable that disables the log. However, on the wikimedia network this should ideally be enabled (as per above). Thanks.
Oct 19 2017
Someone should get back to this if there are accounts to be deleted. Could the people pinged by marco @Dereckson @hoo @Legoktm respond to this please? If everything is fine I think 2000 strangely blank global accounts be deleted but naturally its the sysadmins' decision. If this task is done or dealt with please set the relevant flags on this task. Thanks!