Last modified: 2014-10-16 12:11:41 UTC
Having a 'shell' keyword implies that one has access to all machines or none, but our current permission scheme is more nuanced than that. A schema that maps accurately to the ACLs laid out in operations/puppet:manifests/admins.pp might be good, with keywords for 'root', 'mortal', and 'restricted'.
Which problem is currently created by this general keyword?
Hmmmm. If we could clarify/cleanup the "ops"/"shell" confusion, that might be a nice enhancement. I'm not sure I like the keywords as individual words (particularly "restricted"), but that's likely fixable with additional words (e.g., "needs-root" or "restricted-sysadmin" or something). We must also take note that process documentation all over the Wikimedia ecosystem refers to the "shell" keyword (e.g., for submitting [[m:wiki configuration requests]]). So any plan that removes the "shell" keyword would need a communication strategy.
I agree, there are tasks that can be done by a shell user on fenari, let's say deploy an Apache config change, that doesn't need root, while other things do actually need root users. split into "shell" and "roots"
P.S. even that is technically not catching all, because we also have people with root on one specific box, like "jenkins admins" or "parsoid admins" or "gerrit admins" that don't have global root.
(In reply to comment #4) > P.S. even that is technically not catching all, because we also have people > with root on one specific box, like "jenkins admins" or "parsoid admins" or > "gerrit admins" that don't have global root. Right. We already have "shell" and "ops" (where "ops" is basically a synonym for "root"). Perhaps renaming "ops" to "root(s)" might make sense, but then we're getting closer to Ori's original suggestion to just rely on the actual Puppet definitions.
(In reply to comment #4) > P.S. even that is technically not catching all, because we also have people > with root on one specific box, like "jenkins admins" or "parsoid admins" or > "gerrit admins" that don't have global root. So would those take "root" or "shell" because it's less then true root? Looks like a can of worms, and still no answer to comment 1.
well, the "problem" is that we had bugs sitting there with "shell" keyword which made people think it needs ops but then a bunch of them actually did not, as they just needed people from platform.
If we (royal we, not me because I don't understand the infrastructure enough [yet]) could list for which usecases on which machines which kind of access is needed we certainly can differentiate here, but I'd need to explain / link to such an explanation/wikipage in the description of the affected keywords, otherwise at least I would likely continue to flag requests incorrectly from time to time...
My 2cents: shell : anyone with access to bastion and able to deploy code changes ops : for roots :-]
(In reply to comment #9) > My 2cents: > > shell : anyone with access to bastion and able to deploy code changes > ops : for roots :-] That's not bad, except for the names: 'shell' is opaque with respect to what users in the group can actually do, and 'ops' includes some people outside of operations (Tim, Roan, etc.). So I'd rename that to 'deployment'. (In reply to comment #8) > ... for which usecases on which machines which kind of access is needed ... (I'm painting with a broad brush.) deployment ---------- * Ability to change MediaWiki configurations. * Ability to deploy code changes to MediaWiki (core and extensions). * Ability (..but sometimes not authority) to read and modify data from the production databases that power Wikimedia wikis. root ---- All of the above, plus root shell everywhere. On Bugzilla, the need for this level of access comes up most often in relation to Wikimedia tools that are (a) not directly tied to MediaWiki and (b) have not been fully puppetized. Examples: Bugzilla, OTRS, Wikimedia blog.
Dropping another aspect here so I won't forget it: "Ready for action" vs "would need shell access in the future" <andre__> Hi Nemo_bis, why did you remove the "shell" keyword on https://bugzilla.wikimedia.org/show_bug.cgi?id=45764 and some others? <Nemo_bis> shell is only for bugs ready for shell <Nemo_bis> a site request can either have shell if ready, shellpolicy if consensus has to be found etc., nothing if not ready (e.g. request to run a maintenance script that doesn't yet exist) <Nemo_bis> or at least that's how I was told in the last few years <andre__> that's not clear from https://bugzilla.wikimedia.org/describekeywords.cgi
(In reply to comment #11) > Dropping another aspect here so I won't forget it: > "Ready for action" This is what "shell" means; clarification filed as bug 46781. > vs "would need shell access in the future" All bugs in "Site requests" do (whatever the keyword), and all bugs which do should probably be in "Site requests". The pseudo site requests that don't require shell (like, fixing MediaWiki:Common.css on some wiki) go to General/Unknown.
(from bug 59711) I think the "shell" keyword should only be used for things that volunteers can't submit to gerrit, like requests to run maintenance script. That way it would help to focus what bugs the shell users themselves need to go and work on. Patches written by volunteers go to the Gerrit review queue, and the bugs have PATCH_TO_REVIEW status, so the shell keyword is redundant and needless for these bugs. I guess it is up to the shell users to decide how their keyword is used. It should reflect their workflow.
No use case provided still. A use case would be someone who steps up to say "I commit to watch all bugs of the kind X which are currently marked as shell, if they're instead marked in Y way".
