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

We also need to move the list of users from ~urbanecm/config/users.yaml to a better location. Filled T361547 to track that. Also, we should create a more reasonable export path than somewhere in my home. Maybe /srv/exports?

In T351202#9639225, @Dzahn wrote:

Following up on the last comment by Legoktm. I am also in favor of this option and would be happy to make the relevant puppet change to add a systemd timer for this on the lists server.

Could you export the list of stewards/email addresses on the stewards* machines locally and let me know where they are and then I take a look at the rest?

Hi @Dzahn, do you have any thoughts on this, please?

That sounds perfect to me @Dzahn! Thanks for the suggestion.

This was actually done AFAICS. Closing.

Move is in progress.

In T359553#9612508, @Superpes15 wrote:

In T359553#9612388, @sbassett wrote:

Accounts without Phab MFA enabled:

1. @Ajraddatz

Many thanks! I added the 6 members who have 2FA enabled to acl*security_steward and notified Ajraddatz about this :) We let you know when you should check again :D

Should be done now. Sorry it took so long, and thank you for your patience.