Located in Germany: CET (UTC+1)/CEST (UTC+2)
User Details
- User Since
- Feb 6 2017, 6:31 PM (356 w, 3 d)
- Availability
- Available
- IRC Nick
- eddiegp
- LDAP User
- EddieGP
- MediaWiki User
- EddieGP [ Global Accounts ]
Dec 22 2022
Oct 24 2022
Feb 13 2022
Aug 4 2020
Jul 31 2020
May 29 2020
https://secure.phabricator.com/T11816#218816 referred a seperate task for this problem, which is why I replied to the follow-up question there (https://secure.phabricator.com/T11073#218832 and following discussion).
Mar 19 2019
I'm not actively working on this any more, but still willing to rebase and correct the patches in case anyone cares to review them.
I'm not actively working on this any more, but still willing to rebase and correct the patches in case anyone cares to review them.
Feb 7 2019
Nov 16 2018
[13:03:01] <legoktm> I think someone needs to look at the threat models, and what exactly does "arbitrary code access in a docker instance runing on a cloud vps instance" let you escalate to
Sep 21 2018
First of all, I agree with MarcoAurelio. I don't have any context here, but if the plan was to create a new wikis for a one-off campaign and delete it after said campaign is over, then you've probably found one of the most effective ways of burning wmf resources that could easily be circumvented. I'm not sure whether it's easy to create a wiki these days, but deleting it is definitely not, it requires a lot of manual work from different wmf teams, none of which are usually short on work.
Aug 24 2018
As I understand it T97580 was about those volunteers who are already entrusted with root access to toolforge, and the solution seems to have been to add a user to the nda ldap group. Membership in the nda group and especially toolforge root access require far more trust than access just to the puppet compiler.
Aug 9 2018
Jun 15 2018
Jun 13 2018
Jun 9 2018
Jun 6 2018
AFAIK this used be a way to disable abusive accounts (by removing this right they could no longer log in, which normal blocking on wikitech didn't do iirc). Did keystone roles take that functionality over? Even if rarely used, there should be a easy way to disable abusive accounts on wmcs.
Jun 1 2018
Ping @ArielGlenn per your work on this instance in T184258.
Ping @Catrope - you created that instance two months ago.
At a short look: GitInfo::getRemoteUrl is used to determine the remote url, which just reads the git config file. The config file will have a different value for the remote (with or without .git) based on whether mediawiki/core.git or mediawiki/core was checked out, although there's no functionally difference in that as far as I know.
May 30 2018
Woohoo! Thanks Daniel and Tyler! :)
May 29 2018
Per T188367, crons are preferred over jenkins.
May 28 2018
May 27 2018
See also T188367, which is about going the other way round (jenkins->cron) for mediawiki, and my comment there.
I wonder how this relates to T73305, which is about migrating away from a cron to jenkins for the puppet repo. Although these repositories are independent, it seems to me that the upsides/downsides on that other task still apply here. As I understand it the gist of these two tasks is that
- crons work well, unless they break, in which case they suck at alerting and making it easy to find an offending commit
- jenkins nice at alerting and helps to find the offending commit, unless it breaks for some reason we can't figure out (as described in this task description)
According to openstack browser this uses ::standalone as of now. Seems the ony thing left to do here is a more general change in how we handle puppet at the beta cluster (for example heira). That's tracked at T161675.
Please provice a bit more information on what you were doing, which wiki in beta you specifically used, what part of the software you're refering to or what the 'edit layer' option is. See also https://www.mediawiki.org/wiki/How_to_report_a_bug
en_rtl is in the table of projects. Under "other projects" there's en-rtl. Probably all that's needed is to swap the underscore with a dash in the langlist-labs file at the top of the mediawiki/config repo. Thus tagging as good first task.
It seems you used the same flavor for deploy1001 that tin had. This would've been a great time to switch to a different flavor (with bigger disk) and resolve T166492. This comment is probably late for tin->deploy1001, but maybe not for mira->deploy2001 (or whatever it will be called).
May 26 2018
May 25 2018
Apparently the reason was just "unused": https://tools.wmflabs.org/sal/log/AWDgixgYwg13V6286cnS
Per the link in the task description labs-puppetmaster/Labs Puppetmaster HTTPS is OK since 19m 45s
These are two out of four remaining trusty instances in deployment-prep, and continuously failing puppet for months. I wonder whether they still serve any purpose or should just be deleted - and if they are meant to stay, who would be responsible for upgrading them/resolving the puppet errors.
All the hosts that are failing puppet in deployment-prep (as seen on shinken.wmflabs.org) look familiar and seem to have their own tasks. So I think we can consider this done.
DNS entries instance-deployment-secureredirexperiment.deployment-prep.wmflabs.org. and *.secureredirtest.wmflabs.org. can probably go away as well?
May 24 2018
Where/how does the ConfirmEdit extension currently set how "strong" a captcha should be?
May 22 2018
20:29 <shinken-wm> RECOVERY - Puppet errors on deployment-db03 is OK: OK: Less than 1.00% above the threshold [0.0] 20:47 <shinken-wm> RECOVERY - Puppet errors on deployment-elastic07 is OK: OK: Less than 1.00% above the threshold [0.0] 20:50 <shinken-wm> RECOVERY - Puppet errors on deployment-ircd is OK: OK: Less than 1.00% above the threshold [0.0] 20:50 <shinken-wm> RECOVERY - Puppet errors on deployment-logstash2 is OK: OK: Less than 1.00% above the threshold [0.0] 20:51 <shinken-wm> RECOVERY - Puppet errors on deployment-mathoid is OK: OK: Less than 1.00% above the threshold [0.0] 20:52 <shinken-wm> RECOVERY - Puppet errors on deployment-tin is OK: OK: Less than 1.00% above the threshold [0.0] 20:53 <shinken-wm> RECOVERY - Puppet errors on deployment-prometheus01 is OK: OK: Less than 1.00% above the threshold [0.0] 20:53 <shinken-wm> RECOVERY - Puppet errors on deployment-ms-fe02 is OK: OK: Less than 1.00% above the threshold [0.0]
May 19 2018
May 18 2018
May 10 2018
May 6 2018
May 3 2018
Each column in the "user" table is a row in the "describe user" view. The column "Null" in the "describe user" view above describes whether the respective column in the "user" table is allowed to have NULL as a value. It says nothing about whether we're nulling it on the cloud replicas for privacy reasons. You cannot see that from the "describe user" view at all.
I'm not sure what that sentence means ("the Null field" is a bit ambiguous). If you're refering to the integer "0" for user_id, yes, it works the same way (if no user id is specified, 0 will be used).
May 2 2018
20:18 <Hauskatze> jynus: when I use "describe user" on metawiki_p, the user_editcount field says it's NULLed, but in fact it's not, and should not 20:19 <Hauskatze> https://phabricator.wikimedia.org/P7068
Right, I already wondered whether we need them or they can be removed. I pushed that idea back because I don't want to mix it with the commit getting rid of the wildcard vhost (to have smaller steps, one removing the wildcard vhost and replacing it with redirects, the other to remove the unwanted redirects). I'll upload another patch in the correct relationship when I find some time.
@thcipriani: Could you document this on https://wikitech.wikimedia.org/wiki/LDAP/Groups please? By now I only see a vague point "Jenkins administration", and that only for the wmf group.
May 1 2018
What's the correct closed status for "Whoever fixed this did so inadvertently or did not know about this task."?
All cleanup done :-)
Currently unable to commit time for this.
Apr 30 2018
Assigning to joe - it seems you're the one most comfortable (or only one comfortable?) on apache changes. Also per the previous -2 on the patch, so it's blocked on you anyway.
To the opposite, all app servers in deployment-prep have been replaced with stretch via T192071 (although you're right that the specific instance that made problems is gone). jfyi