For now I just did an mkdir /var/lib/gerrit2 to stop the puppet error noise. But the real fix is of course to not depend on that directory anymore on the new host.

The reason here was that I deleted /var/lib/gerrit2 (since the new directory is /var/lib/gerrit).

This isn't about the actual task, which is valid of course, but just because I thought it might be helpful to avoid this issue.

Yeah, There might be some hysterical raisins

I am currently working on setting this host up.

I tested removing the "safedir" git config and ran puppet and it added it back and it worked as designed. So I can't explain why it was broken but now it works again. Back to just the submodule status.

reason was:

Somehow the "dubious ownership" issue is back even though we wrote and puppetized an entire script for that :/

wmspecial wikis need a "description" field.

Don't forget to set method to 8 for everything to use the "new" way to fetch stats via the normal API, or it won't work.

In T377643#10293371, @Ladsgroup wrote:

Slaves are not configured to use dbproxy:

I changed all update scripts to use the "extinfo" update method which pulls in the version and changed version to use the "si_generator" version string.

https://gitlab.wikimedia.org/cloudvps-repos/wikistats/-/commit/23d14d562a84eba0501d8395cbc873442d21a317

unfortunately the link that supposedly once documented this is a 404 nowadays :( (https://docs.gitlab.com/ee/user/admin_area/settings/sign_in_restrictions.html#email-notification-for-unknown-sign-ins)

Almost certainly this request should be for the following:

The easiest way is to go to https://lists.wikimedia.org/postorius/lists/ops.lists.wikimedia.org/ and fill out the "Subscribe" form at the bottom.

(regardless of _WHEN_ you actually do that) Suggesting you go to https://gitlab.wikimedia.org/projects/new and from there to *Import Project* -> https://gitlab.wikimedia.org/projects/new#import_project

In T377643#10274574, @Ladsgroup wrote:

And does that mean it's out of sync with config in reality?

That can be the case. https://people.wikimedia.org/~ladsgroup/omg/ tries to catalog the reality. Does anything super obvious stand out to you checking omg?

blocked on T377922

blocked on T377919

Thanks for reporting!

Since onboarding to mailing lists is handled by ITS, it seems logical that ITS would also handle offboarding from the same lists. So I'm not sure I agree with the removal of Office IT. I agree it's not related to LDAP though.

As someone using cloud VPS with puppet the one major advantage for users like me would be that puppet roles could "just work" like they do in production.

If you don't mind that they are public, can you please paste email addresses here who should become list admin?

Yea, per IRC, and here to make it explicit. Everything looks good now. Thank you, Andrea :)

https://gerrit.wikimedia.org/r/c/operations/puppet/+/1082846 in relation to T315942

This also needs to be fixed. It's the parameters of the rsync command for LFS syncing.

@ABran-WMF Maybe you can also help with this? It's not super urgent though, so if not I can also wait for Amir to be back. Either is alright. Thanks

Here are the relavant Wikipedia articles about the different software that is used:

Yes, basically. But the details depend on how you configure it. You would be expected to name like 2 admins who maintain the list and can change settings according to your needs.

Added! What I'm actually adding is the URL to api.php, so

This isn't all there is to it though, puppet creates plenty of things in the old path. WIP.

There are many more because -xdev doesn't only exclude /proc but also /srv since that's a different filesystem too.

The usual backup related alert after doing a version upgrade.

caused by version upgrade.

In T378039#10256892, @ssingh wrote:

That being said and in the meantime, I am curious to hear if you have a suggestion on how to improve this text.