I set up LDAP data collector at first with the following configuration:
<user_defaults>
<profile>Portal user</profile>
</user_defaults>
<json_placeholders>
<profile_list_update_policy>write_if_empty</profile_list_update_policy>
</json_placeholders>
All users were created with "portal user" profile as expected.
Later I changed the collecor's configuration to:
<synchronize_profiles>yes</synchronize_profiles>
<itop_group_pattern>/^CN=GRP_iTop-([^,]*)/</itop_group_pattern>
<json_placeholders>
<profile_list_update_policy>master_locked</profile_list_update_policy>
</json_placeholders>
In the collector's csv file, in the database and in public data section of the replica I can see that profiles are recognized correctly:
profileid->name:Change Approver|profileid->name:Administrator
In the iTop data source's deletion policies I changed allowed persons to delete from nobody to administrators and deleted a user for testing. It was recreated by the collector with the desired profile list. It just won't update the existing users. They remain with "portal user" profile.
The collector runs every 15 minutes and full reload interval is set to 1 day. Setting the reload interval up to 3 years or down to 5 minutes didn't help.
Can anybody give any advice to troubleshoot or force synchronization?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Do you mean iTopUserLDAPCollector.json? I didn’t modify it because "update_policy" refers to the placeholder "$profile_list_update_policy$" in the params[….].xml file. I only modified these xml files and the collector updated the synchronization data source definition in iTop.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Meanwhile I’m pretty sure what caused the problem. At first I added
<synchronize_profiles>yes</synchronize_profiles>
<itop_group_pattern>/^CN=GRP_iTop-([^,]*)/</itop_group_pattern>
to the params xml file. Then crontab called the collector and user’s profiles where written to "synchro_data_myprefixldap_users" table but not updated in iTop because profile_list_update_policy was still write_if_empty. I wondered why it didn’t update profiles in iTop and I changed profile_list_update_policy to master_locked. At the next runs of the collector, synchro_data_myprefixldap_users table was already up to date and no modification could be detected to trigger the profile update in iTop. I artificially did a random modification to all rows of "synchro_data_myprefixldap_users" table and and all profiles were updated in itop. I would not recommend to do this and I’d be happy to hear about a more proper way to force a full synchronization:
update synchro_data_myprefixldap_users set language="abc";
update synchro_data_myprefixldap_users set language="the value it was before";
I think the way things happened unveils a little pitfall.
Last edit: eric24V 2023-04-27
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I set up LDAP data collector at first with the following configuration:
<user_defaults>
<profile>Portal user</profile>
</user_defaults>
<json_placeholders>
<profile_list_update_policy>write_if_empty</profile_list_update_policy>
</json_placeholders>
All users were created with "portal user" profile as expected.
Later I changed the collecor's configuration to:
<synchronize_profiles>yes</synchronize_profiles>
<itop_group_pattern>/^CN=GRP_iTop-([^,]*)/</itop_group_pattern>
<json_placeholders>
<profile_list_update_policy>master_locked</profile_list_update_policy>
</json_placeholders>
In the collector's csv file, in the database and in public data section of the replica I can see that profiles are recognized correctly:
profileid->name:Change Approver|profileid->name:Administrator
In the iTop data source's deletion policies I changed allowed persons to delete from nobody to administrators and deleted a user for testing. It was recreated by the collector with the desired profile list. It just won't update the existing users. They remain with "portal user" profile.
The collector runs every 15 minutes and full reload interval is set to 1 day. Setting the reload interval up to 3 years or down to 5 minutes didn't help.
Can anybody give any advice to troubleshoot or force synchronization?
Hello,
Did you update the datasource JSON file according to the modifications you made in the datasource in iTop ?
Do you mean iTopUserLDAPCollector.json? I didn’t modify it because "update_policy" refers to the placeholder "$profile_list_update_policy$" in the params[….].xml file. I only modified these xml files and the collector updated the synchronization data source definition in iTop.
Yes : the JSON file is used by the collector to update the datasynchro, so if your datasynchro isn't aligned it will be reset to the JSON values...
Meanwhile I’m pretty sure what caused the problem. At first I added
<synchronize_profiles>yes</synchronize_profiles>
<itop_group_pattern>/^CN=GRP_iTop-([^,]*)/</itop_group_pattern>
to the params xml file. Then crontab called the collector and user’s profiles where written to "synchro_data_myprefixldap_users" table but not updated in iTop because profile_list_update_policy was still write_if_empty. I wondered why it didn’t update profiles in iTop and I changed profile_list_update_policy to master_locked. At the next runs of the collector, synchro_data_myprefixldap_users table was already up to date and no modification could be detected to trigger the profile update in iTop. I artificially did a random modification to all rows of "synchro_data_myprefixldap_users" table and and all profiles were updated in itop. I would not recommend to do this and I’d be happy to hear about a more proper way to force a full synchronization:
update synchro_data_myprefixldap_users set language="abc";
update synchro_data_myprefixldap_users set language="the value it was before";
I think the way things happened unveils a little pitfall.
Last edit: eric24V 2023-04-27