Re: Scripts for /etc/init.d or /etc/rc.d

[Joel S and Jonathan H have been bouncing around various
reasonable ideas for managing startup scripts...]

(Sorry to be slow in having anything to say about these
topics.)

First, w.r.t. the Sidai packages {hpux,solaris}-rc.d-config:

* The solaris one is just a complete hack

* The hpux one is not so bad, because: hpux puts the scripts
  themselves in /sbin/init.d and expects them *not* to change;
   all the tweakable parameters have been moved out to
  "source"able files in /etc/rc.config.d -- the
  hpux-rc.d-config package is manipulating those...

Obviously, I have not previously cracked the startup-script
problem.  You want:

* To turn off vendor-supplied system services that you don't
  want (inetd, telnet, ...) [common]

* To turn on vendor-supplied services that are off by default
  [less common]

* To turn on/off add-on (non-Arusha) services; something
  like ClearCase or whatnot

* To turn on/off Arusha-managed services.

In summary, your ARK "spec" for your site should say exactly
what the boot-started services are (and give you ways to
make sure it stays that way), no matter their provenance.

Jonathan puts forward the approach of using ARK methods
to do the business (e.g.
/our/bin/ark package start --host=. boot-services).  This,
as has been discussed here, is a legitimate approach.

I *think* I might go another way... namely to have the ARK
machinery manipulate /etc/{init.d,rc?.d} (or whatever)
directly.  Perhaps:

* The package that lays down the binaries
  (e.g. httpd--2.0.46) would also put the boot script into
  place (e.g. /etc/init.d/httpd) -- but no symlinks to it!

* The package that "configures" the above
  (e.g. apache-config-our-groovy-website) would put in the
  symlinks (/etc/rc?.d/S04httpd or whatever)

  Or better, it would simply supply a <chkconfig-fragment>,
  maybe 

  <chkconfig-fragment><table>
    <entry name="service">samba</entry>
    <entry name="spec">234 21 82</entry>
    <entry name="description">Provide file service to Windows hosts.</entry>
  </table></chkconfig-fragment>

  and then some "super-chkconfig" script would slurp these
  in and make everything behave.

  In the latter case, to change vendor-supplied behavior,
  let's say to turn off xinetd, you'd make a little tiny
  xinetd-config package, and it would be

  <chkconfig-fragment><table>
    <entry name="service">xinetd</entry>
    <entry name="spec">- 4 93</entry>
  </table></chkconfig-fragment>

  (Or maybe that should be
  <chkconfig-fragment><table>
    <entry name="xinetd">
       chkconfig: - 4 93
       description: switched off
    </entry>
  </table></chkconfig-fragment>

  so you could have a whole bunch of settings in one ARK file.)

  Method of operation: read the chkconfig specs in
  /etc/rc.d/init.d/*, then override with whatever comes out
  of the ARK package, then make it true.  Run from a cron
  job once a day or something.

Joel, maybe this is not too far from some of your thinking?

Will


-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.