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
gPlazmaNumberOfSimultaneousRequestsThe number of concurrent requests
Default:
30useGPlazmaAuthorizationModuleRun
gPlazmalocal for each doorDefault: False
useGPlazmaAuthorizationCellRun a central
gPlazmainstance.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 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.