gplazma2-xacml: fix regression on network address sort

module:  gplazma2-xacml

svn trunk@18137 altered NetworkUtils to use an immutable list for local addresses.  The XACML plugin needs to sort these according to external/internal.  This sort was failing and causing failure to load the plugin (undiscovered until now).

Patch copies the immutable list and then sorts.

Redeployed and authenticated using XACML.

Target: master
Patch: http://rb.dcache.org/r/5539
Require-notes: no
Require-book: no
Acked-by: Paul
Request 2.6
Parameterize log levels and log formats

The log levels and log formats are now customizable through
dcache.conf.

New configuration properties:

dcache.log.level.file
dcache.log.level.pinboard
dcache.log.level.remote
dcache.log.level.events
dcache.log.format.file
dcache.log.format.pinboard

Target: master
Require-notes: yes
Require-book: yes
Acked-by: Albert Rossi <arossi@fnal.gov>
Patch: http://rb.dcache.org/r/5530/
Remove version number handling for SVN

Since we no longer use SVN, we can simplify our Maven
project by not supporting SVN revision numbers.

Target: trunk
Require-notes: no
Require-book: no
Acked-by: Paul Millar <paul.millar@desy.de>
Patch: http://rb.dcache.org/r/5532/
ftp: Log CertPath in case CertPath validation fails

Addresses the issue that if authentication fails with a certificate
chain validation error, the error message contains absolutely no
information about the certificate that triggered the failure.

Requires https://github.com/gbehrmann/JGlobus/tree/feature/certpathvalidationexception_includes_certpath

Target: trunk
Request: 2.6
Request: 2.5
Request: 2.2-sha2
Require-notes: yes
Require-book: no
Acked-by: Paul Millar <paul.millar@desy.de>
Patch: http://rb.dcache.org/r/5543/
ftp: Log stack trace on authentication failure

A recent patch removed logging of stack trace during GSI/Kerberos
authentication failure. Although it is correct not to log a stack
trace for such a failure (it is not a bug), having a stack trace
while debugging JGlobus 2 is convenient. This patch adds logging
of the stack trace at trace level.

Target: trunk
Request: 2.6
Require-notes: no
Require-book: no
Acked-by: Tigran Mkrtchyan <tigran.mkrtchyan@desy.de>
Patch: http://rb.dcache.org/r/5547/
wevdav,xrootd,nfs: Fix blocking reverse DNS lookup

Addresses an issue in these doors that could cause the door to
become unresponsive.

Our monitoring services periodically poll our doors to get a list
of active transfers. The door did a reverse DNS lookup on the client
IP and this lookup could block the door.

Target: trunk
Request: 2.6
Request: 2.5
Request: 2.2
Require-notes: yes
Require-book: no
Acked-by: Tigran Mkrtchyan <tigran.mkrtchyan@desy.de>
Patch: http://rb.dcache.org/r/5546/
don't use /opt/ paths in dcachesrm-gplazma.policy

There's still a place in the template file, where /opt is used, namely the
default for the kpwdPath property.

* Change the default value for the kpwdPath to "/etc/dcache/dcache.kpwd".

Actually I'd personally suggest introducing a new subdirectory like
/etc/dcache/access_control/
where access control related files should go into. This may include things like
grid-vorolemap, grid-mapfile, storage-authzdb or dcache.kpwd.
/etc/grid-security doesn't seem the right place for them, as they are not
necessarily grid-related.
But that could be done in another patch.

Signed-off-by: Christoph Anton Mitterer <mail@christoph.anton.mitterer.name>
use example.org in some more places

example.org is already used in most places as default domain name.

* Use example.org instead of real (not reserved) domain names in some more
  places.

Using example.org is already much better than using real domain names as it was
done in the past, but still it has some negative effects.
If a dCache instance really uses them, the example.org server will get
“attacked”.
Or it could be even a security problem, when someone manages to actually run a
services on example.org, which dCache tries to use then (and potentially
trusts).

The best way IMHO would be to mark all options where an example value is given
with some flag, that they _must_ be overridden.
Another alternative, that should work in practise is using a domain like
“example.invalid” as this should already be sorted out by the local nameservers.
And ”invalid” is a specially reserved (top level) domain.

Signed-off-by: Christoph Anton Mitterer <mail@christoph.anton.mitterer.name>
Merge pull request #30 from calestyo/example-domains

use example.org in some more places
Merge pull request #29 from calestyo/old-opt-paths

don't use /opt/ paths in dcachesrm-gplazma.policy
Add one-of annotation for log levels

Addresses the lack of an enumeration of allowed values for
dcache.log.level.* properties.

Require-book: no
Require-notes: yes
Request: 2.6
Target: master
Acked-by: Albert Rossi <arossi@fnal.gov>
Patch: http://rb.dcache.org/r/5548/
dcache: alarms: Extend log level capture to all levels; fix server-side logging

module: dcache, package alarms

Because of issues that were not working with the Turbo Filter, the Alarm definition was implemented to accept only messages at WARN or ERROR levels.  It is preferable to allow an ALARM to be defined against any logging level.

I have retested the Turbo Filter and it is now working as advertised.  This patch

- moves the alarms.remote-logging.level property to the level element of the remote appender in the TurboFilter, where it belongs, and eliminates the extra filter on the appender itself;
- makes the necessary modifications to allow ALARMS to be captured at any level, even though ERROR and WARN will undoubtedly be the most common (and even though to capture those below the WARN level one risks a considerable amount of congestion on the alarm server; in such a case it is advisable not to use the XML store).

The logback-server.xml has also been adjusted so that:

- the log file messages are fuller and resemble the optional MAIL message;
- events from the server's own domain are excluded from the store and the history and are placed in the server.log

Testing:

On testbed.  Tested by varying the levels of alarms.remote-logging.level (set globally in the dcache.conf file) and observing the results in the history.log, server.log and on the webadmin page.  Also added an arbitrary ALARM defined at INFO level and observed it appear on the page when the remote logging level was low enough.

Target: master
Patch: http://rb.dcache.org/r/5522
Require-book: yes
Require-notes: yes
Acked-by: Gerd
Request: 2.6

RELEASE NOTES:
BOOK:

Alarms can now be defined at all logging levels.  However, the volume of traffic sent to the server (where the logging message is captured and converted into a potential alarm) increases dramatically below the WARN level.  If this kind of alarm is desired, it is advisable to run the RDBMS version of the store, as the XML store fills up to scores of pages very quickly and searching becomes slow.  Logging messages from the logging server and the domain in which it runs are not sent to the store, but are written to the server.log.