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

Publishing dCache information

BDII obtains information by querying different sources. One such source of information is by running an info-provider command and taking the resulting LDIF output. To allow BDII to obtain dCache information, you must allow BDII to run the dCache info-provider. This is achieved by symbolically linking the dcache-info-provider script into the BDII plugins directory:

[root] # ln -s /usr/sbin/dcache-info-provider

If the BDII daemons are running, then you will see the information appear in BDII after a short delay; by default this is (at most) 60 seconds.

You can verify that information is present in BDII by querying BDII using the ldapsearch command. Here is an example that queries for GLUE v1.3 objects:

[root] # ldapsearch -LLL -x -H ldap://<dcache-host>:2170 -b o=grid \
GlueSEStatus: Production
objectClass: GlueSETop
objectClass: GlueSE
objectClass: GlueKey
objectClass: GlueSchemaVersion
GlueSETotalNearlineSize: 0
GlueSEArchitecture: multidisk
GlueSchemaVersionMinor: 3
GlueSEUsedNearlineSize: 0
GlueSchemaVersionMajor: 1
GlueSEImplementationName: dCache
GlueSEImplementationVersion: 1.9.12-3 (ns=Chimera)
GlueSESizeFree: 84
GlueSEUsedOnlineSize: 2
GlueSETotalOnlineSize: 86
GlueSESizeTotal: 86

Careful with the hostname

You must replace <dcache-host> in the URI ldap://<dcache-host>:2170/ with the actual hostname of your node.

It’s tempting to use localhost in the URI when executing the ldapsearch command; however, BDII binds to the ethernet device (e.g., eth0). Typically, localhost is associated with the loopback device (lo), so querying BDII with the URI ldap://localhost:2170/ will fail.

The LDAP query uses the o=grid object as the base; all reported objects are descendant objects of this base object. The o=grid base selects only the GLUE v1.3 objects. To see GLUE v2.0 objects, the base object must be o=glue.

The above ldapsearch command queries BDII using the (objectClass=GlueSE) filter. This filter selects only objects that provide the highest-level summary information about a storage-element. Since each storage-element has only one such object and this BDII instance only describes a single dCache instance, the command returns only the single LDAP object.

To see all GLUE v1.3 objects in BDII, repeat the above ldapsearch command but omit the (objectClass=GlueSE) filter: ldapsearch -LLL -x -H ldap://<dcache-host>:2170 -b o=grid. This command will output all GLUE v1.3 LDAP objects, which includes all the GLUE v1.3 objects from the info-provider.

Searching for all GLUE v2.0 objects in BDII is achieved by repeating the above ldapsearch command but omitting the (objectClass=GlueSE) filter and changing the search base to o=glue: ldapsearch -LLL -x -H ldap://<dcache-host>:2170 -b o=glue. This command returns a completely different set of objects from the GLUE v1.3 queries.

You should be able to compare this output with the output from running the info-provider script manually: BDII should contain all the objects that the dCache info-provider is supplying. Unfortunately, the order in which the objects are returned and the order of an object’s properties is not guaranteed; therefore a direct comparison of the output isn’t possible. However, it is possible to calculate the number of objects in GLUE v1.3 and GLUE v2.0.

First, calculate the number of GLUE v1.3 objects in BDII and compare that to the number of GLUE v1.3 objects that the info-provider supplies.

[root] # ldapsearch -LLL -x -H ldap://<dcache-host>:2170 -b o=grid \
'(objectClass=GlueSchemaVersion)' | grep ^dn | wc -l
[root] # dcache-info-provider | \
grep -i "objectClass: GlueSchemaVersion" | wc -l

Now calculate the number of GLUE v2.0 objects in BDII describing your dCache instance and compare that to the number provided by the info-provider:

[root] # ldapsearch -LLL -x -H ldap://<dcache-host>:2170 -b o=glue | perl -p00e 's/\n //g' | \
grep dn.*GLUE2ServiceID | wc -l
[root] # dcache-info-provider | perl -p00e 's/\n //g' | \
grep ^dn.*GLUE2ServiceID | wc -l

If there is a discrepancy in the pair of numbers obtains in the above commands then BDII has rejecting some of the objects. This is likely due to malformed LDAP objects from the info-provider.