Ban elliptic-curve ciphers to prevent unsupported ciphers from being selected

Elliptic-Curve (EC) based ciphers offer advantages over RSA- and
DSA-based ciphers and are being introduced, albeit slowly.  OpenJDK (6 &
7) use external libraries, such as libnss3, to provide support for
various cipher-suites, including support for EC ciphers.  The libnss3
library provide only partial support for all of the EC-based ciphers.

Unfortuantely, the generic front-end believes all ciphers are supported.
So, if during an SSL/TLS negotiation, the client requests an EC cipher
that libnss3 doesn't support, the SSLEngine may choose that cipher.  The
result is an exception being thrown with the cryptic
'CKR_DOMAIN_PARAMS_INVALID' message.

Rather than trying to deploy work-arounds in the client or trying to
document how to disable EC-support in the server using JVM-related
configuration, this patch bans the EC ciphers programatically.

Patch: http://rb.dcache.org/r/5527/
Acked-by: Gerd Behrmann
Target: master
Request: 2.6
Merge pull request #61 from paulmillar/fix/2.6/ban_ciphers

Ban elliptic-curve ciphers to prevent unsupported ciphers from being selected
dcache: billing -- fix error in liquibase varchar changeset

module: dcache

The liquibase changeset 4.1.7 was discovered to contain an off-by-one error in the string used to test the condition for changing the varchar length in the billing tables (the actual length of the string was 256, not 257). As a result, 4.1.7. 4.1.8 and 4.1.9 never will run, and all billing installations created by liquibase (which hardcodes the default to 256) remained as such.

The reason for the requested change was that the path and errormessage attributes of certain tables can well exceed 256.

The new changesets correct the error.

Target: master
Committed: master@9e5b5f5077d152dc2ab5b3990b21989790a54aa9
Patch: http://rb.dcache.org/r/5555
Require-book: no
Require-notes: yes
Request: 2.6
Acked-by: Dmitry

Testing done:  Ran new changesets on new and previous installations, observing correct attribute lengths on table afterwards.

RELEASE	NOTES: 	Fixes string lengths in billing databse tables. Tables created automatically contained character columns limited to 256 which is too restrictive for path and errormessage columns in billinginfo, doorinfo and storageinfo tables. Additionaly, the length of pnfsid string was limited to 36.
A previous patch designed to address this issue failed to so.
Merge pull request #62 from alrossi/fix/2.6/billing_varchar_lengths

dcache: billing -- fix error in liquibase varchar changeset
pool: Configure timeout for pool to pool transfer

Addresses the issue that a pool to pool transfer does not time out
if the underlying TCP connection "gets stuck".

Back when we used DCAP for pool to pool transfers, we configured TCP
keep alive to ensure that we eventually get a timeout if the TCP stacks
of the two operating systems disagree about the state of the TCP
connection. Ever since we switched to HTTP, this functionality was lost.

At NDGF we observed a situation in which a migration from one pool to
another got stuck because the TCP connection got into an inconsistent
state. The target pool saw the connection as established, while the
source pool no longer had a connection. The transfer forever stayed
in the DoorFinished state, as dCache expected that the TCP connection
would eventually be closed (since dCache knew it had been closed on the
source pool already).

We cannot get Sun's HTTP client to enable TCP keep alive, however we
can configure connect and read timeouts. Since we only ever need these
timeouts for the rare case when the OSes get confused, I don't see a
reason to make these values end user configurable. I have simply hard
coded some conservative timeout values.

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/5556/
(cherry picked from commit 7de28ba592e39c46df4bf430b6d6d1a8151bd901)
Merge pull request #64 from gbehrmann/fix/2.6/rb5556

pool: Configure timeout for pool to pool transfer
[maven-release-plugin] prepare release 2.6.1
[maven-release-plugin] prepare for next development iteration