GLUE2: add GLUE2EndpointImplementation information

The EGI GLUE2 profile requires us to publish the implementation name
and version for all published endpoints, which we currently don't
do.

This patch adds this information.

Target: master
Request: 2.6
Request: 2.2
Patch: http://rb.dcache.org/r/5591/
Acked-by: Gerd Behrmann
Merge pull request #67 from paulmillar/fix/2.6/glue2_add_endpoint_version

GLUE2: add GLUE2EndpointImplementation information
Various improvements to short-lived Java invocations

This patch adds several features to improve responsiveness
for various short-lived java invocations and in particular
the chimera-cli command.

The '-client' option is used (sporadically) as a hint to
the JVM not to waste time optimising the byte-code as much
of the code won't be run multiple times.  This option only has
an effect on 32-bit JVMs.  This patch adds '-client' to the
places where it's missing and adds the '-XX:+TieredCompilation
-XX:TieredStopAtLevel=1' options that have the same effect for
64-bit JVMs.

For short-lived tasks, much of the time is spent processing
the classes.  By limiting the classpath to only the jar files
that are needed, less time is taken.  This patch adds support
for this and applies it to the chimera-cli command.

A considerable fraction of the time processing a class involves
verifying certain aspects of the byte-code.  If we trust the
Java compiler and the source of the code, we can choose to
side-step this verification by adding the classes to the
bootstrap-classpath.  This patch does this for the
chimera-cli command.

The chimera-cli creates a BoneCP database pool.  The current
options are not optimal.  This patch updates them.

The effect of these changes were tested by timing how long it
takes to run "chimera-cli ls /" 10 times (discarding output)
using the system-test deployment.  This is then repeated 5
times and the mean and std. deviation is calculated.

The initial time to run "chimera-cli ls /" on my laptop is
(2.99 +/- 0.03) s

Each of the improvements had the following improvements:

    -client -XX:+TieredCompilat... (0.64 +/- 0.07) s
    Limiting jars on classpath     (0.44 +/- 0.03) s
    Using boot-classpath           (0.45 +/- 0.02) s
    Updated BoneCP configuration   (0.07 +/- 0.02) s

    Total improvement              (1.56 +/- 0.03) s

Time to run "chimera-cli ls /" with all improvements is
(1.43 +/- 0.01) s

Acked-by: Tigran Mkrtchyan
Acked-by: Gerd Behrmann
Patch: http://rb.dcache.org/r/5584/
Target: master
Request: 2.6
Merge pull request #69 from paulmillar/fix/2.6/speedup_short_lived

Various improvements to short-lived Java invocations
srm: Make login broker of SRM configurable and clean up properties

The patch allows the login brokers used by the SRM to be configurable.
Since the SRM uses two login brokers, one for lookup and one for
registration, I have renamed all related properties such that those
related to door lookup begin with srm.lookup. and those for login
broker registration begin with srm.loginbroker.

When merging into stable branches, the old properties will not be marked
deprecated.

Deprecated by this patch:

srmLoginBrokerUpdatePeriod
srmNumberOfDoorsInRandomSelection

Introduced by this patch:

srm.lookup.loginbroker
srm.lookup.timeout
srm.lookup.population-size
srm.loginbroker
srm.loginbroker.period
srm.loginbroker.threshold
srm.loginbroker.family
srm.loginbroker.version

Target: trunk
Request: 2.6
Request: 2.2
Require-book: yes
Require-notes: yes
Acked-by: Paul Millar <paul.millar@desy.de>
Patch: http://rb.dcache.org/r/5604/
pool: Improve logging of common errors

Improve log levels and log messages of common errors found in
production log files.

Target: trunk
Require-book: no
Require-notes: yes
Ticket: http://rt.dcache.org/Ticket/Display.html?id=7685
Acked-by: Paul Millar <paul.millar@desy.de>
Acked-by: Dmitry Litvinsev <litvinse@fnal.gov>
Patch: http://rb.dcache.org/r/5255/
(cherry picked from commit 5302c40b0942d7d09f5b8820a62f162d827e6957)
dcache: alarms fix four small bugs

module dcache alarms

Four small bugs:

1.  alarm send:  if -s does not provide a path, the subsequent string operation throws array out of bounds.
2.  alarm definition toXML is not emitting the matchException node when the value is true rather than false (the default)
3.  the server logback file defines the MAIL appender reference after it uses it, which is not allowed.
4.  If an alarm has an id which permits duplicates, and the admin closes the alarm, but thereafter another of its type arrives, that alarm currently will not be visible unless show closed is selected.  The fix is to force the closed flag to false on duplicate arrival.

Target: master
Committed: ce8d000e6a87d3abab649deded7494a34b34d572
Patch:  http://rb.dcache.org/r/5602
Require-notes: yes
Require-book: no
Request: 2.6
Acked-by: Tigran

RELEASE NOTES:

Fixes four small bugs.

1.  dcache alarm send:  if -s does not provide a path (e.g., "src://otfrid" rather than "src://otfrid/"), the subsequent string o$
2.  dcache alarm add * modify fail to record matchException = true because of a logic error in the XML emitter.
3.  the server logback file defined the MAIL appender reference after it uses it, which is not allowed.
4.  If an alarm has an id which permits duplicates, and the admin closes the alarm, but thereafter another of its type arrives, that alarm currently will not be visible unless show closed is selected.  The fix is to force the closed flag to false on duplicate arrival.
pool: Remove caching behaviour of file meta backend

Revert 8290f2f878a818a1398bea7c415a5b1274ec47eb

Tigran reported that the pool performs badly with the
simple caching behaviour added in the above patch.

Target: trunk
Request: 2.6
Require-notes: yes
Require-book: no
Acked-by: Tigran Mkrtchyan <tigran.mkrtchyan@desy.de>
Patch: http://rb.dcache.org/r/5608/
(cherry picked from commit 98e8a9a34ea20a1eaae8f1c4ab5043b64e043360)
broadcast: Fix expiration of dynamic subscribers

Addresses the issue that HSM cleaner is broken as it newer
receives pool-up notifications.

BroadcastRegistrationTask supplies a relative timeout, but the
broadcast registration cell expects an absolute timeout.

Target: trunk
Request: 2.6
Request: 2.2
Require-notes: yes
Require-book: no
Acked-by: Paul Millar <paul.millar@desy.de>
Patch: http://rb.dcache.org/r/5601/
(cherry picked from commit 6276fca8040315bcf38e9c77a60e3c87258027e1)
gplazma: Simplify mapping plugin interface

Addresses an issue with the interface of gPlazma mapping plugins.
Third party mapping plugins will have to be updated.

The old interface distinguished between identified principals and
authorized principals. The idea was that only principals that had
somehow been recognized by a mapping plugin would be considered
authorized and returned to dCache. This approach howeve has several
problems:

- Complexity

- Redundancy; a principal by definition is an assertion that the
  principal belongs to the user (although the level of trust can
  be given a principal strongly depends on its type, eg a DN is
  stronger that a user name, and a user name is stronger than an
  unchecked login name). More over, a principal in it self doesn't
  give access to any additional resources: A second authorization
  step is always done by dCache, authorizing a particular principal
  to do something.

- Limiting, as it was impossible to just "pass through" a principal
  already generated and confirmed by the door. Some doors can do
  their own authentication and there is no reason why one should
  absolutely have to configure a mapping plugin just for the i
  principal to be passed through.

- Inability of authentication plugins to generate principals that
  are passed through to dCache without further mapping. For instance,
  the XACML plugin takes DN and FQAN extracted from the cert chain
  and does a lookup through XACML to generate a user name. A
  subsequent mapping plugin maps the user name to UID/GID, but the
  DN and FQAN is lost as it is not mapped. Yet both DN and FQAN are
  used by other components in dCache for authorization steps.

This patch addresses the problem by changing the mapping plugin
interface. It now takes a single set of principals which it can
add principals to (and possible remove from). Tests are updated
to reflect the changed semantics.

Merge for 2.6 is requested because the patch is a prerequisite to
resolve the XACML problem mentioned above.

Target: master
Request: 2.6
Require-notes: yes
Require-book: yes
Acked-by: Tigran Mkrtchyan <tigran.mkrtchyan@desy.de>
Acked-by: Paul Millar <paul.millar@desy.de>
Patch: http://rb.dcache.org/r/5545/
(cherry picked from commit b5a977e0463a6084401eaa0aeca1a8b6ba938bdf)
Merge pull request #73 from gbehrmann/fix/2.6/rb5604

srm: Make login broker of SRM configurable and clean up properties
Merge pull request #76 from gbehrmann/fix/2.6/rb5608

pool: Remove caching behaviour of file meta backend
Merge pull request #77 from alrossi/fix/2.6/alarms_small_bugs_fix

dcache: alarms fix four small bugs
Merge pull request #78 from gbehrmann/fix/2.6/rb5601

broadcast: Fix expiration of dynamic subscribers
Merge pull request #80 from gbehrmann/fix/2.6/rb5545

gplazma: Simplify mapping plugin interface
Merge pull request #74 from gbehrmann/fix/2.6/rb5255

pool: Improve logging of common errors
webdav: Fix interpretation of client cert properties

Addresses a problem that causes the interpretation of the
webdavWantClientAuth and webdavNeedClientAuth properties to
be reversed.

JGlobus 2 seems to have a different interpretation of these
flags. The relevant JGlobus code is:

	 if (this.requireClientAuth.booleanValue() == Boolean.TRUE) {
             this.sslEngine.setNeedClientAuth(this.requireClientAuth.booleanValue());
	 } else
             this.sslEngine.setWantClientAuth(!this.acceptNoClientCerts.booleanValue());

Target: trunk
Request: 2.6
Request: 2.2-sha2
Require-notes: yes
Require-book: no
Acked-by: Tigran Mkrtchyan <tigran.mkrtchyan@desy.de>
Patch: http://rb.dcache.org/r/5615/
(cherry picked from commit c914cdcb1fa4d476a8eaeb7abc103251c065170b)
Merge pull request #81 from gbehrmann/fix/2.6/rb5615

webdav: Fix interpretation of client cert properties
Add support for banning problematic ciphers for Jetty SSL connectors

An earlier patch added support for banning ciphers through the JGlobus
library.  The same problem exists for the connectors supplied with
Jetty, which are used in the WebDAV/HTTP door and the webadmin.

This patch adds support for banning problematic ciphers for
these services.

Target: master
Request: 2.6
Signed-off-by: Paul Millar <paul.millar@desy.de>
Acked-by: Gerd Behrmann <behrmann@nordu.net>
Patch: http://rb.dcache.org/r/5614/
Require-notes: yes
Require-book: no
(cherry picked from commit d22ef811e7a3bd8f15093ed1fc199eda6b18b025)
Merge pull request #84 from gbehrmann/fix/2.6/rb5614

Add support for banning problematic ciphers for Jetty SSL connectors