On 03/02/2019 22:03, Daniel Miller wrote: > On 2/3/2019 8:36 AM, David Sommerseth wrote: >> On 01/02/2019 01:35, Daniel Miller via Openvpn-users wrote: >>> I may open a bug with Ubuntu (my server is on Bionic) but a recent re-boot >>> after some config changes may have exposed something. This isn't an OpenVPN >>> bug - rather known OpenVPN behavior that may catch others so I'm sharing. >>> >>> Having installed packages quagga-ospfd & quagga-core I setup some basic OSPF >>> rules to communicate with my router. After re-booting yesterday I found >>> that >>> my VPN wouldn't start up. Further investigation found the TUN devices >>> wasn't >>> being created - and the error was the dreaded "RTNETLINK answers: File >>> exists". Stopping the ospfd & zebra services then allowed openvpn to >>> initialize without issue. >>> >>> Accordingly, I modified my systemd units: >>> >>> openvpn.service - change to "After=network-online.target" >>> >>> zebra.service - remove the "Before=network.target" and change to >>> "After=openvpn-server@<my-vpn>.service" >> Just some potential confusion .... you say you modify *openvpn.service* >> (which >> you should forget all about, but that's a different story) but you actually >> do >> use *[email protected]* (which is what you should use). This latter >> one >> should have (if your package contains the latest upstream changes) these two >> lines: >> >> After=syslog.target network-online.target >> Wants=network-online.target >> > Quite right - I made the change to [email protected] as well. And if we > need a different thread for the different story... > > The "openvpn.service" seems to basically be null. Was this intended for some > future purpose? That's part of the different thread of a different story ;-)
openvpn.service is basically a result of Debianism in addition to Linux distributions not working with upstream OpenVPN directly back in the days. They created some unit files without interacting with us in the very beginning. Well, in fact, no distros switching to systemd got in touch with us. openvpn.service in the Debian/Ubuntu world was their attempt of trying implementing something which behaved similar to /etc/init.d/openvpn before systemd came to existence. So they have some generators which does some magic behind the scene and starts [email protected] instances per config. There are some claims lately that this is now working as it should. But I'm not quite sold on it yet. There has also been some ugly history with distributions not having really good [email protected] unit files too. Which is why we created the openvpn-{client,server}@.service unit files. As server and client configurations are different and have different requirements on the host, we split it up into two pieces so we can harden them separately. And the benefit was that it was a bigger chance to get users migrating away from brokenness. And for quite a bit we had much better functional working unit files shipped in the openvpn package than what distro maintainers put into their builds. This became quite clear when we released OpenVPN 2.4, which is much more systemd aware and can facilitate systemd features much better. In addition to even more hardening. But ... we also discovered that some distros didn't pick up our .service file updates in later releases; resulting in brokenness again. I do know Debian packages has improved here though. I'm sorry for all the distro maintainers reading this rant, but after having spent too much time on the #openvpn IRC channel helping users of various distributions (even though Debian/Ubuntu users has been more common) get their VPN setup running at boot due to bad unit files .... well, it's been a rough ride at times and even users blaming the OpenVPN community for breaking their setups. That said, I have the impression things have improved lately. And it helped a lot when some Arch(?) user stepped in and helped figuring out a lot of additional fixes as well around the 2.4 release. But due to the history, I'm still not convinced it is working as well as it could in the Debian/Ubuntu universe. Hopefully I'm just plain wrong. (And if something is misbehaving in Fedora/RHEL/CentOS/Scientific Linux land ... hit me! I'm the maintainer of those packages) -- kind regards, David Sommerseth OpenVPN Inc
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Openvpn-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openvpn-users
