Change #1060092 merged by jenkins-bot:

[operations/software/bitu@master] Wikimedia: New management command for blocking users in systems.

https://gerrit.wikimedia.org/r/1060092

Thank you for reporting. I think I have some idea as to why the key updated failed, so I'll try to add a test case and see if we can replicate the problem and get it fixed.

In T372581#10072020, @SLyngshede-WMF wrote:

@Meno25 I manually updated your SSH key to the eddsa-key-20240812, the old key has been removed. I've also deleted the cached copies found in Bitu (idm.wikimedia.org). The new key "should" import correctly next time you access the SSH key section there.

Please test if you can login to Toolforge.

@Meno25 I manually updated your SSH key to the eddsa-key-20240812, the old key has been removed. I've also deleted the cached copies found in Bitu (idm.wikimedia.org). The new key "should" import correctly next time you access the SSH key section there.

In T372581#10071994, @SLyngshede-WMF wrote:

Hi, could you do a quick test for me? We had another user with a similar issue, but have yet to receive feedback regarding the fix.

On https://idm-test.wikimedia.org there's a version where the SSH key management have been reworked to handle an issue that seems really similar to yours. Could you try to login there and see if you can activate your key?

Hi, could you do a quick test for me? We had another user with a similar issue, but have yet to receive feedback regarding the fix.

Thank you for a very good bug report, it's appreciated

I've uploaded 0.11.0 to Debian unstable.

mwclient 0.11.0 is now released with this fixed on that side. It also comes with four years of other changes, so please test carefully before deploying :)

In T371977#10054698, @DavidBrooks wrote:

To the comment on breaking-or-not siteinfo, please note that the AWB break (now fixed) was due to the flag removed from userinfo. That may come to the same thing; I don't know the internals.

In T371977#10049711, @LucasWerkmeister wrote:

In T371977#10049550, @bd808 wrote:

In "fun" news, the wmfkeystoneauth and Bitu usage of mwclient is via the python3-mwclient Debian package, so it looks like we will probably need to build and host a .deb for the updated library when it is available.

If we’re going to be reinstating the writeapi removal in production soon-ish, I would guess that other users of the Debian package would also want a fixed version of the library so they don’t get an error when talking to Wikimedia wikis? (Easier said than done, of course. And I don’t know how many third-party users the Debian package actually has – I couldn’t find any other packages depending on it, at least, though that might just be me operating apt wrong.)

To the comment on breaking-or-not siteinfo, please note that the AWB break (now fixed) was due to the flag removed from userinfo. That may come to the same thing; I don't know the internals.

mwclient-side fix is merged and I intend to do a new mwclient release tomorrow, if nothing else comes up, and none of the other maintainers can think of a reason why not.

In T371977#10049882, @Krinkle wrote:

I specifically amended https://gerrit.wikimedia.org/r/c/mediawiki/core/+/392542, which removed the "writeapi" feature to not break the stable API for "siteinfo", by leaving this behind as constant and non-deprecated boolean field.

The AWB breakage is specifically: format=xml&action=query with a body &meta=userinfo&uiprop=blockinfo%7chasmsg%7cgroups%7crights returns a rights element that no longer includes <r>writeapi</r> (English Wikipedia)

In T371977#10048477, @LucasWerkmeister wrote:

In T371977#10048450, @LucasWerkmeister wrote:

however, AutoWikiBrowser (AWB) also checks writeapi.

Eh… looking closer, it seems to check the writeapi right, not the siteinfo response member. So it’s not gonna be directly broken in the same way, I guess. Let’s untag them again.

"I told you so".

In T371977#10049711, @LucasWerkmeister wrote:

If we’re going to be reinstating the writeapi removal in production soon-ish, I would guess that other users of the Debian package would also want a fixed version of the library so they don’t get an error when talking to Wikimedia wikis? (Easier said than done, of course. And I don’t know how many third-party users the Debian package actually has – I couldn’t find any other packages depending on it, at least, though that might just be me operating apt wrong.)

In T371977#10049550, @bd808 wrote:

In "fun" news, the wmfkeystoneauth and Bitu usage of mwclient is via the python3-mwclient Debian package, so it looks like we will probably need to build and host a .deb for the updated library when it is available.

In T371977#10048887, @brennen wrote:

Change #1060468 had a related patch set uploaded (by BryanDavis; author: Lucas Werkmeister)

I'll deploy the above shortly.

In T371977#10048706, @bd808 wrote:

the OpenStack lifecycle hooks that create Nova Resource namespace pages on wikitech.wikimedia.org when we create a new Cloud-VPS project.

Change #1060396 had a related patch set uploaded (by Slyngshede; author: Slyngshede):

[operations/puppet@production] P:idp More precise base_dn for user lookup

https://gerrit.wikimedia.org/r/1060396

We've tested modifying the basedn on test and @hashar confirms that login is now working.

While I don't have the password, I've tested authenticating as jenkin-deploy on idp-test2004, and CAS now sees the user and rejects due to invalid password.

CAS uses the following to lookup the user:

Given that users are always supposed to use different keys for prod vs cloud, should the system user also use different keys?

Here is the developer account record:

$ ldap uid=jenkins-deploy
dn: uid=jenkins-deploy,ou=people,dc=wikimedia,dc=org
uid: jenkins-deploy
cn: Jenkins-deploy
loginShell: /bin/bash
sn: Jenkins-deploy
homeDirectory: /mnt/home/jenkins-deploy
uidNumber: 2947
gidNumber: 500
displayName: Jenkins Slave
objectClass: person
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: ldapPublicKey
objectClass: shadowAccount
objectClass: posixAccount
objectClass: top
sshPublicKey: ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIJCRyjVoIXXNgbxnPyOCALNbttc/Z4WX9X+YbudFa/h1 jenkins-deploy@toolforge
sshPublicKey:: c3NoLXJzYSBBQUFBQjNOemFDMXljMkVBQUFBQkl3QUFBUUVBNFFHYzFacy9TNHM3em5FWXc3UmlmVHVaNHk0aVl2WGw1anA1dEpBOWtHVUd6emZMMGRjNFpFRWhwdSs0Qy9UaXhaSlhxdjBONnlrZTY3Y004aGZkWG5MT1ZKYzRuL1owMnVZSFFwUkRlTEFKVUFsR2xiR1pOdnpzT0x3MzlkR0YwdTNZbXdEbTZyajg1UlN2R3F6OEV4YnZybmVDVkpTYVlsSVJ2T0VLdzBlMEZZczhZYzdhcUZSVjYwTTZmR3pXVmFDM2xRalNuRUZNTkdkU2lMcDNWbC9HQjRHZ3ZSSnBiTkVOUnJUUzNUZTlCUHRQQUdoSlZQbGlUZmxWWXZVTENqWVZ0UEVidmFia1crdlp6bmxjVkhBWkpWVFRnbXFwRFpFSHFwNGJ6eU84ckJOaE1jN0JqVVZ5TlZOQzVGQ2srRDJMYWdtSXJpWXhqaXJYRE5yV2x3PT0gamVua2luc0BnYWxsaXVtCg==
mail: [email protected]

Change #1060092 had a related patch set uploaded (by Slyngshede; author: Slyngshede):

[operations/software/bitu@master] Wikimedia: New management command for blocking users in systems.

https://gerrit.wikimedia.org/r/1060092