Re: Three scripts needed to run the server, Why?

[Murukesh Mohanan]

Also, you can use bash to debug bin/cassandra:

PS4=' $BASH_SOURCE:$LINENO:   ' bash -x bin/cassandra

This should print the filename of the file being executed/sourced and the line 
number being currently executed, so it should be easier to find out what 
happened, where and when. Of course, /bin/sh need not be bash, but I'm not sure 
what the equivalent method would be for dash or other shells.

On 2017-07-12 00:15 (+0900), "Murukesh Mohanan" 
wrote: 
> What you complain about may be useful to someone else who might appreciate 
> the added flexibility. I'd personally be opposed to a single script, as I'd 
> rather not edit something that might cause conflicts or be overwritten on 
> upgrades (the location of the include and environment files being 
> configurable mean that they can be in an entirely different corner of the 
> filesystem).
> 
> I can also think of cases where having two configurable files is useful. For 
> example, as an administrator, I'd keep everything in the cassandra install 
> directory read-only except for upgrades, then keep a common include file for 
> my users with some common configuration for my server, and let the users use  
> `$CASSANDRA_CONF` (the directory where the environment file is) to configure 
> everything else they wish for running their instances of Cassandra taking 
> advantage of the common install and base setup. Admittedly this isn't a 
> common use case.
> 
> If you're modifying bin/cassandra, then you're doing it wrong, IMHO. Only two 
> files need to be examined: the (an?) included file and the environment file. 
> And if you simply need to override a setting, then, you can just use the 
> environment file as the ultimate override, since it is sourced after the 
> include (not by it).
> 
> On 2017-07-11 23:39 (+0900), Tomas Repik  wrote: 
> > Thanks for the answer, it did not help much. I have read this several times 
> > and this I already know, It still does not answer the question, why there 
> > is the need for three files instead of a single file. Not to mention 
> > multiple different config files.
> > All these files are more or less configuration file which set up the 
> > environment and properties of the server. Why can't there be a single file 
> > that one would modify in order to tweak the server to his or her needs. In 
> > the current situation you have to search many different files to find the 
> > place where the option is configured.
> > 
> > - Original Message -
> > > 
> > > The bin/cassandra script has an explanation
> > > (https://github.com/apache/cassandra/blob/trunk/bin/cassandra#L24):
> > > 
> > > # As a convenience, a fragment of shell is sourced in order to set one or
> > > # more of these variables. This so-called `include' can be placed in a
> > > # number of locations and will be searched for in order. The lowest
> > > # priority search path is the same directory as the startup script, and
> > > # since this is the location of the sample in the project tree, it should
> > > # almost work Out Of The Box.
> > > #
> > > # Any serious use-case though will likely require customization of the
> > > # include. For production installations, it is recommended that you copy
> > > # the sample to one of /usr/share/cassandra/cassandra.in.sh,
> > > # /usr/local/share/cassandra/cassandra.in.sh, or
> > > # /opt/cassandra/cassandra.in.sh and make your modifications there.
> > > #
> > > #[...]
> > > #
> > > # If you would rather configure startup entirely from the environment, you
> > > # can disable the include by exporting an empty CASSANDRA_INCLUDE, or by
> > > # ensuring that no include files exist in the aforementioned search list.
> > > # Be aware that you will be entirely responsible for populating the needed
> > > # environment variables.
> > > 
> > > You can use just a single environment file, if you so wish.
> > > 
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > 
> > 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 
> 

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Three scripts needed to run the server, Why?

[Murukesh Mohanan]

What you complain about may be useful to someone else who might appreciate the 
added flexibility. I'd personally be opposed to a single script, as I'd rather 
not edit something that might cause conflicts or be overwritten on upgrades 
(the location of the include and environment files being configurable mean that 
they can be in an entirely different corner of the filesystem).

I can also think of cases where having two configurable files is useful. For 
example, as an administrator, I'd keep everything in the cassandra install 
directory read-only except for upgrades, then keep a common include file for my 
users with some common configuration for my server, and let the users use  
`$CASSANDRA_CONF` (the directory where the environment file is) to configure 
everything else they wish for running their instances of Cassandra taking 
advantage of the common install and base setup. Admittedly this isn't a common 
use case.

If you're modifying bin/cassandra, then you're doing it wrong, IMHO. Only two 
files need to be examined: the (an?) included file and the environment file. 
And if you simply need to override a setting, then, you can just use the 
environment file as the ultimate override, since it is sourced after the 
include (not by it).

On 2017-07-11 23:39 (+0900), Tomas Repik  wrote: 
> Thanks for the answer, it did not help much. I have read this several times 
> and this I already know, It still does not answer the question, why there is 
> the need for three files instead of a single file. Not to mention multiple 
> different config files.
> All these files are more or less configuration file which set up the 
> environment and properties of the server. Why can't there be a single file 
> that one would modify in order to tweak the server to his or her needs. In 
> the current situation you have to search many different files to find the 
> place where the option is configured.
> 
> - Original Message -
> > 
> > The bin/cassandra script has an explanation
> > (https://github.com/apache/cassandra/blob/trunk/bin/cassandra#L24):
> > 
> > # As a convenience, a fragment of shell is sourced in order to set one or
> > # more of these variables. This so-called `include' can be placed in a
> > # number of locations and will be searched for in order. The lowest
> > # priority search path is the same directory as the startup script, and
> > # since this is the location of the sample in the project tree, it should
> > # almost work Out Of The Box.
> > #
> > # Any serious use-case though will likely require customization of the
> > # include. For production installations, it is recommended that you copy
> > # the sample to one of /usr/share/cassandra/cassandra.in.sh,
> > # /usr/local/share/cassandra/cassandra.in.sh, or
> > # /opt/cassandra/cassandra.in.sh and make your modifications there.
> > #
> > #[...]
> > #
> > # If you would rather configure startup entirely from the environment, you
> > # can disable the include by exporting an empty CASSANDRA_INCLUDE, or by
> > # ensuring that no include files exist in the aforementioned search list.
> > # Be aware that you will be entirely responsible for populating the needed
> > # environment variables.
> > 
> > You can use just a single environment file, if you so wish.
> > 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 
> 

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Three scripts needed to run the server, Why?

[Michael Shuler]

Standard unix/linux systems policy is that editable configurable files
go under /etc. It is not proper to edit files under /{s}bin or
/usr/{s}bin. $PATH contains /{s}bin and /usr/{s}bin files as executables
that can be run by a user, so that's why the basic separation of the
runnable files and tunable configuration files that are intended to be
edited.

There may be multiple executables in /{s}bin and /usr/{s}bin that use
the common configurations under /etc - they may not be just single
purpose. If there were all configs contained in each executable script,
we would be repeating ourselves, as well as possibly creating unexpected
results, if they are not all aligned by the user.

Additionally, package managers like apt and rpm should not overwrite
configuration files, if they have been edited, so hopefully, upgrades
won't hose a user-edited change under /etc. (Back them up, regardless).
If there is a fundamental change to the executables it /usr/{s}bin, they
will be overwritten by package managers, since users are expected to not
edit those.

This is all really basic system administration and common policy for
most different software packages. Group common configs where they are
meant to be edited and split out various configs when it makes sense or
they may be utilized by various executables.

The user may deviate from these common practices as they see fit, but
may also introduce self inflicted problems. :)

-- 
Kind regards,
Michael

On 07/11/2017 09:39 AM, Tomas Repik wrote:
> Thanks for the answer, it did not help much. I have read this several
> times and this I already know, It still does not answer the question,
> why there is the need for three files instead of a single file. Not
> to mention multiple different config files. All these files are more
> or less configuration file which set up the environment and
> properties of the server. Why can't there be a single file that one
> would modify in order to tweak the server to his or her needs. In the
> current situation you have to search many different files to find the
> place where the option is configured.
> 
> - Original Message -
>> 
>> The bin/cassandra script has an explanation 
>> (https://github.com/apache/cassandra/blob/trunk/bin/cassandra#L24):
>>
>>
>> 
# As a convenience, a fragment of shell is sourced in order to set one or
>> # more of these variables. This so-called `include' can be placed
>> in a # number of locations and will be searched for in order. The
>> lowest # priority search path is the same directory as the startup
>> script, and # since this is the location of the sample in the
>> project tree, it should # almost work Out Of The Box. # # Any
>> serious use-case though will likely require customization of the #
>> include. For production installations, it is recommended that you
>> copy # the sample to one of /usr/share/cassandra/cassandra.in.sh, #
>> /usr/local/share/cassandra/cassandra.in.sh, or #
>> /opt/cassandra/cassandra.in.sh and make your modifications there. 
>> # #[...] # # If you would rather configure startup entirely from
>> the environment, you # can disable the include by exporting an
>> empty CASSANDRA_INCLUDE, or by # ensuring that no include files
>> exist in the aforementioned search list. # Be aware that you will
>> be entirely responsible for populating the needed # environment
>> variables.
>> 
>> You can use just a single environment file, if you so wish.
>> 
> 
> -
>
> 
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Three scripts needed to run the server, Why?

[Tomas Repik]

Thanks for the answer, it did not help much. I have read this several times and 
this I already know, It still does not answer the question, why there is the 
need for three files instead of a single file. Not to mention multiple 
different config files.
All these files are more or less configuration file which set up the 
environment and properties of the server. Why can't there be a single file that 
one would modify in order to tweak the server to his or her needs. In the 
current situation you have to search many different files to find the place 
where the option is configured.

- Original Message -
> 
> The bin/cassandra script has an explanation
> (https://github.com/apache/cassandra/blob/trunk/bin/cassandra#L24):
> 
> # As a convenience, a fragment of shell is sourced in order to set one or
> # more of these variables. This so-called `include' can be placed in a
> # number of locations and will be searched for in order. The lowest
> # priority search path is the same directory as the startup script, and
> # since this is the location of the sample in the project tree, it should
> # almost work Out Of The Box.
> #
> # Any serious use-case though will likely require customization of the
> # include. For production installations, it is recommended that you copy
> # the sample to one of /usr/share/cassandra/cassandra.in.sh,
> # /usr/local/share/cassandra/cassandra.in.sh, or
> # /opt/cassandra/cassandra.in.sh and make your modifications there.
> #
> #[...]
> #
> # If you would rather configure startup entirely from the environment, you
> # can disable the include by exporting an empty CASSANDRA_INCLUDE, or by
> # ensuring that no include files exist in the aforementioned search list.
> # Be aware that you will be entirely responsible for populating the needed
> # environment variables.
> 
> You can use just a single environment file, if you so wish.
> 

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Three scripts needed to run the server, Why?

[Murukesh Mohanan]

The bin/cassandra script has an explanation 
(https://github.com/apache/cassandra/blob/trunk/bin/cassandra#L24):

# As a convenience, a fragment of shell is sourced in order to set one or
# more of these variables. This so-called `include' can be placed in a 
# number of locations and will be searched for in order. The lowest 
# priority search path is the same directory as the startup script, and
# since this is the location of the sample in the project tree, it should
# almost work Out Of The Box.
#
# Any serious use-case though will likely require customization of the
# include. For production installations, it is recommended that you copy
# the sample to one of /usr/share/cassandra/cassandra.in.sh,
# /usr/local/share/cassandra/cassandra.in.sh, or 
# /opt/cassandra/cassandra.in.sh and make your modifications there.
#
#[...]
# 
# If you would rather configure startup entirely from the environment, you
# can disable the include by exporting an empty CASSANDRA_INCLUDE, or by 
# ensuring that no include files exist in the aforementioned search list.
# Be aware that you will be entirely responsible for populating the needed
# environment variables.

You can use just a single environment file, if you so wish.

On 2017-07-11 23:08 (+0900), Tomas Repik  wrote: 
> Greetings,
> 
> I've been working with Cassandra for more than a year but I still wonder 
> about one thing:
> 
> To run the server there is a bash script (cassandra) which uses another 
> script (cassandra.in.sh) which uses yet another bash script 
> (cassandra-env.sh).
> What is the reason behind this?
> Why there is not only a single file setting up the environment and running 
> the server? 
> 
> Thanks for your answers
> 
> Tomas
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 
> 

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Three scripts needed to run the server, Why?

[Tomas Repik]

Greetings,

I've been working with Cassandra for more than a year but I still wonder about 
one thing:

To run the server there is a bash script (cassandra) which uses another script 
(cassandra.in.sh) which uses yet another bash script (cassandra-env.sh).
What is the reason behind this?
Why there is not only a single file setting up the environment and running the 
server? 

Thanks for your answers

Tomas

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org