Re: not starting packages at boot
On Fri, Jan 21, 2005 at 12:09:42PM +0800, Dan Jacobson wrote: > Now that maintainers realized that one might like a package installed, > but perhaps only plans to use it unoften, it only makes sense for not > starting at boot to be offered as a friendly configuration option, > instead of needing some devious guerilla techniques to thwart the > packages starting. For packages I maintain that provide system services, I use another solution than making it a configuration option. The packages are split into a package providing the programs, and a -run package providing the service. Users that don't want the service to be enabled by default simply don't install the -run package. This additionally has an advantage concerning virtual packages representing a system service, such as ftp-server, mail-transport-agent, system-log-daemon, or imap-server. Here's the rationale from the bincimap-run package: $ sed -ne '18~1p' , Fri, 17 Oct 2003 07:45:52 + $ Regards, Gerrit. -- Open projects at http://smarden.org/pape/. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: not starting packages at boot
On Mon, 24 Jan 2005 18:01:46 -0600, Steve Greenland <[EMAIL PROTECTED]> wrote: >On 24-Jan-05, 03:45 (CST), Marc Haber <[EMAIL PROTECTED]> wrote: >> Last time I looked, invoke-rc.d was not yet a requirement to be used >> by packages. As far as I remember, it is for sarge, but not for woody >> and thus unuseable on woody, right? >> >> Do we already have packages that provide policy-rc.d? A quick apt-get >> search didn't show any. > >At present, the standard way to control this to edit the symlinks (or >runlevel.conf, if using file-rc). This is good, because '/etc/init.d/foo start' >still works. > >The standard for the future is invoke-rc.d. If a package doesn't support >this, then the thing to do is to submit a wishlist bug for invoke-rc.d >support, NOT create some new ad-hoc method. I am not a native speaker, but to me it looks like your message doesn't fit the questions I asked. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: not starting packages at boot
On Tue, Jan 25, 2005 at 08:15:52AM +0100, Marc Haber wrote: > On Mon, 24 Jan 2005 18:01:46 -0600, Steve Greenland > <[EMAIL PROTECTED]> wrote: > >On 24-Jan-05, 03:45 (CST), Marc Haber <[EMAIL PROTECTED]> wrote: > >> Last time I looked, invoke-rc.d was not yet a requirement to be used > >> by packages. As far as I remember, it is for sarge, but not for woody > >> and thus unuseable on woody, right? > >> > >> Do we already have packages that provide policy-rc.d? A quick apt-get > >> search didn't show any. > > > >At present, the standard way to control this to edit the symlinks (or > >runlevel.conf, if using file-rc). This is good, because '/etc/init.d/foo > >start' > >still works. > > > >The standard for the future is invoke-rc.d. If a package doesn't support > >this, then the thing to do is to submit a wishlist bug for invoke-rc.d > >support, NOT create some new ad-hoc method. > > I am not a native speaker, but to me it looks like your message > doesn't fit the questions I asked. Steve answered your first question. The second question makes no sense, since policy-rc.d is supposed to be written by the administrator to fit their local policy. - Matt signature.asc Description: Digital signature
Re: not starting packages at boot
On 2005-01-25 Steve Greenland <[EMAIL PROTECTED]> wrote: > On 24-Jan-05, 03:45 (CST), Marc Haber <[EMAIL PROTECTED]> wrote: > > Last time I looked, invoke-rc.d was not yet a requirement to be used > > by packages. As far as I remember, it is for sarge, but not for woody > > and thus unuseable on woody, right? > > > > Do we already have packages that provide policy-rc.d? A quick apt-get > > search didn't show any. > At present, the standard way to control this to edit the symlinks > (or runlevel.conf, if using file-rc). This is good, because > '/etc/init.d/foo start' still works. > The standard for the future is invoke-rc.d. If a package doesn't support > this, then the thing to do is to submit a wishlist bug for invoke-rc.d > support, NOT create some new ad-hoc method. Hello, Changing symlinks to disable a service is no working solution for packages which do not use invoke-rc.d. - They'll include /etc/init.d/foo start in their postinst and will start the (disabled) service unwantedly on any upgrade. (The correct way to disable these services is to add "exit 0" add the top of the initscript.) invoke-rc.d is no replacement for changing symlinks, it is a necessary piece for making changing symlinks work correctly. (Apart from that the new init-scripts support policy-rc.d which adds a another optional control level. - The only thing that makes use of this are buildds, they are just diabling any daemon starts.) cu andreas -- "See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in "Snow Crash" http://downhill.aus.cc/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: not starting packages at boot
Marc Haber <[EMAIL PROTECTED]> wrote: > A bad hack. I hate to drop my own binaries to /usr/sbin. You can make /usr/sbin/policy-rc.d a symlink to the file of your choice under /usr/local. A bit less bad, but wouldn't prevent something undesirable happening if you install a package shipping /usr/sbin/policy-rc.d (which should not be very hard to avoid). -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: not starting packages at boot
On Fri, Jan 21, 2005 at 12:09:42PM +0800, Dan Jacobson wrote: > Now that maintainers realized that one might like a package installed, > but perhaps only plans to use it unoften, it only makes sense for not > starting at boot to be offered as a friendly configuration option, > instead of needing some devious guerilla techniques to thwart the > packages starting. apt-get install rcconf I don't think it leaves a message at boot saying "not starting," but it sure is friendly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: not starting packages at boot
On Fri, Jan 21, 2005 at 12:09:42PM +0800, Dan Jacobson wrote:
> Sure, one can go behind the backs of maintainers with
> > http://www.debian.org/doc/manuals/securing-debian-howto/ch3.en.html#s3.6
> > ("Disabling daemon services")
> and hope you remember what you did. But it's not as friendly as
> the approaches more and more packages are taking, as seen in my /var/log/boot:
> SpamAssassin Mail Filter Daemon: disabled, see /etc/default/spamassassin
> hylafax is disabled, see /etc/default/hylafax
> OpenBSD Secure Shell server not in use (/etc/ssh/sshd_not_to_be_run)
> Not starting xprint: disabled in /etc/default/xprint
> Not starting apache2 - edit /etc/default/apache2 and change NO_START to be 0.
> We are still waiting for
> 281974 cupsys: allow not starting on boot
> 218040 fetchmail: no way to not start on boot permanently
> Now that maintainers realized that one might like a package installed,
> but perhaps only plans to use it unoften, it only makes sense for not
> starting at boot to be offered as a friendly configuration option,
> instead of needing some devious guerilla techniques to thwart the
> packages starting.
> Sure those tactics might work, but whatever you did isn't easy to see
> as it is in /etc/default/.
> That each package will have its own way of not starting in
> /etc/default/ is because of disbelief that there needs a standard
> mechanism to do this _that the user can encounter with
> dpkg-reconfigure_, with the results stored in /etc/default/ etc. No
> more monkeying with the links behind maintainers' backs, etc. Proof
> that something visible upon dpkg-reconfigure is better is seen in the
> more and more packages that are getting on the user friendly
> bandwagon.
This is not "monkeying with the links behind maintainers' backs", this is
the *documented interface* for changing which daemons run in which
runlevels. Asking individual maintainers to reinvent the same per-package
solution for opting not to start a service in the default runlevel is
wasteful and ill-designed. We need a central, user-friendly interface for
managing start script policies, not to pick off 100 different packages
one-by-one until they're all trying to duplicate the same code with
different bugs each time.
I hope that at least the cupsys maintainer will close this bug without
mangling the package in this fashion; there's no reason to have the cupsys
server package installed if you're not going to use it as a server. If you
can't be bothered to move a symlink so that you only have to start cupsys
"once a year" when you're printing, then FFS, surely you can at least remove
the package using the package management interface and only install it when
you need it. That's bound to save you disk space on keeping an unpacked
copy around, as well as bandwidth for security updates you wouldn't need.
The xprt-xprintorg at least has the additional factor of being a dependency
of other packages (x-window-system), so there's pressure from users to be
able to install it without enabling it; but even then, the default
configuration of Xprt does not allow network connections, so I really don't
see the point of complicating the package for the convenience of users who
*refuse* to run "rm /etc/rc2.d/S20" when indicated to do so.
--
Steve Langasek
postmodern programmer
signature.asc
Description: Digital signature
Re: not starting packages at boot
On Sat, 22 Jan 2005 18:44:16 -0800, Steve Langasek <[EMAIL PROTECTED]> wrote: >I hope that at least the cupsys maintainer will close this bug without >mangling the package in this fashion; there's no reason to have the cupsys >server package installed if you're not going to use it as a server. I disagree. I have a number of server packages installed on my personal laptop for the sake of having the docs with me. I am, however, fine with using update-rc.d or $EDITOR /etc/runlevel.conf[1] to accomplish this. My beef is that I want to be able to prevent a newly installed package's postinst from starting the service (for example, because I know that the service needs configuration before it can be started for the first time, or because I know that this service is probably never going to run on this installation). Greetings Marc [1] Thanks, Roland, for file-rc, which is really great -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: not starting packages at boot
On Sun, 23 Jan 2005 10:38:20 +0100, Marc Haber wrote: [...] > My beef is that I want to be able to prevent a newly installed > package's postinst from starting the service Looks like something invoke-rc.d calls policy-rc.d for. > (for example, because I > know that the service needs configuration before it can be started for > the first time, or because I know that this service is probably never > going to run on this installation). -- Michał Politowski Talking has been known to lead to communication if practised carelessly. signature.asc Description: Digital signature
Re: not starting packages at boot
Marc Haber <[EMAIL PROTECTED]> writes: > On Sat, 22 Jan 2005 18:44:16 -0800, Steve Langasek <[EMAIL PROTECTED]> > wrote: >>I hope that at least the cupsys maintainer will close this bug without >>mangling the package in this fashion; there's no reason to have the cupsys >>server package installed if you're not going to use it as a server. > > I disagree. I have a number of server packages installed on my > personal laptop for the sake of having the docs with me. I am, > however, fine with using update-rc.d or $EDITOR /etc/runlevel.conf[1] > to accomplish this. > > My beef is that I want to be able to prevent a newly installed > package's postinst from starting the service (for example, because I > know that the service needs configuration before it can be started for > the first time, or because I know that this service is probably never > going to run on this installation). > > Greetings > Marc > > [1] Thanks, Roland, for file-rc, which is really great Chroots also nearly never want to start services and it would be nice fi there were a consistent way to stop daemons from getting started (stoped on upgrade) on install there. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: not starting packages at boot
On Sun, Jan 23, 2005 at 11:10:37AM +0100, Goswin von Brederlow wrote: > Marc Haber <[EMAIL PROTECTED]> writes: > > On Sat, 22 Jan 2005 18:44:16 -0800, Steve Langasek <[EMAIL PROTECTED]> > > wrote: > >>I hope that at least the cupsys maintainer will close this bug without > >>mangling the package in this fashion; there's no reason to have the cupsys > >>server package installed if you're not going to use it as a server. > > > > I disagree. I have a number of server packages installed on my > > personal laptop for the sake of having the docs with me. I am, > > however, fine with using update-rc.d or $EDITOR /etc/runlevel.conf[1] > > to accomplish this. > > > > My beef is that I want to be able to prevent a newly installed > > package's postinst from starting the service (for example, because I > > know that the service needs configuration before it can be started for > > the first time, or because I know that this service is probably never > > going to run on this installation). > > > > Greetings > > Marc > > [1] Thanks, Roland, for file-rc, which is really great > Chroots also nearly never want to start services and it would be nice > fi there were a consistent way to stop daemons from getting started > (stoped on upgrade) on install there. echo -e '#!/bin/sh\n\nexit 101' > /chroot/usr/sbin/policy-rc.d \ && chmod a+x /chroot/usr/sbin/policy-rc.d -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: not starting packages at boot
On Sun, 23 Jan 2005 03:00:27 +0100, Dan Jacobson wrote: > Now that maintainers realized that one might like a package installed, > but perhaps only plans to use it unoften, it only makes sense for not > starting at boot to be offered as a friendly configuration option, > instead of needing some devious guerilla techniques to thwart the > packages starting. apt-get install sysv-rc-conf. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: not starting packages at boot
On Sun, 23 Jan 2005 10:40:08 +0100, Marc Haber wrote in part: > Ihave a number of server packages installed on my > personal laptop for the sake of having the docs with me. I am, > however, fine with using update-rc.d or $EDITOR /etc/runlevel.conf[1] > to accomplish this. In some cases this might be grounds for wishing that the docs be split off into a separate package. Another solution is to "dpkg -x" the package into the directory of your choice and to peruse the docs in there. Of course, neither of these is completely convenient. If one really wants the package to be installed but deactivated then he can install it and disable it using sysv-rc-conf. I agree that sysv-rc-conf leaves something to be desired. It would really be much better if there were a reliable way of restoring a service's runlevel settings to their "factory defaults" -- i.e. to what the package postinst set them to. This could be implemented by changing update-rc.d so that it recorded these settings somewhere; the information could later be used to restore the service's runlevel settings to their factory defaults. I have written about this in #183460 and #237379. This feature is also needed so that maintainer scripts can change runlevel configuration iff they haven't been changed by the user. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: not starting packages at boot
On 20-Jan-05, 22:09 (CST), Dan Jacobson <[EMAIL PROTECTED]> wrote:
> Sure, one can go behind the backs of maintainers with
> > http://www.debian.org/doc/manuals/securing-debian-howto/ch3.en.html#s3.6
> > ("Disabling daemon services")
> and hope you remember what you did. But it's not as friendly as
> the approaches more and more packages are taking, as seen in my /var/log/boot:
There is nothing more unfriendly than having
'/etc/init.d/foo start'
fail because because of some non-standard bit of crap in
/etc/default/foo. I could tolerate it if packaged defaulted *on*, but it
seems the habit is to default off. And more importangly, as others have
said (every single time this comes up), there is an *existing* mechanism
to accomplish this that doesn't require modifying every daemon package:
invoke-rc.d and policy-rc.d.
Steve
--
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world. -- seen on the net
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: not starting packages at boot
On Sun, Jan 23, 2005 at 10:53:48AM -0600, Steve Greenland wrote: > /etc/default/foo. I could tolerate it if packaged defaulted *on*, but it > seems the habit is to default off. And more importangly, as others have > said (every single time this comes up), there is an *existing* mechanism > to accomplish this that doesn't require modifying every daemon package: > invoke-rc.d and policy-rc.d. The main case where this sort of thing is useful is the case where the package can't be shipped with a sane default configuration for some reason and the init script can't detect this situation. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: not starting packages at boot
On Sun, Jan 23, 2005 at 10:53:48AM -0600, Steve Greenland wrote:
> On 20-Jan-05, 22:09 (CST), Dan Jacobson <[EMAIL PROTECTED]> wrote:
> > Sure, one can go behind the backs of maintainers with
> > > http://www.debian.org/doc/manuals/securing-debian-howto/ch3.en.html#s3.6
> > > ("Disabling daemon services")
> > and hope you remember what you did. But it's not as friendly as
> > the approaches more and more packages are taking, as seen in my
> > /var/log/boot:
>
> There is nothing more unfriendly than having
>
>'/etc/init.d/foo start'
>
> fail because because of some non-standard bit of crap in
> /etc/default/foo. I could tolerate it if packaged defaulted *on*, but it
> seems the habit is to default off. And more importangly, as others have
> said (every single time this comes up), there is an *existing* mechanism
> to accomplish this that doesn't require modifying every daemon package:
> invoke-rc.d and policy-rc.d.
>
Amen. I found this with distcc the other day. I had to dpkg-reconfigure it
and answer yes to starting it on boot to be able to start it manually via
/etc/init.d
It almost needs to be a question as to whether you want the start link in
/etc/rc?.d/
regards
Andrew
--
linux.conf.au 2005 - http://linux.conf.au/ - Birthplace of Tux
April 18th to 23rd - http://linux.conf.au/ - LINUX
Canberra, Australia - http://linux.conf.au/ -Get bitten!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: not starting packages at boot
On 23-Jan-05, 14:05 (CST), Mark Brown <[EMAIL PROTECTED]> wrote: > On Sun, Jan 23, 2005 at 10:53:48AM -0600, Steve Greenland wrote: > > > /etc/default/foo. I could tolerate it if packaged defaulted *on*, but it > > seems the habit is to default off. And more importangly, as others have > > said (every single time this comes up), there is an *existing* mechanism > > to accomplish this that doesn't require modifying every daemon package: > > invoke-rc.d and policy-rc.d. > > The main case where this sort of thing is useful is the case where the > package can't be shipped with a sane default configuration for some > reason and the init script can't detect this situation. But it seems to be used far more often than in that case. Besides, IMO, '/etc/init.d/foo start' should *always* attempt to start the daemon if foo isn't running. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: not starting packages at boot
* Dan Jacobson | Not starting apache2 - edit /etc/default/apache2 and change NO_START to be 0. [...] | Now that maintainers realized that one might like a package installed, | but perhaps only plans to use it unoften, it only makes sense for not | starting at boot to be offered as a friendly configuration option, | instead of needing some devious guerilla techniques to thwart the | packages starting. I hope you know that you are way off into the scenery with your explanation here. At least for apache2. NO_START is used by the maintainer scripts in the case of there already being an httpd running when a2 is installed. We might Yeah, and changing it with dpkg-reconfigure is not supported and shouldn't. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: not starting packages at boot
On Sun, 23 Jan 2005 11:01:39 +0100, Michal Politowski <[EMAIL PROTECTED]> wrote: >On Sun, 23 Jan 2005 10:38:20 +0100, Marc Haber wrote: >> My beef is that I want to be able to prevent a newly installed >> package's postinst from starting the service > >Looks like something invoke-rc.d calls policy-rc.d for. Last time I looked, invoke-rc.d was not yet a requirement to be used by packages. As far as I remember, it is for sarge, but not for woody and thus unuseable on woody, right? Do we already have packages that provide policy-rc.d? A quick apt-get search didn't show any. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: not starting packages at boot
On Sun, 23 Jan 2005 02:21:02 -0800, Steve Langasek <[EMAIL PROTECTED]> wrote: >echo -e '#!/bin/sh\n\nexit 101' > /chroot/usr/sbin/policy-rc.d \ >&& chmod a+x /chroot/usr/sbin/policy-rc.d A bad hack. I hate to drop my own binaries to /usr/sbin. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: not starting packages at boot
On 2005-01-24 Marc Haber <[EMAIL PROTECTED]> wrote: [...] > Last time I looked, invoke-rc.d was not yet a requirement to be used > by packages. As far as I remember, it is for sarge, but not for woody > and thus unuseable on woody, right? [...] There are almost no packages in woody which make use of invoke-rc.d in their maintainer scripts (klisa bering the only exeption on my woody system when I used woody, iirc), in sarge the situation is a lot better (I submitted wishlist bug-reports against all daemon packages I was using then and only the one against at, #162677, is still open) but not using invoke-rc.d is no rc-bug for sarge afaik. cu andreas -- "See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in "Snow Crash" http://downhill.aus.cc/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: not starting packages at boot
On 24-Jan-05, 03:45 (CST), Marc Haber <[EMAIL PROTECTED]> wrote: > Last time I looked, invoke-rc.d was not yet a requirement to be used > by packages. As far as I remember, it is for sarge, but not for woody > and thus unuseable on woody, right? > > Do we already have packages that provide policy-rc.d? A quick apt-get > search didn't show any. At present, the standard way to control this to edit the symlinks (or runlevel.conf, if using file-rc). This is good, because '/etc/init.d/foo start' still works. The standard for the future is invoke-rc.d. If a package doesn't support this, then the thing to do is to submit a wishlist bug for invoke-rc.d support, NOT create some new ad-hoc method. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
