[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Release update



Le mar 30/03/2004 à 16:23, Joachim Breitner a écrit :
> Hi,
> 
> This would require some clarifications (is update-rc.d now for
> administrators or for package maintainers)

Considering all I read here about update-rc.d, I'd say that it was
(at least) designed to be used by package maintainers. As explained
in 
http://www.debian.org/doc/manuals/securing-debian-howto/ch3.en.html#s-disableserv
it's hard to use it correctly if you're not aware of some package
maintainance subtilities (the last link in /etc/rc?.d/ for example),
which is not even described in the man page.

But, when someone ask where is chkconfig (the RH version of
update-rc.d), everybody reply that it's update-rc.d.
So from this PoV, I consider that it's also an administrator tool.

And there's still the "good ol' days" way:
find /etc/rc?.d/ -name "???service" -exec rm {} \;
:)

>  and some common guidelines
> (some packages currently use /etc/defaults/something, some use the
> symlinks in /etc/rc?.d directly, others have something set in
> /etc/init.d/something or use some magic, like checking for a line in
> /etc/inetd.conf).
> 
> Ideally, all network daemons, from the administrator POV:
>  * are installed disabled
>  * may be started temporarily (/etc/init.d/package start)
>    - then being logrotated, restarted on upgrade, but no start on boot
>  * may be started permanently (perhaps symlinking in /etc/rc?.d)
>    - logrotated, restarted on upgrade, restarted on boot
>  * may then be temporarily disabled (/etc/init.d/package stop)
>    - no logrotate restart, no start on upgrade, but start on boot.

Exactly!

> Questions to be solved: how to implement, what interface for package
> maintainers, what interface for administrators

In a pleasant world update-rc.d should be enough for both.
The main problem seems to be that the design of update-rc.d is
flawed:

Quoted from Henning Makholm:

> > What is the reason for this behaviour?
> 
> It is easy to implement in update-rc.d without needing specific
> support from the maintainer scripts to tell it whether the
> package is being installed anew or just updated (or resurrected from
> removed-but-not-purged state).

As I understand this (correct me if I'm wrong), when update-rc.d
is called (.postinst ?) by a package, it is unable to know if it's
performing an install (create the links) or an update (don't touch
anything).
So, update-rc.d is based on a hack, which check if there is at least
a single link remaining in /etc/rc?.d/ to guess if the package is
already installed or not.

There are several drawbacks in this situation:
 - there are (heavy) chances that update-rc.d asumptions are false.
If the admin want to disable a service, he will make a find/rm, or
read the update-rc.d man page and make update-rc.d -f.
update-rc.d behaviour will then be wrong, performing an install
instead of an update, and violating the policy about /etc files.

 - As it's based on hack, an admin needs to know about this
http://www.debian.org/doc/manuals/securing-debian-howto/ch3.en.html#s-disableserv
to use update-rc.d correctly. ie: the admin needs to perfrom a
hack to make a simple task.

So, I guess that the real question to ask is more:
How (or when) can we know during the package installation if we're
performing an install or an update, to call update-rc.d accordingly?

With this, you can remove the hack from update-rc.d, and it can be 
used by both package managers and administrators.
This is mainly a package update problem.


Regards,
Patrice.




Reply to: