You are not logged in.
Arch's OpenVPN 2.5.0 introduced a major breaking change to existing systems via git-svn-id: file:///srv/repos/svn-packages/svn@399566 eb2447ed-0c53-47e4-bac8-5bc4a241df78, which moved the service from root to a dedicated user account. This had the effect of breaking any existing OpenVPN configs which relied on reading root-only files (i.e. credential files) or needing root-specific functionality (i.e. iproute).
The change required non-trivial manual intervention to resolve and caused significant confusion, as evidenced by the numerous bug reports and forum threads:
- FS#68480 - [openvpn] running unprivileged with iproute no longer working
- FS#68589 - OpenVPN scripts fail after upgrade to 2.5
- FS#68568 - [openvpn] update-systemd-resolved script no longer runs
- https://bbs.archlinux.org/viewtopic.php?id=260625
- https://bbs.archlinux.org/viewtopic.php?id=260900
- https://bbs.archlinux.org/viewtopic.php?id=261097
- https://bbs.archlinux.org/viewtopic.php?id=260784
- https://lists.archlinux.org/pipermail/a … 48341.html
While the change was acknowledged by a message printed to console at upgrade time, I couldn't find the change documented anywhere else. Even a month later, the OpenVPN entry in Arch Wiki contains outdated advice and information. Documentation on recommended alternatives to broken functionality is still fairly sparse.
Some questions:
1. I generally check https://www.archlinux.org/news/ before upgrading to see if I should expect breaking changes to core system services. Previous OpenVPN breaking changes were documented there in the past. Should this change have been documented there? Where else should I check for these kinds of breaking changes?
2. Are these kinds of changes generally discussed or vetted anywhere before being made? This was a security-relevant change to a very sensitive system component. Notably, Arch seems to be deviating from upstream defaults, and defaults on both Debian and (afaik) RHEL/CentOS. I couldn't find any discussion in either arch-general or arch-dev-public.
3. I decided to workaround these changes by overriding the systemd config in /etc/systemd so that openvpn will continue its pre-2.5.0 behavior. Are there any incompatibilities I need to be aware of because of this?
Overall, I was quite upset and surprised by this change, which was a rare deviation from the usually smooth and well-communicated update process I've enjoyed with Arch over the years. I wanted to provide this feedback, and hopefully spark a discussion to avoid such incidents in the future.
Last edited by RandomBK (2020-12-01 09:17:18)
Offline
I was lucky that I read the post install message on the server that DID NOT have OpenVPN.
Otherwise it would have broken 3-4 OpenVPN servers that I run, without any warning. (with sufficient time in hand to check what has changed)
I immediately wrote a systemd.service file override (with empty User=, Group= entries) and made sure that it wont break OpenVPN after upgrade.
Later I setup a test system and changed my OpenVPN configs to suit the new changes and then upgraded the OpenVPN server.
Overall I do agree that this needed a NEWS item (not just post install message). So people know before they upgrade that changes are going to break your existing VPN config and be prepared before you upgrade. But well ...
Even I was going to write a post complaining why it was done without a warning. But then since LUCKILY it did not affect me, I did not complain.
Last edited by amish (2020-12-01 09:48:23)
Offline
Yeah I was quite shocked by this change as well, and would have liked it to be on the front page. And a hint towards "new" best practices, in addition to the vague "workarounds may be required.".
I still haven't got a good way of letting openvpn run resolvconf to bring in the DNS from the remote end, but monkey-lazy-patched it with allowing openvpn to sudo it.
Offline
To the OP: Very well said. The breaking changes were definitely worth a news item in my opinion, but nothing was ever proposed by the maintainer(s) in the mailing lists that I can see.
I think it's worth sending that to arch-dev-public. It may or may not get any response, but worth it so more Devs and TUs see it.
Offline
Many of these breaking changes never make it to the news, recently the kernel change of EFI path separators that broke boot on many machines also never made it.
Offline