On 05.01.2024 14.26, Jelle van der Waa wrote:
Hey all,
Hi Jelle, Thanks for looking into this!
We have been wanting to onboard folks automatically via Keycloak to all our services. Mailman being one of them:
Gluebuddy seems to be the best fit for this, as it a) knows keycloak and b) can also talk to mailman eventually (as it's just a REST API).
I agree.
For this I made an issue in Gluebuddy and a WiP branch for Gluebuddy which can do onboarding. [1]
There are however several issues left to solve as we have many different usages of our mailing list.
I for example on Keycloak use jelle@vdwaa.nl for my account and my arch email is jelle@archlinux.org (same as keycloak username).
However this is not always the case, we have folks who have:
- Different Keycloak email from Arch - Different Arch mail address from login name ie. svenstaro => sven@archlinux.org
Yes, I also heard of this Kristian guy (klausenbusk -> kristian@archlinux.org). IIRC we stopped allowing this some time ago.
- May not use Arch email for mailing lists but their own.
So in Keycloak I've used the beta feature of profile attributes, to add arch_email. And I think we should set this for all staff to be their archlinux email address. Even if it's the same as their username.
SGTM. At some point we need to discuss what the source-of-truth should be. Is it the infrastructure repo (archusers.yml) or manually inserted data in Keycloak? We already have the arch_email in archusers.yml, so perhaps we could just sync it into Keycloak with Terraform? Perhaps we could also use Terraform to manage the group memberships in Keycloak, then the infrastructure repo would be the SSOT.
With that solved we can onboard all arch email addresses. Would this also help for onboarding users into mail.archlinux.org? At least we can maybe replace the hardcoded mailmap?
We should already be able to do that today with the email attribut from archusers.yml. I have a few ideas for improving the current mail situation (we have too many files not tracked in Git), I just need to find some time and energy :) The tricky part is handling the credentials and all the aliases. I dunno if we can just store the (hashed) password in a Keycloak attribut and solve the credential issue that way?
Now I know a lot of us subscribe with their personal email, how do we want to handle that from gluebuddy? Just mass subscribe and allow users to unsubscribe? Or at least allow sending?
Perhaps we can add a arch_ml_email attribut in Keycloak and fallback to arch_email or the account email if it is not set? The challenge is how we allow the staff to unsubscribe without starting a subscribe/unsubscribe war between the staff member and Gluebuddy. Perhaps we can just ask staff to set "Delivery status" to "Disabled"[1] if they don't want to receive any mails? [1] "Set it to Disabled if you want to stay subscribed, but don't want mail delivered to you for a while (e.g. you're going on vacation)."
I haven't implemented onboarding, that likely has to request all users from mailman and match them against known keycloak staff's email/arch_email attributes.
[1] https://gitlab.archlinux.org/archlinux/gluebuddy/-/issues/4 [2] https://gitlab.archlinux.org/archlinux/gluebuddy/-/merge_requests/17
P.S. the irony, I am not subscribed with my @archlinux.org address to this list.
Cheers, Kristian Klausen