dCache has many parameters that can be used to configure the systems
behaviour. You can find all these parameters well documented and together
with their default values in the properties files in
/usr/share/dcache/defaults/
. To use
non-default values, you have to set the new values in
/etc/dcache/dcache.conf
or in the layout file.
Do not change the defaults in the properties files! After changing a
parameter you have to restart the concerned cells.
Refer to the file gPlazma.properties
for a full list
of properties for gPlazma
The following table shows the most
commonly used ones:
Properties
gPlazmaNumberOfSimultaneousRequests
The number of concurrent requests
Default:
30
useGPlazmaAuthorizationModule
Run
gPlazma
local for each doorDefault: False
useGPlazmaAuthorizationCell
Run a central
gPlazma
instance.Default: True
Setting the value for
gPlazmaNumberOfSimultaneousRequests
too high may
result in large spikes of CPU activity and the potential to run out of
memory. Setting the number too low results in potentially slow login
activity.
The default mode for gPlazma
is to run centralised in one instance.
It is however possible to specify to use gPlazma1
as module running
locally to the doors. Set this property to True in the
domain you wish to run the module in.
If you decide to run gPlazma1
as a module you can switch off the
centralised by setting useGPlazmaAuthorizationCell
to
False. Note that is also possible to mix both modes.
Cells may also call gPlazma1
methods as an alternative, or as a
fall-back, to using the gPlazma
cell.
If the gPlazma
cell is not started, other cells can still
authorize by calling gPlazma1
methods directly from a pluggable
module. The gPlazma1
control files and host certificates are
needed on the node from which authorization will take place. To invoke
the gPlazma1
modules, modify the following line in
gridftpdoorSetup
or srmSetup
to
useGPlazmaAuthorizationModule=true
and make sure that the gplazmaPolicy
line defines a
valid gPlazma1
policy file on the node for which authorization
is to occur:
gplazmaPolicy=/etc/dcache/dcachesrm-gplazma.policy
No adjustable timeout is available, but any blocking would likely be
due to a socket read in the saml-vo-mapping
plug-in, which is circumvented by a
built-in 30-second timeout.
Both a call to the gPlazma
cell and the direct call of the
gPlazma1
module may be specified. In that case, authentication
will first be tried via the gPlazma
cell, and if that does not
succeed, authentication by direct invocation of gPlazma1
methods will be tried. Modify the following lines to:
useGPlazmaAuthorizationModule=true useGPlazmaAuthorizationCell=true
Make sure that the line for gplazmaPolicy
gplazmaPolicy=/etc/dcache/dcachesrm-gplazma.policy
set to a local policy file on the node. The gPlazma
policy file on the
or GridFTP
doorsrm
does not have to
specify the same plug-ins as the gPlazma
cell.
This section describes how to activate the Username/Password access for
WebDAV
. It uses dcache.kwpd
file as an example
format for storing Username/Password information. First make sure
gPlazma2
is enabled in the /etc/dcache/dcache.conf
or in the layout file.
Example:
gplazma.version = 2
Check your WebDAV
settings: enable the HTTP
access, disallow the
anonymous access, disable requesting and requiring the client
authentication and activate basic authentication.
webdavProtocol=http webdavAnonymousAccess=NONE webdavWantClientAuth=false webdavNeedClientAuth=false webdavBasicAuthentication=true
Adjust the /etc/dcache/gplazma.conf
to use the
kpwd
plug-in (for more information see also the section called “Plug-ins”).
It will look something like this:
auth optional kpwd map requisite kpwd session requisite kpwd
The /etc/dcache/dcache.kpwd
file is the place
where you can specify the username/password record. It should contain
the username and the password hash, as well as UID, GID, access
mode and the home, root and fsroot directories:
# set passwd passwd tanja 6a4cd089 read-write 500 100 / / /
The passwd-record could be automatically generated by the dCache kpwd-utility, for example:
[root] #
dcache kpwd dcuseradd -u 500 -g 100 -h / -r / -f / -w read-write -p dickerelch tanja
Some file access examples:
curl -u tanja:dickerelch http://webdav-door.example.org:2880/pnfs/
wget --user=tanja --password=dickerelch http://webdav-door.example.org:2880/pnfs/
This section describes how to configure gplazma
to
enable webadmin
in authenticated mode with a grid
certificate as well as with a username/password and how to
give a user administrator access.
Example:
In this example for the
/etc/dcache/gplazma.conf
file the
X.509
plug-in plugin is used for the authentication step with
the grid certificate and the kpwd
plug-in plugin is used for
the authentication step with username/password.
auth optional x509 auth optional kpwd map requisite kpwd session requisite kpwd
The following example will show how to set up the
/etc/dcache/dcache.kpwd
file:
version 2.1 mapping "/C=DE/O=ExampleOrganisation/OU=EXAMPLE/CN=John Doe" john # the following are the user auth records login john read-write 1700 1000 / / / /C=DE/O=ExampleOrganisation/OU=EXAMPLE/CN=John Doe # set pwd passwd john 8402480 read-write 1700 1000 / / /
This maps the DN of a grid certificate
subject=/C=DE/O=ExampleOrganisation/OU=EXAMPLE/CN=John Doe
to the user john
and the
entry
login john read-write 1700 1000 / / / /C=DE/O=GermanGrid/OU=DESY/CN=John Doe
applies unix-like values to john
, most important is the
1000
, because it is the assigned
GID. This must match the value of the
webadminAdminGid
configured in your
webadmin. This is sufficient for login using a
certificate. The entry
passwd john 8402480 read-write 1700 1000 / / /
enables Username/Password login, such as a valid login would
be user john
with
some password. The password is encrypted with the
kpwd-algorithm (also see the section called “The kpwd plug-in”)
and then stored in the file. Again the
1000
here is the assigned GID.