Along the same line, I wonder if bigtop community has considered to have a shell that allows single point of entry to any of the upstream systems. Something like mvn or git command. This will introduce something to learn at first but it adds value to start/stop/access help for all systems in a consistent way. It can also shield some changes that happens with upstream systems. Instead of dealing with some many <XXX>_HOME, we could have one BIGTOP_HOME. It's quite nice to be able to say: bigtop -help bigtop -start <xxx|all>
David On 5/2/12 10:49 AM, "Peter Linnell" <[email protected]> wrote: >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 >
