On 2018/04/03 10:14:57, Francesco Chicchiriccò <[email protected]> wrote: > Hi Adam, > > On 02/04/2018 20:22, Adam Levine wrote: > > Francesco: > > > > thank you for your response and guidance. > > > > My mapping is identical to the demo site. > > > > So, thanks to your email, I've found a few things and made some > > changes. > > > > 1: The pull task was firing repeatedly because I'd placed a timer > > on it without realizing. > > Clear. > > > 2: There was no pull policy defined. > > I created one: > > Conflict Resolution: Ignore > > Group: rule type of plain attributes, and I > > selected "name". > > > > I ran a pull cycle, and the error was no longer there. > > But, I'm not sure if the error has been resolved because of the > > resolution strategy I chose, or because it's able to match on the > > name. I looked at the default correlation, and it appears it's doing > > the same attribute matching, which makes me think my problem was > > resolved by choosing "ignore". I changed the strategy to first match, > > and again, no errors on pull. > > Conflict resolution comes into place when more than an internal match is > found: I don't think this was your case. > > Adding a matching rule based on Group name was the good move. > > > If I'm understanding this correctly, without an explicit pull policy > > in place, the default is to create, rather than update. And using > > first or last match, uses the first/last in LDAP as the source of > > changes to update internal DB. But, I'm not sure how "all" is then used. > > When no pull policy is in place, Syncope attempts anyway to perform some > matching based on the row in the mapping which is flagged as "Remote > Key": it seems that, in your configuration, this kind of match is not > working, and the pull policy matching rule solved the issue.
Update: I have found that the LDAP connector configuration in the demo site (which is also the same configuration used by integration tests and delivered with the standalone distribution), reports, under "Uid Attribute for groups" the value "entryUUID": if you replace this with "cn", then the Pull Policy rule mentioned below is not necessary. Hope this clarifies. Regards. > > On Mon, Apr 2, 2018 at 11:50 AM, Francesco Chicchiriccò > > <[email protected] <mailto:[email protected]>> wrote: > > > > Hi Adam, > > shortly: there is a problem in your LDAP mapping. > > > > The errors reported below are consequence of a Pull Task's > > execution, where Syncope attempts to *create* Groups (according to > > the provided Mapping for the External Resource for which the Pull > > Task is executed), while it should instead *update* Groups. > > > > Why does it fail, then? It fails because the matching process [1] > > is not able to correctly identify the Group in Syncope which > > should match the given Group on LDAP. > > > > Could you please report your LDAP Group mapping? > > > > Regards. > > > > [1] > > https://syncope.apache.org/docs/reference-guide.html#provisioning-pull > > <https://syncope.apache.org/docs/reference-guide.html#provisioning-pull> > > > > > > > > On 02/04/2018 11:30, Adam Levine wrote: > >> I'm coming up to speed with Syncope, so this could be a newbie > >> mistake, and I'm not sure how to fully trace/debug what's > >> happening. Please let me know what extra relevant information I > >> can provide. > >> > >> > >> v208 > >> Maven > >> MariaDB 10.2.11 > >> ApacheDS 2.0.0-M24 > >> > >> I have the LDAP connector wired up, and a singular instance for > >> managing users and groups; this is the only external resource I have. > >> > >> I can create groups and users with no problem. > >> > >> If I connect them to the LDAP resource, they populate in DS. I > >> can edit values, and they are propagated to DS. > >> > >> However, the core.log fills up with repeated errors about a > >> duplicate entry. If I don't connect the user/group to LDAP, > >> there are no errors in the log. If I disconnect the user/group > >> from LDAP, the log entries stop. > >> > >> This happens even on the first entry, so there's no chance > >> there's actually a pre-existing entry. > >> > >> Thank you in advance for your assistance. > >> > >> > >> Log Snippets: > >> > >> 03:20:02.358 ERROR > >> org.apache.syncope.core.provisioning.api.pushpull.SyncopeResultHandler > >> - Could not create GROUP 72221ad0-d819-42f3-a0bb-1d21162866b1 > >> org.apache.openjpa.persistence.PersistenceException: The > >> transaction has been rolled back. See the nested exceptions for > >> details on the errors that occurred. > >> at > >> > >> org.apache.openjpa.kernel.BrokerImpl.newFlushException(BrokerImpl.java:2368) > >> ~[openjpa-kernel-2.4.2.jar:2.4.2] > >> at > >> org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:2205) > >> ~[openjpa-kernel-2.4.2.jar:2.4.2] > >> ..... > >> > >> Caused by: org.apache.openjpa.persistence.EntityExistsException: > >> (conn=1464) Duplicate entry 'abvc' for key 'U_SYNCGRP_NAME' > >> {prepstmnt 1442070129 INSERT INTO SyncopeGroup (id, creationDate, > >> creator, lastChangeDate, lastModifier, status, workflowId, name, > >> REALM_ID, GROUPOWNER_ID, USEROWNER_ID) VALUES (?, ?, ?, ?, ?, ?, > >> ?, ?, ?, ?, ?)} [code=1062, state=23000] > >> at > >> org.apache.openjpa.jdbc.sql.DBDictionary.narrow(DBDictionary.java:4988) > >> ~[openjpa-jdbc-2.4.2.jar:2.4.2] > >> at > >> > >> org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:4963) > >> ~[openjpa-jdbc-2.4.2.jar:2.4.2] > >> at > >> > >> org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:133) > >> ~[openjpa-jdbc-2.4.2.jar:2.4.2] > >> at > >> > >> org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:75) > >> ~[openjpa-jdbc-2.4.2.jar:2.4.2] > >> > >> .... > >> > >> Caused by: org.apache.openjpa.lib.jdbc.ReportingSQLException: > >> (conn=1464) Duplicate entry 'abvc' for key 'U_SYNCGRP_NAME' > >> {prepstmnt 1442070129 INSERT INTO SyncopeGroup (id, creationDate, > >> creator, lastChangeDate, lastModifier, status, workflowId, name, > >> REALM_ID, GROUPOWNER_ID, USEROWNER_ID) VALUES (?, ?, ?, ?, ?, ?, > >> ?, ?, ?, ?, ?) } [code=1062, state=23000] > >> at > >> > >> org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.wrap(LoggingConnectionDecorator.java:218) > >> ~[openjpa-lib-2.4.2.jar:2.4.2] > >> at > >> > >> org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.wrap(LoggingConnectionDecorator.java:194) > >> ~[openjpa-lib-2.4.2.jar:2.4.2] > >> at > >> > >> org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.access$1000(LoggingConnectionDecorator.java:58) > >> ~[openjpa-lib-2.4.2.jar:2.4.2] > >> at > >> > >> org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator$LoggingConnection$LoggingPreparedStatement.executeUpdate(LoggingConnectionDecorator.java:1133) > >> ~[openjpa-lib-2.4.2.jar:2.4.2] > >> at > >> > >> org.apache.openjpa.lib.jdbc.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:275) > >> ~[openjpa-lib-2.4.2.jar:2.4.2] > > > -- > Francesco Chicchiriccò > > Tirasa - Open Source Excellence > http://www.tirasa.net/ > > Member at The Apache Software Foundation > Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail > http://home.apache.org/~ilgrosso/ > >
