In this section we will have a look at the configuration and log files of pnfs and dCache.

The primary configuration file for pnfs is /usr/etc/pnfsSetup. For administrative tasks in pnfs it has to be sourced and the path to the admninistration tools should be added to $PATH:

[root] # . /usr/etc/pnfsSetup
[root] # PATH=$PATH:$pnfs/tools

Stopping and starting the pnfs server can now be done with

[root] # pnfs stop
[root] # pnfs start

The log files for the three pnfs server daemons are /var/log/pmountd.log, /var/log/dbserver.log, and /var/log/pnfsd.log. The pnfsd is the NFS server implementation. Its log file contains one line for each NFS filesystem operation. The result code of that operation can be found at the end of the line.

The pnfsd daemons communicate with the dbserver daemons via a shared memory area. These perform the actual operations on the database files which can be found in /opt/pnfsdb/pnfs/databases/. The pnfs system finds them via the information in the directory /opt/pnfsdb/pnfs/info/.

Each database file is handled by one dbserver daemon and each access will lock the database file. Each database file/server is the container for one directory sub-tree. Similar to mounts in the UNIX filesystem, the filesystem tree is stitched together from several such sub-trees. In the standard configuration the admin database contains the root of the filesystem (the one mounted on /pnfs/fs/) and the data1 database the sub-tree starting at /pnfs/fs/usr/data/. the section called “The Databases of pnfs” describes how to create new databases.

The dCache software is installed in one directory, normally /opt/d-cache/. All configuration and log files can be found here. In the following filenames will always be relative to this directory.

In the previous section we have already seen how a domain is restarted:

[root] # /opt/d-cache/jobs/<domainName> stop
[root] # /opt/d-cache/jobs/<domainName> \
-logfile=/opt/d-cache/log/<domainName>.log start

Listing the contents of jobs/ you will see that these scripts are all in fact links to jobs/wrapper2.sh. This script will determine the domain to start by its basename. From the above commands you can already read of the standard location for the log files.

The files config/<domainName>Setup will be used by the wrapper script and by the domains at start-up. These files are also links to config/dCacheSetup. This is the primary configuration file of the dCache system.

The only files which are different for each domain are config/<domainName>.batch. They describe which cells are started in the domains. Normally, changes in these files should not be necessary. However, if you need to change something, consider the following:

Since the standard config/<domainName>.batch files will be overwritten when updating to a newer version of dCache (e.g. with RPM), it is a good idea to modify only private copies of them. When choosing a name like config/<newDomainName>.batch you give the domain the name <newDomainName>. The necessary links can be created with

[root] # cd /opt/d-cache/config/
[root] # ../jobs/initPackage.sh

Then the old domain can be stopped and the new one started:

[root] # /opt/d-cache/jobs/<domainName> stop
[root] # /opt/d-cache/jobs/<newDomainName> -logfile=/opt/d-cache/log/<newDomainName>.log start

Recall, that we did change config/httpd.batch in order to adjust the names of the cells which should show up in the “Cell Services” page. Since this was a minor change not influencing the functionality of the dCache instance, it is preferable not to change the name of the domain. This way, changes to config/http.batch in the distribution will be included in your config/httpd.batch. Such a future change will correct the problem with the “OFFLINE” cells, anyway.

An example, where you might want to create new .batch files is the following:

Changing the postgresql password in config/srm.batch, config/utility.batch, and config/replica.batch to a secure one would be done best in copies of these .batch files. You should also do e.g.

[root] # chmod 600 config/mysrm.batch

to secure the password further. Note that future versions of dCache will not require a plain text postgresql password in these files anymore.

More details about domains and cells can be found in Chapter 5, The Cell Package.

The most central component of a dCache instance is the PoolManager cell. It reads additional configuration information from the file config/PoolManager.config at start-up. However, in contrast to the config/<domainName>Setup files, it is not necessary to restart the domain when changing the file. We will see an example of this below.

The domains containing the pools are handled a little differently from the other domains. They are started by

[root] # /opt/d-cache/jobs/pool -pool=<pool> \
-logfile=log/<pool>Domain.log start

This will start the domain <pool>Domain which contains a pool cell for each line in the file config/<pool>.poollist. When only one pool domain is started on a host, it is conventional to use the hostname for <pool>. A line of the <pool>.poollist has the form

<poolName> <poolDir> <options>

The convention for pool names is <hostname>_<n> where the first pool has <n> of 1.

Similar to config/PoolManager.conf, the pools read their configuration from <poolDir>/pool/setup at startup.