By default BDII obtains fresh information by querying GIP. To
allow BDII to obtain the GLUE information, you must tell GIP
where to find this information. This is achieved by either
copying the above script into the directory /opt/glite/etc/gip/provider/
[root] #cp /opt/d-cache/libexec/infoProvider/info-based-infoProvider.sh \ /opt/glite/etc/gip/provider/
or by symbolically linking the script in there:
[root] #ln -s /opt/d-cache/libexec/infoProvider/info-based-infoProvider.sh /opt/glite/etc/gip/provider/
If GIP (available in the glite-info-generic
RPM package) and BDII are installed, and the BDII daemons
are running, then you will see the information appear in BDII
after a short delay; by default, this is 60 seconds.
You can verify the information is present with the query:
[root] #ldapsearch -LLL -x -H ldap://<dcache-host>:2170 \ -b o=griddn: o=grid objectClass: organization o: grid dn: Mds-Vo-name=local,o=grid objectClass: Mds Mds-Vo-name: local dn: Mds-Vo-name=resource,o=grid objectClass: Mds Mds-Vo-name: resource dn: GlueSEUniqueID=dcache-host.example.org,Mds-Vo-name=resource,o=grid GlueSEStatus: Production objectClass: GlueSETop objectClass: GlueSE objectClass: GlueKey objectClass: GlueSchemaVersion GlueSETotalNearlineSize: 2000 GlueSEArchitecture: tape GlueSEName: SRM-DEVEL GlueSchemaVersionMinor: 3 GlueSEUsedNearlineSize: 0 GlueChunkKey: GlueSEUniqueID=dcache-host.example.org GlueForeignKey: GlueSiteUniqueID=EXAMPLE-SITE GlueSchemaVersionMajor: 1 GlueSEImplementationName: dCache GlueSEUniqueID: dcache-host.example.org GlueSETotalOnlineSize: 4832 GlueSESizeTotal: 4832 GlueSESizeFree: 4832 GlueSEUsedOnlineSize: 0 GlueSEImplementationVersion: 1.9.5-16 (ns=Chimera) dn: GlueSALocalID=tape-atlas,GlueSEUniqueID=dcache-host.example.org,Mds-Vo-name=reso urce,o=grid GlueSATotalNearlineSize: 1000 objectClass: GlueSATop objectClass: GlueSA objectClass: GlueSAAccessControlBase objectClass: GlueSAState objectClass: GlueSchemaVersion objectClass: GlueKey GlueSAExpirationMode: neverExpire GlueChunkKey: GlueSEUniqueID=dcache-host.example.org GlueSAReservedOnlineSize: 0 GlueSACapability: InstalledOnlineCapacity=0 GlueSACapability: InstalledNearlineCapacity=1000 GlueSchemaVersionMinor: 3 GlueSAUsedNearlineSize: 0 GlueSAName: Tapes for ATLAS GlueSAUsedOnlineSize: 0 GlueSAFreeOnlineSize: 0 GlueSAFreeNearlineSize: 1000 GlueSAReservedNearlineSize: 1000 GlueSchemaVersionMajor: 1 GlueSAAccessControlBaseRule: VO:atlas GlueSALocalID: tape-atlas There are likely many further objects defined. These objects have been omitted for brevity.
Don’t use localhost
It’s tempting to use localhost as the hostname in the
ldapsearch command above. Unfortunately,
for some versions of BDII this will not work. Recent
versions of BDII bind to the ethernet device (e.g.,
eth0). Typically, localhost is
associated with the loopback device (lo),
so the LDAP server part of BDII will not hear the
connection request and the query will fail.
You should be able to compare this output with the output from running the info-provider script manually. If the info-provider output includes LDAP objects that are absent in the BDII output then there is a problem somewhere. The BDII log file will likely explain why this object was not accepted; for example, due to a badly formatted attribute.
Unfortunately, the order of the LDAP objects and the order of the attributes within the object (other than the distinguished name, DN, which must be first) are not required to be in any particular order. Because of this one cannot use the diff command to look for changes.