GFAL release 1.11.11-1

The release contains the following minor fixes:

- IPv6 compliance
- Manual page update

The release tag is:

glite-data-gfal_R_1_11_11_1

Wrong LDAP search filters?

Today, I tried to replace the deprecated LDAP functions, related to this post. As I have never did anything with LDAP (new skill ;) ), first I wanted to get familiar with it. Google Code Search helped a lot, however, it turned out that the problem might not be related to the deprecated functions, because the LDAP API developers still maintain them, for backward compatibility. What I did in this context was:

• Created the ldap_facade module, to hide the calling details of the deprecated functions (which function is called in fact, some of the always-the-same LDAP API function parameters, etc.).
• Added the ldap_facade_init and ldap_facade_search functions only, and left the rest (may be added later, if change is needed there).
  

To check if I am able to connect to the LDAP server, and execute the search appeared in the log attached to the bug, I installed the Apache LDAP browser plugin for Eclipse, created a connection to the server, and copied the search filter. Here, I made an observation: the plugin did not accept the search filter, because it started with a space...

I checked it in the code, the hard-wired template filters really started with a single space. If I removed it, then the test command went further, and tried to do some SRM operations.

So, the questions:

• Is it true that the LDAP search filter string cannot start with a white space?
• If it is true, then is it a bug in the code? Other filters start with space as well.
• If it is a bug, why could not we see them so far?

Deprecated LDAP API functions in GFAL

On SLC5, certification of the following patch failed:

https://savannah.cern.ch/patch/?3119

The error can be reproduced in the following way:

1. Check out and build org.glite.data with GFAL (instuctions here). The next steps are continuation of the linked build process.
   
2. Build the org.glite.data.dm-util package:
   
   cd ~/org.glite.data.dm-util/build
   make install
   
   
3. Execute the following commands:
   
   
   cd src
   export LCG_GFAL_INFOSYS=lcg-bdii.cern.ch:2170
   ./lcg-cr -d srm://lxb7608v1.cern.ch/dpm/cern.ch/home/dteam/test_rm_02 -D srmv2 -vv /etc/redhat-release
   

(about the LCG_GFAL_INFOSYS: see this). The command results:

Using grid catalog type: lfc
Using grid catalog : (null)
Checksum type: None
[INFO] BDII server: lcg-bdii.cern.ch:2170/o=grid
[INFO] BDII filter: (| (GlueSEUniqueID=lxb7608v1.cern.ch) (& (GlueServiceType=srm*) (GlueServiceEndpoint=*://lxb7608v1.cern.ch:*)))
[INFO] Trying to use BDII: lcg-bdii.cern.ch:2170/o=grid (timeout 60)
[BDII][ldap_search_st][] lcg-bdii.cern.ch:2170 > Bad search filter
[GFAL][bdii_query_send][EINVAL] No accessible BDII
lcg_cr: Invalid argument

That is the same result that can be seen in the bug. After analysis, we found that several LDAP C API functions got deprecated on this platform. Ideas at this point:

- We may as well create a facade to the LDAP API.
Pros: unit-testability, without real LDAP servers (mock finctionality). Future LDAP API changes are isolated.
Cons: The LDAP API does not change frequently, so probably the workload is not worth.

TODO-s:

- Change the deprecated LDAP functions
- Create a regression test for the bug
- Re-send the patch for certification.