Page MenuHomePhabricator

Server Access for Isaac Johnson
Closed, ResolvedPublic


Today is Isaac Johnson's @Isaac first day and this task is to request server access for him. We still don't have the full account details but will fill them in as soon as poosible.

@Isaac 's email is:
His LDAP username is: Isaac Johnson
His shell user should be: isaacj

Isaac will need to be added to the following groups:

  • analytics-privatedata-users
  • researchers

Isaac please:
[1] Create a LDAP/Phabricator account and edit your details above
[2] Read this
[3] And then sign this:
[4] Generate a dedicated SSH key pair, put your public key on your user page on Office Wiki (see for example:
[5] Post the link to your key in this task

Ops Clinic Duty Checklist for Access Requests

Most requirements are outlined on

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.

  • - User has signed the L3 Acknowledgement of Wikimedia Server Access Responsibilities Document.
  • - 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.
  • - 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

Event Timeline

Miriam triaged this task as High priority.Oct 1 2018, 10:55 AM
Miriam created this task.
Miriam added a subscriber: Isaac.
Isaac updated the task description. (Show Details)

I believe I have completed my bullet points - just let me know if something is checking out!

Thanks @Isaac! Looks like we just need a manager thumbs up here in the task before moving forward with granting access.

Thannks @herron!
@DarTar could you please check this, and if ok, approve it? Thanks!

Change 464605 had a related patch set uploaded (by Herron; owner: Herron):
[operations/puppet@production] admin: add isaacj to analytics-privatedata-users and researchers

@Nuria could you please review/approve the group addition? Thanks in advance!

This comment was removed by herron.

Change 464605 merged by Dzahn:
[operations/puppet@production] admin: add isaacj to analytics-privatedata-users and researchers


on stat1006:

[stat1006:~] $ id isaacj
uid=20171(isaacj) gid=500(wikidev) groups=500(wikidev),714(researchers)

on bast1002:

[bast1002:~] $ id isaacj
uid=20171(isaacj) gid=500(wikidev) groups=500(wikidev),600(all-users)
Dzahn updated the task description. (Show Details)

This is done. Requested access should now work as expected. I can confirm the user has been created on stat1006 and puppet will create it in all other places where "researchers" is used, such as SWAP.

I verified that I can ssh in - thanks all!

Stashbot subscribed.

Mentioned in SAL (#wikimedia-operations) [2018-10-10T16:25:20Z] <mutante> LDAP - added isaacj to wmf group (for SWAP access, existing shell user since recently) (T206631) (T205840)

^ We talked on IRC about SWAP access. Membership in the "wmf" LDAP group was missing. (T206631) So i added that and now all should work.

P.S. The docs on SWAP claim " For WMF employees, this is often already done when production shell access is granted. " but that isn't accurate, there is nothing that would make that happen by default. It is only done by request on a case-by-case basis. For most shell access the LDAP groups don't play any role.