[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: init script config files



Martin Bialasinski wrote:
> 
> Christopher> That's ok, too.  I misspoke when I said they should not
> Christopher> be.  But they do not *need* to be.
> 
> So you propose "init scripts are located in /etc/init.d and _can be_
> conffiles."? This is flawed.

Proposing nothing.  I said that if the config.d system for an initscript
was comprehensive that the script would then no longer *need* to be a
conffile.  I've since conceded the point, as you may want to completely
replace it.  I stated that you could completely replace it in config.d,
but that was just a technical point, not a logistical one.

> Christopher> If the script is not comprehensive, then yes, there are
> Christopher> definately problems like this.
> 
> Problems like what? I can't follow your argumentation.

If the config.d system was not comprehensive.

But as it never can be, point conceded.

> 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

I would add:

3. consistent error reporting (exit values)

so that:

a) a Caldera (I assume RedHat, too) style "[Done]", "[Failed]" could be
wrappered around the script
b) off-the-shelf programs can make use of it, which includes
	-) vmware
	-) http://www.mountlinux.com/olympus/
	-) cluster administration tools

This would require further constraints, such as init scripts having
consistent names among distributions.  This is also a topic of LSB
discussions (if not now, it will need to be).

> Any others? No instrumental goals ("I want it because it helps
> reaching fundamental goal X") please.
> 
> OK let's see some alternatives.
> 
> "old style" script
> 
>  ad 1. admin has complete control of the script. He can change the
>  commands used, variables etc. No formal structure for customisation,
>  some scripts define some variables at the top.
> 
>  ad 2. init scripts are conffiles. If it was changed by the admin, and
>  changed by the maintainer, dpkg asks what to do on upgrade. The init
>  script has to be revised and merged manually by the admin.
> 
> Christopher's suggestion (please correct me, if I am wrong)
> 
>   ad 1. if a script is a "old style" one, see above. If a script is of
>   new style, admin may not change the init script and the way it works
>   himself. He may only change variables defined in a external
>   file. Changes only possible to things the maintainer has provided
>   variables for.
> 
>   ad 2. if a script is a "old style" one, see above. If a script is of
>   new stlye, dpkg will install the new init script right away.

Sorta.  I'm not trying to say, "don't touch the file"; I'm saying, if
you don't want conflicts on upgrade, "go touch this other file".  What
you say is correct if I wanted to persue the "make it not a conffile"
tract, but I'm not.  It just seemed like this was an option for ``new
style'' scripts (which it really is, but in a hokey [non-obvious] way).

> 
> Martin's alternative
> 
>  ad 1. admin has complete control of the script. He can change the
>  commands used, variables etc. All customisation variables have to be
>  defined and commented at the top of the script. They have to have
>  default values, which can be overridden by the admin through vaules
>  set in an external file.
> 
>  ad 2. init scripts are conffiles. If the admin changes just variables
>  defined in the external file, dpkg will install the new init script
>  right away. If the initscript was changed by the admin, and changed
>  by the maintainer, dpkg asks what to do on upgrade. The init script
>  has to be revised and merged manually by the admin.
> 
> Note, that my alternative is already possible by policy, and I
> wouldn't be surprised if some script already does it that
> way. [checking]. At least xdm uses /etc/X11/xdm/xdm.options.

I believe Joey Hess has proposed exactly this and submitted a diff. 
Without policy, these 'options' files go into N different directories,
which makes administration harder.

The huge controversy erupted because my initial thought was two config.d
files.  One would have all the variables with gratuitous comments, the
other would be user overrides.  As such, the user created file would be
optional.  At this point, the script has to do lots of checking, and
maintenance headache to meet goal (3) - consistent error values.  Then,
if these values change (eg, as dictated by the LSB), it will cause a lot
of headache for script writers, so I created a file (called defaults)
that would ship with sysvinit or some required package, and the script
could simply source that one file and get all the checking done
automatically.  If this directory moved, only 'defaults' would have to
be updated.  If the exit codes standardized to something else, only this
one file changed.

But, I thought, it could be even easier.  I wrote 'start', 'status', and
various 'kill's (usr1, term, hup, kill9) which initscript writers who
were using this file anyway could use.  'start' and 'kill's work similar
in principle to start-stop-daemon, but return consistent error codes
which can be seen by looking at the file.  Specifically, they are
enumerated in the 'status' function, which reports what these errorcodes
are to the user.  Again, for consistency.

This drew the ire of RedHat haters, and the thread exploded.

> Problem: the "external file" that holds the variables to change is not
> defined. I think it would make sense to define how variable definition
> have to be made. One synatax instead of multiple ones. [xdm uses
> "no-ignore-nologin" or "ignore-nologin". Maybe "ignore-nologin=true",
> "timeout=30" or such would be better. "#" as the comment character]
> 
> For the later two alternatives, there is the question how to bahave on
> a significant change in the init script.
> 
> Example:
> before: one timeout value, changed in the "external file"
> now: incoming timeout and outgoing timeout, so what do we do now
>
> Joey said: "The config.d system makes the files sufficiently simple to
> parse that packages can deal with fixing them up after such changes."
> I can't really judge this.
> 
> Now, we can make up other alternatives, and see if how they behave wrt
> out goals.

Joey is correct.  In the postinst script, ``if grep foo
/etc/config.d/bar ; echo "bar has been replaced with bar1, bar2 - bar
has been obsolesced.  Setting bar1 = bar2 = bar"; work_sed_magic()''

> Christopher> Well, you could say that if the script supplied doesn't
> Christopher> support X without having to be edited, it should be fixed
> Christopher> upstream so that others can share in the 'fix'.
> 
> You mean the Debian maintainer should fix it, not upstream. The
> initscripts are part of the Debian adaptation.

Yes.  I meant 'upstream' from the user.

[scripts getting complex]
> 
> The worst case would be complexity of level O².

I see that too, which is why I wanted to make the common things
(starting and stopping of daemons) as simple as possible.

> Christopher> But there's no reason they can't coexist, and I'm not
> Christopher> trying to dictate anything;
> 
> If you mean that a package can either have an "old style" init script,
> which is a conffile, or a "new style" init script which is not a
> conffile and parses some file for option, then this is not good,
> because it makes the interface, then this is not good because of the
> "not a conffile" part. This makes the interface (= the files in
> /etc/init.d/ behave differently/inconsistent wrt package upgrades).

Eargh?  ;-)

I agree.  However, every script is not going to be able to be written
using ``new style'' options; therefore, for consistency, all *should be*
conffiles, even if they don't *need* to be.  That is, since at least one
*must* be a conffile, they should all be conffiles, whether anything
else is true or not.

Christopher



Reply to: