@Sergey.Trofimovsky.SF - this is followup from questions you raised during our first meeting the other day. Please let us know if anything else would be useful here.

But if Gitlab supports additional self-managed 2FA within Gitlab this could be an option as well.

cc: @colewhite for awareness, per some discussion between RelEng and Observability today.

• Wikitech developer accounts are how users create an LDAP objects for themselves:
  • • The process for signup: https://wikitech.wikimedia.org/wiki/Help:Create_a_Wikimedia_developer_account
  • We're in the process of adopting Apereo CAS for some services.
    • Currently limited to services with an SRE / technical audience, but is intended to be rolled out more widely in future.
    • Documentation: https://wikitech.wikimedia.org/wiki/CAS-SSO
  • We have a test instance of the GitLab omnibus install at https://gitlab-test.wmcloud.org/ and a test instance of Apereo CAS at https://idp.wmcloud.org/
    • Comments on this task indicate what we've tried with those test instances.

@Eugene.chernov please comment here confirming signature of L3 Wikimedia Server Access Responsibilities document and also that ichernov is correct for shell username.

@OlyKalinichenkoSpeedAndFunction please comment here confirming signature of L3 Wikimedia Server Access Responsibilities document.

cc: @OlyKalinichenkoSpeedAndFunction, @Eugene.chernov for Speed & Function - didn't find a Phabricator account for Sergey.

So, doing some rough estimation here:

Quick reply to cover open questions heard through other avenues. If there are additional questions that must be answered before setting up these VMs please ask here and I'll do my best to answer.

@jbond wrote:

Thanks both for the detailed responses. I'll cherry-pick a couple of things here and then respond in more detail.

First, there's a test instance of Apereo CAS at idp.wmcloud.org.

All good - thanks again!

For production-images we specify the ca_bundle for python requests to use via 'ca_bundle' in the config.yaml

@Joe any thoughts here?

Same result with:

This could be done by manually glancing at the dashboard or via some kind of alerting system (TBD)

After discussion last week (or thereabouts), we updated the "Holding the train" docs that constitute official policy to reflect the "> 1000 in 12 hours" requirement, but deployment docs in general are kind of scattered, redundant, and in need of work (see T273802 for a placeholder on that one).

Yeah, on the whole I think this seems like it would solve more problems than it creates.

After discussion, @jeena and I think we can probably just have the equivalent of 20-xdebug.ini included from somewhere else rather than our hacky solution of having the one in /etc writable by the runuser; I'll give that a shot.

Should I be able to see /docker/build-xdebug.sh in the container, if so, I am not seeing it, and perhaps that is a clue.

A clarification seems like the right thing, and I think it would be easy to have it notify the user once then quit spamming the log on every retry. I'll write up a patch.

Hmm, yeah. We could offer a convenient shorthand for shelling into the mediawiki container and running the sqlite CLI against the db, for example, but if people are using a rich GUI app to get a view on the db (or IDE features that know about schema? I'm really not familiar with what's available in that space) it's not going to be the same experience...

This might warrant a couple of separate tickets, but I wanted to get this captured while I still had it in scrollback.

Noticing what feels like an uptick in these in 1.36.0-wmf.28.