Thanks guys for joining the discussion, I hope you don't mind if I continue to
argue a bit more.
The core intelligence and functionality of Cassandra server lays in the Java
classes, which reside in jar archives. This is the place where the main
functionality updates take place. To ease the use of the classes there is,
let's call it "wrapper" script (bin/cassandra), which sets up the environment
for the classes to provide the functionality. This wrapper uses two other
scripts: one of which sits in bin (the include) and the other in etc (the env
file). I agree that the files in bin should not be edited by the users, but the
following quotes from the wrapper script state the opposite:
"Any serious use-case though will likely require customization of the include."
"Developers and enthusiasts can put a customized include file at
~/.cassandra.in.sh."
According to these the include file is no different from the environment file.
But why would you have two separate files meant for the same purpose? What is
more important is that to "configure" the options in both scripts the user has
to be somewhat familiar with bash. The "bashy" stuff could be well hidden from
the user in the wrapper script and the configuration options could be sitting
in the cassandra.yaml file in the key-value pairs fashion like the other ones.
When solving some issues that the users run into they would provide just a
single configuration file and the maintainer would easily reproduce the issue
by plugging in the single config file. Regarding the updating, only the wrapper
script would be updated of course and the user modified config file would stay
untouched in etc directory. Speaking about flexibility and the use-case when
there is a upstream default, admin specific and user specific configuration, it
is not a problem at all. Making the config file modular would do the job. There
won't be any duplicity. In case user does not care about the configuration and
just wants to run the server out of the box there are always default options
embedded in the java classes.
What do you think? I don't think my solution is ideal and I'd be glad to hear
where my assumptions are wrong.
Tomas
- Original Message -
> 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
-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
