incubator-bigtop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roman Shaposhnik <>
Subject Guarding against the use of upstream scripts
Date Wed, 02 May 2012 15:34:47 GMT

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

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

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?


P.S. I guess there are 2 questions I'm asking really:
   * is this worth attacking
   * what would the most effective approach be

View raw message