Clément OUDOT <[email protected]> a écrit :
Hi,
another test today: I have an asyncLdapSourceService, and I want to
force the objectClass values on entry creation, but keep existing
values for existing entries.
So I have this dataset:
<dataset>
<name>objectclass</name>
<policy>KEEP</policy>
<createValues>
<string>"inetOrgPerson"</string>
<string>"organizationalPerson"</string>
<string>"person"</string>
<string>"top"</string>
</createValues>
</dataset>
When synchronizing, I have an error because the created objectClass
values are the values from the source entry. Of course, source entry
object classes are not compatible with destination object classes
(imagine OpenLDAP and AD synchronization)
I searched the reason: in async mode, the list of fetched attributes
is ignored, all source attributes are fetched, including the
objectclass attribute. And despite the dataset configuration of
objectclass, the source objectclass is used.
By replacing asyncLdapSourceService by ldapSourceService, it works. I
confirm that objectclass is present in destination fetched attributes
and not in source fetched attributes.
What do you think, should I open an issue?
Clément.
_______________________________________________________________
Ldap Synchronization Connector (LSC) - http://lsc-project.org
lsc-users mailing list
[email protected]
http://lists.lsc-project.org/listinfo/lsc-users
Hi,
I do think that this should be changed.
First of all, it's kind of a trap. It is not a trivial behavior. When
you specify some setting in lsc.xml you would normally expect that it
will be used.
Second, let me share another case where it cause a problem.
I synchronize a MySQL DB with a Novell eDirectory. The attribute
"userPassword" is special in eDirectory because it is "write-only".
When I run my task, LSC can't read the attribute (as if the attribute
doesn't exist at all), so it tries to create it with the value named
"userPassword" in the source DB. However, the value already exist in
eDirectory but it isn't exposed. As a result, LSC reset the password
with a initial password each time I run the task :(
As a workaround, I had to rename the attribute in the source DB to
"motDePasse", and then assign it to the "createValue" of the
"userPassword" attribute.
So in short, I think that the definition in lsc.xml should always
override any other rule/definition.
Regards
P.S.: Keep on the good work Sébastien and Clément!
_______________________________________________________________
Ldap Synchronization Connector (LSC) - http://lsc-project.org
lsc-users mailing list
[email protected]
http://lists.lsc-project.org/listinfo/lsc-users
