Identity management service to centralize account creation/settings, access groups for Wikimedia Developer accounts.
See https://wikitech.wikimedia.org/wiki/IDM
As of 2023, stewarded by Infrastructure-Foundations
Identity management service to centralize account creation/settings, access groups for Wikimedia Developer accounts.
See https://wikitech.wikimedia.org/wiki/IDM
As of 2023, stewarded by Infrastructure-Foundations
I can confirm the BarryTheBrowserTestBot account is now inactive in Gerrit. From the All-Users.git database:
$ git show commit 94c67416a2c1adc8bde631e6c9e72701915e424f (HEAD -> users/53/2653, origin/users/53/2653) Author: [BOT] Gerrit Code Review <gerrit@wikimedia.org> Date: Fri Oct 3 06:39:58 2025 +0000
Mentioned in SAL (#wikimedia-releng) [2025-10-03T06:42:11Z] <hashar> gerrit set-account BarryTheBrowserTestBot --inactive # T388662 T390070
As part of this task I found out that the logic to ban an account in Gerrit was not migrated from the wikitech-l MediaWiki hook to Bitu. Blocks were ineffective. I went to implement support for blocking users in Gerrit by porting the PHP code to Python. This was done via T390070
Change #1190198 merged by jenkins-bot:
[operations/software/bitu@master] User Block: Add option for unsetting email address
Change #1190198 had a related patch set uploaded (by Slyngshede; author: Slyngshede):
[operations/software/bitu@master] User Block: Add option for unsetting email address
Change #1189390 merged by jenkins-bot:
[operations/software/bitu@master] Release version 0.1.13
Change #1189390 had a related patch set uploaded (by Slyngshede; author: Slyngshede):
[operations/software/bitu@master] Release version 0.1.13
Change #1188719 merged by jenkins-bot:
[operations/software/bitu@master] Permissions: Prevent duplicate permission requests
Change #1188719 had a related patch set uploaded (by Slyngshede; author: Slyngshede):
[operations/software/bitu@master] Permissions: Prevent duplicate permission requests
striker_admin@m5-master.eqiad.wmnet(striker)> update labsauth_labsuser set sulname = null, sulemail = null, oauthtoken = null, oauthsecret = null where shellname = 'josef1992'; Query OK, 1 row affected (0.002 sec) Rows matched: 1 Changed: 1 Warnings: 0
Neither Developer account has been linked with a SUL account via Bitu (idm.wikimedia.org).
@Arendpieter Yes, that's the same issue, and you are correct that the fix needs to go into the cas-overlay-template repo as it's an update/bugfix in Apereo CAS, which runs idp.wikimedia.org (not to be confused with idm.wikimedia.org).
In T392350#10759377, @SLyngshede-WMF wrote:The bug should be fixed in CAS, but requires an update.
I am not sure there was a follow up on this but after it was restarted, it was all working fine for a week so I am going to close this as fixed.
What was found out on Monday?
Change #1169250 merged by Ssingh:
[operations/puppet@production] admin: schema.yaml: bump max for uid
Change #1169250 had a related patch set uploaded (by Ssingh; author: Ssingh):
[operations/puppet@production] admin: schema.yaml: bump max for uid
Change #1169235 merged by Ssingh:
[operations/puppet@production] admin: data_test.py: bump system_uid_max to 499999
Change #1169235 had a related patch set uploaded (by Ssingh; author: Ssingh):
[operations/puppet@production] admin: data_test.py: bump system_uid_max to 499999
<marostegui> idp is down? <marostegui> I get icinga or orchestrator with: upstream connect error or disconnect/reset before headers. retried and the latest reset reason: connection failure <marostegui> https://idp.wikimedia.org/ is down yep <marostegui> https://phabricator.wikimedia.org/T399356 created this <moritzm> marostegui: I've restarted Tomcat and it's working again, I'll have a closer log at the logs on Monday <marostegui> moritzm: thank you <3
IDP seems to be back to normal. Decreasing the priority and leaving the investigation for Monday.
It seems to be normal now, are you still having problems?