Requesting access for bmansurov to run mwscript in terbium
Closed, ResolvedPublicRequest
Actions

Assigned To

Authored By

	• bmansurov
	Mar 9 2018, 8:08 AM

Description

Username: bmansurov
Full name: Bahodir Mansurov

Research needs access to terbium.eqiad.net in order to send bulk email using sendBulkEmails.php script as part of T184212.

Cc'ing @DarTar in case you need my manager's approval

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.

- 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)
- 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 - https://gerrit.wikimedia.org/r/#/c/419387/

Details

Related Changes in Gerrit:

Subject	Repo	Branch	Lines +/-
Add bmansurov to restricted group instead of maintenance-log-readers	operations/puppet	production	+2 -2
admin: Grant bmansurov access to terbium.eqiad.wmnet	operations/puppet	production	+1 -1
restoring bmansurov shell access	operations/puppet	production	+1 -1
bmansurov's production and cloud keys match	operations/puppet	production	+1 -1

Customize query in gerrit

Related Objects
Search...

Status	Subtype	Assigned	Task
Resolved		leila	T171224 [Objective 9.1.1] Article expansion recommendations
Resolved		leila	T183039 Gather labels as ground truth for translation and synonym section classifiers
Resolved		• bmansurov	T184212 Gather labels as ground truth for section translation
Resolved	Request	MoritzMuehlenhoff	T189285 Requesting access for bmansurov to run mwscript in terbium

Event Timeline

• bmansurov created this task.Mar 9 2018, 8:08 AM

Restricted Application added a project: SRE. · View Herald TranscriptMar 9 2018, 8:08 AM

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

I guess this is what's called restricted in the puppet config.

• bmansurov added a parent task: T184212: Gather labels as ground truth for section translation.Mar 12 2018, 6:12 AM

This could be solved by adding bmansurov to either one of these groups:

admin::groups:
  - restricted
  - deployment
  - ldap-admins
  - maintenance-log-readers

or by adding the "researchers" admin group to the list above. To go more literally with the ticket title.

But probaly adding user(s) to restricted makes the most sense.

This is approved on my end, if manager approval is needed. Thanks for getting the ball rolling, @bmansurov.

Vgutierrez claimed this task.Mar 14 2018, 10:07 AM

Vgutierrez triaged this task as Medium priority.

Change 419387 had a related patch set uploaded (by Vgutierrez; owner: Vgutierrez):
[operations/puppet@production] admin: Grant bmansurov access to terbium.eqiad.wmnet

https://gerrit.wikimedia.org/r/419387

gerritbot added a project: Patch-For-Review.Mar 14 2018, 10:35 AM

The task is now just pending of Monday Ops meeting approval.

RobH updated the task description. (Show Details)Mar 15 2018, 4:37 PM

RobH updated the task description. (Show Details)Mar 16 2018, 4:26 PM

RobH updated the task description. (Show Details)

Change 420064 had a related patch set uploaded (by RobH; owner: RobH):
[operations/puppet@production] bmansurov's production and cloud keys match

https://gerrit.wikimedia.org/r/420064

Please note in reviewing open access requests, I went ahead and checked, and the public ssh key used by @bmansurov on cloud/wikitech is identical to the one used in production.

Since that is not allowed, I've merged live the removal of the ssh key from production. The end result will be @bmansurov's access won't work until he updates this task with a new ssh key, and someone in the SRE team rolls the change live.

I've also emailed @bmansurov so hopefully they are aware of this access revocation.

Change 420064 merged by RobH:
[operations/puppet@production] bmansurov's production and cloud keys match

https://gerrit.wikimedia.org/r/420064

RobH moved this task from Untriaged to user confirm on the SRE-Access-Requests board.Mar 16 2018, 4:42 PM

RobH mentioned this in T189890: add ssh key comparison to cross-validate-accounts.py.Mar 16 2018, 4:47 PM

@RobH thanks for the email with detailed instructions. Here's my new production key:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDo4whVVoxM3qhsE2FPfQslsnkoZMQozoOlQln//9fEqQmm6ixZjrTqBLFlSD88ZBISR/42o7gxhEFNGYud70A46+txvnC5JoQjXlkRcZIhcegO1xJYu+dvmQAOAHSfwnM9XgZd55ib03v3ib8dVlQNwlMbO/ONOsJwwHLBYu43rhI2kimuEP00RvLwA+78S4x8c5E5haHbk063WzVpFAI5ntyAeANJ5EnEfiXhKV2J7R7YazXP178YOkgSRTBHJpb6CNTiuEtWfLCZ1MgS14vypD/cI20SzgvZovPQ/6kdaneziiNIhVLRPbFfVcg0HtvOxlld2NJwJfnkvWRTuJvp bmansurov@wikimedia.org

Change 420080 had a related patch set uploaded (by RobH; owner: RobH):
[operations/puppet@production] restoring bmansurov shell access

https://gerrit.wikimedia.org/r/420080

Change 420080 merged by RobH:
[operations/puppet@production] restoring bmansurov shell access

https://gerrit.wikimedia.org/r/420080

I've restored your shell access, however we'll still need to work on the access request expansion requested on this task.

Ok, sorry for the delay on this, but it turns out everyone seems to have thought someone else was working on it!

So @bmansurov requires access to terbium in order to send bulk email using sendBulkEmails.php script as part of T184212.

Terbium has the following groups allowing access to it:

admin::groups:

restricted
deployment
ldap-admins
maintenance-log-readers

My understanding is the concerns with restricted is it has access to PII data. deployers is (im my viewpoint) a worse option, since they want a single item and deployers would grant them the ability to break a lot of things. I thin giving a staff member 'restricted' is far better than deployers.

Thoughts?

I've gone ahead and modified https://gerrit.wikimedia.org/r/#/c/419387/ to have restricted, not deployers. This is still a sudo group, so this will have to be in next Monday's team meeting review.

RobH updated the task description. (Show Details)Mar 21 2018, 4:00 PM

Not an op, but as I said at T189285#4041129 I think restricted is better as it does not grant any deployment right. I do not know what the maintenance-log-readers group is/does, but if it provides the same access and its even safer then I'd say go for it. Obviously PII is an issue and I feel the Ops should see if they trust the requestor with such an access beforehand. If they do not, then there's no point in continuing the discussion. If he is, and given that his purpose is rather limited to just use a maintenance script, give him access to the more restricted group that allows him to do so -or- create a new group to just run (some) maintenance scripts. My two cents and, just in case, I am not suggesting @bmansurov isn't trusted. Thanks.

I think the best option is using maintenance-log-readers. maintenance-log-readers just give shell on exactly the maintenance servers (currently terbium and wasat) and in addition they have sudo permissions to read syslog and dmesg. That's it, but also what is needed. The second best option is to create another group "maintenance-server-users" that does nothing but the login but i think that's going too far.

In T189285#4069778, @Dzahn wrote:

I think the best option is using maintenance-log-readers. maintenance-log-readers just give shell on exactly the maintenance servers (currently terbium and wasat) and in addition they have sudo permissions to read syslog and dmesg. That's it, but also what is needed. The second best option is to create another group "maintenance-server-users" that does nothing but the login but i think that's going too far.

Updated the patch to reflect the above. Its still a sudo group though, so this is the most restrictived group for terbium to give them what they need to access. They should likely have the sudo rights to read the logs, since they will send out emails via a script.

ACK, +1 on the updated patch

RobH renamed this task from Requesting access to terbium.eqiad.wmnet for bmansurov to Requesting access to terbium/maintenance-log-readers for bmansurov.Mar 26 2018, 3:17 PM

Change 419387 merged by RobH:
[operations/puppet@production] admin: Grant bmansurov access to terbium.eqiad.wmnet

https://gerrit.wikimedia.org/r/419387

@bmansurov: Your access to terbium (via maintenance-log-readers) has been approved and merged live. Please allow up to 30 minutes for the access to update on terbium, and you should be all set.

RobH removed RobH as the assignee of this task.Mar 26 2018, 5:35 PM

Thank you, all.

@RobH I'm unable to send emails using the following command because sudo is asking for my password (which I don't have):

mwscript /srv/mediawiki/php-1.32.0-wmf.5/extensions/WikimediaMaintenance/sendBulkEmails.php --wiki=enwiki --subject "Test email T190776" --body "/home/bmansurov/test-email-body.txt" --from "recommender-feedback@wikimedia.org" --to "/home/bmansurov/test-email-users.txt" --reply-to "recommender-feedback@wikimedia.org" --optout "User:Bmansurov_(WMF)/T190776-opt-out" --dry-run

What should I do to send emails like above?

• bmansurov mentioned this in T190776: Test the model for eliciting new editor interests.May 29 2018, 6:47 PM

You'd need to be in the restricted group to run that. maintenance-log-readers cannot.

• bmansurov renamed this task from Requesting access to terbium/maintenance-log-readers for bmansurov to Requesting access for bmansurov to run mwscript in terbium.May 30 2018, 1:34 PM

• bmansurov reopened this task as Open.

Change 436773 had a related patch set uploaded (by Muehlenhoff; owner: Muehlenhoff):
[operations/puppet@production] Add bmansurov to restricted group instead of maintenance-log-readers

https://gerrit.wikimedia.org/r/436773

Change 436773 merged by Muehlenhoff:
[operations/puppet@production] Add bmansurov to restricted group instead of maintenance-log-readers

https://gerrit.wikimedia.org/r/436773

@bmansurov I changed your group membership, please retry.

@MoritzMuehlenhoff thank you, all good now.

Requesting access for bmansurov to run mwscript in terbiumClosed, ResolvedPublicRequestActions