openSUSE admin

GitLab done. As part of the change, GitLab administrators are now managed using the "gitlab-admins" group in Kanidm.

Grafana done. As part of the change, Grafana administrators are now managed through the "grafana-admins" group, and editors through the "grafana-editors" group in Kanidm.

Whereas GitLab migrated users from LDAP to Oauth2 "under the hood", Grafana was more involved.
Using oauth2_prefer_short_username: true in the Oauth2 client for Grafana in Kanidm, Grafana would notice the existing users, but try to create new ones "on top", failing with unique database constraints.
One solution would have been to use SPN based usernames (the default with Kanidm if oauth2_prefer_short_username is not set) and just delete the old, stale, short name based ones, given them not containing much data anyways.
But out of curiosity, I worked out how to migrate the existing short name based users in the Grafana database.

Example based on my own account:

First, query the existing data from the user and user_auth tables:

sqlite> SELECT * FROM user;
...
7|0|crameleon|crameleon|||xxx|xxx||1|1|0||2023-11-26 20:04:57|2023-11-26 20:04:57|1|2024-03-23 14:09:39|0|0

sqlite> SELECT * FROM user_auth;
...
7|7|ldap|uid=crameleon,cn=users,cn=compat,dc=infra,dc=opensuse,dc=org|2024-03-21 20:25:21|||||

Note the id of my account is 7.

• Change the login field from the short name to the primary email address (the first mail field reported by kanidm person get crameleon):

sqlite> UPDATE user set login = 'crameleon@opensuse.org' WHERE id = 7;

• Change the auth_module field:

sqlite> UPDATE user_auth SET auth_module = 'oauth_generic_oauth' WHERE user_id = 7;

• Change LDAP DN to UUID (the uuid field reported by kanidm person get crameleon):

sqlite> UPDATE user_auth SET auth_id = 'c9b48c02-e8ff-11ec-9769-b47042ddcecb' WHERE user_id = 7;

Now authenticating with Oauth2/Kanidm gets me into my old/existing account.

For larger Grafana installations this should probably be scripted.
In our case a mere 5 unique users ever logged in to the instance, hence I just did UPDATE user_auth SET auth_module = 'oauth_generic_oauth' WHERE auth_module = 'ldap'; and then updated login and auth_id manually for every user.

Since the Matomo authentication is currently broken anyways, and the lack of logging in the application making both repairing the existing issues as well as switching it to the new system unfeasible, I will mark it as complete without action.
If we repair logging in Matomo in the future, I can implement https://plugins.matomo.org/LoginOIDC there. Since it's not clear when it will happen, it shouldn't be blocking the migration.

Patch to raise timeouts applied, all minions in Nuremberg migrated.

All minions in Provo migrated as well. Highly unspectacular.