I see that renaming Realms isn't forbidding in console, so keeping track of the o's via entryUUID and renaming Realms should be possible if only I knew how to configure that? As soon as I replace 'Account Uid' with entryUUID in resource the second pull allways results in inserts, failing unique naming constraints, instead of updates.
Another question: our groups have quite awkward names, e.g. "CO:members:all". While pull'ing I get the following error: Groups failed to create: CREATE FAILURE (key/name): null/CO:members:all with message: InvalidEntityException: JPAGroup [InvalidName, InvalidPlainAttr] CREATE FAILURE (key/name): null/CO:members:all with message: InvalidEntityException: JPAGroup [InvalidName, InvalidPlainAttr] Is it the colon in the groupname? And if so, is there a simple JEXL expression to replace them with a valid separation character? Best regards, Martin On Mon, May 7, 2018 at 4:50 PM Martin van Es <mrva...@gmail.com> wrote: > The only minor remaining problem: 'o' moves are not detected, because > there's no way I can find a way to link the realm to the source's entryUUID? > The result is there is a stale oldname realm left, and a new newname realm > created. > On Mon, May 7, 2018 at 4:25 PM Martin van Es <mrva...@gmail.com> wrote: > > Fixed it. Setting 'Uid Attribute' = 'o', did the trick! > > Thx! > > Best regards, > > Martin > > On Mon, May 7, 2018 at 3:45 PM Martin van Es <mrva...@gmail.com> wrote: > > > Thx for the answer. > > > I inspected the resource-ldap-orgunit and discoverd the omission of the > > > fullpath mapping for realms, which is mapped to LDAP l attribute. I've > > > added an l attribute to my organisations and mapped that to fullpath, > but > > > then the persistence class complains about a malformed realm path: > > > org.apache.syncope.core.persistence.api.dao.MalformedPathException: The > > > provided realm path is malformed: Foobar > > > What would the correct syntax of realm path look like? I don't see any > > JEXL > > > transformations for both fullpath or name in the resource-ldap-orgunit > > > example? > > > Some testing reveals the above Foobar is extracted from the o= > attribute, > > > which I mapped to 'name', which very much resembles the mapping of ou to > > > name in the resource-ldap-orgunit example. > > > What's wrong with that as a path? > > > Here's the complete logging from my test setup: > > > 13:36:46.230 DEBUG Enter: search(ObjectClass: __ACCOUNT__, null, > > > org.apache.syncope.core.provisioning.java.ConnectorFacadeProxy$2@aabea88 > , > > > OperationOptions: {PAGED_RESULTS_OFFSET:-1,ATTRS_TO_GET:[__NAME__,__UID__,l,__ENABLE__,o],PAGE_SIZE:100}) > > > Method: search > > > 13:36:46.232 DEBUG Enter: executeQuery(ObjectClass: __ACCOUNT__, null, org.identityconnectors.framework.impl.api.local.operations.SearchImpl$1@5ba5c871 > > , > > > OperationOptions: {PAGED_RESULTS_OFFSET:-1,ATTRS_TO_GET:[__NAME__,__UID__,l,__ENABLE__,o],PAGE_SIZE:100}) > > > Method: executeQuery > > > 13:36:46.232 WARN Attribute __ENABLE__ of object class __ACCOUNT__ is > not > > > mapped to an LDAP attribute Method: getLdapAttribute > > > 13:36:46.233 DEBUG Searching in [dc=scz,dc=vnet] with filter > > > (&(objectClass=organization)(!(objectClass=dcObject))) and > SearchControls: > > > {returningAttributes=[l, o], scope=SUBTREE} Method: doSearch > > > 13:36:46.240 WARN Attribute __ENABLE__ of object class __ACCOUNT__ is > not > > > mapped to an LDAP attribute Method: getLdapAttribute > > > 13:36:46.240 DEBUG Enter: {Uid=Attribute: {Name=__UID__, > Value=[Foobarb]}, > > > ObjectClass=ObjectClass: __ACCOUNT__, Attributes=[Attribute: > > > {Name=__NAME__, Value=[o=Foobarb,dc=scz,dc=vnet]}, Attribute: > > > {Name=__UID__, Value=[Foobarb]}, Attribute: {Name=l, Value=[/Foobara]}, > > > Attribute: {Name=__ENABLE__, Value= > > > []}, Attribute: {Name=o, Value=[Foobarb]}], Name=Attribute: > > {Name=__NAME__, > > > Value=[o=Foobarb,dc=scz,dc=vnet]}} Method: handle > > > 13:36:46.240 DEBUG Return: true Method: handle > > > 13:36:46.240 DEBUG Enter: {Uid=Attribute: {Name=__UID__, > Value=[Foobarb]}, > > > ObjectClass=ObjectClass: __ACCOUNT__, Attributes=[Attribute: > > > {Name=__NAME__, Value=[o=Foobarb,dc=scz,dc=vnet]}, Attribute: > > > {Name=__UID__, Value=[Foobarb]}, Attribute: {Name=l, Value=[/Foobara]}, > > > Attribute: {Name=__ENABLE__, Value= > > > []}, Attribute: {Name=o, Value=[Foobarb]}], Name=Attribute: > > {Name=__NAME__, > > > Value=[o=Foobarb,dc=scz,dc=vnet]}} Method: handle > > > 13:36:46.240 WARN Attribute __ENABLE__ of object class __ACCOUNT__ is > not > > > mapped to an LDAP attribute Method: getLdapAttribute > > > 13:36:46.240 DEBUG Enter: {Uid=Attribute: {Name=__UID__, > Value=[Foobar2]}, > > > ObjectClass=ObjectClass: __ACCOUNT__, Attributes=[Attribute: > > > {Name=__NAME__, Value=[o=Foobar2,dc=scz,dc=vnet]}, Attribute: > > > {Name=__UID__, Value=[Foobar2]}, Attribute: {Name=l, Value=[/Foobar2]}, > > > Attribute: {Name=__ENABLE__, Value= > > > []}, Attribute: {Name=o, Value=[Foobar2]}], Name=Attribute: > > {Name=__NAME__, > > > Value=[o=Foobar2,dc=scz,dc=vnet]}} Method: handle > > > 13:36:46.240 DEBUG Return: true Method: handle > > > 13:36:46.241 DEBUG Exception: Method: handle > > > org.apache.syncope.core.persistence.api.dao.MalformedPathException: The > > > provided realm path is malformed: Foobarb > > > ... > > > On Mon, May 7, 2018 at 12:33 PM Francesco Chicchiriccò < > > ilgro...@apache.org> > > > wrote: > > > > Hi Martin, > > > > short answer: your Realm mapping is not correct, hence during pull > there > > > > is no way for Syncope to match the incoming data with existing Realms. > > > > You normally "fix" incomplete mappings with Pull policies, but as you > > > > already discovered, Pull policies do not apply to Realms. > > > > Hence, you have no choice but providing a good mapping for Realms. > > > > I'd suggest to take a look at how the resource-ldap-orgunit is > defined: > > > > you can check it either via > > > > http://syncope-vm.apache.org:9080/syncope-console/ or by downloading > and > > > > running the standalone distribution. > > > > Regards. > > > > On 07/05/2018 11:23, Martin van Es wrote: > > > > > Still stuck. > > > > > It would be really nice if somebody could explain how to create a > > REALM > > > > > pull policy or tell me that it's not a possibility at the moment? > > > > > > > > > > I've created a new AnyType FOO of AnyTypeClass BaseUser, which gives > > me > > > the > > > > > possibility to choose 'name' as PLAIN ATTRIBUTES Correlation Rule > > > attribute > > > > > in Pull Policy 'Realm' which I can apply to the REALM Resource that > > > pulls > > > > > in the realms, but I keep getting u_realm_name unique name > constraints > > > > > violations on all following pulls. > > > > > > > > > > Best regards, > > > > > Martin > > > > > On Thu, May 3, 2018 at 10:31 PM Martin van Es <mrva...@gmail.com> > > wrote: > > > > > > > > > >> Ok, I'm a step further but still have problems. > > > > >> I encountered the same problems when pull'ing users and it turned > > out I > > > > >> needed to create a pull policy for users and assign that to my > > resource > > > > > for > > > > >> update conflict and correlation rules (I'm still learning the > basics > > > > > here). > > > > >> Pull Update now works for users! > > > > >> It turns out, I can't find anything like that for REALMS? In the > pull > > > > >> policy rule composer I can only choose USER or GROUP. When choosing > > > USER, > > > > > I > > > > >> can only match on username, but the assigned internal REALM > attribute > > > is > > > > >> called 'name'. For GROUPS I can choose 'name', but then the policy > > > doesn't > > > > >> work or apply? > > > > >> Also, I tried add a REALM key to AnyTypes to contain the 'name' > > > attribute, > > > > >> but that's forbidden. > > > > >> Best regards, > > > > >> Martin > > > > >> On Thu, May 3, 2018 at 2:12 PM Martin van Es <mrva...@gmail.com> > > wrote: > > > > >>> Hi, > > > > >>> On Thu, May 3, 2018 at 12:43 PM Andrea Patricelli < > > > > >>> andreapatrice...@apache.org> wrote: > > > > >>>>> Realms created in the root realm: > > > > >>>>> CREATE SUCCESS (key/name): > > > > >> 3a3370df-3aa2-4787-b370-df3aa2278786///Foobar > > > > >>>>> CREATE SUCCESS (key/name): > > > > >>> 38d90785-ab9c-4fc8-9907-85ab9c2fc8e4///Foobar2 > > > > >>>>> CREATE SUCCESS (key/name): > > > > >>> b3c86117-400b-457d-8861-17400bf57d5d///Foobar3 > > > > >>>> Please check if realm path is correctly created on Syncope. > > > > >>> The Foobar realm's path is /Foobar, as expected. > > > > >>>> [1] > > > http://blog.tirasa.net/syncope-basics-manage-active-directory.html > > > > >>> I've checked the blog and since it's intended for AD I have to > mold > > it > > > > >> into > > > > >>> LDAP only configuration a bit. Also, my realms come from > > organizations > > > > >>> instead of organizationalUnit, but I assume that doesn't matter > for > > > the > > > > >>> excersice. I have done that to the best of my knowledge, knowing > > that > > > > >>> mapping organization only wouldn't apply the > > (!(objectClass=dcObject)) > > > > >>> filter, effectively resulting in one too many Realms, but I could > > live > > > > >> with > > > > >>> that. The original problem however still remains: consecutively > > > pulling > > > > > in > > > > >>> the Realms results in unique key violoations. > > > > >>> Since I deployed Syncope from debian packages I'm not in a > position > > to > > > > >>> develop, compile and deploy custom pull Actions. Also, I accept > the > > > > > Realms > > > > >>> being inserted in a flat hierarchy, so I don't need any special > > > mapping > > > > > I > > > > >>> hope? > > > > >>> Best regards, > > > > >>> Martin > > > > > > > > > > > > > > >> -- > > > > >> If 'but' was any useful, it would be a logic operator > > > > > > > > > > > > > > -- > > > > 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/ > > > -- > > > If 'but' was any useful, it would be a logic operator > > -- > > If 'but' was any useful, it would be a logic operator > -- > If 'but' was any useful, it would be a logic operator -- If 'but' was any useful, it would be a logic operator