LDAP directory services versus the Sybase interfaces file

LDAP directory services are a convenient alternative to the typical Sybase interfaces file. The Sybase interfaces file stores server information in a “flat” file. Any changes to server information in the interfaces file need to be updated on each machine (client and server) in the enterprise.

Table 5-1 highlights the differences between the Sybase interfaces file and LDAP server.

**Table 5-1: The interfaces file versus LDAP directory services**
The interfaces file	Directory services
Platform-specific	Platform-independent
Specific to each Sybase installation	Centralized and hierarchical
Contains separate master and query entries	Contains one entry for each server that is accessed by both clients and servers
Cannot store metadata about the server	Stores metadata about the server

The traditional interfaces file on a UNIX machine with a TCP connection and a failover machine looks like this:

master tcp ether huey 5000

query tcp ether huey 5000

hafailover secondary

An example of an LDAP entry with a TCP connection and a failover machine looks like this:

dn: sybaseServername=foobar, dc=sybase,dc=com
objectClass: sybaseServer
sybaseVersion: 1500
sybaseServername: foobar
sybaseService: ASE
sybaseStatus: 4
sybaseAddress: TCP#1#foobar 5000
sybaseRetryCount: 12
sybaseRetryDelay: 30

sybaseHAServernam: secondary

All entries in the LDAP directory service are called entities. Each entity has a distinguished name (DN) and is stored in a hierarchical tree structure based on its DN. This tree is called the directory information tree (DIT). Client connections specify where to begin the search of an LDAP server by specifying a DIT base during connection.

Table 5-2 lists valid DIT-base values.

**Table 5-2: Sybase LDAP entry definitions**
Attribute name	Value type	Description
sybaseVersion	Integer	Server version number.
sybaseServername	Character string	Server name.
sybaseService	Character string	Service type: Sybase Adaptive Server.
sybaseStatus	Integer	Status: 1 = Active, 2 = Stopped, 3 = Failed, 4 = Unknown.
sybaseAddress	String	Each entry in the address string is separated by the # character. Each server address includes: Protocol: TCP, NAMEPIPE, DECNET (entry is case sensitive). The value of the sybaseStatus. Address: any valid address for the protocol type. The dscp utility splits this attribute into Transport type and Transport address.
sybaseSecurity (optional)	String	Security OID (object ID).
sybaseRetryCount	Integer	This attribute is mapped to CS_RETRY_COUNT, which specifies the number of times that ct_connect retries the sequence of network addresses associated with a server name.
sybaseRetryDelay	Integer	This attribute is mapped to CS_LOOP_DELAY, which specifies the delay, in seconds, that ct_connect waits before retrying the entire sequence of addresses.
sybaseHAservername (optional)	String	A secondary server for failover protection.

Sybase provides LDAP directory schema in $SYBASE/$SYBASE_OCS/config directory for the following LDAP services:

sybase.schema - it contains the directory schema to be used with OpenLDAP servers.
sybase-schema.conf - it contains the same schema but in a Netscape-specific syntax.
sybase.ldf - it contains directory schema in Unicode format for a Microsoft Active Directory.

In the previous example, the entity describes an Adaptive Server named “foobar” listening on a TCP connection with a port number of 5000. This entity also specifies a retry count of 12 (times) and a retry delay of 30 (seconds). sybaseRetryCount and sybaseRetryDelay map to CS_RETRY_COUNT and CS_LOOP_DELAY, respectively. When Client-Library finds an address where a server responds, the login dialog between Client-Library and the server begins. If the login attempt fails.Client-Library does not retry any other addresses.

The most important entity is the address attribute, which contains the information for setting up a connection to the server and for how the server listens for incoming connections. For entries to be usable by different Sybase products on different platforms, the protocol field and the address field in an “Address Attribute” (for example, “TCP” and “foobar 5000”) should be in a platform- and product-independent form.

Because LDAP supports multiple entries for each attribute, each address attribute must contain the address of a single server, including protocol, access type, and address. See sybaseAddress in Table 5-2.