afs: Verify osi_UFSOpen worked

  In some builds (UKERNEL) osi_UFSOpen returns a NULL if it runs
into a problem.  On the other builds osi_UFSOpen simply panics.
afs/afs_cell.c was checking for a NULL return but other callers
were not.  Add checking logic to all callers.
  This is a prepartory patch.  A subsequent patch will have
osi_UFSOpen return NULL rather than panic for other builds too.

Change-Id: I3610a57dff59b84fe5ea8b1c862f3192157f255f
Reviewed-on: http://gerrit.openafs.org/11243
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Reviewed-by: Garrett Wollman <wollman@csail.mit.edu>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: D Brashear <shadow@your-file-system.com>
aklog: Fix segfault on aklog -path

Commit 2fac53522e7ef5b3a376e191bffdc1f6784e6995 “aklog: Fix improper
use of readlink” inadvertently changed the meaning of int link from a
boolean flag (length > 0) to just a length.  This caused ‘aklog -path
(anything)’ to segfault.

Update the type of link and the condition of the while loop to account
for this change.

FIXES 131930

Change-Id: Ia05836795425a53e858ab29866900f6d45970644
Reviewed-on: http://gerrit.openafs.org/11517
Reviewed-by: Anders Kaseorg <andersk@mit.edu>
Tested-by: Anders Kaseorg <andersk@mit.edu>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Tested-by: Stephan Wiesand <stephan.wiesand@desy.de>
Reviewed-by: D Brashear <shadow@your-file-system.com>
build: remove trailing whitespace from makefiles

Remove trailing whitespace from the makefiles, except for
trailing whitespace in the boilerplate comment headers.

Change-Id: Ib8ee87a51f00633ba15e1974ac0b311969bef1bf
Reviewed-on: http://gerrit.openafs.org/11456
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Reviewed-by: D Brashear <shadow@your-file-system.com>
Tested-by: D Brashear <shadow@your-file-system.com>
Use correct syntax for libtool version info

It does not take an '='.

Whomever thought that making libtool silently accept all (i.e.,
malformed) command-line arguments was a good idea ... seems to
have been mistaken.

Change-Id: I357cd44ac6f495474f9763a2f768ac9c8d1e4cb4
Reviewed-on: http://gerrit.openafs.org/11458
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: D Brashear <shadow@your-file-system.com>
Tested-by: D Brashear <shadow@your-file-system.com>
Normalize names of libtool convenience libraries

Part of why libtool was introduced into the tree was to reduce the
number of times each source file is compiled.  PIC code is needed
for shared objects, and non-PIC code for static libraries, so in most
cases a C file must be compiled twice, but not more than that.

Libtool automatically manages which version of an object is passed to
the linker when libtool is used to link .la files.  At several places
in the tree (libafsrpc, libafsauthent, libuafs_pic.so, and pam_afs.so)
we use libtool to link a .la library and pass other .la libraries in
as linker inputs.  In normal situations, libtool would produce an
output shared library that registered a shared library dependency on
the (shared version of the) input library.  However, in our usage,
these input .la libraries are used only for our convenience, and are
not intended to be installed, so libtool would produce an output
library that was not usable.

Libtool refers to our usage of libraries not intended to be installed
as "convenience libraries"; for us, they are essentially just
static archives that contain PIC objects (as opposed to normal
static archives which contain non-PIC objects).

Prior to this commit, we had named our convenience libraries things
like libafsauthent_auth.la or libafsrpc_comerr.la, since they were
mostly only used for either libafsrpc or libafsauthent.  However,
future commits will need to use some of these convenience libraries
in other shared objects (such as pam_afs.so), so we normalize the
library name to indicate merely that it is a PIC version of that
module.

There are three exceptions to this rule: libafsrpc_sys.la, which
contains only a single file and not the whole of the sys module,
libafsrpc_util.la, which contains a subset of the util objects,
and libauthent_ubik.la, which contains a subset of the ubik
objects.  Since these convenience libraries are in fact tailored to
the particular application, a target-specific name is appropriate.

The convenience library provided by the ptserver module is named
libprot_pic to match the existing public interface libprot.a.

We cannot link the dependencies of the convenience libraries
directly into them, because any given object may only be linked
once into a given library, and our dependency graph between
modules is decidedly not a tree, so attempting to link in the
dependencies would result in duplicate symbol errors.

Change-Id: I5f10af74b8582edd51e5f1b3f0026dbc7ef9f7ad
Reviewed-on: http://gerrit.openafs.org/11459
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: D Brashear <shadow@your-file-system.com>
Tested-by: D Brashear <shadow@your-file-system.com>
Normalize LT_deps/LT_objs split

As described in the commit message of
69f26ece3c4545ecc9099641f7a507796fe9dc77, LT_objs should contain
the .lo files for the given module, and LT_deps should contain the
libtool dependencies, i.e., the .la files from other parts of the
tree.  However, this simple split by file suffix is not correct
when we are using convenience libraries.  Really, LT_objs represents
the "new" objects being provided by the module, and LT_deps is
libraries from other modules that provide functionality on which
we depend.  Since convenience libraries are just thin aggregates
of object files, they behave more like object files than libraries
upon which we depend.  In particular, libafsrpc and libafsauthent
are wrapper libraries that gather together the functionality of
several modules and export them as a single library interface;
they do not have any objects of their own.

However, libafsauthent has a dependency on libafsrpc, which does
belong in LT_deps (or possibly in LT_libs).

Simon's description of LT_libs leaves a little ambiguity, as it
does not describe what should be done with non-libtool libraries
from within OpenAFS.  (At present, these include libafshcrypto
and librokenafs, both of which are regularly put in LT_libs.)
I prefer to recast LT_libs as containing externally visible libraries,
not just external libraries, which rationalizes the inclusion of
roken and hcrypto there, since we currently install those libraries,
and build libraries that have shared library dependencies on them.

In the future, as we begin committing to stable shared library
interfaces for libraries produced by libtool, I would like to
have those .la files be moved to LT_libs, since they would then
be external library dependencies of the given module.

Change-Id: Ie50010da84df99cec048c3e39ffeb9d5897fc08c
Reviewed-on: http://gerrit.openafs.org/11460
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: D Brashear <shadow@your-file-system.com>
Tested-by: D Brashear <shadow@your-file-system.com>
Build and install libafsrpc.so.2

During the libtool interim, we had been building a .0 but not
installing it.  Prior to the libtoolization of shlibafsrpc, we
had installed a libafsrpc.so.1.4 (though the 1.6 branch was
installing libafsrpc.so.1.5, "so we don't collide with the shlibafsrpc
versions on the master branch", which seems misguided).  Since there
have been backwards-incompatible ABI changes (e.g., rx_SetMaxMTU) since
the .1.4 version, we must bump the SONAME to .2.0.

At time of this writing, the libtool rules for updating the
version information is found at:
http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html
and
http://www.gnu.org/software/libtool/manual/html_node/Libtool-versioning.html

This lets us consolidate the building of the shared and static libafsrpc
and their installation), as libtool will happily do both for us
at once.

We explicitly do not install the .la files, as our libtool use is
to be kept entirely internal.

Change-Id: I11bc3cbc80048d0192aadeb80b89d2772bcd01cd
Reviewed-on: http://gerrit.openafs.org/11461
Reviewed-by: D Brashear <shadow@your-file-system.com>
Tested-by: D Brashear <shadow@your-file-system.com>
Build and install libafsauthent.so.2

During the libtool interim, we had been building a .0 but not
installing it.  Prior to the libtoolization of shlibafsauthent, we
had installed a libafsauthent.so.1.1, which is the same version currently
installed by the 1.6 branch.  Since there have been backwards-incompatible
ABI changes (e.g., afsconf_BuildServerSecurityObjects) since the .1.1
version, we must bump the SONAME to .2.0.

At time of this writing, the libtool rules for updating the
version information is found at:
http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html
and
http://www.gnu.org/software/libtool/manual/html_node/Libtool-versioning.html

This lets us consolidate the building of the shared and static libafsrpc
and their installation), as libtool will happily do both for us
at once.

We explicitly do not install the .la files, as our libtool use is
to be kept entirely internal.

Change-Id: I283f9bb74eb9853c268e8642ac1f01741deeae2b
Reviewed-on: http://gerrit.openafs.org/11462
Reviewed-by: D Brashear <shadow@your-file-system.com>
Tested-by: D Brashear <shadow@your-file-system.com>
Build a usable pam_afs.so

Our use of libtool for building the pam modules resulted in shared
objects which had dependencies on liboafs_auth.so and liboafs_kauth.so,
neither of which are installed.

We still need some way to resolve those dependencies at link time, and
a dependency on libafsauthent.so seems ill-advised to insert into the
pam stack, so we are left with only the option of directly linking in
the requisite functionality.  Fortunately, almost all of the requisite
convenience libraries of PIC objects already exist to meet the
requirements of libafsrpc and libafsauthent; the only exception is
from the auth module.  Here, we require a new convenience library,
because the pam_afs.krb.so module includes its own version of ktc.o,
compiled with AFS_KERBEROS_ENV defined, yet the pam_afs.so module
requiers a ktc.o compiled without AFS_KERBEROS_ENV defined.  The
convenience library from the auth module can only include one version,
and would therefore be wrong for the other.  As such, create the new
libpam_auth.la archive from the BASE_objs in src/auth, and manually
compile ktc.lo and ktc_krb.lo as needed for the pam modules.

As for libafsrpc and libafsauthent, the convenience libraries included
from other parts of the tree belong in LT_objs, not LT_deps, because
they are contributing actual content to be included in the resulting
library; they are not library dependencies of the output of this module.

Change-Id: I5292718a5494710d166043fd08ad07269ff9fdf2
Reviewed-on: http://gerrit.openafs.org/11463
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: D Brashear <shadow@your-file-system.com>
Tested-by: D Brashear <shadow@your-file-system.com>
Make pam conditional on INSTALL_KAUTH

The pam module we provide is only useful in kaserver-like environments,
and as such should not be installed when the user has requested to
not have kauth.

Change-Id: I9b336593e34cedfd6e8c2210f3798575d115d2d6
Reviewed-on: http://gerrit.openafs.org/11466
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: D Brashear <shadow@your-file-system.com>
Tested-by: D Brashear <shadow@your-file-system.com>
Deorbit the netscape plugin

Netscape hasn't been a thing since 2008.

We would only try to build it if someone manually ran 'webinstall'
in src/libuafs, and there is no documentation telling anyone to do so.

It's dead, Jim.

Change-Id: I7486ca33da7ff19f23f0d9f54f5fb4e7e3232540
Reviewed-on: http://gerrit.openafs.org/11470
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: D Brashear <shadow@your-file-system.com>
Tested-by: D Brashear <shadow@your-file-system.com>
Deorbit separate JUAFS build

Since 80943970b8cfcdf3fc630b25804aebaea228bd73, when the web enhancements
were enabled universally, there has no longer been a functional difference
between the UAFS and JUAFS builds.  Their object files are compiled
using the same compilation rule, and the list of object files differed
only by rx_kmutex.o (which is devoid of content) and xdr_int32.o
(which is preumably an oversight).

Save the extra build time by just reinstalling libuafs.a as libjuafs.a
to preserve the existing interfaces.

Additionally, drop the LIBJUAFS make variable -- all definitions set
it to libjuafs.a.  Similarly, the LIBJUAFS_FLAGS variable was unused
and can be removed.

Change-Id: I2074d5bc26e326db36b16e055431818ef1c69210
Reviewed-on: http://gerrit.openafs.org/11471
Reviewed-by: D Brashear <shadow@your-file-system.com>
Tested-by: D Brashear <shadow@your-file-system.com>
Adjust roken.m4 to allow separate lib and include

In some installations (e.g., Debian), the roken libraries and headers
will not be installed in a common root directory to which /lib and
/include may be appended to find the appropriate library and header
directories, respectively.

Take inspiration from rra-c-util's GSSAPI macros and allow the
specification of separate include and lib directories.  Since there
are now three values to pass to the guts of the checking routine,
pass them in global variables instead of as parameters.

The expected usage would be to set either --with-roken, or both of
--with-roken-libdir and --with-roken-includedir, as in
configure --with-roken-include=/usr/include/heimdal
--with-roken-lib=/usr/lib/x86_64-linux-gnu/heimdal

This also fixes a typo that prevented --with-roken=internal from
functioning as intended.

Change-Id: I6f651ef3f3abf37c92ea81ea1801294ca3dc00b2
Reviewed-on: http://gerrit.openafs.org/11473
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: D Brashear <shadow@your-file-system.com>
Tested-by: D Brashear <shadow@your-file-system.com>
Allow building with MIT krb5 and external roken

That is, an external roken which is part of a heimdal distribution,
with full headers and libraries, most notably krb5.h and libkrb5.

This adjusts the ordering of file- and module-specific compiler and
linker arguments so that the more specific arguments are able to
take precedence.  For general flags arguments, such as enabling
or disabling warnings or features, the more-specific settings should
come last, so as to override the flags set by default.  However,
for arguments that affect a global search list (e.g., for headers
or libraries),  the more-specific arguments must come first, so
as to be at the beginning of the search list.

We presently use per-file CFLAGS for both warning-type flags and
preprocessor (i.e., include path) type flags, so add an additional
file-specific setting for CPPFLAGS, which comes at the beginning of
the compiler invocation.

At present, MODULE_CFLAGS are essentially only used for preprocessor
functionality, so treat them as CPPFLAGS and put them right after
the per-file CPPFLAGS.  (It might be cleaner to rename them to
MODULE_CPPFLAGS, but that would be more churn than is needed.  If
such a distinction turns out to be necessary, it can be done at a
later date.)  Likewise the MODULE_LDFLAGS are generally being used
to affect the library search path, so put them early as well.

Make the necessary Makefile changes to use these new features to
allow building with MIT krb5 and external roken: put KRB5_CPPFLAGS
in per-file CPPFLAGS, and put LDFLAGS_KRB5 in MODULE_LDFLAGS for
aklog.

Change-Id: I1091223b3b75c782b39b9e189bdd47e52ebefae2
Reviewed-on: http://gerrit.openafs.org/11474
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: D Brashear <shadow@your-file-system.com>
Tested-by: D Brashear <shadow@your-file-system.com>
Fix LT_LDLIB_shlib_missing

Libtool's -symbols-file argument is taken as an exact match of symbols
that this library claims to export.  It does not filter based on what
symbols are actually present in the objects comprising the library.
Instead, if there are symbols in the file which are not implemented
by the library, there is an implicit assumption that some other library
will provide those symbols, which must be linked into a consumer of
this library alongside this library.

These are not the semantics we want (at present, only for roken), wherein
a library will implement some (but probably not all) of a given list
of symbols, and we want the export list to reflect only those symbols
which are implemented.  Instead, use the symbols file to build a regex that
will only match symbols listed in the file (and no other symbols), and
only export the subset which is present.

Change-Id: Id81f7a35089ae7f760fe643680f9bfb9c81521aa
Reviewed-on: http://gerrit.openafs.org/11475
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: D Brashear <shadow@your-file-system.com>
Tested-by: D Brashear <shadow@your-file-system.com>
Build auth tests with libtool

(And pthreaded.)

This was the only place consuming librokenafs directly, which is
forbidden if we are to properly support using an external roken.
Convert to libtool and throw $(LIB_roken) on at the end.

Change-Id: I0cdea690800be1022888244b613929ce3154db1d
Reviewed-on: http://gerrit.openafs.org/11476
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: D Brashear <shadow@your-file-system.com>
Tested-by: D Brashear <shadow@your-file-system.com>
Build roken using libtool

Previously it was version 1.1; just in case I did something terrible,
bump it to 2.0, as was done for the other libtool conversions.

Install both the libtool archive and the static archive to $(TOP_LIBDIR),
so that all our internal consumers can just use -L$(TOP_LIBDIR) -lrokenafs
(well, via the LDFLAGS_roken and LIB_roken aliases) whether linking
statically or shared.  Installing the libtool archive gets us the shared
library there, but we have to then remove the libtool archive, since
this is not the location we told libtool we would install to (the prefix
we configured with), and libtool would get confused trying to use this
installed, but installed-at-the-wrong-place libtool archive.

Add rk_vsyslog to the export list, for AIX.

It is tempting to eschew this installation and instead point LIB_roken
at the libtool archive file librokenafs.la directly (with empty
LDFLAGS_roken), but this is not possible until all consumers of roken
are converted to build using libtool.  In practice, this will probably
not happen until LWP is evicted from the tree.

Change-Id: If6ab6c2d57c0a1b1511f9631b9aeb522d7e7392b
Reviewed-on: http://gerrit.openafs.org/11477
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: D Brashear <shadow@your-file-system.com>
Tested-by: D Brashear <shadow@your-file-system.com>
Build venus tests with libtool

This was the only place doing -lafshcrypto_lwp on the command line.
(There are other consumers, which list libafshcrypto_lwp.a explicitly;
we can use the presence of libafshcrypto_lwp.a to track progress towards
not needing a LWP hcrypto build, which must come from the in-tree version.)

Convert the tests to build with libtool (as pthreaded), where we can
just throw in $(LIB_hcrypto) and deal with what we get.

Change-Id: Ibc99615d2ff03b8aebf956502a2a6b1cb26f0a65
Reviewed-on: http://gerrit.openafs.org/11479
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: D Brashear <shadow@your-file-system.com>
Tested-by: D Brashear <shadow@your-file-system.com>
Link aklog against LIB_hcrypto

This was the last place where libafshcrypto.a was explicitly referenced,
preventing the use of an out-of-tree hcrypto library.

We will continue to need to build the in-tree code to produce a
libafshcrypto_lwp.a library for use in LWP applications, until we
do not have any more LWP applications, but some systems (such as
Debian) have a desire to avoid bundled libraries, so we should
facilitate the use of an external libhcrypto where possible.

Many consumers of libafshcrypto_lwp.a will be removed when the
LWP versions of various modules are removed after 1.8 is branched.

Change-Id: I23049866caae9c16ffb2ec32c5e7b058465a26ba
Reviewed-on: http://gerrit.openafs.org/11480
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: D Brashear <shadow@your-file-system.com>
Tested-by: D Brashear <shadow@your-file-system.com>
Allow external hcrypto

Put the configure checks into a separate file in src/cf, following
the same general structure as the roken checks.

Allow explicitly requesting the internal version, or checking
what's in the default paths, or providing a specific hcrypto root
or lib/include dirs for Debian compatibility.

We must still always compile libafshcrypto_lwp.a for use by LWP
binaries, from the bundled sources, but other binaries will use
the system version.

The hcrypto headers have an unfortunately large number of dependencies,
including depending on being able to find each other by including
<hcrypto/foo.h> paths.  As such we must pass both the user-supplied
directory and $dir/hcrypto to the preprocessor in order for things
to work, and we also may need to revisit the includes used in the
configure check for use on non-linux systems due to the dependencies
on system headers.

Change-Id: Idcba1418a19a7b562335524c911d69dc84268177
Reviewed-on: http://gerrit.openafs.org/11481
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: D Brashear <shadow@your-file-system.com>
Tested-by: D Brashear <shadow@your-file-system.com>