Respect session read-only in SRM

Ticket: 7842
Acked-by: Al Rossi
Target: 2.6
Require-book: no
Require-notes: yes
(2.6) dcache-webadmin (alarms): provide option for absence of alarms database

module: dcache-webadmin, dcache (alarms)

The ticket reported an SQL stack trace error in the httpd log under the condition that they (a) are not running an alarmserver, and (b) have left the default settings for alarms alone.

The immediate fix was for them to set alarms.store.db.type=xml, but it makes sense for there to be an "off" option on this property as well.

This patch adds this option and makes it the default.  This complements the change of the remote log level default to off as well.

Testing done:

The following configurations were checked:

1.  type = off, alarmserver started
    (a) alarmserver reports: 21 Jun 2013 09:29:53 (alarms) [] alarms database type is OFF; server will not be started
    (b) httpd reports: nothing
    (c) page: The datastore for alarms and warnings has been disabled (see the configuration alarm properties).

2.  type = xml, no store.xml, alarmserver not started
    (b) httpd reports: nothing
    (c) page: The datastore for alarms and warnings has been disabled (see the configuration alarm properties).

3.  type = xml, alarmserver started
    everything is sane

4.  type = xml, with store.xml, alarmserver not started
    (b) httpd reports: nothing
    (c) page: query returns only what is currently in db.

5.  type = rdbms, no alarms db; alarmserver not started
    (b) httpd reports the underlying DataNucleus stack traces for "alarms database does not exist"
    (c) page: reports Internal error
    I would argue this is the correct behavior.  It is a misconfiguration.

6.  type = rdbms, no alarms db; alarmserver started
    (a) alarmserver reports Failed to create bean 'liquibase' : FATAL: database "alarms" does not exist from ac_create_$_2_3
        stops and tries to restart
    (b)/(c) same as above
    Again, this is correct behavior.

7.  type = rdbms, alarmserver not started
    (b) httpd reports: nothing
    (c) page: query returns only what is currently in db.

8.  type = rdbms, alarmserver started
    everything is sane

Target: master
Patch: http://rb.dcache.org/r/5668
Ticket: http://rt.dcache.org/Ticket/Display.html?id=7887
Request: 2.6
Require-notes: yes
Require-book: yes
Acked-by: Gerd

RELEASE NOTES:
BOOK:

The options for alarms.store.db.type are not off,xml,rdbms, with off being the default.  If no alarms service is desired, the off option will prevent the web page from trying to establish a connection the the database.
webdav: Fix problems with root paths

Addresses several issues in the webdav door:

- HTTP PUT without redirect is broken in earlier versions of 2.6. This
  regression was introduced in b460302934a6dab2cde1202a38883552d62ac65d.

  The problem is that the the resource path after upload is produced by
  concatenating the server's root path with a full dCache name space path,
  thus the root path appear twice in the generated path.

- The URI name space depends on who authenticates, which means that the
  same URI can have several meanings. This makes bookmarking and linking
  difficult.

- The CSS refers to a non-existing background image.

The solution to these problems are related. The patch removes the
webdavChrootToUserRoot property. An authenticated users root directory
is now always enforced, but only by checking that the request is within
the users root path. If a user has a non-null root and accesses the
root of the webdav door, a redirect to the users home directory is
generated.

The above change resulted in repeated authentication requests in the
browser, because the browser would try to access a non-existing
background image and a non-existing favicon.ico file. Access to these
would be denied, as they are outside the users root directory, and
thus the browser would ask for another user name and password. To
solve this problem, the patch fixes the CSS and adds a favicon.ico file.

An earlier version of this patch was submitted as http://rb.dcache.org/r/5201/

Target: trunk
Request: 2.6
Require-book: yes
Require-notes: yes
Acked-by: Dmitry Litvintsev <litvinse@fnal.gov>
Patch: http://rb.dcache.org/r/5672/
(cherry picked from commit e48a670d502815203704af59a2dedfa7307c13ba)

Conflicts:
	modules/dcache-webdav/src/main/java/org/dcache/webdav/DcacheResourceFactory.java
dcache: (remote logging) change default server port to be outside ephemeral port range

module: dcache (alarms)

This patch is an added precaution in connection with http://rb.dcache.org/r/5664.  It was discovered that the default port suggested by ch.qos.logback for the SocketAppender and server, 60001, is in fact not a good choice because it lies within the ephemeral port range for some OS's.  When there is no endpoint listening (I believe this only occurs when the server is supposed to be running local to the client domain), that port can be chosen as source for establishing a connection, such that the appender then ends up connecting to itself.  If events are actually sent over this connection, it quickly fills up the buffer and blocks.  This causes all threads which do logging to block, effectively freezing the system.

The above-mentioned patch sets remote logging by default to off, so that events are not sent unless it is explicitly activated.  The self-connected appender, however, is still potentially present (though at the 10 second reconnect timeout -- which is what the logback.xml is configured for -- it will take a while for it to find the 60001 port).

Setting the default port outside most ephemeral port ranges will guarantee that this connect-back does not happen.

Testing done:

Using a small test class with the remote logger reconnect delay set to 1 ms, and no server endpoint running, port 60001 was first chosen.  After 30 seconds,

[root@otfrid dcache]# netstat -anp | grep 60001
tcp        4      0 127.0.0.1:60001             127.0.0.1:60001             ESTABLISHED 6051/java

was seen.  The test waits 60 seconds, then begins to log continuously. The system freezes after 5446 events:

6001 25 Jun 2013 08:03:24 [] error message 1
...
6001 25 Jun 2013 08:03:24 [] error message 5446

Rerunning with port set to 9876 shows that after 10 minutes and more than 17M events, no connection is established and hence no freeze.

Target: 2.6
Require-notes: yes
Require-book: no
Acked-by: Gerd
Bug: http://rt.dcache.org/Ticket/Display.html?id=7856
Merge-req:

RELEASE NOTES:

The default port for remote logging has been changed from 60001 to 9867; the latter lies outside most OS ephemeral port ranges.  This avoids a situation in which the connection host is localhost (the default), but there is no server listening on that port, thus permitting that port to be chosen as source for the appender connection and consequently establishing a connection to itself.  When this happens, the buffer quickly fills and blocks further logging, freezing all threads that do logging (effectively the entire domain).
Merge pull request #104 from DmitryLitvintsev/fix/2.6/fix_srm_readonly

Respect session read-only in SRM
Merge pull request #108 from alrossi/fix/2.6/alarm_server_off_option

(2.6) dcache-webadmin (alarms): provide option for absence of alarms dat...
Merge pull request #109 from gbehrmann/fix/2.6/rb5672

webdav: Fix problems with root paths
Merge pull request #110 from alrossi/fix/2.6/alarm_server_port

dcache: (remote logging) change default server port to be outside epheme...
Merge branch '2.6' into fix/2.6/rb5522

Conflicts:
	skel/share/defaults/alarms.properties