Re: Extending the update-rc.d API to change runlevel and disable scripts?

[Michael Schutte]

On Sun, Apr 27, 2008 at 09:41:49AM +0200, Petter Reinholdtsen wrote:
> [Luk Claes]
> > Isn't this just a matter of stopping the service and renaming the S (K)
> > links to s (k) links so one can easily revert?
> 
> Probably not.  When only stop symlinks are present, one need to know
> which runlevels should keep the stop symlinks, and which should be
> changed.  I suspect the easiest way to revert to the default settings
> is to remove all the packages start settings (update-rc.d -f script
> remove), and reconfigure it to let the postinst script call
> update-rc.d to enable it again.

You probably mis-parsed Luk’s suggestion: He is talking about
lowercasing the initial letters of the start/stop symlinks; this could
easily be changed back again when a script is reactivated.

And since people tend to forget about file-rc: I suppose adding a
special character (for example, a dash) to the beginning command column
in /etc/runlevel.conf and ignoring these lines in /etc/init.d/rc would
work well for this purpose.

Best regards,
-- 
Michael Schutte <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: Extending the update-rc.d API to change runlevel and disable scripts?

[Petter Reinholdtsen]

[Luk Claes]
> Isn't this just a matter of stopping the service and renaming the S (K)
> links to s (k) links so one can easily revert?

Probably not.  When only stop symlinks are present, one need to know
which runlevels should keep the stop symlinks, and which should be
changed.  I suspect the easiest way to revert to the default settings
is to remove all the packages start settings (update-rc.d -f script
remove), and reconfigure it to let the postinst script call
update-rc.d to enable it again.

For dependency based boot sequencing, the default runlevel settings
are in the LSB header in the script, while for the rest it is in the
postinst script.

Happy hacking,
-- 
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Extending the update-rc.d API to change runlevel and disable scripts?

[Luk Claes]

Stefano Zacchiroli wrote:
> On Fri, Apr 25, 2008 at 10:15:27AM +0200, Petter Reinholdtsen wrote:

> Similarly, a counter action for this new "disable" action should be
> provided. I frequently dig into postinsts to retrieve the info about in
> which position I should put back a service I've disabled. (Sure this
> won't be needed with dependency based boot system, but in the meantime
> it still is.)

Isn't this just a matter of stopping the service and renaming the S (K)
links to s (k) links so one can easily revert?

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Extending the update-rc.d API to change runlevel and disable scripts?

[Stefano Zacchiroli]

On Fri, Apr 25, 2008 at 10:15:27AM +0200, Petter Reinholdtsen wrote:
> I believe we should extend the update-rc.d interface to provide a few
> more operations that are commonly needed and commonly done wrong.

Neat, thanks for the initiative.

> Disable scripts
> ---
> 
> This has to be done manually or using one of the tools provided for
> sysv-rc, and is different for earch boot system used.  I propose an
> operation like
> 
>   update-rc.d script disable
> 
> It will rename all start symlinks to stop symlinks for all runlevels.
> For dependency based boot sequencing, it will also update the sequence
> numbers to reflect this new entry.

I would add the option to specify a (set of) runlevel, so that one can
disable a service just for a subset of the runlevels. I'm myself using
sysv-rc-conf for these things and frequently I remove links only for the
default runlevel.

It should also be considered what the default should be if no subset of
the runlevels is specified. To me, both "all" and "only the default
runlevel" make sense. Though probably "all" is better, as the default
runlevel can be changed later on without that update-rc.d notice
anything about that.

Similarly, a counter action for this new "disable" action should be
provided. I frequently dig into postinsts to retrieve the info about in
which position I should put back a service I've disabled. (Sure this
won't be needed with dependency based boot system, but in the meantime
it still is.)

Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],cs.unibo.it,debian.org}  -<%>-  http://upsilon.cc/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: Extending the update-rc.d API to change runlevel and disable scripts?

[Russ Allbery]

sean finney <[EMAIL PROTECTED]> writes:
> On Friday 25 April 2008 06:24:41 pm Russ Allbery wrote:

>> Yes please.  Another desperately needed feature is a query interface
>> that will tell you exactly the current state of a given init script,
>> for use by other automated tools.  Currently, Puppet hacks around this
>> in some really ugly ways since there's no good interface for this.

> you mean like invoke-rc.d --query ?

No, that seems to be something completely different.

Puppet needs to know if a given init script is configured to ever start or
whether it's administratively disabled (K scripts at every runlevel), what
runlevels it starts and stops at (more generally), and its priority
(although dependency-based boot should make that unnecessary).

Puppet would also love to be able to disable a script and then put it back
with the same priority that it had before, although dependency-based boot
will make that obsolete soon enough, hopefully.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Extending the update-rc.d API to change runlevel and disable scripts?

[sean finney]

On Friday 25 April 2008 06:24:41 pm Russ Allbery wrote:
> Yes please.  Another desperately needed feature is a query interface that
> will tell you exactly the current state of a given init script, for use by
> other automated tools.  Currently, Puppet hacks around this in some really
> ugly ways since there's no good interface for this.

you mean like invoke-rc.d --query ?

otherwise, yes i think it would be quite useful to have those features, as i 
regularly see people recommending users in #debian the *wrong* thing to do to 
disable a service with the existing update-rc.d implementation.

either that or have something like chkconfig/insserv installed by default.

sean


signature.asc
Description: This is a digitally signed message part.

Re: Extending the update-rc.d API to change runlevel and disable scripts?

[Russ Allbery]

Petter Reinholdtsen <[EMAIL PROTECTED]> writes:

> I believe we should extend the update-rc.d interface to provide a few
> more operations that are commonly needed and commonly done wrong.
>
>  - One operation to modify the runlevel used by a script/service.
>
>  - One operation to disable a script and make sure it stay disabled.
>
> The first operation will replace the remove-reinsert operation currently
> being done in postinst script to change the runlevels, and the second
> will make it easier for users to disable a service the correct way.

Yes please.  Another desperately needed feature is a query interface that
will tell you exactly the current state of a given init script, for use by
other automated tools.  Currently, Puppet hacks around this in some really
ugly ways since there's no good interface for this.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Extending the update-rc.d API to change runlevel and disable scripts?

[Petter Reinholdtsen]

I believe we should extend the update-rc.d interface to provide a few
more operations that are commonly needed and commonly done wrong.

 - One operation to modify the runlevel used by a script/service.

 - One operation to disable a script and make sure it stay disabled.

The first operation will replace the remove-reinsert operation
currently being done in postinst script to change the runlevels, and
the second will make it easier for users to disable a service the
correct way.

I'm not sure what the optimal interface would be, but here is a draft:

Modify runlevels


At the moment this is done in some postinst scripts using for example

  update-rc.d -f script remove
  update-rc.d script defaults

This is actually the only way to do this currently with the provided
interface of update-rc.d.  The problem is that this drop any changes
done by the local sysadmin.  I propose a new operation to add or
remove runlevels, perhaps like this to drop the start symlink from
rcS.d and add it to rc2.d:

  update-rc.d script runlevel KS S2

This will rename any start symlinks in rcS.d/ to a stop symlink (and
do nothing if no symlink is present), and change any stop symlinks in
rc2.d/ to a start symlink (or add it if it isn't present).  Any better
suggestions on how to specify runlevel changes?  One issue to figure
out is how to handle static sequence number for start and stop.
Perhaps 'default' or start and stop sequence numbers need to be
provided as well.

Disable scripts
---

This has to be done manually or using one of the tools provided for
sysv-rc, and is different for earch boot system used.  I propose an
operation like

  update-rc.d script disable

It will rename all start symlinks to stop symlinks for all runlevels.
For dependency based boot sequencing, it will also update the sequence
numbers to reflect this new entry.

Any comments?  Better suggestions, objects, etc?

Happy hacking,
-- 
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]