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 /opt/glite/etc/gip/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 \ '(objectClass=GlueSE)'dn: GlueSEUniqueID=dcache-host.example.org,Mds-Vo-name=resource,o=grid GlueSEStatus: Production objectClass: GlueSETop objectClass: GlueSE objectClass: GlueKey objectClass: GlueSchemaVersion GlueSETotalNearlineSize: 0 GlueSEArchitecture: multidisk GlueSchemaVersionMinor: 3 GlueSEUsedNearlineSize: 0 GlueChunkKey: GlueSEUniqueID=dcache-host.example.org GlueForeignKey: GlueSiteUniqueID=example.org GlueSchemaVersionMajor: 1 GlueSEImplementationName: dCache GlueSEUniqueID: dcache-host.example.org GlueSEImplementationVersion: 2.8-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 -l10[root] #dcache-info-provider | \ grep -i "objectClass: GlueSchemaVersion" | wc -l10
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 -l27[root] #dcache-info-provider | perl -p00e 's/\n //g' | \ grep ^dn.*GLUE2ServiceID | wc -l27
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.