On Sat, Dec 27, 2003 at 05:36:40PM -0800, Vincent Bernat wrote: > OoO Vers la fin de l'après-midi du samedi 27 décembre 2003, vers > 16:47, Colin Watson <[EMAIL PROTECTED]> disait: > > Having said that, there seems to be a patch in the BTS at the moment > > which I ought to look at. > > Since the original one was quite old, I have sent two new.
That's what I was referring to. > The original one get rid of /etc/ssh/sshd_not_to_be_run. As I say, that should happen by splitting the package, post-sarge. > If the user does not want the server, the symlinks are removed, it > can still launch it via /etc/init.d. That doesn't really work. Your original patch meant that the user's choice was *only* remembered in the debconf cache, which might be removed at any time. At the moment /etc/ssh/sshd_not_to_be_run is simply a record of the answer in a validly persistent location. > My first patch looks at the name of the script. If it is invoked as S* > or K*, /etc/ssh/sshd_not_to_be_run is respected, otherwise the action > is taken whatever this file exists or not. It is almost the same as > the original approach. > > The second patch adds some targets : force-start, force-stop and > force-reload. With start, stop and reload, the script behaves the same > way as the original script, so we don't need to modify other scripts > like the postinst one (and maybe some others). The force-* versions > will do the appropriate actions even if /etc/ssh/sshd_not_to_be_run > exists. > > Just handling symlinks in /etc/rc.d is not sufficient enough since > many postinst scripts should then be modified to avoid the server to > start against the user will. In contrast, adding "force-*" targets > would force the user to modify its own scripts (for example, when he > could have written a script that launches Apache+MySQL). I prefer the second option. ssh's postinst can't invoke the init script via the S* and K* names because the user might wish to change the ordering of their init scripts. Also, the user might not be using the S* and K* scheme at all, but might be using file-rc. In addition, the second option nicely avoids being invasive, since it doesn't change the meaning of existing targets. Cheers, -- Colin Watson [EMAIL PROTECTED]
