incubator-bigtop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Mahé <bm...@apache.org>
Subject Re: Guarding against the use of upstream scripts
Date Wed, 02 May 2012 17:46:25 GMT
On 05/02/2012 08:34 AM, Roman Shaposhnik wrote:
> Guys,
> 
> I've noticed lately that new users of the Bigtop distro fall prey
> to thinking that they can simply utilized upstream launcher scripts
> as is by running them from under /usr/lib/<component>bin
> directories. Something this works. More often it doesn't.
> For example, in order for the hadoop scripts to work the users
> actually need to
>    export  HADOOP_LIBEXEC_DIR
> properly.
> 
> In case of Zookeeper there's more stuff to be setup in the env.
> before you can actually execute upstream scripts.
> 
> Most of these issues have to do with a tendency of upstream
> scripts to cater to the dev. environment where keeping logs, etc.
> in /tmp is perfectly fine. For Bigtop we have to override that and
> the place we do that is in /usr/bin/<component> launcher
> scripts.
> 
> Now the question is -- should we go out of our way to not
> let the users shoot themselves in the feet with trying to
> launch scripts that may fail in the Bigtop setting?
> 
> I could imagine that one approach could be removing an
> executable bit from them. That way we can still leverage
> the code in our /usr/bin scripts by passing the scripts
> as arguments to bash/sourcing, but the users won't be
> able to (easily) execute them directly. We can augment this
> strategy with moving these upstream script from under
> /usr/lib/<component>/bin -> /usr/lib/<component>/libexec
> to further strengthen the fact that they are not supposed
> to be executed directly.
> 
> What do you all think?
> 
> Thanks,
> Roman.
> 
> P.S. I guess there are 2 questions I'm asking really:
>    * is this worth attacking
>    * what would the most effective approach be


Great idea!

I would be a favor of starting with disabling the execution bit and see
how it goes.
This is easier and less intrusive than moving files around.

We can always move the files at a later point if necessary.

Thanks,
Bruno

Mime
View raw message