Re: init script config files
Martin Bialasinski wrote:
>> OK, let's take a step back (and I try to bring in some of the
>> decisiontheory I am learning right now):
>>
>> We are discussing alternatives, without really knowledge of the goals.
>>
>> The init scripts are the interface the admin uses to control daemons.
>> Fundamental goals ("I want it because of its own merits") are
>>
>> 0. one interface on usage = ./foo start etc.(Any alternative has to
>> provide this, so we can leave this out)
>> 1. posibility of customisation by the admin
>> 2. ease of upgrade wrt to changes in the maintainer's version of the
>> script
* "Christopher" == Christopher W Curtis <ccurtis@aet-usa.com> wrote:
Christopher> I would add:
Christopher> 3. consistent error reporting (exit values)
Agreed. "Deterministic error handling by init scripts" (in the end,
this may just be the exit value, but maybe someone has other ideas)
looks like something worthwhile to have.
We need it anyway for LSB, if I understand this correctly. If we agree
that any of the alternatives has to have exactly the same output wrt
to this, then we don't need to look further on it for now, as it
doesn't help to find the best alternative.
Christopher> Without policy, these 'options' files go into N different
Christopher> directories, which makes administration harder.
Agreed. A single place would be better.
Christopher> The huge controversy erupted because my initial thought
Christopher> was two config.d files. One would have all the variables
Christopher> with gratuitous comments, the other would be user
Christopher> overrides.
This is something I also don't feel comfortable with. Let's see if I
understand this correctly.
/etc/init.d/foo would get the maintainers default for the "timeout"
value from the foo.systemdefaults file, and the user can override it
in the foo.useroverrides file.
Christopher> At this point, the script has to do lots of checking, and
Christopher> maintenance headache to meet goal (3) - consistent error
Christopher> values. Then, if these values change (eg, as dictated by
Christopher> the LSB), it will cause a lot of headache for script
Christopher> writers, so I created a file (called defaults) that would
Christopher> ship with sysvinit or some required package, and the
Christopher> script could simply source that one file and get all the
Christopher> checking done automatically.
You have to say what you have in mind with "checking", otherwise, I
can't follow you.
Do you mean checking for valid values in the variables? Then I don't
see how you would automaticaly know the valid interval for a timeout
variable.
And, I don't see what we would gain from a seperate system.defaults
file. I think this can (and should) be merged into the init script.
See my example below.
Christopher> If this directory moved,
What directory? The one containing the user override files?
Christopher> only 'defaults' would have to be updated. If the exit
Christopher> codes standardized to something else, only this one file
Christopher> changed.
OK this is getting clearer now. C header files.
Christopher> But, I thought, it could be even easier. I wrote
Christopher> 'start', 'status', and various 'kill's (usr1, term, hup,
Christopher> kill9) which initscript writers who were using this file
Christopher> anyway could use. 'start' and 'kill's work similar in
Christopher> principle to start-stop-daemon, but return consistent
Christopher> error codes which can be seen by looking at the file.
Christopher> Specifically, they are enumerated in the 'status'
Christopher> function, which reports what these errorcodes are to the
Christopher> user. Again, for consistency.
So these are helper scripts a init file could use. Nothing to say
against this. But for now, they are not of interest.
First, we have to know our goals. We have identified two (or
three). Then we need alternatives which behave different wrt to the
goals we defined. Then we value how good an alternatives performs wrt
the goals. Then we give the goals weights, and can then calculate a
weighted utility.
Then, when we have identified the best alternative, we implement
it. And this is what you describe above. You are too early :-)
You have a "headers" file like
OK = 0
VALUE_OUT_OF_BOUNCE = 1
VALUE_NOT_NUMERIC = 2
VALUE_NOT_A_NET_ADDRESS = 3
VALUE_NOT_AN_EMAIL_ADDRESS = 4
USEROVERRIDES_DIR = /etc/defaults
And you have helper functions/programms like
import_user_overrides("$USEROVERRIDES_DIR/$DAEMON")
check_interval($timeout, 5, 30)
check_emailaddress($contact)
This is also a nice thing, as it helps to cut down unneccassary double
effords and can help with quality.
A initscript has to behave as defined by the alternative that was
chosen. How it does this, doesn't matter. If there are helper
thingies, they will get used by at least some. Like with debhelper.
A init script using these helper could then look like (meta language,
perlesk):
# Initscript for the foo daemon
# Import constants
use constants_file;
# Make helper functions available
use chris_helpers;
$DAEMON=/usr/sbin/foo
$NAME=foo
# Default values, no need to get them from an external file
$timeout = 30;
$contact = root@localhost;
# get the user customisations
import_user_overrides("$USEROVERRIDES_DIR/$DAEMON");
# check the timeout value
if ( check_interval($timeout, 5, 30) == VALUE_OUT_OF_BOUNCE ) {
print "Timeout must be between 5 and 30, but has been set to $timeout.";
# Or maybe even this can be done by a function; would allow
# transparent i18n
exit VALUE_OUT_OF_BOUNCE;
}
# Alternative
# exit_if_not_in_interval("timeout", 5,30);
# that would exit with VALUE_OUT_OF_BOUNCE and a proper message
# check if the contact address is a valid emailaddress
if ( check_emailaddress($contace) == VALUE_NOT_AN_EMAIL_ADDRESS ) {
print "The emailaddress ($contact) you gave as the contact is
syntactically incorrect.";
exit VALUE_NOT_AN_EMAIL_ADDRESS;
}
# Do the usual start), stop) etc stuff.
You also want to offer an alternative to the start-stop-daemon. I have
no problem with this. If it is better, then people will use it. If it
is not, they won't :-) Simple as that.
If init scripts have to provide a deterministic error code, then
either the maintainer have to assure this manually somehow or
start-stop-daemon has to assure this or your script has to assure
this.
The maintainers will choose. But I also see the value in having as few
different solutions as possible, as this eases the understanding of
initfiles, if one only has to be familiar with one way.
It is a clasical trade-off between simplicity to understand for the
admin and flexibility for the maintainer.
Christopher> This drew the ire of RedHat haters, and the thread exploded.
Maybe it was difficult to understand, as you mix conceptual things
like seperation user defaults from the script and implementation
details.
I also think that the fear is, that too much would be done in an
opaque manner in some lib, so you end up with
start)
do_the_magic()
If one makes "speaking" function- and variable names, and leaves the
execution logic in the script, then it looks OK to me. It is just an
alternative. A maintainer could do something like that already. And
indeed, isdnutils does so.
Any way, I don't maintain a package that has an init script, so...
I thing we should identify the best alternative to use (see above),
that says how the result has to look like and how the system bahaves
in general. These are the strict requirements. The implementation can
use different means to accomplish them (tradeoff: freedom to choose ->
diversity -> more difficult to understand than a strictly defined
approach). But we are volunteers. You can only regulate a part of the
whole thing that we agree is reasonable to regulate, or it won't be
fun any more to code.
Christopher> I agree. However, every script is not going to be able
Christopher> to be written using ``new style'' options; therefore, for
Christopher> consistency, all *should be* conffiles,
I see more value in allowing to edit the init files, whether they use
some external file or not. This gives freedom of choice. This is the
main reason I think they should stay conffiles.
Ciao,
Martin
PS:
Christopher> Yes. I meant 'upstream' from the user.
Mind the conventions ("checking" or "directory" in your posting). A
discussion is only good if everyone is talking about the same thing
:-)
Reply to: