Wednesday Sep 02, 2009

Using DB/2 JDBC driver with DPS

The IBM DB/2 jdbc driver db2jcc.jar has a accompanying license file called db2jcc_license_cu.jar.

Both jar files must be part of the DPS java environment. If you don't, you'll get errors similars to "cannot connect to JDBC datasource .....  license is not present". To provide both jar files (driver and license), use dpconf command as follow:

$ dpconf create-jdbc-data-source -b sample -B jdbc:db2://hostname:50000/ -J file:/path/to/db2jcc_license_cu.jar -J file:/path/to/db2jcc.jar -S com.ibm.db2.jcc.DB2Driver db2-source

Corresponding LDIF entry in the proxy configuration file looks like that:

dn: cn=db2-source,cn=data sources,cn=config
dbUrl: jdbc:db2://hostname.domain:50000/
objectClass: top
objectClass: configEntry
objectClass: dataSource
objectClass: jdbcDataSource
driverClass: com.ibm.db2.jcc.DB2Driver
jarUrl: file:/usr/ds/sberthol/db2/etc/db2jcc.jar
jarUrl: file:/usr/ds/sberthol/db2/etc/db2jcc_license_cu.jar
dbName: sample
cn: db2-source
enabled: true
dbPassword: {3DES}3r1CipqhECC5E4JOLE8geyV3G9e9+QIq
dbUser: db2inst1

Monday May 25, 2009

How to change DPS log location

By default, DPS access and error logs are stored in <instance_dir>/logs.  Default setting can be changed using the commands below:


$ dpconf get-access-log-prop log-file-name
log-file-name  :  logs/access

$ dpconf get-error-log-prop log-file-name
log-file-name  :  logs/error 

$ dpconf set-access-log-prop log-file-name:/a/path/to/a/new/location/access

$ dpconf set-error-log-prop log-file-name:/a/path/to/a/new/location/error


Tuesday May 05, 2009

etime granularity in access logs

Unlike DS, DPS 6.3 etimes in the access log are in millisecs.

For sake of performance, DPS uses a timeThread that gets the time regularly (every 500ms only in DPS 6.3)  instead of performing a system call each time the current time is needed so etimes shown in access logs may be biased to a large extend and show 0ms when the effective etime is < 500ms. Conversaly , etimes may show a value of 500ms when the effective time is smaller.

TimeThread -----T1-----T2-----T3-----T4----T5    with (Ti- T()i-1)) = 500ms
DPS time retrieval example 1 |   |   => real value = 5ms, computed value is T2-T2 = 0
DPS time retrieval example 2    |       |   => real value = 15ms, computed value is T3-T2 = 500ms

The time "granularity" can be changed to accommodate with your needs in DPS 7.0 (available soon) but you can get a fix earlier (RFE 6601029) by contacting the Sun support team.


Monday May 04, 2009

Directory Master Event 09 in New Jersey

Last week, I attended the Sun Directory Master Conference in SomerSet, NewJersey.

I gave a presentation about the next major revision of Sun Directory Proxy Server 7.0.
It was also a unique opportunity to meet with Sun Partners and discuss Identity and Directory deployments. 

Friday Feb 27, 2009

cn=Directory Manager access through the proxy

Many DPS users reported the following problem: Bind requests as cn=Directory Manager fails when the proxy is deployed.

DPS analyses the bind dn to route the request to the data view holding the target dn. In many configuration, there is no data view candidate configured to hold the cn=directory manager suffix.

There are 2 ways to address the problem: Either create a additional data view with view base set to "cn=directory manager" or use "implicit" routing with a data view with an empty ("") view base. The latter solution is simple and also user-friendly in the sense the proxy does not need to know about the list of suffixes exposed by the directory.  Note that a "root data view" with empty dn is created by default when a DPS instance is created, but the data source pool associated with it is left empty, so if you plan to use it, don't forget to add at least one data source to that pool.



Tuesday Feb 17, 2009

DSEE 6.3.1 has been released

Sun Directory Services Enterprise Edition (DSEE) 6.3.1 has been released.
Release notes and download informations are available at http://docs.sun.com/app/docs/doc/820-5817

Monday Jan 26, 2009

Forum about LDAP, Sun Directory, Proxy Server and Virtual Directory

If you have some questions about Sun Directory Server Edition, Directory Proxy and Virtual Directory or you want to share best practices, don't hesitate to use the Sun Developer Forum dedicated to these products.

See you there!

Friday Jan 23, 2009

Fail-over based on the directory server operational state

DPS 6.x load-balancing / fail-over can be configured to stop sending traffic to a specific directory server instance in maintenance, even when that instance is up and running. For instance, you may want to remove a directory server instance from the mesh while an import or re index is in progress.

DPS 6.x periodically checks each ds server for availability by issuing (amongst others) a search request. A directory server instance is considered unreachable when that search fails or does not return any entry. By default, the search request hits the rootDSE entry. It can be configured to hit an entry in cn=config or cn=monitor to take into account the directory server operation state.

For more info, look at dpconf properties monitoring-search-filter and monitoring-entry-dn in the ldap data source object.

Wednesday Jan 21, 2009

DPS 6.3 properties that require server restart

The list of  DPS 63 config changes that require a restart is part of Admin guide.  Chapter 18: Directory Proxy Server Instances / Configuring Directory Proxy Server Instances /  Configuration Changes Requiring Server Restart http://docs.sun.com/app/docs/doc/820-2763/gbong?l=en&a=view

This list will be greatly reduced in the next release (7.0) 

Friday Dec 19, 2008

DIT changes with dn virtual transformations

Here is a summary of a common deployment scenario with Sun Directory Proxy Server:

LDAP entries are grouped by location in the DIT, e.g user entries are located under ou=north,ou=people,dc=company, dc=com or  ou=south,ou=people,dc=company, dc=com or ou=east,ou=people,dc=company, dc=com or ou=west,ou=people,dc=company, dc=com based on user physical location.

Later, for sake of simplicity, the DIT is flatten so that every user entry is stored immediatly under ou=people, dc=company, dc=com

New applications are aware of the DIT structure change but DPS is used so that legacy applications expecting the location container node can operate w/o problem.

The dn mapping needed can be achieved by using virtual data transformations as described  in http://docs.sun.com/app/docs/doc/820-2765/virtual_transformations?a=view

Let's assume that
- you have a data view DV1 with viewBase (suffix) set to dc=company,dc=com.
- entry location (north, east,...) is always available in each entry in attribute 'location'
- entry uid=\*,ou=(north|south|east|west),ou=people,dc=company,dc=com mapped to uid=\*,ou=people,dc=company,dc=com

You have to create a virtual data transformation on the 'dn' for data view DV1. For inbound traffic (requests), the proxy must get rid of the ou=(north|south|east|west) node. For outbound traffic (responses), the proxy gerenates a (fake) ou=(north|south|east|west)  from the content of the 'location' attribute of each entry.

Here is the dpconf command to do that:

dpconf add-virtual-transformation -h <host> -p <port> -d <proxy manager> DV1 mapping attr-value-mapping dn internal-value:uid=\\${uid},ou=people view-value:uid=\\${uid},ou=\\${location},ou=people

Note: you might have to escape some characters (e.g $) in the command below depending on the command interpreter you are using. In the example above, I used \\$ instead of plain $.
Note2: dn patterns used in virtual transformations must not contain the data view viewBase (dc=company,dc=com in this case) as it is implicit.


Friday Nov 21, 2008

About rootDSE again

For monitoring purpose, a customer needs to get access to the rootDSE entry of each directory server behind DPS.

By default, DPS manages the rootDSE itself so that (in a virtual context) it reflects all the naming contexts and capabilities exposed by the proxy.
Here is one way to have access to the rootDSEs in question:
- the rootDSE DS content is exposed through a data view dedicated to ds monitoring. This dataview view base is choosen to not conflict with any suffix used by client applications, for instance "o=ds status". This data view is associated with a pool containing every directory server. Dn renaming is used to map o=ds status onto rootDSE ("").

Pros: it is possible to expose this data view to monitoring info only via a connection handler; monitoring traffic is not impact by regular client traffic (unless apps are aware of the special suffix!), so it is easy to get the status from N servers with N searches.
Cons: monitoring app must be changed to search for "o=ds status" instead of rootDSE and proxy configuration need to be changed.

Note: please ask Sun support for fix 6767776 if you choose the option above.

Wednesday Sep 10, 2008

RootDSE entry management with DPS 6.x

By default, the rootDSE entry is managed/returned by the directory proxy itself and reflect proxy LDAP capabilities. Such behaviour is mandatory whenever virtualization is in use so that underlying data layout is hidden from the client applications.

In some specific cases, it might be interesting to configure DPS to fetch the rootDSE entry from the directory server(s) itself. Here is the procedure:
1- Create a data view (rootDSE) with view base set to "" and associate a data source pool containing the directory servers holding the rootDSE entry to be returned.
2- Change the DPS routing policy to manual.
3- Make sure the rootDSE exclusion base property do not contain "". If so, remove that value.

At that point, requests to rootDSE are redirected to the rootDSE data view.

Notice: If multiple directory servers are associated with the rootDSE data view, make sure they have identical rootDSE entries otherwise the rootDSE entry returned to clients may vary over time because of the load-balancing policy. This is likely to confuse client applications. There might be also a mismatch between rootDSE content and proxy capabilities (e.g supported extended operations or supported LDAP controls), so make sure to change the proxy configuration (e.g list of forwarded controls) to reflect the rootDSE entry content.

Friday Jul 25, 2008

Virtual Directory Use Case: Entry aggregation from 2 sources

Let's keep track of the common virtual directory configuration below people ask me every week or so:

Use case description:
  • User entries stored in a LDAP directory server, e.g uid=sylvain, ou=people, o=sun.com
  • Additional user attributes stored in Active Directory. Corresponding entry is cn=sylvain, cn=users,dc=sun, dc=com
  • user credentials identical on both sides (same password)
  • Aggregated entries containing the merge of LDAP and AD available as uid=sylvain, ou=people, o=sun.com

Sun Directory Proxy configuration:
  • Create a LDAP data view, LDAP1, viewBase set to ou=people,o=sun.com, pointing to the LDAP data source
  • Create a LDAP data view, LDAP2, viewBase set to ou=people,o=sun.com, dataSourceBase set to cn=users,dc=sun,dc=com, pointing to the AD server
  • Create a Join data view, JOIN, viewBase set to ou=people,o=sun.com, primary view set to LDAP1, secondary data view set to LDAP2
  • Make sure to mark LDAP1 and LDAP2 as non 'routable' so that the join data view providing aggregated view only can be exposed to the proxy clients. Otherwise, a search to ou=people,o=sun.com may be routed to the 3 data views, leading to duplicate entries to be returned.

With the configuration above, the proxy automatically rewrites DNs when appropriate. However the proxy would bind as uid=sylvain,cn=users,dc=sun,dc=com when it needs to contact the AD source. The naming attribute is wrong, so a dn transformation needs to be configured on the LDAP2 data view to map dns like uid=\*,ou=people,o=sun.com to cn=\*, ou=people,o=sun.com. Mapping of the static portion of the dn is done automatically.

To create the dn transformation, use

dpconf add-virtual-transformation JOIN mapping attr-value-mapping dn view-value:uid=${uid} internal-value:cn={$uid}
(quotes may be needed depending on the command interpreter you are using)

For more details, refer to the proxy documentation.

Monday Apr 14, 2008

Sun Directory Masters Event 2008

The Sun Directory Masters Event 2008 took place in the Sun Grenoble Engineering Center on April 3-4, 2008. The goal of the Directory Masters Event is to promote the sharing of knowledge and best practices, bring together a well known global technical community, enabling sales and deployments of the Sun Java System Directory Server Enterprise Edition 6.x product.

The Directory Masters event targets three specific audiences with one unified theme of designing, implementing and managing Directory Services solutions. All target audiences were drawn from Sun and partner personnel (sales, service, and pro services).



I gave 2 presentations, one covering Sun Directory Proxy Server 6.x and a second one, more technical, on Virtual Directory capabilities of the product along with some "real" virtual use cases!

About


I am Sylvain Duloutre, I work as a Software Architect in the Oracle Directory Integration Team, the customer-facing part of Directory Services & Identity Management Product Development, working on Technical Field Enablement.

The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.

Search

Categories
Archives
« July 2015
SunMonTueWedThuFriSat
   
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
21
22
23
24
25
26
27
28
29
30
31
 
       
Today