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
