Public SourceMage Discussion List

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

Yeah, good point. More complicated than I thought. I'm going to think
this all through some more, but I think its too late to make any
significant changes to the init system before 1.0.


-casey


On Thu, 24 Oct 2002, Sergey A. Lipnevich wrote:

> Perhaps somebody could also think about the problem of stuff being
> started both stand-alone from init.d/ and as xinetd service, like
> openssh does?
>
> Damien Mascord wrote:
>
> > At 07:05 PM 24/10/2002 -0500, Casey Harkins wrote:
> >
> >> What I am proposing is to keep ALL of the init scripts within the init.d
> >> spell. Gurus would need to send their init scripts to the init.d
> >> maintainer to have them included/updated. This should ensure that all
> >> init
> >> scripts make use of the functions when possible to give a consistent
> >> look
> >> to the startup process. A TRIGGERS file could then be added to the
> >> init.d
> >> spell to have it cast_self when a spell which has init scripts is cast.
> >> The init.d spell would then check which spells are installed and
> >> install/update the relevant init scripts. (Could this be handled with
> >> optional_depends?)
> >>
> >> The trick here is preventing a 'make install' from installing any init
> >> scripts.
> >>
> >> Should scripts then be auto-updated? Should there be a "HOLD" mechanism
> >> for init scripts to prevent certain scripts from being updated?
> >
> >
> > 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...
> >
> > 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
> > .
> > .
> >
> > Then when a new init.d spell is written, a "recompile" of the init.d
> > scripts would beef them up.
> >
> >> 2) The init.d spell now uses a dialog to ask the user which scripts to
> >> install. However, this could cause a system-update to sit at the dialog
> >> waiting for input. Should it ask something like "Choose which scripts to
> >> install? [n]". This way it would only open the dialog if the user
> >> selected
> >> yes (similar to "configure kernel?" when casting linux).
> >
> >
> > 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.
> >
> >> 3) The network configuration dialogs also get brought up when casting.
> >> What I propose here is to keep the network configuration stuff separate
> >> from the networking.sh init script. Maybe add a "netconf" script to the
> >> net-tools package which handles creating, modifying and removing device
> >> files from the /etc/sysconfig/network directory. I am going to start
> >> working on this piece right now.
> >
> >
> > Every time I do a sorcery update, it insists on asking me about the
> > network configuration... who really wants dialogs anyway? :)
> >
> >> Ok, enough rambling. What do people think? Yeah I know, too close to
> >> 1.0...
> >
> >
> > think?  what's that ?
> >
> >> -casey
> >
> >
> >
> >
> > _______________________________________________
> > SM-Discuss mailing list
> > SM-Discuss AT lists.ibiblio.org
> > http://lists.ibiblio.org/mailman/listinfo/sm-discuss
> >
>
> _______________________________________________
> SM-Discuss mailing list
> SM-Discuss AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/sm-discuss
>