Everything works well if I start the service by hand. I can connect from remote.
However if I reboot the machine then the automatic start of openvpn fails.
Here the excerpt from my openvpnn log:
TCP/UDP: Socket bind failed on local address [AF_INET]192.168.2.2:1194: Cannot assign requested address
Exiting due to fatal error
Closing TUN/TAP interface
When I start the service later by hand, then it works. Thus I assume its the missing eth0 (192.168.7.2) not coming up in time.
I read ‘man 5 ifcfg’ to find out if there is an option to wait for eth0 to come up but did not find anything.
Here the content of my current /etc/sysconfig/network/ifcfg-tap0
I also tried to change the settings in /etc/systemd/system/openvpn.target.wants/openvpn@openvpn_udp.service
the current change to the original file is highlighted in bold. That change does not seem to change anything.
[Unit]
Description=OpenVPN tunneling daemon instance using /etc/openvpn/%I.conf
After=network.target network-online.target
PartOf=openvpn.target
I’m just guessing,
You could try adding to the [Service] section the following
Requiredby= network.service
Remember,
When you customize a systemd Unit file, never modify the original file.
If this is a “system” and not a “user” Unit file, copy the Unit file to the following directory and modify your copy. That way the original is unchanged so that if your copy doesn’t work then the system will fall back to the original and if you want to undo your changes you can simply delete your copy leaving the original.
/etc/systemd/system/
The diff is that “Requires” ensures that the requirement is absolutely provided.
Everything else like Wants, After are soft requirements, they might be started but not fully working before what you to do has already started.
the problem was, as often, in front of the keyboard.
The issue was that my tap device belongs to a bridge. I stupidly followed the example of the simple example in the tutorial.
In fact, as the device is bridged it shall not trigger the start of openvpn automatically.
After removing PRE_UP_SCRIPT and PRE_DOWN_SCRIPT openvpn server is correctly started after reboot.
Additionally I made sure using Requires= and RequiredBy that openvpn is only started after the wicked service.
Thanks
Bernd
PS: Maybe it would be a good idea to put also a bridging VPN example into the documentation…?
A close reading of the MAN page confirms that Requires= does not affect ordering, but is also unclear what happens if its condition is not met when starting… It only describes what happens in a running system in which case if for some reason what is required stops/crashes, then this configured systemd service would immediately stop. So, I guess this might be a setting useful not only on a running system but possibly for shutting down although it’s unclear what the behavior would be if there is an active long running process, like a file transfer taking place.
One could perhaps extrapolate the MAN page description to infer that if there is a hard requirement that a service needs to exist so that something following can also exist, but that seems to be emphatically not the case. We’re therefor left with the MAN pages describing what is not rather than what is.
Such is the problem when tech-speak becomes so self-involved that it’s not just poorly understood, possibly because it’s poorly understood the meaning is incomplete and faulty.
And,
the MAN page descriptions for the recommended After= and Before= for ordering are also unclear… They clearly try to be specific about only the <start> of a service but there is no mention of a service fully running, is systemd really designed without a fully serial “load” sequence where there is an assurance a prior service is fully functional before proceeding to the next load item?
A brief survey of Internet hits on systemd load sequencing returns plenty of hits of people asking this same question, so this is not nearly the first time the question has been asked. In all cases people answer referencing passages from the MAN pages with no significant further elaboration, so it looks like no one really has a definitive answer they can describe in their own words.