On 11/29/2017 02:04 PM, Stephen John Smoogen wrote: > On 29 November 2017 at 12:29, Dusty Mabe <dusty@xxxxxxxxxxxxx> wrote: >> >> >> So let's develop a set of sudo rules so I can only run certain commands? >> > > That sounds good but isn't what you asked for. This may sound like a > "but it should be clear that isn't what I wanted" but it isn't. My initial email in this thread listed out specific things and did not ask for root access. Patrick explained to me that "you're asking for root access", so yes then I said: "sure I guess i'm asking for root access". You voiced concern. To curb that I suggested sudo rules for those things I asked for in the original email. > Most > requests for root from various projects has been for complete root and > any amount of sudo rules gets them cranky. Which makes us reflex to > assuming that a person is asking for what they know they require. > > Writing limited sudo commands is also hard because it is very easy to > leave something open which goes BOOM.. we have done it to ourselves a > lot and found that there is no shortcut to writing a command. It > usually means making it very very limited and then opening it up > slower and slower until it does what the person wants while we have a > limited amount of risk. We can do this but expect that there will be a > long period of "it doesn't do X", "ok try now" "I have lost Y" "ok why > do you need Y?" "well it needs to get W working". And then a bunch "oh > huh, I never knew it used Z" I really only need a few things. sudo rule to allow me to kick off composes and/or resubmit koji tasks and a few sudo rules to give me "read-only" access to the filesystems/logs/rpm db of the builders. read/write access to /mnt/koji (for admining the ostree repos) might be a difficult sudo rule to write, but should be able to do it. > > That requires a lot of documentation on processes all around. > >>> And when things fail, those of us in root are the ones who >>> collectively get blamed for it. >> >> Possible blame is definitely something I worry about when requesting >> access like this. I do propose that I work with some bumpers (i.e. >> only doing things after I get someone to review it, announcing things >> i'm going to do). Basically I would be in FBR mode all the time, except >> after I get reviewed I can actually do the work myself. >> > > I am not clear on FBR means in this context. I am used to the context > Full Blown Root which is not what you are meaning. Freeze Break Request. When we are in freeze we have to ask for an FBR for everything and we typically get things reviewed more often. I think it should be like this more of the time, or at least have some system in place where actions get reviewed more often. > >> Why did you let smooge have rights to >>> the system? Why did you not check his actions before he did them. How >>> did you not catch a ... in that line of code? It may all sound like >>> reasonable questions but to the people who are dealing with the >>> problem it gets picked up as "How did you let this moron ever do >>> this?" And because things fail so much.. it eventually comes across as >>> "You people are completely inept". >>> >>> All of this: >>> * High chance that someone as root is going to make a mistake and the >>> more people who have it more likely. >>> * High chance that some systems will catch fire through all the rest >>> of infrastructure >>> * Perceived blame >>> >>> makes that adding anyone else a very difficult process. We can be >>> prickly because of 3 and should mitigate it, but the real problem are >>> the first two in the list. >>> >> >> yes, hopefully the infra becomes less kerosene over time, but I'd like to >> be part of the solution there rather than just someone waiting on it to > > I think infrastructure will always be keroseney by the nature of > trying to make radical changes every 6 months. The best we can hope > for at times is that a contained fire will take out enough old stuff > we can build the new refinery on top of it.> <jokes> Then we should give everyone root access :). One controlled burn coming right up! /me runs out and buys a mac because they'll just give anyone root! </jokes> >> happen. I'm mostly here to offer help and also deliver/release atomic host >> every two weeks. Often times this means I find issues before anyone else >> does (because I'm releasing tomorrow and not 6 months from now). This translates >> mostly into: I help fix problems before other people even notice they are >> problems. This translates into: I think I do more good than harm. The >> jury is out on that, though. > > I am not sure I want the jury's opinion on myself. > > >> Dusty > > > _______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx
