@BCornwall We currently have two hosts:

@Tgr do we want to do any more work on this task? If not I'll go a head and close it.

Oh, yeah that look annoying.

That is the Phabricator backend for Social Auth that's being weird. It default assumes that you mean to authenticate with phabricator.com.

@Raine You should now be able to add sk-ecdsa-sha2-nistp256@openssh.com keys

@brouberol Yes, I think that should be fine. We've seen no issues on test and I can't find anything in the docs that should indicate that we really shouldn't.

Yes and no. We need to change the base image to the WMF Java image, which is only available as AMD64, which means that it's pretty much useless for me. The slowdown on ARM64 trying to run Java in AMD64 makes it incredibly slow. So we still need to have build instructions for everyone not on AMD64, and another base image for them to build from.

Leftovers from moving ldaptui to OS packages:

Quick test revels that the error handling does NOTHING if the fail doesn't exist.

@ssingh The issue is in the Lua code that opens the database file, but fails. It's a little weird, because the codes is identical to the handling of other database files, where we raise a warning if the file cannot be opened.

We already have the ability to build the docker image, but it makes sense to push it to the registry. Also good to have for other projects.

Some one goofed up and assumed that SSH key algorithms all have short, less than 32 character, names. They do not.
I initially tested with a Yubikey, which is sk-ssh-ed25519, this type was unsupported by the old sshpubkeys version. I did not test with a sk-ecdsa-sha2-nistp256@openssh.com, which I assume is also what @Raine attempted. In that case we also hit the size limit on the database field, and Django errors out. The database field for the key_type is only 32 characters, but the key type name is 34.

For the log: I've added @DPogorzelski-WMF and re-encrypted.

Weird question, how many characters is your key, and how many characters is the comment?
I think you might managed to trigger at least two bugs :-)

@Raine would you mind testing again. @MoritzMuehlenhoff has update the package, so the FIDO key should be supported now.

After a bit of debugging. The fingerprinting of the FIDO key failes, with an error when calling: hash_sha512() on the ssh key object. This is done when we verify that we're working on the correct object, e.g. that we have the right key before deleting it.

@cmooney can you let the people from Meta know that this should be fixed now?

I'm removing Traffic, we're not going to find this two years later.

@cmooney / @Papaul traffic is moving.

DNS traffic, for those following at home: https://grafana.wikimedia.org/goto/gdcIGJmDR?orgId=1

Depooling at 15:30 UTC

Script and tooling https://gitlab.wikimedia.org/slyngshede/meta-geomap

@ssingh The dnsdist shipping with Trixie is already a version 1.9, is there any reason for us to package our own version?

Working with the suggestion from @Fabfur and mixing in a few suggestions from @CDanis I did a script that will query Druid for the "heaviest" bots. Heaviest being those which generates the most traffic in terms of number of requests, but also in terms of using the most data.

Turns out I can just handle this myself :-)

@ssingh - for manager sign off

We're reworking the design/layout. The updated UI is available for preview here: https://idm-test.wikimedia.org/keymanagement/list/ but not yet completed.

@Aklapper that's a very good point. For SUL accounts we link on the ID returned, and just store the username for reference. I'll see if we can do the same for Phabricator.

@Aklapper I've created the account "slyngshede" but I did not get a confirmation email. Is that expected?

@Aklapper that's fine, I just need a user to be able to sign in using Phabricator as an OAuth server, like this: https://secure.phabricator.com/book/phabcontrib/article/using_oauthserver/

@Novem_Linguae I've updated the description to be a bit more descriptive. Please feel free to request the permission now.

Users can now request the new permission via https://idm.wikimedia.org/permissions/

The infrastructure foundation team has decided that NDA will not be granted Netbox access in the future, most users in the NDA group simply do not need Netbox. However it is a useful tool for many, including volunteers, so instead a new group/permission will be added, specifically for Netbox read-only access. This also aligns with our goal of creating more fine grained access control.

Personally I don't love the private repository with Puppet code inside it, as it hides a lot of information. I get that this is the idea, but it makes things difficult to work on. E.g. we would then be able to break Puppet from yet another repository.