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

---
 configure.ac |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

index e30f990..e1ca65e 100644
@@ -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])

1.7.1

This 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

index 41f2008..0047900 100644
@@ -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
 

index e1ca65e..6401095 100644
@@ -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

new file mode 100644
index 0000000..8f83679
@@ -0,0 +1,3 @@
+This directory is empty in the Git repository and gets
+populated by libtoolize (which is usually run automatically from
+autoreconf).

index 6e490c5..7f8d805 100644
@@ -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.

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:

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.

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/

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-----