I'd like ssh access and some reasonable privileges on the production boxes, if that's the norm for our team.
Description
Details
Subject | Repo | Branch | Lines +/- | |
---|---|---|---|---|
admins: Add awight to ores-admins | operations/puppet | production | +1 -1 |
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Resolved | None | T168917 Get Adam all the rights | |||
Resolved | awight | T168442 Grant AWight accounts on ores production clusters |
Event Timeline
@akosiaris: Hey, @awight is joing Scoring platform team, do you think this needs to go through normal access requests period as Adam is already staff.
FWIW, I see that I have access to tin and can presumably deploy there. However, I don't have ssh access to the canary server scb1002 or any of the other workers. This might be the correct access level for my team, in which case I think we're finished here. Let me know!
Please note that being staff doesn't exempt anyone from any of the steps for access requests. So we'd have to confirm everything anyhow if this was a brand new request. Since he already has shell access, this is merely increasing the access. This included me auditing L3 (@awight has already signed it), and confirming they already exist in the admin module with an active user (he does.)
However, it still isn't clear if this request is needed for increased access levels to the scb1002 (and assorted cluster?)
@awight: Can you please provide details as to exactly what servers or data that you need access to, but do not currently have?
@RobH Thanks, I think I've determined I have appropriate access to deploy, and will deal with anything extra in additional requests, if it turns out I was wrong...
Looks like I'll need shell access to scb1002.eqiad.wmnet, in order to do canary tests while deploying. I don't seem to have that access yet, please let me know if I should provide any more info!
Sounds like I'll need shell on scb[1-2]* and also the ores-admin group, so I can do terrible things on production boxes.
Change 361593 had a related patch set uploaded (by Ladsgroup; owner: Amir Sarabadani):
[operations/puppet@production] Add awight to ores-admins
Addition to the ores-admins is a sudo group, and thus will require review during the weekly operations meeting on Monday.
Also no one reopened this when requesting more rights be added, opening it back up now.
My fault, I've been flapping this task like crazy... T168442#3380731
Thanks for taking a look!
Change 361593 merged by Dzahn:
[operations/puppet@production] admins: Add awight to ores-admins
You have been added to the ores-admins group. This was approved in today's ops meeting.
This gives you access to "service b" nodes. Such as, for example:
Notice: /Stage[main]/Admin/Admin::Groupmembers[ores-admin]/Exec[ores-admin_ensure_members]/returns: executed successfully Notice: Finished catalog run in 17.00 seconds [scb1001:~] $ id awight uid=4974(awight) gid=500(wikidev) groups=500(wikidev),782(ores-admin)
but also all these: node /^scb[12]00[123456]\.(eqiad|codfw)\.wmnet$/ {
I ran puppet on scp1001/2001 to confirm, the others will happen automatically within the next 30 min.
This is what you can run as root:
[scb2001:~] $ sudo cat /etc/sudoers.d/ores-admin # This file is managed by Puppet! %ores-admin ALL = NOPASSWD: /usr/sbin/service uwsgi-ores * %ores-admin ALL = NOPASSWD: /usr/sbin/service celery-ores-worker *