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

[As always, apologies for stupid below-message quoting style. I hate Notes.]

I think Matt makes a good point here as it makes sense to keep the startup information in the XML as this is something that tends to vary from site to site much more than the rest of a package (e.g., changing parameters to daemons).

His idea of generating the startup scripts from this is a great one, but the main reason I'd say it's great is that it means you can generate startup scripts for different kinds of init. For instance, generating an /etc/init.d/flexlm is a fat lot of good on a BSD box. What you probably want to generate is an '/etc/rc.flexlm' and add a call to it onto the end of 'rc.local' (or have an ark generated 'rc.ark-packages' and have just one call to that in 'rc.local'). It's irritating when the only difference between a package on two platforms is how to start it - why should I have to sully the package XML file with knowing this?

But going back to Will's original idea, perhaps 'at-boot' isn't fine grain enough. Perhaps what would be better is methods along the lines of 'start', 'stop', 'restart', 'reload'. Then you have a choice - directly control the packages via ark or use Matt's scheme to generate appropriate startup/shutdown scripts for whatever your flavour of init is, e.g.:

     cat <<EOT
     case \$1
     start)
     EOT
     arkpkg start --pretend $package
      cat <<EOT
      ;;
      stop)
      EOT
      arkpkg stop --pretend $package
      cat <<EOT
      ;;
      esac
      EOT

for generating a SYSV style init script. But you can still do cool things like:

     # arkpkg restart --host='dns0,dns1' bind--mumble

Finally, just to throw another idea into the pan: perhaps we should jump back a moment and ask ourselves whether a 'package' is the right unit of abstraction for worrying about starting and stopping daemons. Perhaps we need a new class of object, like 'services' which encapsulates this.

A 'service' would be something like 'ssh' which would have dependancies requiring 'ssh-mumble' and 'ssh-config-mumble' to be deployed and methods for starting and stopping the service, getting status information, etc.

Secure shell isn't much of an example, but consider something like qmail. What I really want to think about is controlling My Mail System. The open, plug-n-play, nature of qmail means that you actually need to install and manage a bunch of packages to get a decent system running: qmail, checkpasswd, ezmlm, some kind of daemon manager, all the necessary configs.

Or should these just be meta-packages that don't install/deploy anything of their own but just have the necessary dependancies and start/stop methods?

Erk. Brain too fuzzy to think anymore.

Jonathan

--
Jonathan Hogg
DB London Web Development and Support
+44 20 7547 1543 / +44 7976 614338


---------------------------------------- Message History ----------------------------------------


From: Matt Holgate <[email protected]>@lists.sourceforge.net on 06/02/2001 20:58

DELEGATED - Sent by:     [email protected]


To:   Will Partain <[email protected]>
cc:   <[email protected]>
Subject:  Re: [Ark-dev] 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


_______________________________________________
Ark-dev mailing list
[email protected]
http://lists.sourceforge.net/lists/listinfo/ark-dev



--

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.