Talk:SRE/Production access

Proposed Change for new Hires

Hi!

I propose a change to the new shell request process: No need for the 3 day wait period for new WMF employee shell requests if they are getting the same level of access as others in the same role. For example, a researcher getting stat* access wouldn't have a 3 day wait period. They'd still have to get the other requirements (signoff from manager, etc). This will help ease onboarding for new hires, since otherwise there is a 3 day thumb twiddling period.

Thoughts? I'll mention this during the next ops meeting as well. yuvipanda (talk) 19:51, 27 July 2015 (UTC)

• Opposed: I think we need to have the 3 day no matter what. The fact is, it lets us have time to review if we know the person, and if there is any reason against it. Managers shoudl simply plan this into their onboarding, no one is hired in less than 3 days from position being openly filed to final hiring. --RobH (talk) 19:53, 27 July 2015 (UTC)
• Support. "no matter what" ignores a lot of practicalities; are you likely to know that person? Is this a plausible thing to even happen? What's the most damage they could do if you do? In the case I've got in front of me we're talking about someone nobody (including you, Rob) would've heard of other than me - they're a brand-new CMU grad. They're asking for access to our data machines, not for deploy permission. And we have to wait most of a work week just in case the people monitoring access requests - which is just ops - has heard of them? For a newly graduated researcher? If this is really the direction Operations want to move in it should be backed by actually advertising it and making it explicit. You say "for most requests" in the doc - which requests? Where's the email to engineering@ or wmfall saying "hey, a reminder that we have this policy". Can hiring managers apply before the person's start date? Analysts are just that - analysts - and for very good reason some amount of access is required for them to get pretty much anything done. Ironholds (talk) 20:06, 27 July 2015 (UTC)

How to login?

I can't login to Terbium. I made setting in ".ssh/config" according Production shell access, but server ask the "Password". I have ssh-key to tools.wmflabs.org, passwords for wikimedia.org and for wikitech.wikimedia.org, these don't fit. --Vladis13 (talk) 07:34, 14 March 2018 (UTC)

Vladis13 Terbium is intended to run Wikimedia maintenance scripts, with an access to the production database.

As such, the access is restricted to system administrators.

If you wanted to connect somewhere else, like on Wikimedia Cloud, you can ask for assistance on IRC FreeNode #wikimedia-cloud.

--dereckson (talk) 21:40, 21 March 2018 (UTC)

Still, it shouldn't ask for a generic password, right? Each sysadmin should be granted access by their SSH keys. MarcoAurelio (talk) 21:42, 21 March 2018 (UTC)

I see. Then need to noting this in the manual. --Vladis13 (talk) 22:39, 21 March 2018 (UTC)

Procedure for new computer

Hi, I have a new laptop. Is it a good idea to move my existing keys from one to the other or should I generate new ones?

Sbisson (talk) 12:59, 27 March 2019 (UTC)

Generate new keys. As it was put in https://wikitech.wikimedia.org/wiki/SRE/Production_access#Generating_your_SSH_key:

Do not reuse an existing key; this presents an unacceptable security risk.

Razzi (talk) 21:06, 7 January 2022 (UTC)

@Razzi: interesting! I have been told something different by someone in SRE (I don't remember who exactly): that as long as we never lose control of the devices or store it unencrypted, it's fine to move a key from one device to another. What's your reason for saying the opposite? Mandating that folks file a new ticket requesting a key update every time they have to change laptops would create a lot of extra work, so it seems like we shouldn't do it without a clear reason.—Neil P. Quinn-WMF (talk) 21:24, 7 January 2022 (UTC)

Cloud VPS SSH config in another article

Help:Accessing_Cloud_VPS_instances#Accessing_Cloud_VPS_instances has an SSH config section as well - does that warrant mention in this article alongside the larger SSH config? Perhaps as a {{see also}} template? --BCornwall (talk) 17:58, 18 May 2022 (UTC)

That doc page is linked to from SRE/Production access#See also currently. Adding a see also hatnote in the "Setting up your SSH config" subsection seems like it would be fine if folks fell that there is enough overlap to be useful. -- BryanDavis (talk) 18:05, 18 May 2022 (UTC)