Jeffrey Altman wrote:
[email protected] wrote:
A separate configuratrion file is not the best solution for all cases
or for all administrators. Nevertheless it can be useful.
No one has suggested that we are getting rid of the existing
command-line interface
In my eyes a separate file containing the necessary configuration settings
as command line arguments is no worse than a different syntax, without
imposing a need for extra efforts.
There are several problems with using the command line:
1. If all you are doing is setting a single value such as
"rxmaxmtu=1200", that is conveniently represented on the command
line. However, if you need to represent a complex data structure
such as a multi-dimensional table using the command line is very
user unfriendly and error prone.
2. On some systems the length of the command line is limited in length.
As a result it becomes impossible to configure everything via the
command line. [On some systems that might be considered for
future support there is no command line at all.]
3. The usage model is different. With a command line all options
that are specified must be understood or the application is supposed
to fail. With a configuration file, the contents of the
configuration are polled. Unrecognized options are silently
ignored. This permits a single configuration file to be used
with multiple versions / builds some of which might contain
experimental features that are being tested.
4. Adding each and every configuration option to the command line
is user unfriendly. There are literally hundreds of compile time
values (most not configurable without a source code editor) that
could be exposed for run time configuration. This would permit
a wide range of values to be altered easily in order to tune the
behavior of the AFS service to specific environments. Why should
the absolute number of client hosts be hard coded to an arbitrary
value picked in the early 90s? Why should the callback expiration
behaviors (a complex table) be restricted to an arbitrary set?
I would suggest to rely on a separate program to process a config file
with the syntax of your choice and produce command line options to give
to the binaries.
I suggest at the same time to deliberately make the syntax nearly
identical to the command line options one. Then the parsing program
will be trivial -- like "grep -v '^#'" -- and there will be no learning
threshold for maintaining the configuration in its "config file" form.
This assumes that there is an external program that can be used to
wrap. This assumption is not going to be valid in all environments.
There will be also full backward compatibility with the existing
scripts and no need to modify the existing programs.
There is no need for backward compatibility. We are not removing the
existing command line options. We are also not ruling out adding
new ones as they are appropriate.
Rationale:
Going for a configuration file, you would need to either hardcode
its location
All of the OpenAFS services and clients already have configuration
files with well-known locations.
[As an example of an unfortunate switch to "configuration files" I would
name stunnel. Version 3 is very convenient when you generate options on
the fly, which is quite painful with version 4. Creation and cleanup of
temporary config files on demand is burdensome ans sometimes impossible,
f.i. if you do not have a writable file system at hand.
OpenAFS is hardly being used with volatile configurations but the general
point remains, an introduction of an explicit "config file syntax"
gives no direct advantage per se and postulates some efforts both in
development, learning and deployment.]
I believe I have given reasons why configuration files are a useful
addition.
I support the use of config files. Kerberos tends to follow the Windows
INI config file syntax, and I think that would be a good choice for
config formats. I'm not sure how well that format handles
multi-dimensional options, though. How would that be encoded?
Given the OS limits on command-line lengths, I don't think it's
technically feasible to require all options to be specified on the
command line. I would propose that, when appropriate, each config
option could optionally be specified on the command line similar to ssh
(i.e. ssh -o "option=value"). I also propose that every current
command-line option be represented in the config file.
Thanks,
Jason
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
