DN principal fix.
eliminated static call.
dcache: fix DoorRequestInfoMessage so that owner is DN if there is public credential

Fixed logger level to log at debug for exception thrown if credential cannot be converted.

With gPlazma 2, the XACML plugin no longer has an ad hoc data structure (like KPWD) from which the DN of the user can be derived on the door message, because the authorized principals include only UserName, UID and GID principals.  However, our CMS Tier1 users say they require this database field to reflect the DN, and not the role name which ends up appearing there.

This fix is simple: the best effort to find a DN and make the "owner" field carry it now includes a search of the certificate chain.

Target: 2.2
Patch: http://rb.dcache.org/r/5536
Require-book: no
Require-notes: yes
Acked-by: Dmitry
Merge-req: http://rt.dcache.org/Ticket/Display.html?id=7794
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/
(cherry picked from commit cf364eecc3a2b69e321ad41246c238900fbdf902)
Merge pull request #26 from gbehrmann/fix/2.2/rb5546

wevdav,xrootd,nfs: Fix blocking reverse DNS lookup
Merge pull request #18 from alrossi/fix/2.2/fix_doorinfo_dn_principal

Fix/2.2/fix doorinfo dn principal
skel: fix billing database properties to work with dcache database commands

module: skel, defaults

While conditional initialization of the billing database works when the cell is created (via Spring), the database commands currently do not handle correctly the case where there is no billing database and billingToDb=no. In particular, database ls lists the billing database regardless, and database update fails because it tries to run the liquibase changelog on a non-existent database.

To fix this, we have added conditional immutable properties in the style of several other default properties files.

Target: master
Committed: master@02dacf3
Patch: http://rb.dcache.org/r/5563
Require-book: no
Require-notes: yes
Request: 2.6
Request: 2.2
Bug: http://rt.dcache.org/Ticket/Display.html?id=7809
Acked-by: Paul

RELEASE NOTES: Fixes a bug in the dcache database commands where update could not run if the billing database does not exist. dcache database ls now correctly lists or does not list the billing database, depending on the billingToDb property, and dcache database update will ignore billing if billingToDb=no.
Merge pull request #48 from alrossi/fix/2.2/billing_props_for_db_cmds

skel: fix billing database properties to work with dcache database comma...
(2.2) dcache: minimal backport to enable remote logging from 2.2 domains

dcache: alarms

For mixed installations where the head and door nodes may be running later versions but pool nodes are not updated from 2.2, it would still be nice for a potential alarm server to receive error or warn events from the pools.

This patch provides a minimal backport of alarm sending (actually, log event sending) capabilities.

  - IAlarms interface for certain constants that are used
  - An appender implementation which adds some properties to the MDC before sending the event
  - an alarms.properties default with only the properties used to configure the appender
  - the necessary xml for the remote appender in logback.xml

Note that this preserves the 2.6 semantics (e.g., the error/warn limitation and the property naming), not the more generalized configuration added to 2.7+.

Target: 2.2
Patch: http://rb.dcache.org/r/5564
Require-notes: yes
Require-book: yes
Acked-by: Tigran

RELEASE NOTES:
BOOK:

Version 2.2 does not contain the full alarm service capabilities (server, store and webpage); however, this patch allows all 2.2 domains to communicate with a potential alarm server by enabling the sending of log events (at the ERROR or WARN levels) to a remote server.  The following properties determine the server endpoint and the level of log events sent:

(one-of?off|error|warn)alarms.remote-logging.level=off

alarms.server.host=localhost

alarms.server.port=60001

The default for 2.2 has been set to "off", unlike later versions, where it is set to warn.
Merge pull request #49 from alrossi/feature/2.2/backport_remote_logging

(2.2) dcache: minimal backport to enable remote logging from 2.2 domains