openafs-kmod: import openafs.spec from upstream project
openafs-kmod: Only build kernel module

I've removed everything related to the openafs project except for
building the kernel module.

Added to this is a new executable, find-installed-kversion.sh, which
uses the installed kernel headers to define the kversion, so the build
process no longer uses the output of `uname -r` or a --define
parameter to the rpmbuild command.  Instead, it parses
LINUX_VERSION_CODE and RHEL_RELEASE defined in <linux/version.h> and
builds the kversion from this.

Also, we're using the Red Hat kmodtool script instead of the OpenAFS
one.  It looks like this might make it easier to build dependencies
against kernel symbols instead of particular kernel releases.
find-installed-kversion.sh: make sure to output a define command
openafs-kmod.spec: add 'kernel' as a BuildRequires

The Red Hat rpmbuild automatic dependency generator uses the kernel's
symbols to add kernel symbol dependencies to the package.  For
example, if the kernel module uses vprintk(), it might use add this as
a dependency to the kmod package:

kernel(vprintk) = 0xbf8ba54a

To get access to the kernel symbols, the rpmbuild automatic dependency
generator needs the 'kernel' package installed.
Bumped version to 1.6.10
openafs-kmod.spec: switch to using upstream OpenAFS kmodtool script

Importing src/packaging/RedHat/openafs-kmodtool from
openafs-stable-1_6_10 in the OpenAFS git repo.
openafs-kmodtool: Add features from RH kmodtool

The Red Hat /usr/lib/rpm/redhat/kmodtool has the ability to add and
remove modules from weak-updates in the template RPM's pre and post
scripts.  This commit uses some of those mechanisms, adapting to the
environment available in the OpenAFS kmodtool script.
openafs.spec: Fix conditional missing %endif

This conditional was missing its trailing %endif until much later in
the spec file, making a huge portion of it get ignored for the
non-systemd case. Put an %else and %endif in here, to make it match
the upstream OpenAFS spec file in this specific place.
openafs.spec: Use more familiar server paths

Currently the spec file uses paths in /var/openafs/ for many server
files (logs, server state, etc). However, it seems more common with
other packages, and for openafs on other platforms, to use
/var/lib/openafs for various states, and /var/log/openafs for logs.
So, use those paths instead.

As such, logs now go in /var/log/openafs, and we now use the dirs
/var/lib/openafs/db, /var/lib/openafs/local, and
/var/lib/openafs/backup. BosConfig still goes in
/etc/openafs/BosConfig.

Specify these new dirs in our configure invocation, and change all
relevant paths in the spec file. Remove our KRB5_CONFIG env var while
we're here, since the macro for its value, %{krb5config} is no longer
defined anywhere. Thus, without any --define arguments to rpmbuild,
this expands to the literal string "%{krb5config}", which is not
really what we want.

Also remove various files marked as %ghost and/or %config(noreplace)
that we never interact with (for example, server ThisCell,
rxkad.keytab or krb.conf). The RPM packaging never has to deal with
these files, as they are completely configured by the user, so there
is no reason to burden the packaging with them. The only benefit I can
see to marking such files as %ghost and %config(noreplace) is that RPM
is aware that the files belong to openafs; but, since they are in an
openafs-specific directory, that should already be obvious.
openafs.spec: Remove --enable-bitmap-later

The --enable-bitmap-later configure option is not really exercised
widely enough to be on all the time. While this option can provide
performance benefits to large sites (it can speed up volume
attachment), for most other users it just adds risk without any
noticeable benefit.

So, turn it off.
openafs.spec: Enable debugging for lwp and PAM
openafs.spec: Disable FUSE client

Currently the FUSE client is not packaged. Until it is, make sure it
is disabled when configuring to ensure we don't get unexpected extra
objects built.
openafs.spec: Consolidate systemd check into macro

Instead of specifying '%if 0%{?fedora} >= 15 || 0%{?rhel >= 7}' in a
dozen places, just put that conditional in one place, to define a new
macro 'use_systemd'. This makes the conditionals around systemd files
a bit clearer, and makes it much easier to update the conditional if
we ever need to.

Also, always put the new systemd case first, before the sysvinit case,
just for consistency.
openafs.spec: Change Packager

This is packaged by the CentOS Storage SIG, not by anyone at
openafs.org.
openafs.spec: Update CellServDB

A new version of the public CellServDB has been released; refer to the
new one.
openafs.spec: Do not use upstream packaging files

Currently we copy files out of src/packaging/RedHat from the upstream
source tarball and modify them using sed et al. But those packaging
files do not officially support EL7, and they will of course differ
from our own packaging. Use our own files instead.

The init scripts, systemd service files, etc. added by this commit
have been copied from upstream openafs, commit 05f3c525 (v1.6.11pre1),
and modified to use our paths.
openafs.spec: Massive reorganization

Various cleanup and reorganization. Some of the bigger changes
include:

 - Move file lists to separate files for each subpackage

 - Move subpackage directives such that directives for the same
   subpackage are near each other

 - Rework how we do compat symlinks a bit
openafs.spec: Avoid nonstandard groups

The Group: tag specified by our packages tend to not be actual
recognized groups (most are "Networking/Filesystems"). These groups
appear to be used only by OpenAFS RPM packages, and rpmlint complains
about them.

The Group: tag itself is deprecated and probably does not matter much,
but this is easy enough to fix, so fix it. I've used "System
Environment/Daemons" for packages including daemons (server, client),
"Applications/System" for packages including commands and such, and
"Development/Libraries" and "Documentation" for the obvious packages.
openafs.spec: Remove unversioned Obsoletes:

Currently the openafs-compat package is marked as Obsoletes:
openafs-client-compat. rpmlint complains that this is an unversioned
Obsoletes:, since this means we will obsolete any package called
openafs-client-compat, even if a new openafs-client-compat package is
created in the future.

All known potential openafs-client-compat packages are very old. The
newest ones I can find are from OpenAFS 1.2.2, from 2001, for Red Hat
6.2, 7.1, and 7.2 (that's pre-RHEL Red Hat), for example:
<http://www.openafs.org/dl/openafs/openafs/1.2.2/redhat-7.2/>

It may be impossible (and even if possible, very unlikely) that any
system using these RPMs would also have an openafs-client-compat
package that's over a decade old. And even if they did, lacking this
Obsoletes: would not cause a big problem (just a confusing error). So
just remove the Obsoletes: from openafs-compat to get rid of the
rpmlint noise and reduce the cruft in the spec file.
openafs.spec: Build with warnings and checking

Always build with --enable-warnings turned on, so we always see
warnings generated by the compiler. By default, also build with
--enable-checking, so any warnings cause a build failure, but allow
this to be turned off with '--without checking'.