Re: Bug#412976 repoened - reassign tech-ctte (mixmaster /etc/default/*)
Florian Weimer writes (Re: Bug#412976 repoened - reassign tech-ctte (mixmaster /etc/default/*)): The manpage also says: | System administrators are not encouraged to use update-rc.d to manage | runlevels. My experience with update-rc.d has been mixed at best. Removing the S links manually is probably the better approach (instead of accidentally removing the K links as well, risking reactivation). Do you think the manpage should be changed ? Manually removing the S links definitely ought to be supported, is quite an obvious route to take for the admin, and is easy. So I don't see why we would recommend using a tool to do it. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#412976 repoened - reassign tech-ctte (mixmaster /etc/default/*)
* Kurt Roeckx: On Sun, Dec 02, 2007 at 10:10:38PM +, Ian Jackson wrote: Florian Weimer writes (Re: Bug#412976 repoened - reassign tech-ctte (mixmaster /etc/default/*)): Really? Won't upgrades re-enable disabled services if update-rc.d is used? Only if you delete _all_ of the links. If you leave the K links in the shutdown and reboot runlevels, they will not be put back. This ought to be documented somewhere ... It is documented in the update-rc.d manpage: Interesting, thanks. The manpage also says: | System administrators are not encouraged to use update-rc.d to manage | runlevels. My experience with update-rc.d has been mixed at best. Removing the S links manually is probably the better approach (instead of accidentally removing the K links as well, risking reactivation). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#412976 repoened - reassign tech-ctte (mixmaster /etc/default/*)
* Marc Haber: On Sat, Dec 01, 2007 at 07:34:58PM +0200, Jari Aalto wrote: From Admin's point of view dealing with symlinks is much more uncomfortable to control the initial start/stop status. If one is not comfortable with a sysvinit scheme, one should not be adminning a Debian system. Alternatives (such as file-rc) are available, and while update-rc.d is strictly speaking only geared to be used from maintainer scripts, it can also be used as a tool for the local admin. Really? Won't upgrades re-enable disabled services if update-rc.d is used? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#412976 repoened - reassign tech-ctte (mixmaster /etc/default/*)
Florian Weimer writes (Re: Bug#412976 repoened - reassign tech-ctte (mixmaster /etc/default/*)): Really? Won't upgrades re-enable disabled services if update-rc.d is used? Only if you delete _all_ of the links. If you leave the K links in the shutdown and reboot runlevels, they will not be put back. This ought to be documented somewhere ... Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#412976 repoened - reassign tech-ctte (mixmaster /etc/default/*)
On Sun, Dec 02, 2007 at 10:10:38PM +, Ian Jackson wrote: Florian Weimer writes (Re: Bug#412976 repoened - reassign tech-ctte (mixmaster /etc/default/*)): Really? Won't upgrades re-enable disabled services if update-rc.d is used? Only if you delete _all_ of the links. If you leave the K links in the shutdown and reboot runlevels, they will not be put back. This ought to be documented somewhere ... It is documented in the update-rc.d manpage: If any files /etc/rcrunlevel.d/[SK]??name already exist then update- rc.d does nothing. The program was written this way so that it will never change an existing configuration, which may have been customized by the system administrator. The program will only install links if none are present, i.e., if it appears that the service has never been installed before. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#412976 repoened - reassign tech-ctte (mixmaster /etc/default/*)
Kurt Roeckx writes (Re: Bug#412976 repoened - reassign tech-ctte (mixmaster /etc/default/*)): It is documented in the update-rc.d manpage: If any files /etc/rcrunlevel.d/[SK]??name already exist then update- rc.d does nothing. The program was written this way so that it will never change an existing configuration, which may have been customized by the system administrator. The program will only install links if none are present, i.e., if it appears that the service has never been installed before. That's good of course but the sysadmin who's messing about in /etc and is not familiar with Debian is not likely to even have heard of update-rc.d. Perhaps it should be in a README somewhere nearby. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#412976 repoened - reassign tech-ctte (mixmaster /etc/default/*)
* Fri 2007-11-30 Ian Jackson [EMAIL PROTECTED] INBOX Peter Palfrader writes (Re: Bug#412976 repoened - reassign tech-ctte (mixmaster /etc/default/*)): Summary of current status: o The mixmaster package provides both the client and server functionality. o By default the server part (running a remailer) is not enabled. o To configure mixmaster to run as a remailer the admin has to set a dozen options in /etc/mixmaster/remailer.conf. Options like email address, which formats they will accept, whether to run as an exit or only as a middleman remailer, etc. o One of those options is the REMAIL setting, which enables or disables the remailing (server) part of mixmaster. o The init script has code to only try starting the mixmaster daemon, which is only needed when it's being run as a remailer, when the REMAIL option is actually set to y in that config file. The submitter wants a new conffile, /etc/default/mixmaster, that is sourced by the init script to control whether the daemon is started. That would either be in addition or instead of the REMAIL setting in /etc/mixmaster/remailer.conf which is already used by the mixmaster software. Jari, do you agree with Peter Palfrader's summary above ? If not, in what way is it not accurate, or which important facts does it leave out ? While I would have found it more beneficial to move towards separate stages: /etc/default/* Daemon boot control setup /etc/daemon/configs Daemon run time configuration I'm fine with the result. From Admin's point of view dealing with symlinks is much more uncomfortable to control the initial start/stop status. Jari -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412976 repoened - reassign tech-ctte (mixmaster /etc/default/*)
[BTS control messages were sent separately] I ask resolution for the following dispute http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=412976 Please find resolution to the dispute where a bug was filed to ask to use /etc/default/mixmaster to control the daemon start/stop behavior. The package maintainer disagrees and has closed the bug. Introduction The bug report was based on understanding of the Policy's section: 9.3.2. Writing the scripts -- Often there are some variables in the `init.d' scripts whose values !control the behavior of the scripts, and which a system administrator !is likely to want to change. As the scripts themselves are frequently `conffile's, modifying them requires that the administrator merge in their changes each time the package is upgraded and the `conffile' changes. To ease the burden on the system administrator, such configurable values should not be placed directly in the script. !Instead, they should be placed in a file in `/etc/default', which typically will have the same base name as the `init.d' script. This extra file should be sourced by the script when the script runs. It must contain only variable settings and comments in POSIX `sh' format. It may either be a `conffile' or a configuration file maintained by the package maintainer scripts. See Section 10.7, `Configuration files' for more details. Marked lines (!) were the basis of the bug, where control of behavior was undestood as control the start or stop the daemon. Background and history The current mixmaster contains configurations files: /etc/mixmaster/ allpingers.txt client.conf filter.conf network.conf remailer ! remailer.conf update.conf Of which, the marked (!) file contains line: REMAIL n The line is used by the /etc/init.d/mixmaster to decide if the daemon will start at boot or via start command. Compatibility and benefits If the setting were in /etc/default/*, the benefits are would be as policy says: To ease the burden on the system administrator. To keep the control settings in a canonical place would make the packages and programs more manageable in the long run. Other packages that use the daemon control settings: $ grep -i enable /etc/default/* bind9: ENABLE=no bootlogd: BOOTLOGD_ENABLE=No cryptdisks: CRYPTDISKS_ENABLE=Yes dbus: ENABLED=1 debtorrent-client: DEBTORRENT_ENABLE=true debtorrent-tracker: DEBTORRENT_TRACKER_ENABLE=false mon:ENABLED=yes rsync: RSYNC_ENABLE=false spamassassin: ENABLED=1 ... Jari -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#412976 repoened - reassign tech-ctte (mixmaster /etc/default/*)
On 11218 March 1977, Jari Aalto wrote: to decide if the daemon will start at boot or via start command. If you do not want something to start - remove the startup links. Thats what those links are for. Everything else is just a broken thing. The maintainer is (IMO) right to deny your request. -- bye Joerg A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). pgpkKrtlvC0cL.pgp Description: PGP signature
Re: Bug#412976 repoened - reassign tech-ctte (mixmaster /etc/default/*)
On Thu, 29 Nov 2007, Jari Aalto wrote: [BTS control messages were sent separately] [apparently not yet, but I'll provide a summary anyway.] Summary of current status: o The mixmaster package provides both the client and server functionality. o By default the server part (running a remailer) is not enabled. o To configure mixmaster to run as a remailer the admin has to set a dozen options in /etc/mixmaster/remailer.conf. Options like email address, which formats they will accept, whether to run as an exit or only as a middleman remailer, etc. o One of those options is the REMAIL setting, which enables or disables the remailing (server) part of mixmaster. o The init script has code to only try starting the mixmaster daemon, which is only needed when it's being run as a remailer, when the REMAIL option is actually set to y in that config file. The submitter wants a new conffile, /etc/default/mixmaster, that is sourced by the init script to control whether the daemon is started. That would either be in addition or instead of the REMAIL setting in /etc/mixmaster/remailer.conf which is already used by the mixmaster software. Obviously my suggestion is to reject this request. Peter signature.asc Description: Digital signature
Re: Bug#412976 repoened - reassign tech-ctte (mixmaster /etc/default/*)
* Joerg Jaspert [Thu, 29 Nov 2007 13:54:35 +0100]: The maintainer is (IMO) right to deny your request. Agreed. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org British policemen don't wear guns. If they're chasing someone, they yell, Stop! Or I'll yell stop again. -- Robin Williams -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
