On 05/02/2012 10:46 AM, Bruno Mahé wrote:
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
+1 As well. I just would add this to a readme or in the release notes
with an explanation why this is done.
Thanks,
Peter
