Hi, On 08/08/2013 12:35, martin f krafft wrote: > > [1] I am really not comfortable with diverting these integral > commands. The reason is that there might well be other tools that > rely on these and might trip over the requirement for a tty, or > unexpected output to stdout.
hm... maybe, maybe not. What do you mean about "requirement for a tty"? I read "test -t 0 || exit 0" (in 30-query-hostname): so tty is required to protect a command, not to execute it. The only one side effect I have found comes from molly-guard itself (needs to export MOLLYGUARD_CMD earlier in the shutdown script to avoid infinite loops with 'shutdown -c'). But as you suggest below, this should be heavily tested. > Don't you think this is too intrusive? No. In the provided patch, sysvinit's commands are not diverted by default, and the question is asked with debconf priority "low". So the diversion should be rare and only done by experienced users. Side effects (if any) should be clearly exposed by debconf, with the question. Additionally, when a command is diverted, this is generally to replace it by another one; for example, if you install gnu-fdisk, this will divert fdisk and cfdisk; then if you invoke 'cfdisk', the diverted command will not be executed; here, the diversion is used to add a check-point before the execution of the diverted command, and then call it or exit. Finally, this is always the sysvinit's commands that are used to halt/reboot/poweroff/shutdown the system. Maybe this usage of dpkg-divert is a little bit hackish or not very canonical, but I don't feel it so intrusive. The global scheme is the following: root@debian:~# halt (is /usr/sbin/halt) then: -> /usr/sbin/halt: *CHECK* -> exit, or exec /sbin/halt -> exec /sbin/halt.real user@debian:~$ halt (is alias halt='sudo /sbin/halt') then: -> /sbin/halt (test the value of "$MOLLYGUARD_CMD") -> exec /usr/sbin/halt: *CHECK* (and export MOLLYGUARD_CMD) -> exit, or exec /sbin/halt (test the value of "$MOLLYGUARD_CMD") -> exec /sbin/halt.real If /usr/sbin/halt is not executable (/usr not mounted...), then: -> /sbin/halt -> exec /sbin/halt.real > [2] Instead of setting env_keep globally, I suggest to create > a Cmnd_Alias for the commands molly-guard protects, and then to use > this syntax: > > Defaults!MOLLY_GUARD_COMMANDS env_keep+=SSH_CONNECTION Oh, yes (even if I think there is no need to be so precautionous with a such variable) > In general, this looks well done. I am really just hesitant to make > such changes at the moment, and this is mainly because I know I will > not be able to deal with bug reports if they come in over the next > months. I hear. But as I would be the author of such bugs, I should be able to deal with reports about them. And I have enough time for that. > How would you feel taking over molly-guard maintenance? Then I would > suggest that we upload a new package to experimental and get some > testers. Alright. Sounds good to me. I'm not very experienced as a package maintainer, so my question is: how to proceed ? (I suppose I have to bump to compat 9 and update the Standards-Version to the current one, add my name and email address here and there, create the missing debian/source/format as "quilt", provide fr.po for debconf as proposed in a previous email, fix lintian warnings and so on, and finally add an entry in the changelog to report that and close the related bugs; but after ?) And for the tests... maybe the author of #660064 could be interested ? Cheers, quidame
signature.asc
Description: OpenPGP digital signature
