[14:46:28] brennen: is there a process for asking for the admin bit in gitlab? I'm working on the Striker->GitLab integration task and it would be helpful at least temporarily for my gitlab user to be able to call apis as an admin as I try to reverse engineer some things. [14:48:27] I would like to figure out what user account config bits are different between the LDAP auth provider that I'm using in my local dev env and the cas provider that is being used in the live site. And I'm hoping to be lazy at first and not need to add CAS to my dev env. :) [14:55:54] bd808: there isn't a formal process. it's entirely reasonable that we make you an admin, but i concede that maybe there *should* be a formal process since things are going to get messy if we have like 30 admins (and for all the usual least privilege reasons). [14:57:44] is there a process for gerrit that we can clone? [14:58:08] * bd808 has somehow managed to never get the admin hat in gerrit and is not sad about that [14:58:57] good question. i don't really think so. i mean for gerrit-roots on the server itself, there's the usual form, but not within the application itself. [14:59:11] (that i know of.) [15:01:48] 10GitLab (Administration, Settings & Policy), 10Gerrit, 10Phabricator, 10Release-Engineering-Team, 10User-brennen: Create a form for tracking administrative privilege requests for GitLab, Phabricator, Gerrit, etc.? - https://phabricator.wikimedia.org/T314495 (10brennen) [15:04:21] 10GitLab (Administration, Settings & Policy), 10Gerrit, 10Phabricator, 10Release-Engineering-Team, 10User-brennen: Create a form for tracking administrative privilege requests for GitLab, Phabricator, Gerrit, etc.? - https://phabricator.wikimedia.org/T314495 (10brennen) [15:15:49] I suppose the gerrit privilege request process is the Right Thing™ make a ticket requesting it, wait a while for people to weigh-in [15:30:02] ^ that seems like a reasonable base process [15:34:52] Folks can steal language and process from https://wikitech.wikimedia.org/wiki/Help:Access_policies as appropriate. That page describes something very similar to thcipriani's suggestion. (phab task + 1 week comment period) [15:43:13] would it be possible to test this api requests on the test instance? https://gitlab.devtools.wmcloud.org/ [15:44:52] jelto: in this case, yes I think it would. That instance is also using the CAS provider which is really the bit I'm trying to understand a bot more about without adding to my local dev env. [15:46:25] * bd808 has determined that provider="cas3" and extern_uid= are the likely magic needed with https://docs.gitlab.com/ee/api/users.html#user-creation [15:47:33] ^demon: ^ that babbling is related to T313366 too. [15:47:33] T313366: Figure out workflow for programatically adding GitLab users - https://phabricator.wikimedia.org/T313366 [15:48:35] bd808: is external needed too to flag it as an external account? [15:50:02] RhinosF1: no, that's actually a flag that means the user is external to the organization sort of. it's about rights and notifications, not how the authz is done [15:51:35] bd808: that kinda makes more sense [15:51:44] naming stuff is hard [15:51:52] the goofy thing with pre-creating/attaching these accounts via the API is that a local password must be set (part of the API validation) and that ends up messing up the workflow to setup 2FA on the same account later. [15:53:38] https://gitlab.com/gitlab-org/gitlab/-/issues/699 is technically about the LDAP authz provider, but I think it's basically all the same issues with CAS or any other external authz. [20:24:44] <^demon> bd808: I'm curious how Gitlab will behave if you login as a CAS-auth'd user that was pre-created with `reset_password` set as opposed to `force_random_password` or just providing some password. [20:30:58] ^demon: I have a pile of testing Developer accounts and now also have the bits needed to do the account pre-creation, so we can start testing such ideas. [20:32:55] [[wikitech:User:Tést őf Unícødë įn Usērnǎmė]] is the first account I was going to offer up as tribute [21:09:33] <^demon> bd808: Sadly, not in CE: https://docs.gitlab.com/ee/api/scim.html#create-a-scim-provisioned-user :( [21:13:48] <^demon> Also, for a bit of background for me: why did we go with CAS for IDP and not OIDC? [21:14:14] f'ing open core :/ The "normal" https://docs.gitlab.com/ee/api/users.html#user-creation is what I was going to poke at today/tomorrow. [21:14:42] <^demon> Yeah, that's what I've been reading up on today [21:16:01] ^demon: I don't remember what led the SRE folks to pick CAS, but I think there are docs on wikitech somewhere [21:16:46] <^demon> Lemme make sure I have this correct btw, we need the user to pre-exist in Gitlab so that they can be associated with the repo, right? I don't recall seeing anything in Striker to pre-create them in Phabricator? Unless I'm missing some nuance here. [21:18:17] ^demon: yeah, it's really for the initial migration although it would be ok for Striker to keep ensuring that accounts exist in gitlab. [21:19:17] For the differential integration Striker just tries to look up existing Phab accounts by SUL name and LDAP name. [21:19:36] ^demon: it's a little muddled, but some background on gitlab + CAS is on T274461 [21:19:37] T274461: Define auth strategy for GitLab - https://phabricator.wikimedia.org/T274461 [21:19:48] But Striker also has a goal prompt for you to create a Phab account and the connect it to Striker via OAuth [21:20:51] <^demon> Can we just ask the users to make sure they can login to Gitlab? I mean it's a one-time cost, right? [21:20:56] <^demon> How many people we talking here? [21:22:04] There are 439 tools with existing diffusion repos to move. [21:22:23] I haven't counted distinct Developer accounts connected to those tools... [21:30:41] <^demon> Could Striker become an application to Gitlab via Oauth2? Don't use it for actual auth'ing into Striker necessarily, but allow it to "connect" the two? That would enable users to create their accounts fairly gently. [21:31:49] <^demon> Then send an email to tool maintainers saying "Hey, we're prepping to move stuff, go ahead and login to Striker and click the little 'connect' button we have there for you?" [21:33:21] yes, we can add something like that (which would match Striker's Phabricator integration). But I 100% know that we will get about a 10% response to an email blast. [21:34:09] which I guess *shrug* at some level, but it makes forcing out of differential and into gitlab a harder problem (I think...) [21:34:25] what else could we do... hmmm [21:35:24] we could make migrating a repo an action in striker that the user initiates after making sure they have a working gitlab user [21:36:05] or we could move them all and make a "recover access" workflow in Striker to take ownership of the gitlab repo [21:37:14] we could even do that in some fancy way so that we make gitlab the primary repo copy and mirror it in differential so that git fetch from differential would keep working [21:41:02] ^demon: I guess my random hope would be that we could provision the accounts and then do the hack from https://gitlab.com/gitlab-org/gitlab/-/issues/699#note_744343440 to fix them for future 2FA for the initial accounts needed to move things. That makes it all a one-time process to pull a list of Developer accounts that need to be provisioned so we can move the existing repos. [21:41:43] we don't need a long term pre-create process, just something to bootstrap getting out of differential [21:45:02] * bd808 is in a rats nest of sql trying to get the count of distinct developers [21:48:20] 383 distinct Developer accounts associated with the 439 distinct tools which own the 469 git repos. [21:49:54] I think that m.utante looked and a large number of those git repos are empty, but ideally I'd like to move all of them [21:50:41] <^demon> If the repos are empty the tool isn't being used at all right? [21:50:49] <^demon> Why not use this as a chance to clean up? [21:51:25] because we don't gatekeep what tools live and what tools are shutdown. [21:51:51] just like WMF doesn't purge crappy content from the wikis. that's up to the community [21:51:59] <^demon> I don't disagree. But if it's never been used at all, we're not exactly shutting something down. [21:52:34] <^demon> This isn't a wiki with crappy content. It's a wiki where nobody bothered to even write the first page...right? [21:52:43] we can certainly purge empty git repos, if it's worth the energy to do so [21:52:59] which is different that deleting the tool [21:53:00] <^demon> Better use of time than migrating empty ones, I think [21:53:41] well, from my POV it is more work to filter the list [21:53:57] but I can certainly see how opinions would vary [21:54:06] <^demon> Pardon me if I'm missing something: but does the took exist really if the repo is empty? [21:54:24] <^demon> s/took/tool/ [21:55:11] yes, git repos are an optional add-on. they actually have no strong connection to the tool which is ultimately an LDAP user + group + k8s namespace in Toolforge [21:56:09] the connection is that Striker lets a tool maintainer push a button to create a git repo names after the tool [21:56:18] <^demon> Got it! So it could very well be some yaml in someone's homedir that they kubectl apply and we never see in git [21:56:33] *nod* [21:56:46] or ad hoc shell scripts they run or whatever [21:56:53] <^demon> Right right [21:58:11] <^demon> Ok then I see your point, filtering out empty repos seems like more work if we have to build the scaffding anyway [21:58:39] <^demon> Wow I cannot type today. [21:59:34] fingers are the worst [23:25:44] Creating an account via the API and setting it's email address triggers a confirmation email from gitlab. Subsequent login attempts via CAS end with a "please confirm your email address" prompt and an unauthenticated state until the verification link is followed. [23:28:02] ^demon: adding 2FA to the account just worked! [23:28:31] so.... maybe there's not a lot to do here except to pre-create the accounts? [23:29:23] * bd808 will add notes to the task [23:32:53] <^demon> Awesome [23:34:22] <^demon> That was using `reset_password` option? [23:34:41] I used `"force_random_password": True` [23:34:59] so in theory there is a local password, but nothing has prompted me for it [23:35:51] <^demon> Weird, it sounds like the issue in the task is LDAP -specific then and not general to all external auth [23:36:05] yeah, that actually might be the case [23:44:33] 10GitLab (Project Migration), 10Striker, 10Tools, 10Release-Engineering-Team (The Decommission Mission 💀): Figure out workflow for programatically adding GitLab users - https://phabricator.wikimedia.org/T313366 (10bd808) I wrote this horrible POC client for creating accounts via the API: `lang=python,name=... [23:55:52] 10GitLab (Project Migration), 10Striker, 10Tools, 10Release-Engineering-Team (The Decommission Mission 💀): Figure out workflow for programatically adding GitLab users - https://phabricator.wikimedia.org/T313366 (10bd808) As another test, I created an account directly via CAS login. This allowed me to confi...