Re: Release update
- To: debian-devel@lists.debian.org
- Subject: Re: Release update
- From: Patrice Fortier <Patrice.Fortier@u-bordeaux3.fr>
- Date: Fri, 02 Apr 2004 15:30:55 +0200
- Message-id: <[🔎] 1080912654.3518.4046.camel@minas-tirith.u-bordeaux3.fr>
- In-reply-to: <1080656620.663.10.camel@barney.ehbuehl.net>
- References: <20040329144022.GA24540@riva.ucam.org> <20040329152459.GA27437@steve.org.uk> <20040329175005.GC17981@keid.carnet.hr> <20040329180159.GA1809@steve.org.uk> <20040329201358.GB4937@keid.carnet.hr> <20040329212351.GB10196@steve.org.uk> <20040329212825.GA17217@keid.carnet.hr> <1080654190.3518.32.camel@minas-tirith.u-bordeaux3.fr> <20040330140854.GB4619@fysh.org> <1080656620.663.10.camel@barney.ehbuehl.net>
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: