@Scardenasmolinar that's perfect, all good. Thanks a lot.

Confirmed all looks good so far, resolving.

I've quickly chatted with @Jpita, here's the summary of my understanding of the current situation.

Change merged, LDAP updated, resolving. Feel free to re-open if you have any issue with accessing resources that requires the wmf membership.

@hueitan in the meanwhile that the patch gets reviewed could you also link your LDAP account (the wikitech one) with this Phabricator account? See https://phabricator.wikimedia.org/settings/user/hueitan/page/external/

Verified via hangout that it's indeed Huei's account. @hueitan could you add here also what's your Wikitech account please?
That's the one to be added to the wmf group. Thanks

For context:

• exit code 23 on rsync is Partial transfer due to error
• there are root owned files and symlinks in /srv/mirrors/debian/dists/sid/main
• the crontab that runs the rsync (AFACIT) is run as the mirror user

If no objections will be raised by Monday afternoon EU time the related patch could be sent and merged.

If no objections will be raised by Monday evening EU time the related patch could be sent and merged.

@JoeWalsh the patch was merged, within 30 minutes it will be applied everywhere. Please read the previous message above and related link.
Feel free to re-open the task if there is any issue with the access.

@Jpita could you confirm that we can "offboard" the previous josepita account in favor of the current jpita one?

@Anthere
List created, here are the URLs for listinfo and admin. The list password has already been sent to the initial list administrator's email address, we recommend they communicate the password with the secondary list administrator.

I think I see the issue here, @Jpita was added with the jpita-ctr@ account before (uid=josepita) while the current one is uid=jpita.
I think we just need to replace the LDAP membership of the wmf group from uid=josepita to uid=jpita and update the reference in data.yaml in https://gerrit.wikimedia.org/r/plugins/gitiles/operations/puppet/+/production/modules/admin/data/data.yaml#4045 for the username and the email.
Adding @MoritzMuehlenhoff for confirmation that this is the right course of action in this specific case.

Patch merged, changes will be applied within 30 minutes. @Jdforrester-WMF: feel free to resolve the task once verified everything works as expected.

Over to @thcipriani for formal approval.

In relation to https://gerrit.wikimedia.org/r/c/operations/cookbooks/+/583109 I've just tested the command on a single host, this is the result:

root@dns4002:~# cd /srv/authdns/git && utils/deploy-check.py -g /srv/git/netbox_dns_snippets --deploy
Assembling and testing data in /tmp/dns-check.45j_ldfk
 -- Generating zonefiles from zone templates
 -- Processed 203 zones into directory /tmp/dns-check.45j_ldfk/zones
 -- Copying automatically generated zone files under target tree
 -- Copying repo-driven real config files and admin_state
 -- Copying puppetized config and GeoIP from /etc/gdnsd
 -- Checking for illegal tabs in zonefiles
OK: No tabs
 -- Running zone_validator to check WMF rules
Summary of violations:
    W001|MISSING_IP_FOR_NAME_AND_PTR: 381
    W002|MISSING_PTR_FOR_NAME_AND_IP: 47
    W101|MISSING_ASSET_TAG: 262
    W103|MISSING_MGMT_FOR_NAME: 415
    W104|TOO_FEW_MGMT_NAMES: 394
    W105|TOO_MANY_PUBLIC_NAMES: 23
RESULT: 0 Errors, 1522 Warnings, 0 Ignored violations, 0 Ignored lines
 -- Running /usr/sbin/gdnsd checkconf on /tmp/dns-check.45j_ldfk
 -- Preflight checkconf is OK
Deploying from /tmp/dns-check.45j_ldfk to system dirs
 -- Descending to subdirectory: netbox
 -- Done with subdir: netbox
No action needed, zones and config files unchanged
OK

@DubOSv10 thanks for the additional context, but this doesn't meet our current requirements for the need-to-know basis for Netbox, I'm sorry.
Have you tried the unofficial public Netbox demo maintained by the Packet Pusher community? It's already setup with some realistic data.

@Lantus: gentle reminder for the pending acknowledge that everything is working as expected.

@Anthere: gentle reminder for the above request if this request is still valid.

@Tarrow thanks for the detailed explanation.

@Scardenasmolinar: could you also please link your Phabricator account to your official WMF meta account on wiki?
See for example my profile on Phabricator under the MediaWiki User line in the top block: @Volans

@spatton: gentle reminder for the above request.

@Tarrow similar to T248482, could you please elaborate a bit more on the "Reason for access" in the task description regarding how the data you need to access relates to the project you're working on?

@Nuria task description was updated with more details on the reason for access. Over to you for approval.

@Nuria any update on this request?

Re-opening as I forgot also for wmf only group we need to add it to Puppet, doing it now.

I've added the user uid=suecarmol, cn=Scardenasmolinar to the wmf LDAP group after verifying their account on the corp LDAP.
Please verify that everything works as expected.

Looping @KFrancis to verify that we have a valid NDA on file. I can see the line in the related spreadsheet but there are no dates, so asking for confirmation.

So far no more errors in racadm. Let's keep an eye on it, but I'm resolving it for now. Feel free to re-open on re-occurrence.

Looping @KFrancis to verify that we have a valid NDA on file. I can see the line in the related spreadsheet but there are no dates, so asking for confirmation.

@DubOSv10 thanks for your interest. Unfortunately Netbox contains information that may be sensitive in nature, so access to it is restricted on a need-to-know basis.

This is related to T245910, the same disk failed then and from that moment it started logging into racadm some failure that I think led the controller fail today.
I've cleared the foreign config of VD3, deleted the preserved cache for that disk and marked that disk as non-raid in order to make the host boot again (was entering the RAID config menu in the BIOS every time without those actions).

Ok, now the message is more readable:

There are offline or missing virtual drives with preserved cache.
Please check the cables and ensure that all drives are present.
Press any key to enter the configuration utility.

Ack, the host led me into the config anyway, even pressing any key. The configuration was already skipping VD3, and confirmed that the RAID1 where the OS resides is in optimal state.
Host is now re-rebooting.

The change was merged. Let at least 30 minutes pass to make sure that it has been applied everywhere.
Resolving, feel free to re-open in case you encounter any issue.

Yeah, sorry I replied too fast, that's what I was thinking actually, and indeed, we should not have those with role:: at all.

@jbond yes, AFAIK it's when two different roles include the same profile but want to pass different value to the profile parameter based on the role. What would be a better setup for this use case?

Thanks all, resolving. Feel free to follow up for the off-boarding part separately.

I've added the unique list of keys in the task description. I think those with the role:: prefix should be treated separately. At first thought I think those should be ok, what do you think?

@WMDE-leszek at the best of my knowledge this has never been done before for WMDE accounts, see for example this list (thanks to quiddity):
https://meta.wikimedia.org/w/index.php?title=Special:Search&limit=250&offset=0&ns2=1&search=intitle%3A%28wmde%29&advancedSearch-current={}

Change merged, added users theseer, spriebsch and sebastianbergmann to the NDA LDAP group.
Please have them verify they can access the requested resources before resolving the task.

Followed https://wikitech.wikimedia.org/wiki/Mailman#Disable_or_re-enable_a_mailing_list
Mailing list disabled and removed previous admins.

[fermium] ~ $ sudo disable_list reading-wmf
reading-wmf disabled. Archives should be available at current location, all mail should be moderated and the list should not be on the listinfo page.

@MBinder_WMF we're in the process of changing the way we schedule clinic duty, the current person on clinic duty is mentioned in the /topic of the #wikimedia-operations IRC channel and listed in the related wikitech page:

• before: https://wikitech.wikimedia.org/wiki/SRE_Clinic_Duty#Past_rotation_roster
• now: https://wikitech.wikimedia.org/wiki/SRE_Clinic_Duty#Jan-Jun_2020_schedule

@BBlack @crusnov This is the script I use to compare the results P10716 both ways.

ganeti1009 is set as Staged in Netbox and missing in PuppetDB, so it's report by the Netbox report.
What should be the correct state for now?

@elukey you can see the failures here: https://puppetboard.wikimedia.org/node/stat1008.eqiad.wmnet

Although this has been open for a while, it would still be a nice addition to the switchdc cookbooks.

@Aklapper this was for an old iteration of things, I'll go ahead and resolve it. Will also update the subtask accordingly.

@Krenair sure, we'll need to make the buster package anyway for the prod migration. If you have a date in mind for your migration let me know so that I can adjust on when doing the buster package. Should be pretty trivial.