LDAP directory services are a convenient alternative to the typical Sybase sql.ini file, which stores server information in a “flat” file. As a result, any changes to server information in the sql.ini file need to be updated on each machine (client and server) in the enterprise.
With LDAP directory services, the integration of user, resource, and security information in a centralized repository makes administration of resource information much easier. In addition, LDAP services provide:
A single, hierarchical view of information, such as users, software, resources, networks, files
A single sign-on for servers and distributed enterprise applications
User login and role information for access control to sensitive data
User roles can be assigned to a single individual, such as the system administrator, or to large groups of users, such as accounting department personnel. Roles determine what information and servers users can access, and what, if any, read and write permission they possess. Multiple users with the same user role can be multiplexed to a few server connections, saving resources and increasing scalability.
Table 5-1 highlights the differences between the Sybase sql.ini file and LDAP server:
The sql.ini 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 sql.ini file specifying a TCP connection and a failover machine looks like this:
[MONEY]
master=TCP, huey, 5000
query=TCP, huey, 5000
hafailover=PERSONEL
[PERSONEL]
master=TCP, huey, 5000
query=TCP, huey, 5000
hafailover=MONEY
An example of an LDAP entry with TCP and a failover machine looks like this:
dn: sybaseServername=foobar, dc=sybase,dc=com objectClass: sybaseServer sybaseVersion: 15501 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.
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:
|
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%\ini for the following LDAP services:
sybase.schema - it contains the directory schema to be used with OpenLDAP servers.
sybase-schema.conf - it contains the directory 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 begins between Client-Library and the server. Client-Library does not retry any other addresses if the login attempt fails.
The most important entity is the address attribute, which contains the information for how to set up a connection to the server and 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.
Since 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.
The following example is an LDAP entry for a Microsoft Windows server listening on two addresses, with different connection protocols:
sybaseAddress = TCP#1#TOEJAM 4444
sybaseAddress = NAMEPIPE#1#\pipe\sybase\query
Each entry in the address field is separated by the # character. Table 5-2 defines the values for each field in the address attribute.