Re: the 'at-boot' package method: a change of direction

On Tue, 6 Feb 2001, Will Partain wrote:

> Folks, there's been a dubious idea floating about (courtesy
> of me) that any ARK package that needs something done at
> boot time (e.g. the openssh packages wants sshd started) can
> simply heave in an 'at-boot' method.
>
> You set up an init.d script to do
>
>    ark package at-boot --host=. ALL--ALL
>
> and that will start *all* your ARK-controlled stuff; if
> you've put in <dependency .../>'s, it will even do them in
> the right order!  As packages come and go, you don't have to
> change your init.d scripts -- the above takes care of it.
> This is cool.

Another potential problem with this is that it assumes that a set of ARK
teams and the associated ARK machinery (python etc.) will be available at
boot time; typically the "master" copies of the teams are in CVS, with
each sysadmin having their own checked out current version in their own
personal workspace. At present we don't use a canonical centrally checked
out version which we can guarantee is always available. In addition the
sysadmin checked out teams are likely to be on some NFS mounted directory,
which we {don't, can't} rely on at boot time.

> I therefore suggest that (sidai-ish) packages with boot-time
> pretensions should generate a normal start/stop init.d
> script, perhaps in their post-install-bits method.

I agree with this, but I like your abstraction of having at-boot, hourly,
weekly etc. methods. So one alternative would be to have post-install
generate the init scripts from the code specified in the appropriate
methods (which are not normally executed manually).

I do something like this manually at the moment. So my /etc/init.d/flexlm
script is basically a tidied up version of:

# arkpkg at-boot --pretend --verbose --use-deps=none flexlm--7.1d >/etc/init.d/flexlm

I quite like this solution, because it has the nice abstraction of using
methods for defining boot-time actions, while at the same time having the
robustness of local scripts (and being able to start/stop services
manually).

It might even be nice to have methods such as "start-daemon" and
"stop-daemon" from which SYSV-style init scripts could be generated.

I'm probably talking gibberish, but just a suggestion...

matt