This task misses a rationale, what do we need it for on the non-labweb mw* servers? Anything which will be rolled out in the future?

Probably because this is a logical blocker to the parent task.

In T237889#5652216, @MoritzMuehlenhoff wrote:

This task misses a rationale, what do we need it for on the non-labweb mw* servers? Anything which will be rolled out in the future?

The rationale is to support T237773: Move Wikitech onto the production MW cluster. The LDAPAuthentication extension used on Wikitech requires php-ldap support.

ldap is already installed in CI, so no need for RelEng to change things from our end.

Pinging @MoritzMuehlenhoff, any objections to this?

Just so everyone is on the same page about this task and its parent (T237773: Move Wikitech onto the production MW cluster), the desired long term solution (T161859: Make Wikitech an SUL wiki) will NOT require LDAP for Wikitech. This is an intermediate step towards that longer term goal. We want to move Wikitech into the main cluster to make it less unique in the Wikimedia wiki farm. We hope this will reduce toil for many folks by making it easier for Wikitech to support the full, modern MediaWiki experience with things like VisualEditor and other extensions which depend on RESTBase and microservices. A reasonably large class of bug reports against wikitech.wikimedia.org are related in one way or another to it current unique hosting situation of being deployed on Wikimedia servers, but not being a part of the shared MediaWiki hosting infrastructure.

Today we have no other general purpose system for self-service creation of Developer accounts (aka LDAP accounts), so Wikitech needs to keep its snowflake status of using MediaWiki-extensions-LdapAuthentication & MediaWiki-extensions-OpenStackManager until T196171: Developer account creation without OpenStackManager is solved (possibly by T179463).

I don't know enough about php-ldap at the moment to have an opinion. In itself, adding a php extension to production is a big deal, but it's also easy to undo.

Security considerations aside, I'm not opposing this, as long as we have a rollback option open for some time.

I would explore the possibility of only routing wikitech to a subset of machines (the canaries?) and enable php-ldap only on those, given it's a temporary solution.

Also: how temporary? Do you have a tentative timeline for transitioning wikitech to SUL?

In T237889#6053313, @Joe wrote:

Also: how temporary? Do you have a tentative timeline for transitioning wikitech to SUL?

Geologically short, but maybe not short by other measures. We need a new Developer account creation portal first. That has been discussed for at least 3 years, but not resourced by any team yet. I wouldn't count on it being less than 24 months at best before SUL happened.

In T237889#6052809, @Andrew wrote:

Pinging @MoritzMuehlenhoff, any objections to this?

Fine with me. php-ldap is built from the core PHP package, so this won't need a rebuild in our PHP 7.2 component.

In T237889#6053314, @bd808 wrote:

In T237889#6053313, @Joe wrote:

Also: how temporary? Do you have a tentative timeline for transitioning wikitech to SUL?

Geologically short, but maybe not short by other measures. We need a new Developer account creation portal first. That has been discussed for at least 3 years, but not resourced by any team yet. I wouldn't count on it being less than 24 months at best before SUL happened.

Then I'd definitely go with the idea of installing wikitech on a subset of appservers, at least at first.

In T237889#6053911, @Joe wrote:

Then I'd definitely go with the idea of installing wikitech on a subset of appservers, at least at first.

@Joe would you also want the php-ldap package limited to a subset of MW servers? I think I can guess that your concern is wikitech somehow degrading performance for project wikis?

*bump*

So one of my concerns is actually about the parent task, I'll comment there.