autotools: Add support for extracting version information from pkg-config modules

From: David Sommerseth <[email protected]...>

---
 m4/pkg.m4 | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

index 9a71878..f82496b 100644
@@ -107,16 +107,18 @@ AC_DEFUN([PKG_CHECK_MODULES],
 [AC_REQUIRE([PKG_PROG_PKG_CONFIG])dnl
 AC_ARG_VAR([$1][_CFLAGS], [C compiler flags for $1, overriding pkg-config])dnl
 AC_ARG_VAR([$1][_LIBS], [linker flags for $1, overriding pkg-config])dnl
+AC_ARG_VAR([$1][_MODVERSION], [module version])dnl
 
 pkg_failed=no
 AC_MSG_CHECKING([for $1])
 
 _PKG_CONFIG([$1][_CFLAGS], [cflags], [$2])
 _PKG_CONFIG([$1][_LIBS], [libs], [$2])
+_PKG_CONFIG([$1][_MODVERSION], [modversion], [$2])
 
 m4_define([_PKG_TEXT], [Alternatively, you may set the environment variables $1[]_CFLAGS
-and $1[]_LIBS to avoid the need to call pkg-config.
-See the pkg-config man page for more details.])
+and $1[]_LIBS to avoid the need to call pkg-config.  The $1[]_MODVERSION provides version
+information.  See the pkg-config man page for more details.])
 
 if test $pkg_failed = yes; then
    	AC_MSG_RESULT([no])

@@ -153,6 +155,7 @@ To get pkg-config, see <http://pkg-config.freedesktop.org/>.])[]dnl
 else
 	$1[]_CFLAGS=$pkg_cv_[]$1[]_CFLAGS
 	$1[]_LIBS=$pkg_cv_[]$1[]_LIBS
+	$1[]_MODVERSION=$pkg_cv_[]$1[]_MODVERSION
         AC_MSG_RESULT([yes])
 	$3
 fi[]dnl

1.8.3.1

From: David Sommerseth <[email protected]...>

In systemd after version 216, systemd-ask-password will support --echo which will avoid masking the user input. As OpenVPN uses this mechanism collecting usernames when systemd is available, this will avoid the input of usernames to be masked.

This patch also adds the --icon argument, which is aimed at graphical inputs. For example when OpenVPN is started at system boot-time using a graphical boot interface such as Plymouth.

---
 configure.ac          | 1 +
 src/openvpn/console.c | 8 ++++++++
 2 files changed, 9 insertions(+)

index 608ab6d..09f32d4 100644
@@ -1017,6 +1017,7 @@ if test "$enable_systemd" = "yes" ; then
     AC_CHECK_FUNCS([sd_booted], [], [AC_MSG_ERROR([systemd library is missing sd_booted()])])
     OPTIONAL_SYSTEMD_LIBS="${libsystemd_LIBS}"
     AC_DEFINE(ENABLE_SYSTEMD, 1, [Enable systemd integration])
+    AC_DEFINE_UNQUOTED(SYSTEMD_VERSION, [`echo ${libsystemd_MODVERSION}`], [systemd version installed])
     LIBS="${saved_LIBS}"
 fi
 

index d66d408..5d4d878 100644
@@ -167,6 +167,14 @@ get_console_input_systemd (const char *prompt, const bool echo, char *input, con
 
   argv_init (&argv);
   argv_printf (&argv, SYSTEMD_ASK_PASSWORD_PATH);
+
+#if SYSTEMD_VERSION > 216
+  if( echo )
+    {
+      argv_printf_cat(&argv, "--echo");
+    }
+#endif
+  argv_printf_cat (&argv, "--icon=network-wired");
   argv_printf_cat (&argv, "%s", prompt);
 
   if ((std_out = openvpn_popen (&argv, NULL)) < 0) {

1.8.3.1

ACK. Enables systemd features on systemd systems, and looks like a no-op on non-systemd systems.

http://cecinestpasunefromage.wordpress.com/
------------------------------------------------
in your fear, seek only peace
in your fear, seek only love

-d. bowie

Hi,

[..]

Now this is getting interesting. I had a LONG discussion with David on IRC today, as I do not like where this is going - it's very very specific code (not only "linux specific" but "linux with systemd"), and the more I think about the less I'm convinced that we really want to have this inside OpenVPN, depend on particular versions of systemd in our source (yet another #ifdef that will turn into dead code in a few years), or link against a systemd library.

OTOH, having a *generic* mechanism to run an external "askpass" mechanism
- which could then be something x11-ssh-askpass, for example, on systems that are not Linux or have no systemd, is something I'd find generically useful. On systemd systems, this would then point to systemd, of course.

So this might be "./configure --enable-ask-pass=$my_program", which could then be /usr/sbin/systemd-askpass, or something private to OpenVPN which would check if systemd is running, and if yes, call systemd-askpass and if not, call "whatever makes sense on that particular environment" (if $DISPLAY, call ssh-askpass, otherwise, not).

Now, the really interesting thing about this is that we have an ACK for a patch which is not without religion around it - from someone who has never sent an ACK or a patch before. So, do I take any ACK, no matter who sent it? Do we require ACKs to come from people that have actual experience with the code, and are willing to work on the code when these bits need maintenance in the future? "This is the material where project forks are made from"...

So fully independent from the patch at hand we have some discussion to do - and we might want to postpone this particular topic and patchset to the face to face meeting, as things tend to get out of hand when discussed purely by mail / IRC.

gert

USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             [email protected]...
fax: +49-89-35655025                        [email protected]...

*sigh* You asked me in that discussion to find someone else to review the patches. Which I did. Jon is the OpenVPN maintainer for the Fedora packages, and I have had several off-list discussions with him on other matters, and trust his judgement fully. Which is also why I asked him to do the review.

Now lets call this what it really is: A typical "I don't like systemd" quarrel, which I honestly do not find much fruitful at all. But now the discussion has moved out of the systemd/sysv-init groups and into the application areas. And I find it interesting that this critic comes from you Gert, who, as far as I know, have had _no_ hands-on experience with systemd.

First of all, I will claim that systemd will be one of the more important system management solutions for Linux distributions in many years. Like it or not. And we cannot ignore that. Also consider that the major enterprise Linux distributions has implemented systemd, all the popular user/hacker distros likewise. Such as Debian, Ubuntu, openSuSE, Fedora, Arch, Mageia (former Mandrake, iirc), etc, etc. Even Gentoo *enforces* systemd if you want GNOME 3, otherwise it's an alternative. (Wikipedia has a nice overview on the systemd page [1])

[1] <http://en.wikipedia.org/wiki/Systemd#Adoption>

In regards to linking in libsystemd. We do that to have a unified way to detect if OpenVPN was started on a system with systemd being functional. The previous implementation in OpenVPN had a copy-paste of a similar approach used in systemd. That implementation was included in OpenVPN in 2011. And things have evolved since those days. To reduce the risk of having to modify OpenVPN later on again, and rather things correctly, I discussed this with upstream systemd, and they recommended to use a feature available in a systemd library. Using the system library also helped us avoiding SELinux challenges which we otherwise would have to face - or in reality, all the package maintainers who uses SELinux would need to take care of this.

That is *exactly* what systemd-ask-password is. And for Linux, this is the mechanism which is designed for this purpose and it will be the solution the majority of Linux distros will use.

But to ensure OpenVPN doesn't malfunction if things are not correctly configured or started up on a system, I've tried to improve these scenarios as I've either stumbled upon them or saw that this can happen.
That also includes ACKing a systemd pacth from the Gentoo community, to
further improving the implementation regarding the detection of where the systemd-ask-password program resides. The only reason it's been some patches is that systemd is fairly new and moves forward as well. A lot have happened since 2011 and we haven't paid attention.

I don't see us complaining about this when it comes to PolarSSL changes when their API changes. We can however have a different attitude to PolarSSL, as the adoption isn't that broad compared to OpenSSL. But for systemd, that train is leaving the station now as systemd really gets tracktion these days.

And just to clarify what systemd-ask-password does. It provides a channel for an application to query the user for input. Whether that is via a console/terminal, through a graphical boot screen or it for some other reasons have this information cached in the systemd infrastructure already. I've even heard systemd guys are working on extending this to use kdbus as well. With the current implementation, we most likely don't need to do that much if we support systemd-ask-password.

The benefit from all this, is that eventually OpenVPN configurations can be started by end-users without root access. The systemd integration provides functionality to ensure that the user is allowed to start OpenVPN, and when OpenVPN needs more input (typically username/passwords/passphrases), systemd ensures that the user who started OpenVPN gets the chance to provide this information. And this isn't unique for OpenVPN, this is a generic interface which all applications which implements it can use. In fact, I'm trying to figure out how to debug a Fedora bugzilla where there are issues related to querying for PKCS#11 PIN codes via systemd-ask-password.

At some point we might even pass the IP address of the tun/tap device together with routing information via systemd, making it possible to run openvpn completely without root privileges. And this can work out-of-the-box for both text-only installations and graphical workstations.

So you want a far more complex implementation to solve a situation which is currently relevant to systemd? Just so you don't need to see #ifdef ENABLE_SYSTEMD in the code? All these changes (except the pkg.m4 patch, which can be used by all modules supported by pkg-config) and a few lines in configure.ac, are well defined *inside* a "only if systemd is enabled" block. It does not pollute any code paths which does not have ENABLE_SYSTEMD defined.

Your suggestion will still need the --echo support, as without that even usernames will not be displayed on the screen or will be masked somehow
- depending on the "ask-password" program. Which means the reality want to add *another* layer wrapper to hide systemd out of your sight. In addition, I've not seen any other distros requiring such a feature, but I might just be misinformed.

Interesting time to question our development process. As I've said earlier, I trust Jon's judgement. And *I* have provided these patches, and I doubt I'm a stranger to the community these days. But you obviously fear that I will disappear completely ...

And this is why I think this is more about "we don't want systemd" than the code itself. We have areas in OpenVPN containing much more crappy code than what I try to improve here. But now I have a systemd focus, because it's low hanging fruits and it can save us from having to fix this in not too far future. And improving the OpenVPN functionality in Fedora is an interest of my employer.

I disagree to postpone this. This is non-sense on such *clearly* *defined* patches which are minimalistic and well contained.

We already have much of the systemd implementations in place, and these two patches will just ensure that OpenVPN will take advantage of useful features on all systemd distros *and* avoiding issues for package maintainers. Plus we can avoid getting trac tickets complaining about OpenVPN not working with systemd due to misalignment of features between our implementation and the systemd reality among Linux users.

And this is one fact which seems to not be understood. Systemd has a potential to unify much of diversity among the Linux distributions than earlier attempts. And we've barely seen the beginning of where systemd will bring the Linux platform next.

kind regards,

David Sommerseth

Hi David,

please take a second to consider what your position on this is - "I like systemd a lot, I want to push support for it everywhere" or "I'm maintainer of OpenVPN and carefully consider what goes in there".

After that, please take a step back and actually *read* what I proposed:

On Wed, Oct 08, 2014 at 01:31:30AM +0200, David Sommerseth wrote:
[..]

So we seem to be in actual agreement that this is a useful thing - but the current code actually is *not* that. It's "this useful feature, done in a very particular way, which only works if systemd is running".

And this is my whole point here - it has nothing to do with "do I have experience with systemd or not" or "do I like systemd or not". When you asked me to take over maintainership for 2.4, you put responsibility on my shoulders, more than just "be the commit-and-push dummy".

When I look at features and patches, I always try to have a broader view

- will this come back and bite us?
- is this code that is very narrow to a particular environment, but might be more useful if done in a more generic way?

So - running a configurable external program which *could* be systemd's ask-password, but could be something completely different on, say, FreeBSD, would give you what you ask for (systemd integration), but be of larger benefit to the OpenVPN project.

Yes, it would be a bit more work to get that API right, well-defined and well-documented. Should that stop us?

[..]

That is actually the point: I try to see the broader picture, and this is more useful than "just systemd". But the way it's currently coded, with your last patch (which I admit that I ACKed - my fault, I should have spend more thought on the design first, and discuss with you beforehand), it's "really just systemd".

If you're seeing this not from a RedHat angle but from an OpenVPN maintainer point of view, why do you care what "distros require"? If a Linux distro *requires* something, they can very well patch it themselves.

We, as OpenVPN community, should aim for what is good for OpenVPN - both for all or user base and for the maintainers ourselves.

[..]

If you think this is so important that the patches need to go in right now, many months before we even consider a release of 2.4 (= many months before this will be relevant to any distribution), and it really can't wait to discuss the larger picture face to face, well, go ahead and do so. You have commit rights, and I won't stop you, as the project is too important to me to risk a schism right now.

gert

USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             [email protected]...
fax: +49-89-35655025                        [email protected]...

I consider myself an OpenVPN maintainer who carefully does consider what we do apply. But I also happen to primarily use Linux, where I see the future will be dominated by systemd. Thus I am concerned about our systemd support.

We've had several patches on pastebins which we've discussed in the past. A few times you have actually told me that my *generic* implementations where over-engineered. Once you even told me to make it specific and we could broaden the scope once we see the need. This is what I am doing right now.

Currently I am not aware of anyone else needing an ask-password feature.
But I'm willing to see how we can adopt the systemd implementation we
already have when that request comes.

In the current state, we will get complaints about usernames being masked. Enforcing --echo regardless of systemd version will come back an bite us on those distros using a too old systemd base. Hence, I try to avoid these two scenarios.

I don't know about systemd versions in other distros than Fedora and RHEL 7. But Fedora 20 which will live alongside Fedora 21 ships with v208. Fedora 19 ships with version 204 but will go EOL some weeks after Fedora 21 is released. RHEL 7 has v208 as the base version. So if we don't consider systemd versions, we will get complaints about OpenVPN not working with systemd on these releases.

In fact the --echo feature will come in a release after v216. So you see there is a gap until this feature will be available in systemd distros.

Okay, should we do the same for setting up IP addresses and routes in tun.c too then? Should we stop fixing issues, isolated to particular platforms in that code because we need a more generic approach which
doesn't bloat the code with #ifdefs? Because that is all I'm doing
here. I'm not extending OpenVPN with new features, just fixing annoyances.

Agreed. But it's damn hard to get the API right without a reference implementation. Currently we do have that in OpenVPN, but it is not optimal. And once we have requests for similar mechanisms for non-systemd distros, yes, I agree we can make things more generic.

But to be honest, I am not convinced making OpenVPN execve() a wrapper execve() the ask-pass program is the proper implementation, and then pipe the result back and forth. I think we should have something more baked into OpenVPN, similar to what we do with OpenSSL and PolarSSL.

One of the first things I did when I stepped up as the first community maintainer of OpenVPN was to try to reduce the fragmentation of OpenVPN on the Linux side. Almost all distros had their own additional patches.
The patches which are in the distroes now are, afaik, only adopting
things which is unique for that distro. We added a lot of the distro patches all could benefit from into the upstream OpenVPN.

I am seeing this from a broader perspective than you probably are aware of. And I want to avoid Linux distros patching OpenVPN on the systemd implementation separately due to issues which has been reported or issues which I see may show up in the future.

In fact, if systemd had had a library function called sd_version() which would return the systemd version, you probably would have ACKed the patch fairly quickly.

But because I touched m4/pkg.m4 you suddenly see a big problem. You even told me on one of the previous patches that as long as systemd related stuff was isolated inside its own configure.ac block, you didn't see any problems. The pkg.m4 is the only change which is outside the systemd scope. Btw. I'm even considering to submit that patch to upstream pkgconfig, to avoid fragmentation (and we can then remove pkg.m4 from our repo in the future).

That is *exactly* what I try to do. To reduce the risk of Linux distros having to add additional patches separately. To reduce the risk of fragmentation among Linux distros. Which means distros can work more closely with upstream OpenVPN, because the gap is minimal.

I have too much respect for the community to go rouge.

But once patches are in our trees, if distros need to patch things before a 2.4 release due to complaints from their users, they can pick our upstream patches instead of having their own approach. And this goes well into the mantra of Fedora and RHEL, where we say: upstream first. Which is why I want to have this solved ASAP.

Fedora 21 currently in Alpha and the final release will be out in a few months. From a Fedora/Red Hat perspective, I want to avoid hacks into that release. For RHEL 7, OpenVPN is no longer part of the base packages, but available via EPEL. Which makes it possible to make RHEL 7+ distributions have more recent versions of OpenVPN as well.

Having that said, I think we need to consider to apply some of the systemd fixes which are already applied to the 2.3 branch. Especially the waitpid() patches.

kind regards,

David Sommerseth

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

It seems the systemd controversy has now reached OpenVPN :). I also would prefer a generic mechanism which could then utilize systemd or whatever. Any ideas how much (more) work would that require?

Very good questions. Perhaps the simplest solution is to give a NACK to the patch to negate the ACK. I don't think an ACK should mean the code _must_ go to the repository _if_ somebody objects it.

That makes sense given that the Munich hackthon is only about one month away.

- --
Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlQ031UACgkQwp2X7RmNIqNWvwCg3+ZCc0Y9vWGXEbP6x1iN32fD b1QAoJLhluPl033np8OTQHXpKjcO/YO0
=IS4U
-----END PGP SIGNATURE-----

ACK.

http://cecinestpasunefromage.wordpress.com/
------------------------------------------------
in your fear, seek only peace
in your fear, seek only love

-d. bowie

So goes open source development. Anytime!

-me

http://cecinestpasunefromage.wordpress.com/
------------------------------------------------
in your fear, seek only peace
in your fear, seek only love

-d. bowie