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).

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.

In T192217#5035980, @hashar wrote:

The check pipeline is gone!

[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

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.

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.

In T191182#4277998, @TerraCodes wrote:

In T191182#4111915, @Aklapper wrote:

I explained in T191182#4103647 why I think this is wrong. So I am reopening this task. If Differential has no future in Wikimedia development then projects should get migrated and it should be turned off. Leaving yet another lingering system around just adds to technical debt, confusion, fragmentation.

Would turning off Differential loose the content it already has and break links to it?

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.

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.

Woohoo! Thanks Daniel and Tyler! :)

Per T188367, crons are preferred over jenkins.

See also T186994, T195709, T192539.

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).

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?

In T172165#4231598, @JeroenDeDauw wrote:

Will WMF be able to run (full) PHP 7.1 any time soon? (Note: I am not asking about bumping MW to 7.1, just when WMF will be able to run it.)

In T187736#4230486, @Krenair wrote:

(and also it should've been being used for things like SSH host key gathering, what happened to that?)

In T194927#4230615, @Krenair wrote:

why on earth is that host named 1001? it doesn't make sense to use that convention in labs which is eqiad-only

Where/how does the ConfirmEdit extension currently set how "strong" a captcha should be?

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).

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.

What's the correct closed status for "Whoever fixed this did so inadvertently or did not know about this task."?

In T192473#4171334, @Pchelolo wrote:

The Kafka queue works correctly overall as far as I can tell.

All cleanup done :-)

Currently unable to commit time for this.

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.

In T151466#4169405, @aaron wrote:

both debian versions, though the stretch server isn't there anymore afaik

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