Upcoming RHEL6 has a problem related to IMA (Integrity Management Architecture) and OpenAFS. See the following mail:

Betreff: [OpenAFS-announce] OpenAFS on Red Had Enterprise Linux 6
Datum: Fri, 23 Apr 2010 15:08:13 -0400
Von: Marc Dionne <marc.c.dionne>
Antwort an: openafs-info
An: openafs-announce

Red Hat has recently announced the availability of a beta version of
its next Red Hat Enterprise Linux release (RHEL6).  While OpenAFS is
functional with this release, it generates a large volume of messages
in the system log when used with a disk cache.

Background
The 2.6.32 kernel in RHEL6 enables IMA (Integrity Management
Architecture).  This feature uses counters to verify and require that
certain operations on files be "balanced", and produces warnings in
the syslog if they are not.
OpenAFS uses dentry_open() to open disk cache files, and in 2.6.32
this function does not increment any IMA counters.  Every caller is
expected to also call ima_counts_get() to properly increment the
counters and balance with the decrement that happens automatically in
fput().
Unfortunately, ima_counts_get() is available only for GPL modules,
which leaves non GPL modules with no way to use the dentry_open/fput
combination correctly.  As cache files are opened and closed
repeatedly in OpenAFS, this generates a very large number of warnings
in the system log.

Fixes
Kernel developers have acknowledged that this API is problematic, and
it has been reworked in 2.6.33 and later, notably with these commits:
      0552f879: Untangling ima mess, part 1: alloc_file()
      b65a9cfc: Untangling ima mess, part 2: deal with counters
      1429b3ec: Untangling ima mess, part 3: kill dead code in ima

These commits have not yet been backported to 2.6.32 and earlier stable
kernels.



See also  

https://bugzilla.redhat.com/show_bug.cgi?id=584901


Since about 15 years we're using AFS as our main shared filesystem here at the University of Cologne. It's the backbone for our Unix/Linux based server environment and about 50000 users have access to their home directories in AFS. We also use AFS to hold centrally installed software. At the moment we have about 240 systems registered in RHN. In addition to these RHEL Systems numerous other systems (various Unix/Linux,OS X, Windows) are connected to AFS througout our campus.

The problem mentioned above is not a functional restriction but it renders systems unmanageable because if the 'noise' in the logs. We need to see the commits from upstream kernels backported to the RHEL6 release kernel.