This section of the user guide explains how VSLDAP should be configured for testing a product against the LDAP Certified Standard Profile.

 
• Configuring the Directory Server

 
• Testing optional features

Configuring the Directory Server

1 Directory Administration

Follow the instructions to configure the Directory server for Base Profile testing (see previous page). There are no additional requirements.

  2 New Attributes

If the server does not recognize the 'roomNumber' attribute than this must be added.

A new attribute: friends must be added to the schema. A suggested ldif form for the attribute definition is:

dn: cn=schema
changetype: modify
add: attributetypes
attributetypes: ( friends-OID NAME 'friends' SYNTAX
'1.3.6.1.4.1.1466.115.121.1.15' DESC 'vsldap attr')

3 Set-up Referrals

If you wish to test referral handling do the following:

ldap://server2.dc.opengroup.org/ is used as the URL for referrals. Note that this is a ficticious URL and no tests are required to examine data from this domain. The test suite does not attempt to follow this referral. Set the server to return this reference whenever a query is made involving a base DN with a suffix that is not managed by the server.

The alias object "ou=Whizz, ou=Search, o=IMC, c=US", defined in Alias.ldif, contains an alias to a ficticious DN: "ou=Servers, o=IMC, c=GB". Depending on how your directory handles referrals, it may be necessary to explicity configure a referral to this ficticious branch, perhaps by managing it on a second server. The intention is that when this alias is dereferenced, a referral is returned.

  4 Set-up Continuation References

If you wish to test continuation reference handling do the following:

The continuation reference tests in scenarios rfc2254 and rfc2255 are designed to test the ability of the server to return continuation references. The intention is not to test the operational requirements of a distributed directory but simply to test that the returned reference in the SearchResultReference is well formed and appropriate to the conditions under which it was generated (the search criteria). The test client makes no attempt to follow the references and in fact the reference returned could be to an entirely fictional slave server with no affect on the test strategy.

All continuation reference tests involve a single level search request of the "o=IMC, c=US" root of the directory. Within this is an entry "ou=Servers, o=IMC, c=US" which is a reference to a branch on a second 'slave' server. The slave server also manages the "o=IMC, c=US" suffix and has the entry "ou=Servers" but here, the entry is a normal organzationalUnit and not a reference. Because there is no follow-up of the reference by the client, there are no entries stored by the slave in this branch of the directory.

The first step in the configuration of the system for testing continuation references is to set-up a second 'slave' server. The purpose of this server is to manage the "ou=Servers, o=IMC, c=US" branch of the directory. The server must be accessible to the master server (the server under test).
The slave server should be configured to manage the suffix "o=IMC, c=US" and should have an organizationalUnit "ou=Servers, o=IMC, c=US" present.

Next, add an entry to the master server. This entry must have DN "ou=Servers, o=IMC, c=US" and must act to generate a continuation when searched from the level above (i.e. it should be configured to be a subordinate knowledge reference). The reference to be returned is "ldap://slavehost:port/ou=Servers,o=IMC,c=US" where slavehost:port are replaced with the hostname and ldap port number of the slave server. If your master server will attempt to contact the slave at this stage then you will need to have the slave running and network-visible. Note that if your master server does not make any contact with the slave then it is not actually necessary to set up a slave server at all. In this case, the master could return a URL with a ficticious host name. The test client will parse this URL but will make no attempt to follow it as this is not in the scope of the tests.

At this stage the system is now configured for continuation reference testing

  5 Populate the Directory

First, import the entries specified in the VSLDAP, Syntaxes and Extras ldif files as required for Base profile testing. See the previous section on Base Profile configuration for more details.

Next, import the entries located in Alias.ldif and Cert-Standard.ldif. These files are in the vsldap/data/ldif directory.

Testing Optional features

Certain tests in the Standard profile exercise optional LDAP features. These tests deal with the maintenance of attributes in the root DSE. If a particular feature (e.g. altServer) is not provided then the test for the presence of this attribute is automatically passed. To specify which features are supported, edit the tetexec.cfg configuration file (Section #3). Each option has a variable which should be set with the value 'yes' if the feature is supported. The mapping of variable names in the configuration file to the attribute type is as follows:
 

Attribute	Config. file variable
altServer	VSLDAP_ALT_SERVER
namingContext	VSLDAP_NAMING_CONTEXT
supportedExtension	VSLDAP_SUPPORTED_EXTENSION

If the product under test supports extended operations, set the VSLDAP_EXTENDED_OPERATION variable in section #3 of tetexec.cfg to the OID of a supported extended operation.

The procedure for certification testing for the Standard Profile is similar to that for Base profile testing with the addition that Base profile certification must be obtained as a prerequisite to obtaining Standard profile certification.

A test journal of an `all' scenario test run from the ldap-certified-standard.scn scenario file will be required as part of the submission procedure.

e.g.
tcc -bec -s ldap-certified-standard.scn . all

and then copy the 'journal' file to a unique name, such as ldap-standard-all.jnl and submit this file as part of your conformance claim.

Also you must run the program vsldap/bin/report on completion of the test run (the program reads the most recently generated test journal file). This will generate a summary report (to standard output by default). Make a copy of this summary and submit it along with the raw journal file. e.g.

bin/report > standard-summary.rpt

Print a copy of the summary report and sign the disclaimer at the bottom. This signed copy must be sent with the conformance claim

Copyright ©  2007 The Open Group
All rights reserved.