Issue #124 has been updated by Jonathan Clarke.
Category changed from Core to Documentation
Status changed from New to Feedback
J?r?me Schell wrote:
> I resolved my problem for now by renaming the key attribute in the database
> table to "uid" instead of "logname".
> This way it all seems to work ok.
>
> My primary interrogation is still valid. What is the good configuration to
> have the clean and sync phase working when the keys have different name in
> database and LDAP?
Hi J?r?me,
You are right about the problem here - the name of the pivot is different in
sync and clean modes: you use _logname_ to sync, and _uid_ to clean. So when
iBatis runs your _getInetOrgPerson_ request, it only has a parameter _uid_, but
doesn't use it.
The simplest solution is to change your SQL requests to use the "SELECT <DB
pivot> *AS* <LDAP pivot>". For example, here, you would change
_getInetOrgPersonList_ to "Select logname AS uid ...", and _getInetOrgPerson_
to "Select ... WHERE logname = #uid#". And of course remove _uid_ from the
resultMap. And, you should then change lsc.tasks.mytask.dstService.filterId to
use {uid} instead of {logname}. Please let us know how it goes.
This is bug #35 (see the discussion there). As a general rule, I try to map all
information to LDAP attribute names as soon as possible (in the SQL requests).
I think the documentation doesn't reflect this clearly (or at all). Any
volunteers to update the wiki?
Jonathan
----------------------------------------
Bug #124: Clean phase of db2ldap deletes all entities
http://tools.lsc-project.org/issues/show/124
Author: J?r?me Schell
Status: Feedback
Priority: High
Assigned to:
Category: Documentation
Target version:
During the clean phase of a db2ldap job, all entities in the destination are
deleted.
After tracking the problem a bit, it seems that the method clean2Ldap of
org.lsc.AbstractSynchronize loops on all destination entries and calls the
getObject method of org.lsc.service.AbstractJdbcService passing it the id of
the entry (to look for it in the source).
The problem is that the format of the id is the DN of the LDAP entry
(uid=john.do,dc=mydomain,dc=com) and in the case of a JDBC source, that value
is irrelevant.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://tools.lsc-project.org/my/account
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.lsc-project.org/pipermail/lsc-dev/attachments/20091014/f2fe7393/attachment.htm>
