Re: Handling migrations if dbScript exists in snapshot?

I sent out a review for a prototype of my proposed migration system here: https://reviews.apache.org/r/45467/ Please take a look at the review and let me know if it seems reasonable at a high level (noting the caveats called out in the review description, this is not production quality code,

Re: Looking for feedback - Setting CommandInfo.user by default when launching tasks.

Aha, i think we have different notions of the proposal. I was under the impression that the executor itself would run as the target user (e.g. steve), not as a system user (e.g. aurora). I find the former more appealing, with the exception that it leaves us without a solution for concealing the

Re: Looking for feedback - Setting CommandInfo.user by default when launching tasks.

If i'm understanding you correctly, that doesn't address preventing users from reading the credentials though. On Tue, Mar 29, 2016 at 1:52 PM, John Sirois wrote: > On Tue, Mar 29, 2016 at 2:31 PM, Steve Niemitz > wrote: > > > So maybe we add it, but

Re: Looking for feedback - Setting CommandInfo.user by default when launching tasks.

On Tue, Mar 29, 2016 at 2:31 PM, Steve Niemitz wrote: > So maybe we add it, but don't change the current default behavior? > Could we use the CommandInfo.uris [1] to solve this? IE: the scheduler would need to learn the credential file path, and with that knowledge, the

Re: Looking for feedback - Setting CommandInfo.user by default when launching tasks.

So maybe we add it, but don't change the current default behavior? On Tue, Mar 29, 2016 at 4:26 PM, Bill Farner wrote: > I'm in favor of moving forward. There's no requirement to use the > Announcer, and a non-root executor seems like a useful option. > > On Tue, Mar 29,

Re: Looking for feedback - Setting CommandInfo.user by default when launching tasks.

I'm in favor of moving forward. There's no requirement to use the Announcer, and a non-root executor seems like a useful option. On Tue, Mar 29, 2016 at 1:00 PM, Steve Niemitz wrote: > Makes sense, I guess it can be up to the cluster operator which model to > choose. Is

Re: Looking for feedback - Setting CommandInfo.user by default when launching tasks.

Makes sense, I guess it can be up to the cluster operator which model to choose. Is there any interest in the feature I proposed or should I just drop it? It's not a lot of code, but also it's not a requirement for anything we're working on either (the docker stuff however, is). On Tue, Mar 29,

Jenkins build is back to normal : Aurora #1441

See

Re: Looking for feedback - Setting CommandInfo.user by default when launching tasks.

That's correct - those credentials should require privileged access. On Tue, Mar 29, 2016 at 10:25 AM, Steve Niemitz < sniem...@twitter.com.invalid> wrote: > Re: ZK credential files, thats an interesting issue, I assume you don't > want the role user to be able to read it either, and only root

Re: Looking for feedback - Setting CommandInfo.user by default when launching tasks.

Re: ZK credential files, thats an interesting issue, I assume you don't want the role user to be able to read it either, and only root or some other privileged user? On Tue, Mar 29, 2016 at 12:14 PM, Erb, Stephan wrote: > I am in favor of your proposal. We offer

Re: Looking for feedback - Setting CommandInfo.user by default when launching tasks.

I am in favor of your proposal. We offer less attack surface if the executor is not running as root. Interesting though, this introduces another security problem: The credentials file in the incoming Zookeeper ACL patch (https://reviews.apache.org/r/45042/) will have to be readable by