openvpn-devel Mailing List for OpenVPN

Hi, Copying openvpn-devel: As this is related to openvpn best to have this discussion in the devel list, I suppose. (see also: https://github.com/OpenVPN/openvpn-gui/issues/168#issuecomment-305250704) On Wed, May 31, 2017 at 12:58 PM, Gert Doering <not...@gi...> wrote: > On Wed, May 31, 2017 at 09:43:21AM -0700, Selva Nair wrote: > > As I said, get openvpn to report route errors in the status and then we > can > > add a warning to the status popup, turn the icon red etc instead of the > > current misleading "successfully connected" behaviour. > > This is actually a discussion I was trying to have a long time ago > (a few years) - "why do we ignore route addition errors?". > > The IPv6 code doesn't (because I think that errors are errors, not > warnings...) and that was always some sort of weird asymmetry... > > I still don't know the reasoning here, but I suspect it's something along > "you push a route that is identical to the local subnet" (192.168.1.0/24, > for example, because the user happens to be in a bad NAT network) and > "all of a sudden it fails"... so this might need more discussion, and > also some code cleanups to gracefully handle situations where an error > is "tolerated". > That and some route addition errors like "route already exists" are often benign. So a fatal error is not appropriate. But, IIRC, openvpn_execve_check only allows printing of errors as FATAL or WARN. Currently we do not parse the log message flags (error vs warning etc.) in the Windows GUI, but that could be improved if openvpn can log route errors like access denied as such. In any case, the status reported to the management when connected with errors should be something other than "CONNECTED,SUCCESS" -- say "CONNECTED,ROUTE-FAILED" etc. so that UI can intimate the user. Selva 

> On 31/05/17 15:51, Simon Matter wrote: >>> Hi, >>> >>> On Wed, May 31, 2017 at 11:14:33AM +0200, David Sommerseth wrote: >>>> On 31/05/17 09:02, Gert Doering wrote: >>>>> Hi, >>>>> >>>>> On Wed, May 31, 2017 at 02:31:40AM +0200, David Sommerseth wrote: >>>>>> If we really do care for supporting 0.9.8, in release/2.4 - I can >>>> give >>>>>> this an ACK. Otherwise, I think it might be better to backport >>>>>> 039a89c331e9b7998d804 + 79ea67f77ca3afe91222f. >>>>> >>>>> You are the one that objects most violently if we break users' >>>> expectations >>>> >>>> Yes and no. In regards to end users, I am very careful. In regards >>>> to >>>> package maintainers, I am less weary as they won't distribute failing >>>> builds to end users. This change hits package building, not the end >>>> user. >>> >>> Well, this is a somewhat simplistic world view, with "package builders" >>> and "package installers". >>> >>> People are stuck on older enterprise distributions, for whatever >>> reasons, >>> but want a newer openvpn version - so they get the source bundle, and >>> compile. Which is a perfectly fine deployment model - and we should >>> not >>> break things in 2.4.3 that worked just fine in 2.4.2 for them (unless >>> there is a strong reason, like "we have a vulnerability here that we >>> cannot fix unless we abandon an older API"). >> >> I strongly support your view, Gert. I really hope we do not see such >> breakage in minor stable releases. > > Do you depend on building against OpenSSL 0.9.8? If so, which > OS/distribution do you use? Yes, I have a case with very customized CentOS 5 systems where we also backport security related patches. Of course the same could be done for openvpn but it's easier to just follow the current 2.4 stream. That's why my suggestion to keep all the compat hacks in 2.4.x and kick them out only in the main devel branch. I guess that's what most package maintainers expect to happen and it keep mailing lists quiet. Regards, Simon 

On 31/05/17 15:51, Simon Matter wrote: >> Hi, >> >> On Wed, May 31, 2017 at 11:14:33AM +0200, David Sommerseth wrote: >>> On 31/05/17 09:02, Gert Doering wrote: >>>> Hi, >>>> >>>> On Wed, May 31, 2017 at 02:31:40AM +0200, David Sommerseth wrote: >>>>> If we really do care for supporting 0.9.8, in release/2.4 - I can >>> give >>>>> this an ACK. Otherwise, I think it might be better to backport >>>>> 039a89c331e9b7998d804 + 79ea67f77ca3afe91222f. >>>> >>>> You are the one that objects most violently if we break users' >>> expectations >>> >>> Yes and no. In regards to end users, I am very careful. In regards to >>> package maintainers, I am less weary as they won't distribute failing >>> builds to end users. This change hits package building, not the end >>> user. >> >> Well, this is a somewhat simplistic world view, with "package builders" >> and "package installers". >> >> People are stuck on older enterprise distributions, for whatever reasons, >> but want a newer openvpn version - so they get the source bundle, and >> compile. Which is a perfectly fine deployment model - and we should not >> break things in 2.4.3 that worked just fine in 2.4.2 for them (unless >> there is a strong reason, like "we have a vulnerability here that we >> cannot fix unless we abandon an older API"). > > I strongly support your view, Gert. I really hope we do not see such > breakage in minor stable releases. Do you depend on building against OpenSSL 0.9.8? If so, which OS/distribution do you use? -- kind regards, David Sommerseth OpenVPN Technologies, Inc 

> Hi, > > On Wed, May 31, 2017 at 11:14:33AM +0200, David Sommerseth wrote: >> On 31/05/17 09:02, Gert Doering wrote: >> > Hi, >> > >> > On Wed, May 31, 2017 at 02:31:40AM +0200, David Sommerseth wrote: >> >> If we really do care for supporting 0.9.8, in release/2.4 - I can >> give >> >> this an ACK. Otherwise, I think it might be better to backport >> >> 039a89c331e9b7998d804 + 79ea67f77ca3afe91222f. >> > >> > You are the one that objects most violently if we break users' >> expectations >> >> Yes and no. In regards to end users, I am very careful. In regards to >> package maintainers, I am less weary as they won't distribute failing >> builds to end users. This change hits package building, not the end >> user. > > Well, this is a somewhat simplistic world view, with "package builders" > and "package installers". > > People are stuck on older enterprise distributions, for whatever reasons, > but want a newer openvpn version - so they get the source bundle, and > compile. Which is a perfectly fine deployment model - and we should not > break things in 2.4.3 that worked just fine in 2.4.2 for them (unless > there is a strong reason, like "we have a vulnerability here that we > cannot fix unless we abandon an older API"). I strongly support your view, Gert. I really hope we do not see such breakage in minor stable releases. Regards, Simon 

On 31-05-17 11:14, David Sommerseth wrote: > On 31/05/17 09:02, Gert Doering wrote: >> On Wed, May 31, 2017 at 02:31:40AM +0200, David Sommerseth wrote: >>> If we really do care for supporting 0.9.8, in release/2.4 - I can give >>> this an ACK. Otherwise, I think it might be better to backport >>> 039a89c331e9b7998d804 + 79ea67f77ca3afe91222f. >> >> You are the one that objects most violently if we break users' expectations > > Yes and no. In regards to end users, I am very careful. In regards to > package maintainers, I am less weary as they won't distribute failing > builds to end users. This change hits package building, not the end user. > > And when we have had the policy (at least on the Linux side) that the > oldest supported library and build dependencies are what the oldest > officially supported RHEL release carries, then moving to OpenSSL 1.0.1 > should not break anything. > > When also considering that any releases older than OpenSSL 1.0.2 is not > supported by OpenSSL upstream [1], and OpenSSL 1.0.1 is supported by at > least Red Hat in RHEL for the lifetime of RHEL ... Then ditching 0.9.8 > support makes even more sense. > > [1] <https://www.openssl.org/policies/releasestrat.html> > > If there are other OS/distros actively supporting, fixing and > backporting security fixes to 0.9.8, then I have no issues keeping 0.9.8 > support. But unless there are someone having this requirement, cleaning > up all the various OpenSSL hacks for unsupported version is fairly > sensible to me. Either backporting 039a89c331e9b7998d804 + 79ea67f77ca3afe91222f or applying this patch is fine by me. As I wrote a little while ago: On 19-02-17 16:09, Steffan Karger wrote: > The other big long-term-support distro, SLES, does still ship and > support 0.9.8 in SELS11 until 2019 (2022 for extended support), but can > be updated to 1.0.1. > > As far as I'm concerned, that is enough reason to only support OpenSSL > 1.0.1+ for OpenVPN 2.4 (and newer). I'll let you guys decide. -Steffan 

Hi, On Wed, May 31, 2017 at 11:14:33AM +0200, David Sommerseth wrote: > On 31/05/17 09:02, Gert Doering wrote: > > Hi, > > > > On Wed, May 31, 2017 at 02:31:40AM +0200, David Sommerseth wrote: > >> If we really do care for supporting 0.9.8, in release/2.4 - I can give > >> this an ACK. Otherwise, I think it might be better to backport > >> 039a89c331e9b7998d804 + 79ea67f77ca3afe91222f. > > > > You are the one that objects most violently if we break users' expectations > > Yes and no. In regards to end users, I am very careful. In regards to > package maintainers, I am less weary as they won't distribute failing > builds to end users. This change hits package building, not the end user. Well, this is a somewhat simplistic world view, with "package builders" and "package installers". People are stuck on older enterprise distributions, for whatever reasons, but want a newer openvpn version - so they get the source bundle, and compile. Which is a perfectly fine deployment model - and we should not break things in 2.4.3 that worked just fine in 2.4.2 for them (unless there is a strong reason, like "we have a vulnerability here that we cannot fix unless we abandon an older API"). gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany ge...@gr... fax: +49-89-35655025 ge...@ne... 

On 31/05/17 09:02, Gert Doering wrote: > Hi, > > On Wed, May 31, 2017 at 02:31:40AM +0200, David Sommerseth wrote: >> If we really do care for supporting 0.9.8, in release/2.4 - I can give >> this an ACK. Otherwise, I think it might be better to backport >> 039a89c331e9b7998d804 + 79ea67f77ca3afe91222f. > > You are the one that objects most violently if we break users' expectations Yes and no. In regards to end users, I am very careful. In regards to package maintainers, I am less weary as they won't distribute failing builds to end users. This change hits package building, not the end user. And when we have had the policy (at least on the Linux side) that the oldest supported library and build dependencies are what the oldest officially supported RHEL release carries, then moving to OpenSSL 1.0.1 should not break anything. When also considering that any releases older than OpenSSL 1.0.2 is not supported by OpenSSL upstream [1], and OpenSSL 1.0.1 is supported by at least Red Hat in RHEL for the lifetime of RHEL ... Then ditching 0.9.8 support makes even more sense. [1] <https://www.openssl.org/policies/releasestrat.html> If there are other OS/distros actively supporting, fixing and backporting security fixes to 0.9.8, then I have no issues keeping 0.9.8 support. But unless there are someone having this requirement, cleaning up all the various OpenSSL hacks for unsupported version is fairly sensible to me. -- kind regards, David Sommerseth OpenVPN Technologies, Inc 

Hi, On Wed, May 31, 2017 at 02:31:40AM +0200, David Sommerseth wrote: > If we really do care for supporting 0.9.8, in release/2.4 - I can give > this an ACK. Otherwise, I think it might be better to backport > 039a89c331e9b7998d804 + 79ea67f77ca3afe91222f. You are the one that objects most violently if we break users' expectations - and I think "changing library *requirements* right in the middle of a release train" is a good way to do that... even if all *supported by the maintainers* OS version have recent-enough OpenSSL libraries, I expect people to happily use 2.4.2 on "something", and if 2.4.3 stops compiling there, this is not a good thing to do. So I'd just fix the library order (= go with Steffan's patch) and not backport the larger changes. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany ge...@gr... fax: +49-89-35655025 ge...@ne... 

Am 31.05.2017 um 02:31 schrieb David Sommerseth: > > I do however vaguely remember someone mentioning some BSD distros still > being on 0.9.8 ... or was it some other OS? ... Anyhow, do we need to > care for them? This is release/2.4 we're talking about after all. The oldest OpenSSL version in use a supported FreeBSD version is FreeBSD 10.3's OpenSSL 1.0.1. I haven't looked at other BSDs. 

On 30/05/17 22:50, Steffan Karger wrote: > Instead of searching for both libssl and libcrypto, just search for > openssl as a whole (which depends on libssl and libcrypto). The previous > discovery order would result in "-lcrypto -lssl" link flags, while we > need "-lssl -lcrypto". > > Trac: #863 > > Signed-off-by: Steffan Karger <st...@ka...> > --- > This patch is for release/2.4 only, because this is already fixed in > master by commit 79ea67f77ca3afe91222f62e17df885a30409285. > > configure.ac | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/configure.ac b/configure.ac > index 2406ad8..854634a 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -859,7 +859,7 @@ if test "${enable_crypto}" = "yes" -a "${with_crypto_library}" = "openssl"; then >	# if the user did not explicitly specify flags, try to autodetect >	PKG_CHECK_MODULES( >	[OPENSSL], > -	[libcrypto >= 0.9.8, libssl >= 0.9.8], > +	[openssl >= 0.9.8], > [have_openssl="yes"], >	[have_openssl="no"] # Provide if-not-found to prevent erroring out >	) > I vaguely remember we discussed the OpenSSL versions. On the Linux side, we shouldn't need to worry about anything older than 1.0.1. I do however vaguely remember someone mentioning some BSD distros still being on 0.9.8 ... or was it some other OS? ... Anyhow, do we need to care for them? This is release/2.4 we're talking about after all. If we really do care for supporting 0.9.8, in release/2.4 - I can give this an ACK. Otherwise, I think it might be better to backport 039a89c331e9b7998d804 + 79ea67f77ca3afe91222f. -- kind regards, David Sommerseth OpenVPN Technologies, Inc 

Instead of searching for both libssl and libcrypto, just search for openssl as a whole (which depends on libssl and libcrypto). The previous discovery order would result in "-lcrypto -lssl" link flags, while we need "-lssl -lcrypto". Trac: #863 Signed-off-by: Steffan Karger <st...@ka...> --- This patch is for release/2.4 only, because this is already fixed in master by commit 79ea67f77ca3afe91222f62e17df885a30409285. configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 2406ad8..854634a 100644 --- a/configure.ac +++ b/configure.ac @@ -859,7 +859,7 @@ if test "${enable_crypto}" = "yes" -a "${with_crypto_library}" = "openssl"; then	# if the user did not explicitly specify flags, try to autodetect	PKG_CHECK_MODULES(	[OPENSSL], -	[libcrypto >= 0.9.8, libssl >= 0.9.8], +	[openssl >= 0.9.8], [have_openssl="yes"],	[have_openssl="no"] # Provide if-not-found to prevent erroring out	) -- 2.7.4 

Hi, On Mon, May 29, 2017 at 05:43:52PM +0200, David Sommerseth wrote: > > Maybe our configure should point this out more clearly, that is, if > > "--enable-systemd" is given and pkg-config cannot be found, complain > > about lack of *pkg-config*... > > Actually, pkcs11-helper and p11-kit checks also depends on pkg-config > ... the systemd pkg-config calls just happens to be run first to bail > out if it can't figure out the systemd details. It seems pkg-config > first called on pkcs11-helper, then openssl - both which considers > "failure" as non-critical. > > If it is only the openssl.pc missing on some *BSD distros, then I think > we can have pkg-config being a requirement which is checked for as early > as possible. Otherwise, we'll need to check for pkg-config if > pkcs11-helper, p11-kit or systemd is enabled. And for each new > dependency with pkg-config support. On the BSDs (and Solaris) we can't assume pkg-config support. So everything that is not linux specific has to fall back to "just try and see if linking works". > Btw ... I also see we could utilize pkg-config for lz4 too (at least > with lz4-1.7.3) This happens to have a pkg-config entry on FreeBSD, but it's called "liblz4.pc"... go figure :-) (And I did not check the other ones) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany ge...@gr... fax: +49-89-35655025 ge...@ne... 

On 29/05/17 16:50, Gert Doering wrote: > Hi, > > On Mon, May 29, 2017 at 02:01:14PM +0100, debbie10t wrote: >> FYI: >> pkg-config was only required for --enable-systemd >> Running './configure' only did not need pkg-config. >> I don't know if it is required for any other options. > > pkg-config is used for OpenSSL checking, but if it's not there, we fall > back to "just see if it works" - because the BSDs do not (all) have > pkg-config files for openssl. > > As systemd is linux specific (today), and linux has pkg-config, it needs > to be there... > > Maybe our configure should point this out more clearly, that is, if > "--enable-systemd" is given and pkg-config cannot be found, complain > about lack of *pkg-config*... Actually, pkcs11-helper and p11-kit checks also depends on pkg-config ... the systemd pkg-config calls just happens to be run first to bail out if it can't figure out the systemd details. It seems pkg-config first called on pkcs11-helper, then openssl - both which considers "failure" as non-critical. If it is only the openssl.pc missing on some *BSD distros, then I think we can have pkg-config being a requirement which is checked for as early as possible. Otherwise, we'll need to check for pkg-config if pkcs11-helper, p11-kit or systemd is enabled. And for each new dependency with pkg-config support. Btw ... I also see we could utilize pkg-config for lz4 too (at least with lz4-1.7.3) -- kind regards, David Sommerseth OpenVPN Technologies, Inc 

Hi, On Mon, May 29, 2017 at 02:01:14PM +0100, debbie10t wrote: > FYI: > pkg-config was only required for --enable-systemd > Running './configure' only did not need pkg-config. > I don't know if it is required for any other options. pkg-config is used for OpenSSL checking, but if it's not there, we fall back to "just see if it works" - because the BSDs do not (all) have pkg-config files for openssl. As systemd is linux specific (today), and linux has pkg-config, it needs to be there... Maybe our configure should point this out more clearly, that is, if "--enable-systemd" is given and pkg-config cannot be found, complain about lack of *pkg-config*... gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany ge...@gr... fax: +49-89-35655025 ge...@ne... 

 On 29/05/17 13:51, David Sommerseth wrote: > On 29/05/17 14:26, debbie10t wrote: >> >> It turns out pkg-config is not installed >> After installing all worked as expected. > > Great! > > I was too lazy to check ... but do we have some documentation on build > requirements anywhere? Should probably be checked into the main openvpn > git repository. And we should ensure pkg-config is listed there, at > least for Linux builds. Not sure if we depend on that on the various > *BSD distros. > FYI: pkg-config was only required for --enable-systemd Running './configure' only did not need pkg-config. I don't know if it is required for any other options. Thanks 

On 29/05/2017 15:51, David Sommerseth wrote: > On 29/05/17 14:26, debbie10t wrote: >> >> It turns out pkg-config is not installed >> After installing all worked as expected. > > Great! > > I was too lazy to check ... but do we have some documentation on build > requirements anywhere? Should probably be checked into the main openvpn > git repository. And we should ensure pkg-config is listed there, at > least for Linux builds. Not sure if we depend on that on the various > *BSD distros. > There is some documentation here: <https://community.openvpn.net/openvpn/wiki/TesterDocumentation> The documentation in README and INSTALL seems rather outdated, even though mostly correct. Those files should definitely be revised. -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock 

On 29/05/17 14:26, debbie10t wrote: > > It turns out pkg-config is not installed > After installing all worked as expected. Great! I was too lazy to check ... but do we have some documentation on build requirements anywhere? Should probably be checked into the main openvpn git repository. And we should ensure pkg-config is listed there, at least for Linux builds. Not sure if we depend on that on the various *BSD distros. -- kind regards, David Sommerseth OpenVPN Technologies, Inc 

 It turns out pkg-config is not installed After installing all worked as expected. Thanks :) 

Hi, On 29/05/2017 11:47, David Sommerseth wrote: > On 29/05/17 07:57, Samuli Seppänen wrote: >> On 29/05/2017 00:36, debbie10t wrote: > [...snip...] >>> >>> $ systemctl --version >>> systemd 229 >>> +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP >>> +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS >>> +KMOD -IDN > > This looks reasonable. > >>>>> apt-get install libsystemd-dev is done >>>> >>>> Can you locate libsystemd.pc or systemd.pc on your system? Are there >>>> other systemd related -dev packages available? >>>> >>>> >>> >>> still looking .. >>> >>> TYVM >>> >> >> Try this (I ran this on Debian 8): >> >> $ sudo -s >> $ find / -name "libsystemd.pc" >> /usr/lib/x86_64-linux-gnu/pkgconfig/libsystemd.pc >> $ find / -name "systemd.pc" >> /usr/share/pkgconfig/systemd.pc > > Samuli: Which systemd related -dev packages do you have installed? libsystemd-daemon-dev libsystemd-dev > > debbie10t: can you also try to run: > > $ pkg-config --libs --cflags --modversion libsystemd > > and > > $ pkg-config --libs --cflags --modversion systemd > > The latter one might not return much more than just "229". > > -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock 

On 29/05/17 07:57, Samuli Seppänen wrote: > On 29/05/2017 00:36, debbie10t wrote: [...snip...] >> >> $ systemctl --version >> systemd 229 >> +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP >> +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS >> +KMOD -IDN This looks reasonable. >>>> apt-get install libsystemd-dev is done >>> >>> Can you locate libsystemd.pc or systemd.pc on your system? Are there >>> other systemd related -dev packages available? >>> >>> >> >> still looking .. >> >> TYVM >> > > Try this (I ran this on Debian 8): > > $ sudo -s > $ find / -name "libsystemd.pc" > /usr/lib/x86_64-linux-gnu/pkgconfig/libsystemd.pc > $ find / -name "systemd.pc" > /usr/share/pkgconfig/systemd.pc Samuli: Which systemd related -dev packages do you have installed? debbie10t: can you also try to run: $ pkg-config --libs --cflags --modversion libsystemd and $ pkg-config --libs --cflags --modversion systemd The latter one might not return much more than just "229". -- kind regards, David Sommerseth OpenVPN Technologies, Inc 

Hi, Welcome to the mailing list. On 26 May 2017 at 19:21, Farhan Ul Haq <fa...@op...> wrote: > --- Well, that is a short commit message. Before we look into this patch, could you please supply a commit message that convinces why we would need this option? We already have a plethora of options, and don't want to add any more unless it is really necessary. The commit message isn't just to make us understand, but also to provide context for future developers who are searching the git logs for reasons why something in the code is the way it is. In general, I'd like to advise you to read this great blog post in detail before resubmitting: https://chris.beams.io/posts/git-commit/ Furthermore, just glancing at the code, I noticed: * this patch seems to be based on the release/2.3 branch, while patches should be based on the master branch. (And we only accept bugfixes in the release/2.3 branch, so this is very unlikely to be backported to release/2.3.) * this adds an options, but doesn't update the man page * this doesn't update Changes.rst Thanks, -Steffan 

On 29/05/2017 00:36, debbie10t wrote: > > > On 28/05/17 22:09, David Sommerseth wrote: >> On 28/05/17 22:47, debbie10t wrote: >>> Hi >>> >>> This is just a heads up ! >>> >>> I cannot build openvpn on ubuntu 16.04.2 LTS (fresh install) because >>> ./configure --enable-systemd fails to build with the following error: >>> >> [...snip...] >>> checking for libsystemd... no >>> checking for libsystemd... no >>> configure: error: in `/home/dik/openvpn/master': >>> configure: error: The pkg-config script could not be found or is too >>> old. Make sure it >>> is in your PATH or set the PKG_CONFIG environment variable to the full >>> path to pkg-config. >>> >> [...snip...] >>> >>> $ systemctl version >>> Unknown operation version. >> >> Can you try --version instead of just 'version'? > > oops .. > > $ systemctl --version > systemd 229 > +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP > +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS > +KMOD -IDN > > > sorry about that blunder > > >> >>> apt-get install libsystemd-dev is done >> >> Can you locate libsystemd.pc or systemd.pc on your system? Are there >> other systemd related -dev packages available? >> >> > > still looking .. > > TYVM > Try this (I ran this on Debian 8): $ sudo -s $ find / -name "libsystemd.pc" /usr/lib/x86_64-linux-gnu/pkgconfig/libsystemd.pc $ find / -name "systemd.pc" /usr/share/pkgconfig/systemd.pc -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock 

 On 28/05/17 22:09, David Sommerseth wrote: > On 28/05/17 22:47, debbie10t wrote: >> Hi >> >> This is just a heads up ! >> >> I cannot build openvpn on ubuntu 16.04.2 LTS (fresh install) because >> ./configure --enable-systemd fails to build with the following error: >> > [...snip...] >> checking for libsystemd... no >> checking for libsystemd... no >> configure: error: in `/home/dik/openvpn/master': >> configure: error: The pkg-config script could not be found or is too >> old. Make sure it >> is in your PATH or set the PKG_CONFIG environment variable to the full >> path to pkg-config. >> > [...snip...] >> >> $ systemctl version >> Unknown operation version. > > Can you try --version instead of just 'version'? oops .. $ systemctl --version systemd 229 +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN sorry about that blunder > >> apt-get install libsystemd-dev is done > > Can you locate libsystemd.pc or systemd.pc on your system? Are there > other systemd related -dev packages available? > > still looking .. TYVM 

On 28/05/17 22:47, debbie10t wrote: > Hi > > This is just a heads up ! > > I cannot build openvpn on ubuntu 16.04.2 LTS (fresh install) because > ./configure --enable-systemd fails to build with the following error: > [...snip...] > checking for libsystemd... no > checking for libsystemd... no > configure: error: in `/home/dik/openvpn/master': > configure: error: The pkg-config script could not be found or is too > old. Make sure it > is in your PATH or set the PKG_CONFIG environment variable to the full > path to pkg-config. > [...snip...] > > $ systemctl version > Unknown operation version. Can you try --version instead of just 'version'? > apt-get install libsystemd-dev is done Can you locate libsystemd.pc or systemd.pc on your system? Are there other systemd related -dev packages available? -- kind regards, David Sommerseth OpenVPN Technologies, Inc 

Hi This is just a heads up ! I cannot build openvpn on ubuntu 16.04.2 LTS (fresh install) because ./configure --enable-systemd fails to build with the following error: autoconf -ifv [done] ./configure --enable-system log <q> checking for RSA_meth_set0_app_data... no checking for lzo1x_1_15_compress in -llzo2... yes checking lzo/lzoutil.h usability... yes checking lzo/lzoutil.h presence... yes checking for lzo/lzoutil.h... yes checking lzo/lzo1x.h usability... yes checking lzo/lzo1x.h presence... yes checking for lzo/lzo1x.h... yes configure: checking for LZ4 Library and Header files... checking for LZ4_compress in -llz4... yes checking lz4.h usability... yes checking lz4.h presence... yes checking for lz4.h... yes checking for libsystemd... no checking for libsystemd... no configure: error: in `/home/dik/openvpn/master': configure: error: The pkg-config script could not be found or is too old. Make sure it is in your PATH or set the PKG_CONFIG environment variable to the full path to pkg-config. Alternatively, you may set the environment variables libsystemd_CFLAGS and libsystemd_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details. To get pkg-config, see <http://pkg-config.freedesktop.org/>. See `config.log' for more details </q> Not only but also .. $ systemctl version Unknown operation version. $ uname -a Linux ub64-tst 4.4.0-62-generic #83-Ubuntu SMP Wed Jan 18 14:10:15 UTC ./configure without --enable-systemd is fine apt-get install libsystemd-dev is done --