In T356294#10046251, @Tchanders wrote:

@Niharika @Madalina Can we just use the same permissions as Special:IPContributions here? That's also the same permissions as for IP reveal.

Adding to @Niharika's list, I think it would be useful to measure the following as well:

In T334620#9510918, @Bugreporter wrote:

Note current Wikimedia Access to Temporary Account IP Addresses Policy has a "not blocked in more than one project" requirement, which is copied from board election eligibility, and I consider it not appropriate as a required minimal requirement; in T356294#9504584 I propose the it be amended so this requirement should be removed. Actually modifying the policy requires WMF legal.

This appears to be somehow duplicate to T334620: Create group for assigning checkuser-temporary-account right. @Dreamy_Jazz @kostajh, should those two tasks be merged?

Per @Aca's request:

Done.

Thanks! We'll review again and let you know :).

@Dzahn @JJMC89's update to users.yaml above should fix a lot of differences reported in P66165. Would you mind running the dry run for global-sysops, global-renamers, stewards-usergroup and checkuser-l again, and pasting it as a new paste, so that we can go through the remaining differences?

In T351202#9983583, @JJMC89 wrote:

https://gitlab.wikimedia.org/repos/stewards/users/-/merge_requests/1 starts to address the differences in the dry run. See comments in P66165 and users.yaml.

In T371279#10023885, @Tchanders wrote:

@Urbanecm Are we also missing checkuser-temporary-account to bureaucrats locally?

FWIW, as I just noted on the Stewards noticeboard, the volume of requests is only higher temporarily. A backlog of about 2 months of data is currently being processed. Personally, I do not think we necessarily need to make any adaptations – as the volume of requests will go down once the backlog clears.

I invited my fellow Stewards to test and comment on the task; there were no objections or similar. Resolving, as further feedback is not expected. If there is some last-time feedback from stewards, please ping me. Looking forward for the deployment!

In T369780#9972040, @Stashbot wrote:

Mentioned in SAL (#wikimedia-operations) [2024-07-11T02:45:38Z] <mutante> stewards2001 - sudo mv /srv/repos/users-db /root/ - run puppet and let it recreate the usersdb repo - this time pulling from gitlab - T369780 T369430

Thanks! I pulled the new code that makes use of the new secret, and everything works in the same way as it does on my local:

Thanks! Verified the onboarder still works for GitLab:

@Dzahn Can you help with updating the secret in private Puppet, please? Thanks in advance!

From the repository end of things, I can easily generate repository-specific credentials (both HTTPS push token or a SSH key). After exploring for a bit, it is possible to include HTTPS credentials within a git clone command (something like git clone https://username:password@gitlab.wikimedia.org/repos/stewards/users.git works just fine). It also appears git::clone support overriding the generated remote via the origin parameter. With those two things combined, we should be able to construct the full URL based on the secret from private Puppet, and clone the repository via HTTPS.

Reassigning for help with the Puppet part.

Reassigning to @Dzahn. Once the dry runs are available, happy to take over to review the diffs.

@Dzahn: I populated the users db with checkusers as well, so checkuser-l should now be ready for a dry run as well.

This is now done, via https://gitlab.wikimedia.org/repos/stewards/users/, available at the stewards machine.

Coding-wise, this is now implemented (via @StewardsBot as the bot processing the changes). I set the system to only remove people from the security ACL (never add), as it requires MFA, and checking that would require Phabricator adminship for the bot. Maybe later :).

Hi @Volans, I see the group approval field was checked, but the WMF sponsor one is not checked. Is it possible for me (the group approver) to also act as the sponsor (in my WMF capacity)? Or do I need to secure an additional approval for the request?

Unstalling, as the repo has been created.

@Dzahn: Can you please help with puppetizing the secret for Phabricator as well? Following the Gitlab example, I uploaded https://gerrit.wikimedia.org/r/c/operations/puppet/+/1052185/, and put the secret to stewards1001:/home/urbanecm/phab_secret.txt. Thanks in advance!

Created as @StewardsBot.

Approved.

Thanks!

In T343377#9941430, @CDanis wrote:

This is great, thanks. One remaining piece here is to figure out how best to get this data to a context where we can edit LDAP like ldap-maint1001. Maybe the simplest way is using rsync::server::module to expose the /srv/exports/ldap_group or /srv/exports directory?

@Dzahn Thank you! I tried following your instructions in https://gerrit.wikimedia.org/r/c/operations/puppet/+/1050731, looks like it works. Review appreciated (but definitely can wait for Monday :)).

@Dzahn Can you help me with the secrets management here, please? I put the token at stewards1001:/home/urbanecm/gitlab_settings.yaml.

Putting on my radar :).

In T343377#9931101, @MoritzMuehlenhoff wrote:

One thing that we could do is to

• Write a script which parses the complete stewards list from $DATASOURCE and retrieves the shell UIDs of their Wikimedia Developer accounts

@SLyngshede-WMF curious to hear what possibilities do we have for automatically granting LDAP access from stewards1001? Would it be helpful if we generated a list of developer accounts somewhere in that machine? Or should we do something similar?

In T343377#9930702, @CDanis wrote:

@Urbanecm what's the status of the stewards VM / onboarding tool?

Here are my unstructured notes from playing with Special:IPContributions:

Done

In T365121#9804221, @Sebastian_Berlin-WMSE wrote:

Thanks for the info, @Urbanecm. I wasn't aware of acl*userdisable.

Hi @Sebastian_Berlin-WMSE! FWIW, all people listed in acl*userdisable are able to disable user accounts via https://phab-ban.toolforge.org/. If that would be useful, I can add someone from WMSE (possibly you or Lokal_Profil?) to that group, and then you would be able to disable accounts on your own, without needing a task (you would need a task if you ever need to re-enable an account, but that should be a less common operation).

This indeed is a site request (more than it is a maint script run), as it involves a config change deployment.

Patch uploaded, should be deployed sometime next week.

Done. @Pppery, per your request, I ignored all subpages and talk pages. I also deleted the /2024 page before starting the move. Would you mean helping with the rest of the cleanup here, please?

Done.

In progress.

In progress :).

Thanks for the quick fix @taavi!

Problem is now resolved.

An idea that originates from a recent-ish meeting with @Tchanders is introducing a temporary "IP addresses visible" mode, which would ensure all temporary accounts are resolved to an IP, which can be enabled from time to time (for a specific reason). Conceptually, this would be similar to Phabricator's high-security mode, which removes the need to enter a MFA token every time a sensitive action is taken. If this mode exists, it could help with the logging. It would be more similar to T346809 (except it would still be multipage, just not unlimited over time).

In T358852#9690255, @Tchanders wrote:

Do we need this for Special:DeletedContributions too?

In T351202#9682286, @Dzahn wrote:

In T351202#9678542, @Urbanecm wrote:

@Dzahn: Can you please make a dry-run of syncmembers and share it as a private past on this task, so that I can take a look at the changes it would make?

Done. Please see P59236