> 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
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
