Re: Key violation
Hi Jonas, 1) Is the entryUUID as 'Uid Attribute' by design not supposed to work in syncope ? entryUUID should work in Syncope very well. Probably, the trouble that you have is in your mapping. I mean, if you are using the default 'Uid Attribute' you have to map it as remote key by specifying entryUUID as "External attribute" and by checking "Remote key" flag for it. I've tried both to map it against userkey field as well as create a new syncope field (also) called entryUUID and map it against the ldap attribute entryUUID both only giving me violation error. Please disregard my previous mail. I must have looked at logs form an old pull task. By creating a new field and populating this with the entryUUID and use it as remote key, it does indeed work as expected. Thank you for your patience. Brgds, Jonas
Re: Key violation
On 28 June 2016 12:08:24 CEST, Jonas Israelsson wrote: > > >On 24/06/16 14:05, Francesco Chicchiriccò wrote: >> On 24/06/2016 14:00, Francesco Chicchiriccò wrote: >>> On 24/06/2016 13:58, Jonas Israelsson wrote: Running 2.0.0-M3 and have hooked up a connector to my openldap >server. >> >> First sync, no problem all users are placed in the local storage. > >> Second sync however, even though the sync is marked as successful > >> I see from the logs syncope are trying to reinsert all entrys to >> the local storage and fail due to key violation. I have set the >> matching rule to update, and use the uid as remote key, mapped to > >> the local username field. >> >> Can I create this behaviour by misconfiguration, or do we have a >> bug here ? > > It is quite common to fall into such issues when configuring an > LDAP resource; please take this (quite old, but still applying) > post of mine as reference: > > http://blog.tirasa.net/unlock-full-ldap-features-in.html > > Please let me know if that improves the situation. That blog post explains how to setup an ldap-connector, under the impression I'm beyond that point. If I miss the obvious may I >please ask you to elaborate ? I have no problem (via the connector) getting the data from my directory service. My problem is I fail to convince syncope not to add already synced users a new ones. >>> >>> The post explains how to correctly setup the connector AND the >>> resource mapping so that you can avoid the problem you have above >>> (plus some additional things, BTW). >> >> In particular, I would check the value provided for 'Uid Attribute' >in >> the connector configuration - which is safe to set to 'cn' when >> managing both users and groups. >> Please check all other parameters as well. >While I have got this somewhat working, it does not work as I'd like it > >to. The problem (with key violation) occurs when leaving 'Uid >Attribute' >to it's default value entryUUID. Not sure I have fully understood the >meaning of the 'Uid Attribute' but if it's meant to create a local >unique identifier mapped to the remote entry, the entryUUID would in my > >humble opinion be the best candidate. By the way, if 'Uid Attribute' is > >meant to be used for this correlation, of what usage is then the remote > >key on the field mapping ? > >When not using entryUUID I'm not quite sure how syncope should be >configured to be compatible with a directory service layout using >different rdn such as uid for users and cn for groups. I though I could > >work around this by creating two resources with different 'uid >attribute'. However with this approach I found no way on how to >populate >the groups with members. > >So to sum things up. > >1) Is the entryUUID as 'Uid Attribute' by design not supposed to work >in >syncope ? >2) If so, is there a way to join data from different resources (user >from one with groups from another) I believe a bit if theory about how ConnId works and how Syncope relies on it may help, and it would also be useful to me to write it down, as part of the ongoing effort to produce the reference guide. I should be able to reply properly in the coming days, please stay tuned. Regards. -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ Involved at The Apache Software Foundation: member, Syncope PMC chair, Cocoon PMC, Olingo PMC, CXF Committer, OpenJPA Committer http://home.apache.org/~ilgrosso/
Re: Key violation
Il 28/06/2016 12:08, Jonas Israelsson ha scritto: On 24/06/16 14:05, Francesco Chicchiriccò wrote: On 24/06/2016 14:00, Francesco Chicchiriccò wrote: On 24/06/2016 13:58, Jonas Israelsson wrote: Running 2.0.0-M3 and have hooked up a connector to my openldap server. First sync, no problem all users are placed in the local storage. Second sync however, even though the sync is marked as successful I see from the logs syncope are trying to reinsert all entrys to the local storage and fail due to key violation. I have set the matching rule to update, and use the uid as remote key, mapped to the local username field. Can I create this behaviour by misconfiguration, or do we have a bug here ? It is quite common to fall into such issues when configuring an LDAP resource; please take this (quite old, but still applying) post of mine as reference: http://blog.tirasa.net/unlock-full-ldap-features-in.html Please let me know if that improves the situation. That blog post explains how to setup an ldap-connector, under the impression I'm beyond that point. If I miss the obvious may I please ask you to elaborate ? I have no problem (via the connector) getting the data from my directory service. My problem is I fail to convince syncope not to add already synced users a new ones. The post explains how to correctly setup the connector AND the resource mapping so that you can avoid the problem you have above (plus some additional things, BTW). In particular, I would check the value provided for 'Uid Attribute' in the connector configuration - which is safe to set to 'cn' when managing both users and groups. Please check all other parameters as well. While I have got this somewhat working, it does not work as I'd like it to. The problem (with key violation) occurs when leaving 'Uid Attribute' to it's default value entryUUID. Not sure I have fully understood the meaning of the 'Uid Attribute' but if it's meant to create a local unique identifier mapped to the remote entry, the entryUUID would in my humble opinion be the best candidate. By the way, if 'Uid Attribute' is meant to be used for this correlation, of what usage is then the remote key on the field mapping ? When not using entryUUID I'm not quite sure how syncope should be configured to be compatible with a directory service layout using different rdn such as uid for users and cn for groups. I though I could work around this by creating two resources with different 'uid attribute'. However with this approach I found no way on how to populate the groups with members. So to sum things up. Hi Jonas, 1) Is the entryUUID as 'Uid Attribute' by design not supposed to work in syncope ? entryUUID should work in Syncope very well. Probably, the trouble that you have is in your mapping. I mean, if you are using the default 'Uid Attribute' you have to map it as remote key by specifying entryUUID as "External attribute" and by checking "Remote key" flag for it. 2) If so, is there a way to join data from different resources (user from one with groups from another) ? Yes, you can but you have to provide an ad-hoc synchronization action class. I'm quite sure you cannot use the once provided by default as is. Best regards, F. -- Fabio Martelli https://it.linkedin.com/pub/fabio-martelli/1/974/a44 http://blog.tirasa.net/author/fabio/index.html Tirasa - Open Source Excellence http://www.tirasa.net/ Apache Syncope PMC http://people.apache.org/~fmartelli/
Re: Key violation
On 24/06/16 14:05, Francesco Chicchiriccò wrote: On 24/06/2016 14:00, Francesco Chicchiriccò wrote: On 24/06/2016 13:58, Jonas Israelsson wrote: Running 2.0.0-M3 and have hooked up a connector to my openldap server. First sync, no problem all users are placed in the local storage. Second sync however, even though the sync is marked as successful I see from the logs syncope are trying to reinsert all entrys to the local storage and fail due to key violation. I have set the matching rule to update, and use the uid as remote key, mapped to the local username field. Can I create this behaviour by misconfiguration, or do we have a bug here ? It is quite common to fall into such issues when configuring an LDAP resource; please take this (quite old, but still applying) post of mine as reference: http://blog.tirasa.net/unlock-full-ldap-features-in.html Please let me know if that improves the situation. That blog post explains how to setup an ldap-connector, under the impression I'm beyond that point. If I miss the obvious may I please ask you to elaborate ? I have no problem (via the connector) getting the data from my directory service. My problem is I fail to convince syncope not to add already synced users a new ones. The post explains how to correctly setup the connector AND the resource mapping so that you can avoid the problem you have above (plus some additional things, BTW). In particular, I would check the value provided for 'Uid Attribute' in the connector configuration - which is safe to set to 'cn' when managing both users and groups. Please check all other parameters as well. While I have got this somewhat working, it does not work as I'd like it to. The problem (with key violation) occurs when leaving 'Uid Attribute' to it's default value entryUUID. Not sure I have fully understood the meaning of the 'Uid Attribute' but if it's meant to create a local unique identifier mapped to the remote entry, the entryUUID would in my humble opinion be the best candidate. By the way, if 'Uid Attribute' is meant to be used for this correlation, of what usage is then the remote key on the field mapping ? When not using entryUUID I'm not quite sure how syncope should be configured to be compatible with a directory service layout using different rdn such as uid for users and cn for groups. I though I could work around this by creating two resources with different 'uid attribute'. However with this approach I found no way on how to populate the groups with members. So to sum things up. 1) Is the entryUUID as 'Uid Attribute' by design not supposed to work in syncope ? 2) If so, is there a way to join data from different resources (user from one with groups from another) ? TIA rgds, Jonas
Re: Key violation
On 24/06/2016 14:00, Francesco Chicchiriccò wrote: On 24/06/2016 13:58, Jonas Israelsson wrote: Running 2.0.0-M3 and have hooked up a connector to my openldap server. First sync, no problem all users are placed in the local storage. Second sync however, even though the sync is marked as successful I see from the logs syncope are trying to reinsert all entrys to the local storage and fail due to key violation. I have set the matching rule to update, and use the uid as remote key, mapped to the local username field. Can I create this behaviour by misconfiguration, or do we have a bug here ? It is quite common to fall into such issues when configuring an LDAP resource; please take this (quite old, but still applying) post of mine as reference: http://blog.tirasa.net/unlock-full-ldap-features-in.html Please let me know if that improves the situation. That blog post explains how to setup an ldap-connector, under the impression I'm beyond that point. If I miss the obvious may I please ask you to elaborate ? I have no problem (via the connector) getting the data from my directory service. My problem is I fail to convince syncope not to add already synced users a new ones. The post explains how to correctly setup the connector AND the resource mapping so that you can avoid the problem you have above (plus some additional things, BTW). In particular, I would check the value provided for 'Uid Attribute' in the connector configuration - which is safe to set to 'cn' when managing both users and groups. Please check all other parameters as well. Regards. -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ Involved at The Apache Software Foundation: member, Syncope PMC chair, Cocoon PMC, Olingo PMC, CXF Committer, OpenJPA Committer, PonyMail PPMC http://home.apache.org/~ilgrosso/
Re: Key violation
On 24/06/2016 13:58, Jonas Israelsson wrote: Running 2.0.0-M3 and have hooked up a connector to my openldap server. First sync, no problem all users are placed in the local storage. Second sync however, even though the sync is marked as successful I see from the logs syncope are trying to reinsert all entrys to the local storage and fail due to key violation. I have set the matching rule to update, and use the uid as remote key, mapped to the local username field. Can I create this behaviour by misconfiguration, or do we have a bug here ? It is quite common to fall into such issues when configuring an LDAP resource; please take this (quite old, but still applying) post of mine as reference: http://blog.tirasa.net/unlock-full-ldap-features-in.html Please let me know if that improves the situation. That blog post explains how to setup an ldap-connector, under the impression I'm beyond that point. If I miss the obvious may I please ask you to elaborate ? I have no problem (via the connector) getting the data from my directory service. My problem is I fail to convince syncope not to add already synced users a new ones. The post explains how to correctly setup the connector AND the resource mapping so that you can avoid the problem you have above (plus some additional things, BTW). Regards. -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ Involved at The Apache Software Foundation: member, Syncope PMC chair, Cocoon PMC, Olingo PMC, CXF Committer, OpenJPA Committer, PonyMail PPMC http://home.apache.org/~ilgrosso/
Re: Key violation
Running 2.0.0-M3 and have hooked up a connector to my openldap server. First sync, no problem all users are placed in the local storage. Second sync however, even though the sync is marked as successful I see from the logs syncope are trying to reinsert all entrys to the local storage and fail due to key violation. I have set the matching rule to update, and use the uid as remote key, mapped to the local username field. Can I create this behaviour by misconfiguration, or do we have a bug here ? It is quite common to fall into such issues when configuring an LDAP resource; please take this (quite old, but still applying) post of mine as reference: http://blog.tirasa.net/unlock-full-ldap-features-in.html Please let me know if that improves the situation. That blog post explains how to setup an ldap-connector, under the impression I'm beyond that point. If I miss the obvious may I please ask you to elaborate ? I have no problem (via the connector) getting the data from my directory service. My problem is I fail to convince syncope not to add already synced users a new ones. TIA Brgds, Jonas
Re: Key violation
On 2016-06-22 23:55 Jonas Israelsson wrote: Greetings. Quite new to syncope but I'm seeing some rather strange behaviour, and could use some guidance. Glad of your interest in Apache Syncope! Running 2.0.0-M3 and have hooked up a connector to my openldap server. First sync, no problem all users are placed in the local storage. Second sync however, even though the sync is marked as successful I see from the logs syncope are trying to reinsert all entrys to the local storage and fail due to key violation. I have set the matching rule to update, and use the uid as remote key, mapped to the local username field. Can I create this behaviour by misconfiguration, or do we have a bug here ? It is quite common to fall into such issues when configuring an LDAP resource; please take this (quite old, but still applying) post of mine as reference: http://blog.tirasa.net/unlock-full-ldap-features-in.html Please let me know if that improves the situation. HTH Regards. -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ Involved at The Apache Software Foundation: member, Syncope PMC chair, Cocoon PMC, Olingo PMC, CXF Committer, OpenJPA Committer, PonyMail PPMC http://home.apache.org/~ilgrosso/
