[arch-dev-public] Preparing OpenVPN 2.4.x - possible incompatible changes - Arch-dev-public

newer
[arch-dev-public] Signoff report...

[arch-dev-public] Preparing OpenVPN 2.4.x - possible incompatible changes

older
[arch-dev-public] Integrity Check...

Christian Hesse

26 Nov 2016 26 Nov '16

4:38 a.m.

Hello everybody, a new OpenVPN stable release is being prepared, namely version 2.4.0. Currently we have 2.4_beta2. I think about making changes to our package that require user intervention. We shipped a systemd unit file before OpenVPN upstream had one. Upstream now has unit files, but two (for server and client) instead of just one. I did backport some security features for our unit, but refused to migrate to the upstream solution within the 2.3.x branch. That could change with 2.4.0. Instead of openvpn@.service we would have openvpn-server@.service and openvpn-client@.service. Additionally the 'daemon' option is no longer allowed with the upstream units. Any opinion about this change? Who can post news about this on the website? Stumbled about another fact... We define PLUGIN_LIBDIR, that allows to use relative paths from that directory in configuration to call the plugins. This path is '/usr/lib/openvpn' - plugins are installed to '/usr/lib/openvpn/plugins', though. Any reason for that? -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}

Attachments:

attachment.sig (application/pgp-signature — 455 bytes)

Show replies by date

Christian Hesse

26 Nov 26 Nov

4:42 a.m.

Christian Hesse on Sat, 2016/11/26 13:38:

...

That could change with 2.4.0. Instead of openvpn@.service we would have openvpn-server@.service and openvpn-client@.service. Additionally the 'daemon' option is no longer allowed with the upstream units.

Oh, and another change... Configuration moves to sub directories /etc/openvpn/server and /etc/openvpn/client. -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}

Florian Pritz

8:37 a.m.

On 26.11.2016 13:38, Christian Hesse wrote:

...

Any opinion about this change? Who can post news about this on the website?

You should be able to add news here[1] at the top right. I don't use openvpn so I don't care about this, but converging towards what upstream does is generally a good idea. [1] https://www.archlinux.org/news/ Florian

Bartłomiej Piotrowski

12:55 p.m.

On 2016-11-26 13:38, Christian Hesse wrote:

...

Hello everybody,

a new OpenVPN stable release is being prepared, namely version 2.4.0. Currently we have 2.4_beta2. I think about making changes to our package that require user intervention.

We shipped a systemd unit file before OpenVPN upstream had one. Upstream now has unit files, but two (for server and client) instead of just one. I did backport some security features for our unit, but refused to migrate to the upstream solution within the 2.3.x branch.

That could change with 2.4.0. Instead of openvpn@.service we would have openvpn-server@.service and openvpn-client@.service. Additionally the 'daemon' option is no longer allowed with the upstream units.

Any opinion about this change? Who can post news about this on the website?

Stumbled about another fact... We define PLUGIN_LIBDIR, that allows to use relative paths from that directory in configuration to call the plugins. This path is '/usr/lib/openvpn' - plugins are installed to '/usr/lib/openvpn/plugins', though. Any reason for that?

I don't really use OpenVPN outside NetworkManager nowadays. Your proposed changes sound reasonable even without a news item (I guess post_upgrade message would be sufficient; let's raise our cups for correct usage of that). Bartłomiej

Christian Hesse

1:11 p.m.

Bartłomiej Piotrowski on Sat, 2016/11/26 21:55:

...

On 2016-11-26 13:38, Christian Hesse wrote:

...
Hello everybody,

a new OpenVPN stable release is being prepared, namely version 2.4.0. Currently we have 2.4_beta2. I think about making changes to our package that require user intervention.

[...]

Any opinion about this change? Who can post news about this on the website?

I don't really use OpenVPN outside NetworkManager nowadays.

Will have to test that... But I do not think anything breaks there.

...

Your proposed changes sound reasonable even without a news item (I guess post_upgrade message would be sufficient; let's raise our cups for correct usage of that).

Thought about that already... and implemented locally. I think that is the way to go. ;) -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}

Sébastien Luttringer

6:55 p.m.

On Sat, 2016-11-26 at 13:38 +0100, Christian Hesse wrote:

...

Any opinion about this change? Who can post news about this on the website?

The switch from Type=forking to simple will break units which rely on proper ordering of subnets added by that tunnel. That look as a regression to me. I'm using openvpn on my hosts, few of them are only reachable via its tunnel. There is other users doing so. I suggest to maximize our chance to warn them by using both News and post upgrade message.

...

Stumbled about another fact... We define PLUGIN_LIBDIR, that allows to use relative paths from that directory in configuration to call the plugins. This path is '/usr/lib/openvpn' - plugins are installed to '/usr/lib/openvpn/plugins', though. Any reason for that?

Never understand that neither. As configuration need to be changed, that's a good time for changing this path. -- Sébastien "Seblu" Luttringer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A

Christian Hesse

27 Nov 27 Nov

4:20 a.m.

Sébastien Luttringer on Sun, 2016/11/27 03:55:

...

On Sat, 2016-11-26 at 13:38 +0100, Christian Hesse wrote:

...
Any opinion about this change? Who can post news about this on the website?

The switch from Type=forking to simple will break units which rely on proper ordering of subnets added by that tunnel. That look as a regression to me.

Can you give more detail on that? For me route-up scripts broke... With Type=simple it is no longer allow to send dnsmasq a SIGHUP to flush its cache. So probably we will go with upstream and slit the units, but apply an additional patch to unbreak things.

...

I'm using openvpn on my hosts, few of them are only reachable via its tunnel. There is other users doing so. I suggest to maximize our chance to warn them by using both News and post upgrade message.

That's true... We will definitely have a post-upgrade message, actually I tend to add a news post as well.

...

...
Stumbled about another fact... We define PLUGIN_LIBDIR, that allows to use relative paths from that directory in configuration to call the plugins. This path is '/usr/lib/openvpn' - plugins are installed to '/usr/lib/openvpn/plugins', though. Any reason for that?

Never understand that neither. As configuration need to be changed, that's a good time for changing this path.

This will change now. -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}

Christian Hesse

29 Nov 29 Nov

6:26 a.m.

Christian Hesse on Sun, 2016/11/27 13:20:

...

Sébastien Luttringer on Sun, 2016/11/27 03:55:

...
On Sat, 2016-11-26 at 13:38 +0100, Christian Hesse wrote:

...
Any opinion about this change? Who can post news about this on the website?

The switch from Type=forking to simple will break units which rely on proper ordering of subnets added by that tunnel. That look as a regression to me.

Can you give more detail on that?

For me route-up scripts broke... With Type=simple it is no longer allow to send dnsmasq a SIGHUP to flush its cache.

Apparently the units do not have CAP_KILL, so my script failed sending SIGHUP to dnsmasq. Probably this is just find... I solved this by sending ClearCache command to dnsmasq via dbus. So still interested in details of your issue... -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}

Christian Hesse

7:36 a.m.

Christian Hesse on Tue, 2016/11/29 15:26:

...

Christian Hesse on Sun, 2016/11/27 13:20:

...
Sébastien Luttringer on Sun, 2016/11/27 03:55:

...
On Sat, 2016-11-26 at 13:38 +0100, Christian Hesse wrote:

...
Any opinion about this change? Who can post news about this on the website?

The switch from Type=forking to simple will break units which rely on proper ordering of subnets added by that tunnel. That look as a regression to me.

Can you give more detail on that?

For me route-up scripts broke... With Type=simple it is no longer allow to send dnsmasq a SIGHUP to flush its cache.

Apparently the units do not have CAP_KILL, so my script failed sending SIGHUP to dnsmasq. Probably this is just find... I solved this by sending ClearCache command to dnsmasq via dbus.

So still interested in details of your issue...

And bonus question... Does this fix your issue? https://sourceforge.net/p/openvpn/mailman/message/35521176/ -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}

Sébastien Luttringer

1 Dec 1 Dec

6:09 p.m.

On Tue, 2016-11-29 at 16:36 +0100, Christian Hesse wrote:

...

Christian Hesse on Tue, 2016/11/29 15:26:

...
Christian Hesse on Sun, 2016/11/27 13:20:

...
Sébastien Luttringer on Sun, 2016/11/27 03:55:

...
On Sat, 2016-11-26 at 13:38 +0100, Christian Hesse wrote:

...
Any opinion about this change? Who can post news about this on the website?

The switch from Type=forking to simple will break units which rely on proper ordering of subnets added by that tunnel. That look as a regression to me.

Can you give more detail on that?

For me route-up scripts broke... With Type=simple it is no longer allow to send dnsmasq a SIGHUP to flush its cache.

Apparently the units do not have CAP_KILL, so my script failed sending SIGHUP to dnsmasq. Probably this is just find... I solved this by sending ClearCache command to dnsmasq via dbus.

So still interested in details of your issue...

And bonus question... Does this fix your issue?

https://sourceforge.net/p/openvpn/mailman/message/35521176/

Yes. Thanks Christian! -- Sébastien "Seblu" Luttringer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A

Christian Hesse

2 Dec 2 Dec

4:23 a.m.

Sébastien Luttringer on Fri, 2016/12/02 03:09:

...

On Tue, 2016-11-29 at 16:36 +0100, Christian Hesse wrote:

...
Christian Hesse on Tue, 2016/11/29 15:26:

...
Christian Hesse on Sun, 2016/11/27 13:20:

...
Sébastien Luttringer on Sun, 2016/11/27 03:55:

...
On Sat, 2016-11-26 at 13:38 +0100, Christian Hesse wrote:

...
Any opinion about this change? Who can post news about this on the website?

The switch from Type=forking to simple will break units which rely on proper ordering of subnets added by that tunnel. That look as a regression to me.

Can you give more detail on that?

For me route-up scripts broke... With Type=simple it is no longer allow to send dnsmasq a SIGHUP to flush its cache.

Apparently the units do not have CAP_KILL, so my script failed sending SIGHUP to dnsmasq. Probably this is just find... I solved this by sending ClearCache command to dnsmasq via dbus.

So still interested in details of your issue...

And bonus question... Does this fix your issue?

https://sourceforge.net/p/openvpn/mailman/message/35521176/

Yes. Thanks Christian!

Great! This already made its way into the official repository and will be available in version 2.4.0 (and our package). Thanks for testing! -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}

Giancarlo Razzolini

29 Nov 29 Nov

8:14 a.m.

Em novembro 26, 2016 10:38 Christian Hesse escreveu:

...

Hello everybody,

a new OpenVPN stable release is being prepared, namely version 2.4.0. Currently we have 2.4_beta2. I think about making changes to our package that require user intervention.

We shipped a systemd unit file before OpenVPN upstream had one. Upstream now has unit files, but two (for server and client) instead of just one. I did backport some security features for our unit, but refused to migrate to the upstream solution within the 2.3.x branch.

That could change with 2.4.0. Instead of openvpn@.service we would have openvpn-server@.service and openvpn-client@.service. Additionally the 'daemon' option is no longer allowed with the upstream units.

Any opinion about this change? Who can post news about this on the website?

Stumbled about another fact... We define PLUGIN_LIBDIR, that allows to use relative paths from that directory in configuration to call the plugins. This path is '/usr/lib/openvpn' - plugins are installed to '/usr/lib/openvpn/plugins', though. Any reason for that?

Well, I think it is good upstream is (finally) caring about the actual deployment of their software. I always found openvpn packaging odd on all the systems I used. On some, a user is created for running unprivileged. On others, everything is created and taken care of, including logging. I do not oppose using whatever upstream is deploying, if it's rationale. I just think that we could create a system user for openvpn, even if most users will deploy it using root. In that sense we would also (probably) need a /run/openvpn directory. I managed to make openvpn work entirely unprivileged here and I plan on changing our wiki[0] on the matter (it's missing some info) and also the official documentation[1] do not account for systemd nor ip netns exec, which is a clear venue for privilege escalation. What do you guys think? Cheers, Giancarlo Razzolini [0] https://wiki.archlinux.org/index.php/OpenVPN#Drop_root_privileges_after_conn... [1] https://openvpn.net/index.php/open-source/documentation/howto.html#security

Christian Hesse

8:38 a.m.

Giancarlo Razzolini on Tue, 2016/11/29 16:14:

...

Em novembro 26, 2016 10:38 Christian Hesse escreveu:

...
Hello everybody,

a new OpenVPN stable release is being prepared, namely version 2.4.0. Currently we have 2.4_beta2. I think about making changes to our package that require user intervention.

We shipped a systemd unit file before OpenVPN upstream had one. Upstream now has unit files, but two (for server and client) instead of just one. I did backport some security features for our unit, but refused to migrate to the upstream solution within the 2.3.x branch.

That could change with 2.4.0. Instead of openvpn@.service we would have openvpn-server@.service and openvpn-client@.service. Additionally the 'daemon' option is no longer allowed with the upstream units.

Any opinion about this change? Who can post news about this on the website?

Stumbled about another fact... We define PLUGIN_LIBDIR, that allows to use relative paths from that directory in configuration to call the plugins. This path is '/usr/lib/openvpn' - plugins are installed to '/usr/lib/openvpn/plugins', though. Any reason for that?

Well,

I think it is good upstream is (finally) caring about the actual deployment of their software. I always found openvpn packaging odd on all the systems I used. On some, a user is created for running unprivileged. On others, everything is created and taken care of, including logging.

I do not oppose using whatever upstream is deploying, if it's rationale. I just think that we could create a system user for openvpn, even if most users will deploy it using root.

We need root privileges at initialization phase, no? Privileges are dropped to nobody/nobody when initialization sequence completed. If we can make things work with non-root system user... Let me know how to do that. :D

...

In that sense we would also (probably) need a /run/openvpn directory.

The new systemd units create this automatically. (Well, actually /run/openvpn-client and /run/openvpn-server.)

...

I managed to make openvpn work entirely unprivileged here and I plan on changing our wiki[0] on the matter (it's missing some info) and also the official documentation[1] do not account for systemd nor ip netns exec, which is a clear venue for privilege escalation. What do you guys think?

Just followed the link from our wiki [2]. Probably you can make this work, but I am not convinced this can be packaged to work smoothly. Dynamic device naming, up/route-up/... scripts, ... There is lot of stuff that can and will break. Still, if you have some clues on how to package this...

...

[0] https://wiki.archlinux.org/index.php/OpenVPN#Drop_root_privileges_after_conn... [1] https://openvpn.net/index.php/open-source/documentation/howto.html#security

[2] https://community.openvpn.net/openvpn/wiki/UnprivilegedUser -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}

Giancarlo Razzolini

9 a.m.

Em novembro 29, 2016 14:38 Christian Hesse escreveu:

...

We need root privileges at initialization phase, no? Privileges are dropped to nobody/nobody when initialization sequence completed.

If we can make things work with non-root system user... Let me know how to do that. :D

We just need root for creating the tun devices and destroying them. I managed to make an entire unprivileged deployment. Basically all I need is this: [Service] User=openvpn Group=openvpn PermissionsStartOnly=true ExecStartPre=-/usr/bin/openvpn --rmtun --dev tun0 ExecStartPre=/usr/bin/openvpn --mktun --dev tun0 --dev-type tun --user openvpn --group openvpn ExecStart= ExecStart=/usr/bin/openvpn --cd /etc/openvpn --config %i.conf --daemon openvpn@%i --writepid /run/openvpn/openvpn@%i.pid --status-version 2 PIDFile=/run/openvpn/openvpn@%i.pid The config file doesn't need any actual user/group configuration, because it is already started with the right user/group. It needs to use a different iproute binary (which in my case is a script) that has sudo permissions for the openvpn user to run the ip command as root.

...

The new systemd units create this automatically. (Well, actually /run/openvpn-client and /run/openvpn-server.)

Nice to hear this.

...

Just followed the link from our wiki [2]. Probably you can make this work, but I am not convinced this can be packaged to work smoothly. Dynamic device naming, up/route-up/... scripts, ... There is lot of stuff that can and will break.

Still, if you have some clues on how to package this...

I never meant for you (us) to package such setup. I was just making the case for a dedicated openvpn system user and it's run directories. At least one of those is already taken care of. If we can deploy such unprivileged systemd units, alongside upstream official ones, it's another matter. Personally I'm okay with all of this and I'll accommodate my setup, no matter how openvpn gets packaged. I had to compile openvpn for at least two release cycles because of a bug on it[0]. I think you'll probably remember that one. Cheers, Giancarlo Razzolini [0] https://bugs.archlinux.org/task/50090

Christian Hesse

2 Dec 2 Dec

4:25 a.m.

Giancarlo Razzolini on Tue, 2016/11/29 17:00:

...

Personally I'm okay with all of this and I'll accommodate my setup, no matter how openvpn gets packaged. I had to compile openvpn for at least two release cycles because of a bug on it[0]. I think you'll probably remember that one.

Sure I do. :-p But as the cause is known now... Why not just set a password with a maximum length of 128 chars? -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}

Giancarlo Razzolini

4:33 a.m.

Em dezembro 2, 2016 10:25 Christian Hesse escreveu:

...

Giancarlo Razzolini on Tue, 2016/11/29 17:00:

Sure I do. :-p

But as the cause is known now... Why not just set a password with a maximum length of 128 chars?

Been doing that for a while now. In fact, Maxime, from PIA, told me they'd change their maximum password size to 128. I've been following the discussion on the OpenVPN list and it seems they didn't yet reached a conclusion. So, 2.4.0, will probably not have this fix yet (if they will do any fix). And I'll make time to improve our wiki regarding running OpenVPN entirely unprivileged. Cheers, Giancarlo Razzolini

Christian Hesse

4:50 a.m.

Giancarlo Razzolini on Fri, 2016/12/02 12:33:

...

Em dezembro 2, 2016 10:25 Christian Hesse escreveu:

...
Giancarlo Razzolini on Tue, 2016/11/29 17:00:

Sure I do. :-p

But as the cause is known now... Why not just set a password with a maximum length of 128 chars?

Been doing that for a while now. In fact, Maxime, from PIA, told me they'd change their maximum password size to 128. I've been following the discussion on the OpenVPN list and it seems they didn't yet reached a conclusion. So, 2.4.0, will probably not have this fix yet (if they will do any fix).

The task [0] is still open und unfixed. I doubt a patch for this will make it into final 2.4...

...

And I'll make time to improve our wiki regarding running OpenVPN entirely unprivileged.

Wondering if this is possible without hard coded interface names... You would have to use %i in openvpn-unprivileged@.service: ExecStartPre=-/usr/bin/openvpn --rmtun --dev %i ExecStartPre=/usr/bin/openvpn --mktun %i ... ExecStart=/usr/bin/openvpn --config %i.conf --dev %i ... However... You should base your work on the new upstream systemd units. [0] https://community.openvpn.net/openvpn/ticket/712 -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}

Giancarlo Razzolini

5:52 a.m.

Em dezembro 2, 2016 10:50 Christian Hesse escreveu:

...

The task [0] is still open und unfixed. I doubt a patch for this will make it into final 2.4...

Yeah. I reduced the password to 128 chars and moved on. Their internal discussion on how to approach this is pointless imho.

...

Wondering if this is possible without hard coded interface names... You would have to use %i in openvpn-unprivileged@.service:

ExecStartPre=-/usr/bin/openvpn --rmtun --dev %i ExecStartPre=/usr/bin/openvpn --mktun %i ... ExecStart=/usr/bin/openvpn --config %i.conf --dev %i ...

However... You should base your work on the new upstream systemd units.

Well, that would require calling the file with the same name as the interface being used, but it would definetely work. Since we now have a run dir, all that would be needed is this "unprivileged" systemd unit. I think the need for an unprivileged iproute could be easily addressed by the user itself, manually. Cheers, Giancarlo Razzolini

Christian Hesse

6:08 a.m.

Giancarlo Razzolini on Fri, 2016/12/02 13:52:

...

Em dezembro 2, 2016 10:50 Christian Hesse escreveu:

...
Wondering if this is possible without hard coded interface names... You would have to use %i in openvpn-unprivileged@.service:

ExecStartPre=-/usr/bin/openvpn --rmtun --dev %i ExecStartPre=/usr/bin/openvpn --mktun %i ... ExecStart=/usr/bin/openvpn --config %i.conf --dev %i ...

However... You should base your work on the new upstream systemd units.

Well, that would require calling the file with the same name as the interface being used, but it would definetely work. Since we now have a run dir, all that would be needed is this "unprivileged" systemd unit. I think the need for an unprivileged iproute could be easily addressed by the user itself, manually.

Well, you could provide a sudoers file, a wrapper with 'sudo /usr/bin/ip $@' and add '--iproute /path/to/wrapper' in your unit file. -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}

Giancarlo Razzolini

6:39 a.m.

Em dezembro 2, 2016 12:08 Christian Hesse escreveu:

...

Well, you could provide a sudoers file, a wrapper with 'sudo /usr/bin/ip $@' and add '--iproute /path/to/wrapper' in your unit file.

Sure. But I guess that the question we must ask is, do we want all this on our OpenVPN package? I know they are small additions, but wouldn't they be better on an optional dependency or something? If not, then we could add a /usr/bin/unpriv-ip, and a /etc/sudoers.d file giving openvpn user permission to run it. I just need to come up with a proper sudo rule giving permission just to do what OpenVPN needs to do and deny netns exec, for instance. Cheers, Giancarlo Razzolini.

Sébastien Luttringer

4 Dec 4 Dec

10:13 p.m.

On Fri, 2016-12-02 at 14:39 +0000, Giancarlo Razzolini wrote:

...

Em dezembro 2, 2016 12:08 Christian Hesse escreveu:

...
Well, you could provide a sudoers file, a wrapper with 'sudo /usr/bin/ip $@' and add '--iproute /path/to/wrapper' in your unit file.

Sure. But I guess that the question we must ask is, do we want all this on our OpenVPN package?

No. Cheers, -- Sébastien "Seblu" Luttringer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A

Christian Hesse

2 Dec 2 Dec

4:40 a.m.

Christian Hesse on Sat, 2016/11/26 13:38:

...

Hello everybody,

a new OpenVPN stable release is being prepared, namely version 2.4.0. Currently we have 2.4_beta2. I think about making changes to our package that require user intervention.

We have 2.4_rc1 as of today.

...

We shipped a systemd unit file before OpenVPN upstream had one. Upstream now has unit files, but two (for server and client) instead of just one. I did backport some security features for our unit, but refused to migrate to the upstream solution within the 2.3.x branch.

That could change with 2.4.0. Instead of openvpn@.service we would have openvpn-server@.service and openvpn-client@.service. Additionally the 'daemon' option is no longer allowed with the upstream units.

Some news about this... I prepared patched for proper systemd support which already have been committed to the upstream repository. So we have: * proper error handling (and service ordering) * option "daemon" is just ignored when started from systemd unit - so no more limitations here We will see the shiny new systemd units in our package.

...

Stumbled about another fact... We define PLUGIN_LIBDIR, that allows to use relative paths from that directory in configuration to call the plugins. This path is '/usr/lib/openvpn' - plugins are installed to '/usr/lib/openvpn/plugins', though. Any reason for that?

This will change... So extra 'plugins/' has to be removed from relative paths in configuration. I built packages for 2.4_rc1 to give a preview... Feel free to test! ;) http://pkgbuild.com/~eworm/openvpn/openvpn-2.4_rc1-1-i686.pkg.tar.xz http://pkgbuild.com/~eworm/openvpn/openvpn-2.4_rc1-1-x86_64.pkg.tar.xz The news post will look something like this: <snip> The upgrade to openvpn 2.4.0 makes changes that are incompatible with previous configurations. Take special care if you depend on VPN connectivity for remote access! Administrative interaction is required: * Configuration is expected in sub directories now. Move your files from `/etc/openvpn/` to `/etc/openvpn/server/` or `/etc/openvpn/client/`. * The plugin lookup path changed, remove extra `plugins/` from relative paths. * The systemd unit `openvpn@.service` was replaced with `openvpn-client@.service` and `openvpn-server@.service`. Restart and reenable accordingly. This does not affect the functionality of `networkmanager`, `connman` or `qopenvpn`. </snip> -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}

2693

Age (days ago)

2702

Last active (days ago)

List overview

Download

21 comments

5 participants

participants (5)

Bartłomiej Piotrowski
Christian Hesse
Florian Pritz
Giancarlo Razzolini
Sébastien Luttringer