Re: [Openvpn-devel] [Openvpn-users] new openssl = new OpenVPN release ?

Gert Doering on Tue, 2020/04/21 20:59: > Hi, > > On Tue, Apr 21, 2020 at 08:37:35PM +0200, Gert Doering wrote: > > On Tue, Apr 21, 2020 at 02:15:43PM -0400, mike tancsa wrote: > > >     Will the sec issue with OpenSSL force a new release of OpenVPN ? > > > > > >

Re: [Openvpn-devel] OpenVPN 2.4.9 released

Samuli Seppänen on Mon, 2020/04/20 09:13: > On a related note: I think we should consider stopping the distribution > of the security list's public key from our webservers and just instruct > people to fetch the key from the keyservers and refresh it if they have > trouble. Key server operation

Re: [Openvpn-devel] OpenVPN 2.4.9 released

"Jonathan K. Bullard" on Fri, 2020/04/17 17:16: > IHi, > > On Fri, Apr 17, 2020 at 8:47 AM Samuli Seppänen wrote: > > > > The OpenVPN community project team is proud to release OpenVPN 2.4.9. It > > can be downloaded from here: > > > > > > I'm

Re: [Openvpn-devel] [PATCH 1/1] configure.ac: replace set with env

Tom Yan on Mon, 2020/01/06 08:48: > How about printenv (without grep)? The variables are not known in advance. This needs to match all variables starting with "enable_" and "with_". -- main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/*Best regards

[Openvpn-devel] [PATCH 1/1] configure.ac: replace set with env

From: Christian Hesse The shell builtin `set` produces different output for different shells: bash$ set | grep '^TERM=' TERM=xterm dash$ set | grep '^TERM=' TERM='xterm' This may break reproducible builds depending on what shell is used. Let's replace `set` with `env`, which is a real command

Re: [Openvpn-devel] [PATCH] Remove extra token after #endif

Lev Stipakov on Fri, 2018/11/09 11:59: > Commit ee80ce3d6f2ebc59068338757311e0488ae620fc wrapped > code in #ifdef/#endif and added extra token after #endif, > which produces compiler warning. > > This removes unneeded extra token. > > Signed-off-by: Lev Stipakov > --- > src/openvpn/init.c | 4

Re: [Openvpn-devel] [PATCH 2/2] systemd: extend CapabilityBoundingSet for learn-address

Christian Ehrhardt on Wed, 2018/08/29 16:27: > It seems a not too uncommon case that learn-address needs to recycle > dnsmasq - to do so it would need CAP_KILL. > > This was suggested on https://community.openvpn.net/openvpn/ticket/918 > > Signed-off-by: Christian Ehrhardt > --- >

Re: [Openvpn-devel] [PATCH 1/1] systemd: run openvpn with dedicated user

t 11:28:13AM +0200, Christian Hesse wrote: > > if ENABLE_SYSTEMD > > +if ENABLE_IPROUTE > > +SYSTEMD_USER=root > > +SYSTEMD_CAPS_OPTION=CapabilityBoundingSet > > +SYSTEMD_CAPS_VALUES=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_BIND_SERVICE > > CAP_NET_RAW CAP_S

Re: [Openvpn-devel] [RFC 0/4] add netlink support for Linux: update

Antonio Quartulli on Fri, 2018/04/06 15:43: > Two new files, namely networking_sitnl.c and networking_ip.c, provides > two implementations for this API: one uses the new sitnl code (netlink) > and one uses iproute2. This complicates the situation for my followup code: Running

[Openvpn-devel] [RFC 0/3] follow-up netlink support, systemd integration

This series is a follow-up to 'add netlink support for Linux' by Antonio Quartulli. It enhances integration with systemd and improves system security by running the openvpn process with a dedicated user. Christian Hesse (3): systemd: run openvpn with dedicated user systemd: do not downgrade

[Openvpn-devel] [RFC 2/3] systemd: do not downgrade UID/GID

From: Christian Hesse <m...@eworm.de> Now that systemd starts the process with dedicated user we do no longer want to downgrade privileges. Also remove CAP_SETGID and CAP_SETUID from granted privileges. Signed-off-by: Christian Hesse <m...@eworm.de> --- distro/systemd/openvpn-cli...

[Openvpn-devel] [RFC 3/3] systemd: create configuration directories from tmpfiles

From: Christian Hesse <m...@eworm.de> We have a dedicated user created by systemd-sysusers, so create configuration directories from systemd-tmpfiles for proper permissions. This mitigates a race condition at packaging/install time. Signed-off-by: Christian Hesse <m...@eworm.de>

Re: [Openvpn-devel] [PATCH 1/1] Update copyright notes

Selva Nair <selva.n...@gmail.com> on Mon, 2018/01/29 10:24: > Hi, > > On Mon, Jan 29, 2018 at 3:43 AM, Christian Hesse <l...@eworm.de> wrote: > > From: Christian Hesse <m...@eworm.de> > > > > Now that the first release in 2018 is imminent let's u

[Openvpn-devel] [PATCH 1/1] Update copyright notes

From: Christian Hesse <m...@eworm.de> Now that the first release in 2018 is imminent let's update the copyright notes. Signed-off-by: Christian Hesse <m...@eworm.de> --- COPYING | 2 +

Re: [Openvpn-devel] [PATCH] avoid useless assignment

David Sommerseth on Thu, 2017/08/24 20:16: > On 24/08/17 09:57, Antonio Quartulli wrote: > > My effort in writing the commit message has been quite poor. > > > > The assignment is useless because 'ret' is re-assigned a few lines later > > without ever being

Re: [Openvpn-devel] [PATCH] avoid useless assignment

David Sommerseth <open...@sf.lists.topphemmelig.net> on Thu, 2017/08/24 20:51: > On 24/08/17 20:40, Antonio Quartulli wrote: > > > > > > On 25/08/17 02:40, Christian Hesse wrote: > >> David Sommerseth <open...@sf.lists.topphemmelig.net> on Thu, 2017/0

Re: [Openvpn-devel] devel mailing list

Selva Nair on Sat, 2017/04/15 16:08: > I did not get this mail > > https://sourceforge.net/p/openvpn/mailman/message/35789733/ > > Something up with the list or is it only me? I did receive the mail. Possibly anything blocked the 7z attachment for you? --

Re: [Openvpn-devel] [PATCH v3 00/15] Add support for OpenSSL 1.1.x

Christian Hesse <l...@eworm.de> on Fri, 2017/02/24 13:13: > Christian Hesse <l...@eworm.de> on Thu, 2017/02/23 21:57: > > Built v3 against openssl 1.0.2k without issues, tests succeed and two > > instanced successfully established vpn connection (with server v

[Openvpn-devel] [PATCH 1/1] fix typo in notification message

From: Christian Hesse <m...@eworm.de> Signed-off-by: Christian Hesse <m...@eworm.de> --- src/openvpn/init.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/openvpn/init.c b/src/openvpn/init.c index ff1551e..7da0061 100644 --- a/src/openvpn/init.c +++ b/src/op

Re: [Openvpn-devel] [PATCH v3 00/15] Add support for OpenSSL 1.1.x

Christian Hesse <l...@eworm.de> on Thu, 2017/02/23 21:57: > Built v3 against openssl 1.0.2k without issues, tests succeed and two > instanced successfully established vpn connection (with server version > 2.3.12 and 2.4.0). Just tested a server instance with ancient client (versio

Re: [Openvpn-devel] [PATCH v3 00/15] Add support for OpenSSL 1.1.x

Emmanuel Deloget on Thu, 2017/02/23 15:35: > This is v3 of the remaining patches for the "Add support for OpenSSL > 1.1.x" series. This series is partial: only the modified patches are > sent to the ML -- the other have not changed. The stats are a bit off > so I don't include

Re: [Openvpn-devel] [RFC PATCH v1 09/15] OpenSSL: don't use direct access to the internal of X509_STORE_CTX

Steffan Karger on Tue, 2017/02/21 22:30: > ACK. Changes look good and tested against OpenSSL 0.9.8, 1.0.0, 1.0.1 > and 1.0.2. You answered to a patch in the middle of a series. Does this ACK apply to the complete series or just this patch? -- main(a){char*c=/*Schoene

Re: [Openvpn-devel] [RFC PATCH v1 00/15] Add support for OpenSSL 1.1.x

Christian Hesse <l...@eworm.de> on Mon, 2017/02/20 16:02: > Emmanuel Deloget <log...@free.fr> on Mon, 2017/02/20 15:52: > > On Mon, Feb 20, 2017 at 2:53 PM, Emmanuel Deloget <log...@free.fr> > > wrote: > > > Hi again, > > > > > > On Mo

Re: [Openvpn-devel] [RFC PATCH v1 00/15] Add support for OpenSSL 1.1.x

i Christian, > >> > >> On Mon, Feb 20, 2017 at 1:29 PM, Christian Hesse <l...@eworm.de> wrote: > >>> That matches my findings. Built against openssl 1.1.0e (Arch Linux > >>> package openssl 1.1.0.e-1 [0]) the build itself succeeds, but 'make

Re: [Openvpn-devel] [RFC PATCH v1 00/15] Add support for OpenSSL 1.1.x

Emmanuel Deloget on Mon, 2017/02/20 12:45: > Hello, > > On Sun, Feb 19, 2017 at 6:49 PM, Gert Doering wrote: > > Hi, > > > > On Sun, Feb 19, 2017 at 01:03:45PM +0100, Steffan Karger wrote: > >> Thank you very much. You approach looks good to me, and quite

Re: [Openvpn-devel] build against openssl 1.1.0

David Sommerseth on Sat, 2017/02/18 02:52: > On 17/02/17 22:59, Emmanuel Deloget wrote: > > I'm not targetting 2.4 -- my work is done on the current master. Adding > > hundreds of lines to the current 2.4 for the purpose of supporting a > > library which is not

Re: [Openvpn-devel] build against openssl 1.1.0

On Mon, 13 Feb 2017 20:33:38 +0100 Gert Doering <g...@greenie.muc.de> wrote: > On Mon, Feb 13, 2017 at 08:17:58PM +0100, Christian Hesse wrote: > > Arch Linux is about to upgrade openssl to version 1.1.0. OpenVPN > > does not compile against this version. Did anybody start th

[Openvpn-devel] build against openssl 1.1.0

Hello everybody, Arch Linux is about to upgrade openssl to version 1.1.0. OpenVPN does not compile against this version. Did anybody start the work to support latest openssl versions? -- main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/*Best regards

[Openvpn-devel] [PATCH 1/1] remove GNUism and fix out-of-tree build

From: Christian Hesse <m...@eworm.de> The plugin path handling cleanup (4590c383) introduced GNUism and broke out-of-tree builds. Revert back to let configure generate the header file. Instead let make add an extra CFLAG that defines PLUGIN_LIBDIR. Signed-off-by: Christian Hesse <m...

[Openvpn-devel] [PATCH v5 1/1] Clean up plugin path handling

From: Christian Hesse <m...@eworm.de> Drop --with-plugindir, instead use an environment variable PLUGINDIR to specify the plugin directory. This puts a define into include/openvpn-plugin.h.in which has the plugin directory. The configure script does not know about the final plugin path. T

[Openvpn-devel] [PATCH v4 1/1] Clean up plugin path handling

From: Christian Hesse <m...@eworm.de> Drop --with-plugindir, instead use an environment variable PLUGINDIR to specify the plugin directory. This makes src/openvpn/plugin.h a template (moved the file to src/openvpn/plugin.h.in). The real header file is generated on the fly, including a

Re: [Openvpn-devel] [PATCH v3 1/1] Clean up plugin path handling

David Sommerseth <open...@sf.lists.topphemmelig.net> on Wed, 2017/01/25 18:06: > On 25/01/17 17:04, Christian Hesse wrote: > > From: Christian Hesse <m...@eworm.de> > > > > Drop --with-plugindir, instead use an environment variable PLUGINDIR &g

[Openvpn-devel] [PATCH v3 1/1] Clean up plugin path handling

From: Christian Hesse <m...@eworm.de> Drop --with-plugindir, instead use an environment variable PLUGINDIR to specify the plugin directory. This generates a header file src/openvpn/plugindir.h which contains a define file the plugindir. v2: The configure script can not evaluate the

[Openvpn-devel] [PATCH 1/2] use automake tools to install systemd files

From: Christian Hesse <m...@eworm.de> If systemd is enabled we install unit files to $libdir/systemd/system (or the path specified by SYSTEMD_UNIT_DIR). The unit files are generated on the fly with matching $sbindir. Signed-off-by: Christian Hesse <m...@eworm.de> ---

[Openvpn-devel] [PATCH 2/2] do not race on RuntimeDirectory

From: Christian Hesse <m...@eworm.de> Different unit instances create and destroy the same RuntimeDirectory. This leads to running instances where the status file (and possibly more runtime data) is no longer accessible. So do not handle this in unit files but provide a tmpfiles.d configu

Re: [Openvpn-devel] [PATCH 2/2] do not race on RuntimeDirectory

David Sommerseth <open...@sf.lists.topphemmelig.net> on Fri, 2017/01/20 21:55: > On 27/12/16 23:15, Christian Hesse wrote: > > From: Christian Hesse <m...@eworm.de> > > > > Different unit instances create and destroy the same RuntimeDirectory. > > This lead

Re: [Openvpn-devel] [PATCH 1/2] use automake tools to install systemd files

David Sommerseth <open...@sf.lists.topphemmelig.net> on Fri, 2017/01/20 21:39: > On 27/12/16 23:15, Christian Hesse wrote: > > From: Christian Hesse <m...@eworm.de> > > > > If systemd is enabled we install unit files to $libdir/systemd/system > > (or

[Openvpn-devel] [PATCH v2 2/2] fix timeout in non-TLS mode with systemd

From: Christian Hesse <m...@eworm.de> In non-TLS configuration we wait for the remote peer to connect before issuing "Initialization Sequence Completed". So prevent to time out by telling systemd service manager we are ready for now. Status will be "Non-TLS mode, ready for

[Openvpn-devel] [PATCH 1/2] move systemd specific code to platform.c

From: Christian Hesse <m...@eworm.de> We have voices that do not want to "litter ENABLE_SYSTEMD all over the code". So move the systemd specific bits to platform_notify() in platform.c. Signed-off-by: Christian Hesse <m...@eworm.de> --- src/openvpn/init.c | 23 +-

Re: [Openvpn-devel] [PATCH 1/1] fix timeout in non-TLS mode with systemd

Gert Doering <g...@greenie.muc.de> on Wed, 2016/12/28 19:57: > Hi, > > On Wed, Dec 28, 2016 at 02:07:21PM +0100, Christian Hesse wrote: > > @@ -73,6 +77,21 @@ tunnel_point_to_point(struct context *c) > > return; > > } > > > >

[Openvpn-devel] [PATCH 1/1] fix timeout in non-TLS mode with systemd

From: Christian Hesse <m...@eworm.de> In non-TLS configuration we wait for the remote peer to connect before issuing "Initialization Sequence Completed". So prevent to time out by telling systemd service manager we are ready for now. Status will be "Non-TLS mode, ready for

[Openvpn-devel] [PATCH 1/1] man: fix formatting for alternative option

From: Christian Hesse <m...@eworm.de> This looked like... --server-poll-timeout n --connect-timeout n when connecting to [...] ... and this patch changes this to... --server-poll-timeout n, --connect-timeout n When connecting to [...] ... preserving c

[Openvpn-devel] [PATCH v2 1/1] Clean up plugin path handling

From: Christian Hesse <m...@eworm.de> Drop --with-plugindir, instead use an environment variable PLUGINDIR to specify the plugin directory. This generates a header file src/openvpn/plugindir.h which contains a define for the plugindir. v2: The configure script can not evaluate the final $

[Openvpn-devel] [PATCH v2 1/1] add more security feature for systemd units

From: Christian Hesse <m...@eworm.de> ProtectSystem=true mounts the /usr and /boot directories read-only. ProtectHome=true makes the directories /home, /root and /run/user inaccessible and empty for the process. See systemd.exec(5) [0] for details. v2: Replace ProtectSystem=

[Openvpn-devel] [PATCH 2/2] do not race on RuntimeDirectory

From: Christian Hesse <m...@eworm.de> Different unit instances create and destroy the same RuntimeDirectory. This leads to running instances where the status file (and possibly more runtime data) is no longer accessible. So do not handle this in unit files but provide a tmpfiles.d configu

[Openvpn-devel] [PATCH 1/2] use automake tools to install systemd files

From: Christian Hesse <m...@eworm.de> If systemd is enabled we install unit files to $libdir/systemd/system (or the path specified by SYSTEMD_UNIT_DIR). The unit files are generated on the fly with matching $sbindir. Signed-off-by: Christian Hesse <m...@eworm.de> ---

Re: [Openvpn-devel] [PATCH 1/1] do not race on RuntimeDirectory

David Sommerseth <open...@sf.lists.topphemmelig.net> on Mon, 2016/12/26 17:45: > On 26/12/16 17:12, Christian Hesse wrote: > > debbie10t <debbie...@gmail.com> on Sat, 2016/12/24 11:10: > >> On 16/12/16 22:00, Christian Hesse wrote: > >>

Re: [Openvpn-devel] [PATCH 1/1] do not race on RuntimeDirectory

debbie10t <debbie...@gmail.com> on Sat, 2016/12/24 11:10: > On 16/12/16 22:00, Christian Hesse wrote: > > From: Christian Hesse <m...@eworm.de> > > > > Different unit instances create and destroy the same RuntimeDirectory. > > This leads to running instan

Re: [Openvpn-devel] [PATCH release/2.4] Update copyrights

David Sommerseth on Wed, 2016/12/21 21:00: > Signed-off-by: David Sommerseth As we will (hopefully) see a release in 2016... Does it make sense to update to 2017? -- main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"

Re: [Openvpn-devel] [PATCH 1/1] do not race on RuntimeDirectory

debbie10t <debbie...@gmail.com> on Tue, 2016/12/20 00:32: > On 16/12/16 15:57, Christian Hesse wrote: > > From: Christian Hesse <m...@eworm.de> > > > > Different unit instances create and destroy the same RuntimeDirectory. > > This leads to running instan

[Openvpn-devel] [PATCH 1/1] do not race on RuntimeDirectory

From: Christian Hesse <m...@eworm.de> Different unit instances create and destroy the same RuntimeDirectory. This leads to running instances where the status file (and possibly more runtime data) is no longer accessible. So do not handle this in unit files but provide a tmpfiles.d configu

Re: [Openvpn-devel] [PATCH 1/1] do not race on RuntimeDirectory

David Sommerseth <open...@sf.lists.topphemmelig.net> on Fri, 2016/12/16 22:15: > On 16/12/16 20:09, Christian Hesse wrote: > > David Sommerseth <open...@sf.lists.topphemmelig.net> on Fri, 2016/12/16 > > 19:14: > >> On 16/12/16 16:57, Christian Hesse wro

Re: [Openvpn-devel] [PATCH 1/1] do not race on RuntimeDirectory

David Sommerseth <open...@sf.lists.topphemmelig.net> on Fri, 2016/12/16 19:14: > On 16/12/16 16:57, Christian Hesse wrote: > > From: Christian Hesse <m...@eworm.de> > > > > Different unit instances create and destroy the same RuntimeDirectory. > > This lead

[Openvpn-devel] [PATCH 1/1] do not race on RuntimeDirectory

From: Christian Hesse <m...@eworm.de> Different unit instances create and destroy the same RuntimeDirectory. This leads to running instances where the status file (and possibly more runtime data) is no longer accessible. So create a RuntimeDirectory per instance. Signed-off-by: Christian

[Openvpn-devel] [PATCH 1/1] replace deprecated LZ4 function

From: Christian Hesse <m...@eworm.de> The LZ4 function LZ4_compress_limitedOutput() is deprecated, compiler gives warning: warning: ‘LZ4_compress_limitedOutput’ is deprecated: use LZ4_compress_default() instead The new function LZ4_compress_default() appeared in r129 (1.7.0), so r

[Openvpn-devel] [PATCH 1/1] replace deprecated LZ4 function

From: Christian Hesse <m...@eworm.de> The LZ4 function LZ4_compress_limitedOutput() is deprecated, compiler gives warning: warning: ‘LZ4_compress_limitedOutput’ is deprecated: use LZ4_compress_default() instead So replace the function. Signed-off-by: Christian Hesse <m...@eworm.de&

Re: [Openvpn-devel] [PATCH 1/1] bind mount systemd notification socket into chroot

David Sommerseth <open...@sf.lists.topphemmelig.net> on Sat, 2016/12/10 01:03: > On 10/12/16 00:19, Christian Hesse wrote: > > From: Christian Hesse <m...@eworm.de> > > > > sd_notify() uses a socket to communicate with systemd. Communication > > fail

Re: [Openvpn-devel] [PATCH 1/1] add more security features for systemd units

SviMik on Sat, 2016/12/10 06:06: > > You can break this with something like: > > > > status /etc/openvpn/client/status.log > > > > in your configuration. Writing a status file > > to /run/openvpn-{client,server}/status.log works, though. So the default > > setups should be fine.

Re: [Openvpn-devel] [PATCH 1/1] Clean up plugin path handling

David Sommerseth <open...@sf.lists.topphemmelig.net> on Fri, 2016/12/09 23:40: > On 09/12/16 22:54, Christian Hesse wrote: > > David Sommerseth <open...@sf.lists.topphemmelig.net> on Fri, 2016/12/09 > > 22:37: > >> On 29/11/16 12:07, Christian Hesse wro

[Openvpn-devel] [PATCH 1/1] bind mount systemd notification socket into chroot

From: Christian Hesse <m...@eworm.de> sd_notify() uses a socket to communicate with systemd. Communication fails if the socket is not available within the chroot. So bind mount the socket into the chroot when startet from systemd. Unsharing namespace and mounting requires extra capa

Re: [Openvpn-devel] [PATCH 1/1] Clean up plugin path handling

David Sommerseth <open...@sf.lists.topphemmelig.net> on Fri, 2016/12/09 22:37: > On 29/11/16 12:07, Christian Hesse wrote: > > From: Christian Hesse <m...@eworm.de> > > > > Drop --with-plugindir, instead use an environment variable PLUGINDIR &g

Re: [Openvpn-devel] [PATCH 1/1] add more security features for systemd units

David Sommerseth <open...@sf.lists.topphemmelig.net> on Fri, 2016/12/09 20:42: > On 09/12/16 19:13, Christian Hesse wrote: > > From: Christian Hesse <m...@eworm.de> > > > > ProtectSystem=strict mounts the entire file system hierarchy read-only, > > excep

[Openvpn-devel] [PATCH 1/1] add more security features for systemd units

From: Christian Hesse <m...@eworm.de> ProtectSystem=strict mounts the entire file system hierarchy read-only, except for the API file system subtrees /dev, /proc and /sys (which can be protected using PrivateDevices=, ProtectKernelTunables=, ProtectControlGroups=). ProtectHome=true

Re: [Openvpn-devel] [PATCH] systemd: Intermediate --chroot fix with the new sd_notify() implementation

Christian Hesse <l...@eworm.de> on Fri, 2016/12/09 18:37: > David Sommerseth <dav...@openvpn.net> on Wed, 2016/12/07 03:51: > > Commit c5931897ae8d663e7e introduced support for talking directly > > to the systemd service manager about the situation for the OpenVPN >

Re: [Openvpn-devel] [PATCH] systemd: Intermediate --chroot fix with the new sd_notify() implementation

David Sommerseth on Wed, 2016/12/07 03:51: > Commit c5931897ae8d663e7e introduced support for talking directly > to the systemd service manager about the situation for the OpenVPN > tunnel. This approach makes a lot of sense and is mostly the proper > way to do it. But it was

[Openvpn-devel] [PATCH v3 1/2] Use systemd service manager notification

From: Christian Hesse <m...@eworm.de> Notify systemd service manager when our initialization sequence completed. This helps ordering services as dependencies can rely on vpn being available. v2: Add curly brackets (and indention) to block the else-part, msg() call was non-conditional

[Openvpn-devel] [PATCH v2 2/2] Refuse to daemonize when running from systemd

From: Christian Hesse <m...@eworm.de> We start with systemd Type=notify, so refuse to daemonize. This does not affect starting openvpn from script or command line. v2: Update commit message about script and command line. Signed-off-by: Christian Hesse <m...@eworm.de> --- distro/sys

[Openvpn-devel] [PATCH 1/1] update year in copyright for README

From: Christian Hesse <m...@eworm.de> This line has not been touched in a long time... Let's update the copyright with recent year for README. Signed-off-by: Christian Hesse <m...@eworm.de> --- README | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README b/

[Openvpn-devel] [PATCH v2 2/2] Refuse to daemonize when running from systemd

From: Christian Hesse <m...@eworm.de> We start with systemd Type=notify, so refuse to daemonize. This does not affect starting openvpn from script or command line. Signed-off-by: Christian Hesse <m...@eworm.de> --- distro/systemd/openvpn-client@.service | 1 - distro/systemd/op

[Openvpn-devel] [PATCH v2 1/2] Use systemd service manager notification

From: Christian Hesse <m...@eworm.de> Notify systemd service manager when our initialization sequence completed. This helps ordering services as dependencies can rely on vpn being available. Signed-off-by: Christian Hesse <m...@eworm.de> --- distro/systemd/openvpn-client@.service |

Re: [Openvpn-devel] [PATCH 1/1] Use systemd service manager notification

Christian Hesse <l...@eworm.de> on Wed, 2016/11/30 09:12: > Ok, lets go into detail. We can use three different settings: Type=simple, > Type=forking and Type=notify. > > * We used Type=forking for a long time. That is fine: systemd reports > success when the process

Re: [Openvpn-devel] [PATCH 1/1] Refuse to daemonize when running from systemd

David Sommerseth <open...@sf.lists.topphemmelig.net> on Wed, 2016/11/30 12:52: > On 30/11/16 09:59, Christian Hesse wrote: > > From: Christian Hesse <m...@eworm.de> > > > > We start with systemd Type=notify, so refuse to daemonize. > > > >

Re: [Openvpn-devel] [PATCH 1/1] Refuse to daemonize when running from systemd

Steffan Karger <steffan.kar...@fox-it.com> on Wed, 2016/11/30 10:06: > Hi, > > On 30-11-16 09:59, Christian Hesse wrote: > > --- a/src/openvpn/init.c > > +++ b/src/openvpn/init.c > > @@ -926,6 +926,13 @@ bool > > possibly_become_daemon (const struct o

[Openvpn-devel] [PATCH 1/1] Refuse to daemonize when running from systemd

From: Christian Hesse <m...@eworm.de> We start with systemd Type=notify, so refuse to daemonize. Signed-off-by: Christian Hesse <m...@eworm.de> --- distro/systemd/openvpn-client@.service | 1 - distro/systemd/openvpn-server@.service | 1 - src/openvpn/init.c |

Re: [Openvpn-devel] [PATCH 1/1] Use systemd service manager notification

2016/11/30 02:45: > On 29/11/16 16:27, Christian Hesse wrote: > > From: Christian Hesse <m...@eworm.de> > > > > Notify systemd service manager when our initialization sequence > > completed. This helps ordering services as dependencies can rely on vpn > &

Re: [Openvpn-devel] [PATCH] reload CRL only if file was modified

Christian Hesse <l...@eworm.de> on Tue, 2016/11/29 20:16: > Oops, missed that in my logs (and did not find the code)... You are right, > cache is cleared. > > Either of both is just fine and it works as-is. So ignore my patch. Oops again... Looks like I answered a wrong m

Re: [Openvpn-devel] [PATCH] reload CRL only if file was modified

Steffan Karger on Tue, 2016/11/29 17:43: > Hi, > > Thanks for following up. I did some stare-at-code and trivial tests. > Will test more thoroughly tonight (hopefully on Windows too), but have a > lot of faith that those will succeed. I have some comments from

[Openvpn-devel] [PATCH 1/1] Use systemd service manager notification

From: Christian Hesse <m...@eworm.de> Notify systemd service manager when our initialization sequence completed. This helps ordering services as dependencies can rely on vpn being available. Signed-off-by: Christian Hesse <m...@eworm.de> --- distro/systemd/openvpn-client@.service |

Re: [Openvpn-devel] [PATCH 1/1] Clean up plugin path handling

Christian Hesse <l...@eworm.de> on Tue, 2016/11/29 12:07: > From: Christian Hesse <m...@eworm.de> > > Drop --with-plugindir, instead use an environment variable PLUGINDIR > to specify the plugin directory. > > This always defines PLUGIN_LIBDIR and enables plugi

[Openvpn-devel] [PATCH 1/1] Clean up plugin path handling

From: Christian Hesse <m...@eworm.de> Drop --with-plugindir, instead use an environment variable PLUGINDIR to specify the plugin directory. This always defines PLUGIN_LIBDIR and enables plugin search path. Signed-off-by: Christian Hesse <m...@eworm.de> --- configure.ac

Re: [Openvpn-devel] [PATCH 2/2] allow to enable plugin lookup with configure argument

David Sommerseth <open...@sf.lists.topphemmelig.net> on Tue, 2016/11/29 00:47: > On 28/11/16 17:16, Christian Hesse wrote: > > From: Christian Hesse <m...@eworm.de> > > > > For plugin lookup (give relative path to plugin directory in > > configuration)

[Openvpn-devel] [PATCH 1/1] update year in copyright message

From: Christian Hesse <m...@eworm.de> This line has not been touched in a long time... Let's update the copyright message with recent year. Signed-off-by: Christian Hesse <m...@eworm.de> --- src/openvpn/options.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a

[Openvpn-devel] [PATCH 1/2] show correct default for plugin dir in configure help

From: Christian Hesse <m...@eworm.de> Signed-off-by: Christian Hesse <m...@eworm.de> --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index f4073d0..d0fe889 100644 --- a/configure.ac +++ b/configure.ac @@ -

[Openvpn-devel] [PATCH 2/2] allow to enable plugin lookup with configure argument

From: Christian Hesse <m...@eworm.de> For plugin lookup (give relative path to plugin directory in configuration) we had to configure with something like this: CFLAGS="$CFLAGS -DPLUGIN_LIBDIR=\\\"/usr/lib/openvpn/plugins\\\"" ./configure This allows to pass --enable-

[Openvpn-devel] fix build with automake 1.13(.1)

Hello everybody, AM_CONFIG_HEADER has been deprecated for some time, finally it is removed on automake 1.13. The attached patch replaces it with AC_CONFIG_HEADERS and fixes build process with latest automake. Please apply. -- main(a){char*c=/*Schoene Gruesse