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
/opt/d-cache/share/defaults/. To
use non-default values, you have to set the new values in
/opt/d-cache/etc/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:
| Parameter | Meaning | Default |
|---|---|---|
gPlazmaNumberOfSimultaneousRequests | The number of concurrent requests | 30 |
useGPlazmaAuthorizationModule | Run gPlazma local for each door | False |
useGPlazmaAuthorizationCell | Run a central gPlazma instance. | 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=/opt/d-cache/etc/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=/opt/d-cache/etc/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.
In this section an example configuration of gPlazma1 is presented to enable working with
Webadmin in authenticated mode and give a user administrator access.
Example:
The /opt/d-cache/etc/dcachesrm-gplazma.policy file would look like this:
# Switches
xacml-vo-mapping="OFF"
saml-vo-mapping="OFF"
kpwd="ON"
grid-mapfile="OFF"
gplazmalite-vorole-mapping="OFF"
# Priorities
xacml-vo-mapping-priority="5"
saml-vo-mapping-priority="1"
kpwd-priority="3"
grid-mapfile-priority="4"
gplazmalite-vorole-mapping-priority="2"
# Configurable Options for plug-ins|Services
# #################################################################################
# Path to local or remotely accessible authorization repositories|services.
# A valid path is required if corresponding switch is ON.
# dcache.kpwd
kpwdPath="/opt/d-cache/etc/dcache.kpwd"
# #################################################################################
# END
The /opt/d-cache/etc/dcache.kpwd file would look like this:
version 2.1 mapping "/C=DE/O=ExampleOrganisation/OU=EXAMPLE/CN=John Doe" john # the following are the user auth records login jans read-write 1000 100 / / / /C=DE/O=ExampleOrganisation/OU=EXAMPLE/CN=John Doe # set pwd passwd john 8402480 read-write 1000 100 / / /
This maps the subject part 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 1000 100 / / /
/C=DE/O=GermanGrid/OU=DESY/CN=John Doe applies
unix-like values to john, most
important is the 100, 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 1000 100 / / /
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
100 here is the assigned GID.