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
