Public SourceMage Discussion List

[Casey Harkins <charkins AT upl.cs.wisc.edu>]

On Fri, 25 Oct 2002, Damien Mascord wrote:
> Wouldn't an audit of the init scripts be a better way to do this?  Or
> perhaps have different init scripts for the different replaceable init
> systems?  You don't want to have to recast init.d everytime you install
> something...

The other init system I looked into has its own scripting language, so
each init system would indeed have to have its own scripts. This is why I
think the scripts should be kept in the init system spell and not moved to
the individual spell. Then the question is how to get the scripts to
install when you install the relevant spell.

For example, someone already has init.d installed and they cast openssh.
Somehow that init script needs to get installed. If you let the openssh
spell do it (the way it does it now), this only works for the init.d
system. I suppose each spell could keep the necessary info for every init
system we provide, but I think it is better to do it the other way around.

Since the init.d spell really isn't compiling anything, just copying files
and creating symlinks, I don't see too much of a problem with recasting
whenever a relevant spell is cast.


> Another way to do this is to create an easy init.d config file per script,
> and have something create the init.d scripts on install. ie...
>
> RUNLEVELS=1,2,3
> DAEMON_TO_START=/usr/bin/sshd

For scripts which just start a daemon this would work, but there are other
scripts which require much more work (i.e. networking, mount).

> Then when a new init.d spell is written, a "recompile" of the init.d
> scripts would beef them up.

This is where I was heading with the last few questions. Currently the
init.d spell will ask using a dialog which scripts you would like to
update. This doesn't work well for an unattended update, so I think
choosing a default behaviour would be nice. The problem comes in when
people make modifications to an init script, then they probably don't want
it to be overwritten/updated. Perhaps a special comment at the top
(similar to the SGL-START and SGL-STOP comments) could be used to instruct
the init.d spell to update or not.

> Wouldn't an interactive vs non interactive detection be something
> worthwhile in scripted updates ?    If there are loads of questions to be
> asked, a scripts system update could take a long time to complete.

If the delay is set high enough it could definitely take a while. Any
other spell you cast has some sort of default configuration and its up to
the SA to configure it. Perhaps we should adapt this approach to the init
system. Scripts are set to start/stop at their default run levels and set
to update automatically when init.d spell is updated. If the SA edits the
init script, they just set the SGL-HOLD to on to prevent updates. We could
provide a command line tool for changing the symlinks (nealbirch has this
stuff separated into a bash library already), or they can just be modified
by hand.

> Every time I do a sorcery update, it insists on asking me about the network
> configuration... who really wants dialogs anyway? :)

It doesn't hurt to be a little user friendly and provide some sort of
guided configuration for things like networking. The networking.sh init
script just looks at each file in the  /etc/sysconfig/network directory
(currently just ones that start with 'eth'), loads the information in the
file and does what is necessary to bring up the connection. If there are
minor fixes to the networking.sh script, I don't see any need to ask if
you want to re-configure.