beta2.2: automake support for plugin build
Greetings,
this is the beta2.2 patch pair for hooking the auth-pam and down-root plugins to the build.
The bugfix2.1 patch pair has been sent earlier.
Looking for review, ACK and NAK.
Best regards
Matthias
PATCH 1/2 Cleanup: move AC_GNU_SOURCE to quench autotools warnings.
--- configure.ac | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
configure.ac +1 -1
@@ -32,6 +32,7 @@ AC_CONFIG_SRCDIR(syshead.h) dnl Guess host type. AC_CANONICAL_HOST +AC_GNU_SOURCE AM_INIT_AUTOMAKE(openvpn, [$PACKAGE_VERSION]) AC_ARG_WITH(cygwin-native,
@@ -337,7 +338,6 @@ dnl Checks for programs. AC_PROG_CC AC_PROG_INSTALL AC_PROG_GCC_TRADITIONAL -AC_GNU_SOURCE if test "${WIN32}" = "yes"; then AC_ARG_VAR([MAN2HTML], [man2html utility])
Signature · 1 line
1.7.1
PATCH 2/2 Hook auth-pam and down-root to the build.
In reply to Matthias AndreeThis includes autoconf checks so we only build auth-pam on systems that have security/pam_appl.h
--- Makefile.am | 17 +++++++++++++++++ configure.ac | 10 ++++++++++ m4/README | 3 +++ plugin/README | 13 +++++++------ 4 files changed, 37 insertions(+), 6 deletions(-) create mode 100644 m4/README
Makefile.am +17 -0
@@ -30,6 +30,8 @@ LDADD = @LIBOBJS@ # INSTALL targets: AUTOMAKE_OPTIONS = foreign +ACLOCAL_AMFLAGS = -I m4 + MAINTAINERCLEANFILES = \ config.log config.status \ $(srcdir)/Makefile.in \
@@ -149,6 +151,21 @@ configure.h: Makefile awk -f $(srcdir)/configure_h.awk config.h > $@ awk -f $(srcdir)/configure_log.awk config.log >> $@ +# building default plugins +pkglib_LTLIBRARIES = down-root.la +if HAVE_PAM +pkglib_LTLIBRARIES += auth-pam.la +endif +libtoolmoduleflags = -module -avoid-version +down_root_la_SOURCES = plugin/down-root/down-root.c +down_root_la_LDFLAGS = $(libtoolmoduleflags) + +auth_pam_la_SOURCES = plugin/auth-pam/auth-pam.c \ + plugin/auth-pam/pamdl.h \ + plugin/auth-pam/pamdl.c +auth_pam_la_LIBADD = -lpam +auth_pam_la_LDFLAGS = $(libtoolmoduleflags) + dist-hook: cd $(distdir) && for i in $(EXTRA_DIST) $(SUBDIRS) ; do find $$i -name .svn -type d -prune -exec rm -rf '{}' ';' ; rm -f `find $$i -type f | grep -E '(^|\/)\.?\#|\~$$|\.s?o$$'` ; done
configure.ac +10 -0
@@ -29,6 +29,7 @@ m4_include(version.m4) AC_INIT([OpenVPN], [PRODUCT_VERSION], [[email protected]], [openvpn]) AM_CONFIG_HEADER(config.h) AC_CONFIG_SRCDIR(syshead.h) +AC_CONFIG_MACRO_DIR([m4]) dnl Guess host type. AC_CANONICAL_HOST
@@ -338,6 +339,11 @@ dnl Checks for programs. AC_PROG_CC AC_PROG_INSTALL AC_PROG_GCC_TRADITIONAL +LT_INIT([disable-static]) +dnl we need to dlopen() things, later, we might +dnl look into libltdl stuff that can possibly link the plugin +dnl statically, but I suppose that takes changes to plugin.? code, +dnl too. -- Matthias Andree, 2011-01-06 if test "${WIN32}" = "yes"; then AC_ARG_VAR([MAN2HTML], [man2html utility])
@@ -379,7 +385,9 @@ if test "${WIN32}" != "yes"; then netinet/tcp.h arpa/inet.h dnl netdb.h sys/uio.h linux/if_tun.h linux/sockios.h dnl linux/types.h sys/poll.h sys/epoll.h err.h dnl + security/pam_appl.h dnl ) + AC_CHECK_HEADERS(net/if.h,,, [#ifdef HAVE_SYS_TYPES_H # include <sys/types.h>
@@ -422,6 +430,8 @@ if test "${WIN32}" != "yes"; then ]) fi +AM_CONDITIONAL(HAVE_PAM, test "$ac_cv_header_security_pam_appl_h" = yes) + AC_CACHE_SAVE dnl check that in_addr_t is defined
m4/README new file +3 -0
@@ -0,0 +1,3 @@ +This directory is empty in the Git repository and gets +populated by libtoolize (which is usually run automatically from +autoreconf).
plugin/README +7 -6
@@ -2,8 +2,8 @@ OpenVPN Plugins --------------- Starting with OpenVPN 2.0-beta17, compiled plugin modules are -supported on any *nix OS which includes libdl or on Windows. -One or more modules may be loaded into OpenVPN using +supported on any *nix OS which includes libdl, or on Windows. + One or more modules may be loaded into OpenVPN using the --plugin directive, and each plugin module is capable of intercepting any of the script callbacks which OpenVPN supports:
@@ -28,7 +28,7 @@ auth-pam -- Authenticate using PAM and a split privilege execution model which functions even if root privileges or the execution environment have been altered with --user/--group/--chroot. - Tested on Linux only. + Tested on Linux only. down-root -- Enable the running of down scripts with root privileges even if --user/--group/--chroot have been used
@@ -42,6 +42,7 @@ examples -- A simple example that demonstrates a portable Building Plugins ---------------- -cd to the top-level directory of a plugin, and use the -"make" command to build it. The examples plugin is -built using a build script, not a makefile. +The auth-pam and down-root modules are built as part of the regular +OpenVPN build. Other than that, cd to the top-level directory of a +plugin, and use the "make" command to build it. The examples plugin is +built using a build script, not a Makefile.
Signature · 1 line
1.7.1
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 06/01/11 18:13, Matthias Andree wrote:
| Greetings, | | this is the beta2.2 patch pair for hooking the auth-pam and down-root | plugins to the build. | | The bugfix2.1 patch pair has been sent earlier. | | Looking for review, ACK and NAK. |
Hi Matthias,
And thanks a lot for your patches. Just one question. I see you try to do all the Makefile generation in the main/root Makefile.am. That is for sure a fast-track to get started. But I'm concerned if that might backfire in the long run.
Why not to use the SUBDIRS variable in the root Makefile.am, and then have separate Makefile.am per plugin? That way, each plug-in can more easily control the build independently.
kind regards,
David Sommerseth
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk0mORcACgkQDC186MBRfrrUMQCdEyCiQoerumQOo3ghc4F+kmrj EGIAn3KhLzYGShvTZ5BRKoCcSVNIFXvl
=LG/J
-----END PGP SIGNATURE-----
Am 06.01.2011 22:50, schrieb David Sommerseth:
Quoted 11 lines · Matthias Andree
| Greetings, | | this is the beta2.2 patch pair for hooking the auth-pam and down-root | plugins to the build. | | The bugfix2.1 patch pair has been sent earlier. | | Looking for review, ACK and NAK. |
Quoted 6 lines
Hi Matthias,
And thanks a lot for your patches. Just one question. I see you try to do all the
Makefilegeneration in the main/root Makefile.am. That is for sure a fast-track to get started. But I'm concerned if that might backfire in the long run.
Yes, but in my experience with autotools, the fewer SUBDIRS you have the better it works, the faster and more reliably everything builds. SUBDIRS should only be used as a last resort.
Quoted 3 lines
Why not to use the SUBDIRS variable in the root Makefile.am, and then have separate Makefile.am per plugin? That way, each plug-in can more easily control the build independently.
SUBDIRS is one of the worst ideas I've seen in autotools, and I try to avoid that wherever reasonable. SUBDIRS breaks dependencies because you run multiple "make" processes that all only have a partial view. It is inefficient, leads to autotools bloat, and other reasons are given in "Recursive make considered harmful" by Peter Miller of "cook" fame (URL below). Old as it may seem its points still stand.
Automake allows for per-target build control through _LDADD, _DEPENDENCIES and all sorts of options, and if that fails you can still hand-code the build rules, automake passes them through.
http://miller.emu.id.au/pmiller/books/rmch/
Signature · 1 line
Matthias Andree
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 06/01/11 23:53, Matthias Andree wrote:
| Am 06.01.2011 22:50, schrieb David Sommerseth: |> On 06/01/11 18:13, Matthias Andree wrote: |> | Greetings, |> | |> | this is the beta2.2 patch pair for hooking the auth-pam and down-root |> | plugins to the build. |> | |> | The bugfix2.1 patch pair has been sent earlier. |> | |> | Looking for review, ACK and NAK. |> | |> |> Hi Matthias, |> |> And thanks a lot for your patches. Just one question. I see you try to do |> all the Makefile generation in the main/root Makefile.am. That is for sure a |> fast-track to get started. But I'm concerned if that might backfire in the |> long run. | | Yes, but in my experience with autotools, the fewer SUBDIRS you have the better | it works, the faster and more reliably everything builds. SUBDIRS should only | be used as a last resort. | |> Why not to use the SUBDIRS variable in the root Makefile.am, and then have |> separate Makefile.am per plugin? That way, each plug-in can more easily |> control the build independently. | | SUBDIRS is one of the worst ideas I've seen in autotools, and I try to avoid | that wherever reasonable. SUBDIRS breaks dependencies because you run multiple | "make" processes that all only have a partial view. It is inefficient, leads to | autotools bloat, and other reasons are given in "Recursive make considered | harmful" by Peter Miller of "cook" fame (URL below). Old as it may seem its | points still stand. | | Automake allows for per-target build control through _LDADD, _DEPENDENCIES and | all sorts of options, and if that fails you can still hand-code the build rules, | automake passes them through. | | http://miller.emu.id.au/pmiller/books/rmch/
Thanks for that link, that was a good and enlightening read, and one of the better arguments I've heard in a long long time. I can agree to a lot of the issues here (I have even experienced many of these issues in other projects). ~ However the examples he brings up are not directly comparable to the OpenVPN build process.
* OpenVPN is mainly single directory/single Makefile oriented, considering the build process. Even though, we have been discussing about to separate the bits and pieces a little bit into separate directories, to make the source tree more readable. If we slice it up a bit, that still does not mean that we can't use a single Makefile approach for building OpenVPN executable itself.
* The OpenVPN plug-ins are to be considered third-party plug-ins, even though some plug-ins are shipped with the source tree. However, the *only* thing they depend on is openvpn-plugin.h in the root directory. Nothing more and it will not be anything else they should need to compile in, even in the future. ~ The plug-in system is a pure API, which is all defined in that header file (it's kind of what /usr/include/stdio.h is to glibc). If this header file is modified, it is irrelevant if OpenVPN is rebuilt or the plug-ins are rebuilt first.
So when taking into account this and what is mentioned in the summary on page 13:
~ "Because make can only operate correctly with a complete DAG, the error
~ is in segmenting the Makefile into incomplete pieces."
I would say that this should not be a problem for OpenVPN. The core OpenVPN executable and the plug-ins are really segmented into individual and complete pieces.
Yes, Make does not tackle all kind of Makefile setups well, and especially when sliced into incomplete pieces which depends on each other. This is not the case for OpenVPN (at least 2.x)
Therefore I am still of the opinion that SUBDIRS are not that bad or risky for OpenVPN as in other more "sliced up" projects. But it is important to beware of this pitfall.
kind regards,
David Sommerseth
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk0mVu8ACgkQDC186MBRfromWACgr1mgkUR+GZ4UgohM9linIgm0 2RcAmgL25F+s9B4tstihWsaYt3bjaiqe
=F5Qq
-----END PGP SIGNATURE-----