Change Details

Username: `lucaswerkmeister-wmde` Full name: Lucas Werkmeister Public key: P6884 (freshly generated, private key file protected by a strong password using 100 KDF rounds) Reason: I want to run long-running queries, e. g. to analyze usage of the WikibaseQualityConstraints extension (how many API requests are from our own gadget and how many from other users – cf. T180780) and to determine which logging table patrolling entries refer to autopatrols and can be deleted (see T189594#4071518). == Ops Clinic Duty Checklist for Access Requests == Most requirements are outlined on https://wikitech.wikimedia.org/wiki/Requesting_shell_access This checklist should be used on all access requests to ensure that all steps are covered. This includes expansion to access. Please do not check off items on the list below unless you are in Ops and have confirmed the step. [x] - User has signed the L3 Acknowledgement of Wikimedia Server Access Responsibilities Document. [x] - User has a valid NDA on file with WMF legal. (This can be checked by Operations via the NDA tracking sheet & is included in all WMF Staff/Contractor hiring.) [] - User has provided the following: wikitech username, preferred shell username, email address, and full reasoning for access (including what commands and/or tasks they expect to perform. [x] - User has provided a public SSH key. This ssh key pair should only be used for WMF cluster access, and not share with any other service (this includes not sharing with WMCS access, no shared keys.) [] - access request (or expansion) has sign off of WMF sponsor/manager (sponser for volunteers, manager for wmf staff) [] - non-sudo requests: 3 business day wait must pass with no objections being noted on the task [] - sudo requests: all sudo requests require explicit approval during the weekly operations team meeting. No sudo requests will be approved outside of those meetings without the direct override of the Director of Operations. [] - Patchset for access request - user is in ldap section, will need to be moved up to shell users.

Username: `lucaswerkmeister-wmde` Full name: Lucas Werkmeister Public key: P6884 (freshly generated, private key file protected by a strong password using 100 KDF rounds) Reason: I want to run long-running queries, e. g. to analyze usage of the WikibaseQualityConstraints extension (how many API requests are from our own gadget and how many from other users – cf. T180780) and to determine which logging table patrolling entries refer to autopatrols and can be deleted (see T189594#4071518). == Ops Clinic Duty Checklist for Access Requests == Most requirements are outlined on https://wikitech.wikimedia.org/wiki/Requesting_shell_access This checklist should be used on all access requests to ensure that all steps are covered. This includes expansion to access. Please do not check off items on the list below unless you are in Ops and have confirmed the step. [x] - User has signed the L3 Acknowledgement of Wikimedia Server Access Responsibilities Document. [x] - User has a valid NDA on file with WMF legal. (This can be checked by Operations via the NDA tracking sheet & is included in all WMF Staff/Contractor hiring.) [x] - User has provided the following: wikitech username, preferred shell username, email address, and full reasoning for access (including what commands and/or tasks they expect to perform. [x] - User has provided a public SSH key. This ssh key pair should only be used for WMF cluster access, and not share with any other service (this includes not sharing with WMCS access, no shared keys.) [] - access request (or expansion) has sign off of WMF sponsor/manager (sponser for volunteers, manager for wmf staff) [x] - non-sudo requests: 3 business day wait must pass with no objections being noted on the task - analytics-privatedata-users group [] - sudo requests: all sudo requests require explicit approval during the weekly operations team meeting. No sudo requests will be approved outside of those meetings without the direct override of the Director of Operations. [] - Patchset for access request - user is in ldap section, will need to be moved up to shell users.