[systemd-devel] script assigned via Unit's ExecStartPre= only partially executes, fails to complete ?

[jen142 at promessage.com]

> There is no reason to lose valuable debugging information. All output
> is collected by systemd and is available via journal. Hiding it makes
> really no sense.
...
> Show quoted textThis is not a shell, and you cannot reference $PATH like this. Full
> content of the variable has to included instead.

I fixed both of those.

Now,

	cat /etc/systemd/system/openvpn.service 
		[Unit]
		Description=OpenVPN Server
		After=syslog.target network.target
		Before=openvpn.target

		[Service]
		Type=forking
		PrivateTmp=true
		PIDFile=/var/run/openvpn/openvpn.pid
		Environment=PATH="/usr/local/openvpn-unpriv:/usr/local/scripts:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin"
		ExecStartPre=/usr/local/etc/openvpn/up.script
		ExecStart=/usr/local/sbin/openvpn --daemon --writepid
		/var/run/openvpn/openvpn.pid --cd
		/usr/local/etc/openvpn/ --config server.conf
		ExecStopPost=/usr/local/etc/openvpn/down.script

		[Install]
		WantedBy=multi-user.target

and

	cat /usr/local/etc/openvpn/up.script
		#!/bin/sh
		/usr/local/sbin/openvpn --rmtun --dev tun1
		/usr/local/sbin/openvpn --mktun --dev tun1 --dev-type
		tun --user openvpn --group openvpn
		/usr/sbin/iptables -v -I FORWARD -i eth0 -o tun1 -j
		ACCEPT
		/usr/sbin/iptables -v -I FORWARD -i tun1 -o eth0 -j
		ACCEPT

, adding the "-v" verbose flag to iptables

> Use "journalctl -u openvpn.service", this will show *all* output
> associated with your unit start/stop.

The output from 'journalctl -u openvpn.service' was helpful.  Thanks for
the pointer!

A colleague pointed out permissions problems for iptables & insmod, and
suggested a solution

Adding 

	Defaults:openvpn !requiretty
	openvpn ALL=(ALL) NOPASSWD: /usr/sbin/iptables
	openvpn ALL=(ALL) NOPASSWD: /usr/sbin/ip6tables
	openvpn ALL=(ALL) NOPASSWD: /sbin/insmod

to

	/etc/sudoers.d/openvpn

seems to do the trick.

Now, after boot,

	journalctl -u openvpn.service

		...
		Dec 01 09:44:45 test systemd[4461]: Executing:
		/usr/local/etc/openvpn/up.script
		Dec 01 09:44:46 test up.script[4461]: Sun Dec  1
		09:44:46 2013 TUN/TAP device tun1 opened
		Dec 01 09:44:46 test up.script[4461]: Sun Dec  1
		09:44:46 2013 Persist state set to: OFF
		Dec 01 09:44:46 test up.script[4461]: Sun Dec  1
		09:44:46 2013 TUN/TAP device tun1 opened
		Dec 01 09:44:46 test up.script[4461]: Sun Dec  1
		09:44:46 2013 Persist state set to: ON
		Dec 01 09:44:46 test up.script[4461]: ACCEPT  all opt --
		in eth0 out tun1  0.0.0.0/0  -> 0.0.0.0/0
		Dec 01 09:44:46 test up.script[4461]: ACCEPT  all opt --
		in tun1 out eth0  0.0.0.0/0  -> 0.0.0.0/0
		Dec 01 09:44:46 test systemd[4489]: Executing:
		/usr/local/sbin/openvpn --daemon --writepid
		/var/run/openvpn/openvpn.pid --cd
		/usr/local/etc/openvpn/ --config server.conf
		Dec 01 09:44:47 test sudo[4504]: root : TTY=unknown ;
		PWD=/usr/local/etc/openvpn ; USER=root ;
		COMMAND=/sbin/ip link set dev tun1 up mtu 1500
		Dec 01 09:44:47 test sudo[4530]: root : TTY=unknown ;
		PWD=/usr/local/etc/openvpn ; USER=root ;
		COMMAND=/sbin/ip addr add dev tun1 local 10.1.1.1 peer
		10.1.1.2
		Dec 01 09:44:47 test sudo[4552]: root : TTY=unknown ;
		PWD=/usr/local/etc/openvpn ; USER=root ;
		COMMAND=/sbin/ip route add 10.1.1.0/24 via 10.1.1.2

there's no more permission errors, and it appears iptables execs, now.

checking,

	iptables -L -v -n | grep tun
	    0     0 ACCEPT     all  --  tun1   eth0    0.0.0.0/0        
	       0.0.0.0/0           
	    0     0 ACCEPT     all  --  eth0   tun1    0.0.0.0/0        
	       0.0.0.0/0  

it's clearly been exec'd.

iptables & insmod needing root perms via sudoers I _suspect_ has to do
with openvpn being chroot'd, with user:group == openvpn:openvpn.

I don't know is there's a systemd-specific method of granting those
permissions correctly, without using sudoers.

The "-v" flag to iptables is required in the unit's referenced
ExecStartPre= script -- without it, there's NO trace of iptables
exec'ing in the journalctl output.

JenL