Le jeudi 11 août 2011 à 14:37 +0200, Dr. Werner Fink a écrit :
On Wed, Aug 10, 2011 at 11:45:01AM +0200, Frederic Crozat wrote:
Currently I've not found a way to port
PortOpts="" for cfg in /etc/sendmail.cf /etc/mail/sendmail.cf do test -s $cfg || continue PortOpts=$(sed -rn '/^O[[:blank:]]+DaemonPortOptions=.*Name=MTA.*$/I { s/[[:blank:]]+//g s/^O[^=]+=(.*)/\1/p }' $cfg) break done unset cfg
if test "$SMTPD_LISTEN_REMOTE" != "yes" ; then PortOpts="${PortOpts:+${PortOpts},}Addr=127.0.0.1" SENDMAIL_ARGS="-O DaemonPortOptions=${PortOpts} $SENDMAIL_ARGS" fi
from /etc/init.d/sendmail to the service unit sendmail.service. With this there is a control if the MTA is listen on port 25 of any remote network interface or if not. How can this be done within a systemd service unit (without using a wrapper script)?
You can't do that directly in a unit file.
Maybe it would be an idea to have to possiblity to use short shell commands as it is possible in make or spec files:
Environment=SENDMAIL_PORT_OPTS=$(shell code)
You should suggest this on systemd-devel mailing list but I'm not sure systemd folks wants this.
One option is to create a systemd generator (which is what is used for crypttab and getty service), to be installed in /lib/systemd/system-generator which would be started by systemd and would create temporary .service files in /run/systemd/generators (which is a tmpfs) which would be used by systemd as "normal" service files.
I've tested quickly and just dropping generator script in /lib/systemd/system-generators, make sure it is executable and takes one parameter which is the path where generated unit files should be written.
Hmmm ... I'm missing documentation on the topic `System Generators'.
I've discussed this with systemd people at Desktop Summit. They
suggested only do socket activation on the "main" socket and have the
daemon listen to other sockets specified in sendmail configuration, if
they are free (like cups is doing :
http://0pointer.de/blog/projects/socket-activation2.html ).
System Generators were also mentioned as another way to do this but they
are started very early in boot process (so you can't depend on any
service) and don't have any "API stability promisse" (which is probably
why there is no real documentation about it).
--
Frederic Crozat