release notes | Book: 1.9.5, 1.9.12 (opt, FHS), 2.11 (FHS), 2.12 (FHS), 2.13 (FHS), 2.14 (FHS), | Wiki | Q&A black_bg
Web: Multi-page, Single page | PDF: A4-size, Letter-size | eBook: epub black_bg

gPlazma specific dCache configuration

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:

ParameterMeaningDefault
gPlazmaNumberOfSimultaneousRequestsThe number of concurrent requests30
useGPlazmaAuthorizationModuleRun gPlazma local for each doorFalse
useGPlazmaAuthorizationCellRun 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.

[return to top]

Using Direct Calls of gPlazma1 Methods

Cells may also call gPlazma1 methods as an alternative, or as a fall-back, to using the gPlazma cell.

[return to top]

Operation without a 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.

[return to top]

Using a gPlazma Cell with a Direct-Call Fallback

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 door or srm does not have to specify the same plug-ins as the gPlazma cell.

[return to top]

gPlazma config example to work with authenticated webadmin

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 /etc/dcache/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="/etc/dcache/dcache.kpwd"

# #################################################################################
# END

The /etc/dcache/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.