Skip to Content.
Sympa Menu

grouper-users - Re: [grouper-users] ldappcng : modify the format attribute

Subject: Grouper Users - Open Discussion List

List archive

Re: [grouper-users] ldappcng : modify the format attribute


Chronological Thread 
  • From: Tom Zeller <>
  • To: Wallaert-Taquet Brigitte <>
  • Cc:
  • Subject: Re: [grouper-users] ldappcng : modify the format attribute
  • Date: Tue, 19 Jul 2011 10:49:07 -0500

Each <object id=X /> in ldappcng.xml has an <identifyingAttribute />
element, which helps ldappcng map a provisioned (e.g. ldap) object to
the corresponding <object id=X /> in the ldappcng.xml configuration.
This mapping is only resolved during diff or sync operations, not
calc.

I assume that the values of ${groupObjectClassAEC} and
${groupObjectClassGOF} are the same, and are defined in
ldappc.properties :

<object id="groupAEC" ...
<identifyingAttribute name="objectClass" value="${groupObjectClassAEC}" />

<object id="groupGOF" ...
<identifyingAttribute name="objectClass" value="${groupObjectClassGOF}" />

An exception is thrown when ldappc cannot determine if a provisioned
(e.g. ldap) object is either "groupAEC" or "groupGOF".

To fix, you will want to provision an attribute with a value unique to
each <object id=X /> you are provisioning, e.g.

<object id="groupAEC" ...
<identifyingAttribute name="objectClass" value="groupAEC" />

<object id="groupGOF" ...
<identifyingAttribute name="objectClass" value="groupGOF" />

Does this make sense ?

On Tue, Jul 19, 2011 at 10:20 AM, Wallaert-Taquet Brigitte
<>
wrote:
> Le 19/07/2011 17:08, Tom Zeller a écrit :
>>
>> Could you post your ldappcng.xml and ldappc-resolver.xml, again, please ?
>
> Here are these files.
>
> Thanks.
>>
>> On Tue, Jul 19, 2011 at 10:03 AM, Wallaert-Taquet Brigitte
>> <>
>>  wrote:
>>>
>>> Hello,
>>>
>>> I have done this on attribute "owner" at first and after, on attribute
>>> "ustlPresident" only but I obtain exactly the same, it's strange :
>>>
>>> I can't publish in any case and I obtain a good response with bulkCalc
>>> command and a bad one with bulkSync :
>>> "
>>> Case A - "bin/gsh.sh -ldappcng -bulkSync -entityName groupAEC" :
>>> response :<ldappc:bulkSyncResponse
>>> xmlns:ldappc='http://grouper.internet2.edu/ldappc' status='success'
>>> requestID='2011/07/19-16:31:32.312_Q0K8YV2Z'/>
>>> BUT NO PUBLISH DONE
>>>
>>> Case B - "bin/gsh.sh -ldappcng -bulkCalc -entityName groupAEC" :
>>> ...
>>> <dsml:attr xmlns:dsml='urn:oasis:names:tc:DSML:2:0:core'
>>> name='ustlPresident'>
>>> <dsml:value>uid=djellal,ou=people,dc=univ-lille1,dc=fr</dsml:value>
>>> </dsml:attr>
>>> ...
>>> Ok but it's not a publish command.
>>>
>>> in log file, case A, I see :
>>> 2011-07-19 16:48:12,965: [main] INFO  PSP.execute(200) -  -
>>>
>>> CalcResponse[id=lille1:groupesdetravail:avancementsec:comadhocaecm0000fses,status=success,requestID=2011/07/19-16:48:12.234_Q0K9KBVB,pso=PSO[psoID=PSOIdentifier[id='cn=comAdHocAEC_M0000-FSES,ou=groups,dc=univ-lille1,dc=fr',targetID=ldap,containerID=<null>]]]
>>> 2011-07-19 16:48:12,966: [main] INFO  PSP.execute(297) -  -
>>>
>>> LookupRequest[psoID=PSOIdentifier[id='cn=comAdHocAEC_M0000-FSES,ou=groups,dc=univ-lille1,dc=fr',targetID=ldap,containerID=<null>],returnData=everything,requestID=2011/07/19-16:48:12.966_Q0K9KBV1]
>>> 2011-07-19 16:48:12,967: [main] INFO  LdapTargetProvider.execute(356) -
>>>  -
>>>
>>> LookupRequest[psoID=PSOIdentifier[id='cn=comAdHocAEC_M0000-FSES,ou=groups,dc=univ-lille1,dc=fr',targetID=ldap,containerID=<null>],returnData=everything,requestID=2011/07/19-16:48:12.966_Q0K9KBV1]
>>> 2011-07-19 16:48:12,971: [main] ERROR
>>> LdapTargetProvider.getPSODefinition(797) -  - Unable to determine schema
>>> entity for cn=comAdHocAEC_M0000-FSES,ou=groups,dc=univ-lille1,dc=fr
>>> 2011-07-19 16:48:12,973: [main] ERROR BaseSpmlProvider.execute(95) -  -
>>>
>>> Response[status=failure,error=unsupportedOperation,errorMessages={},requestID=2011/07/19-16:48:12.966_Q0K9KBV1]
>>> java.lang.reflect.InvocationTargetException
>>>        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>        at
>>>
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>>>        at
>>>
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>        at java.lang.reflect.Method.invoke(Method.java:616)
>>>        at
>>>
>>> edu.internet2.middleware.ldappc.spml.provider.BaseSpmlProvider.execute(BaseSpmlProvider.java:79)
>>>        at edu.internet2.middleware.ldappc.spml.PSP.execute(PSP.java:308)
>>>        at
>>> edu.internet2.middleware.ldappc.spml.PSPDiffer.diff(PSPDiffer.java:126)
>>>        at edu.internet2.middleware.ldappc.spml.PSP.execute(PSP.java:221)
>>>        at edu.internet2.middleware.ldappc.spml.PSP.execute(PSP.java:577)
>>>        at edu.internet2.middleware.ldappc.spml.PSP.execute(PSP.java:681)
>>>        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>        at
>>>
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>>>        at
>>>
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>        at java.lang.reflect.Method.invoke(Method.java:616)
>>>        at
>>>
>>> edu.internet2.middleware.ldappc.spml.provider.BaseSpmlProvider.execute(BaseSpmlProvider.java:79)
>>>        at
>>> edu.internet2.middleware.ldappc.spml.PSPCLI.run(PSPCLI.java:168)
>>>        at
>>> edu.internet2.middleware.ldappc.spml.PSPCLI.main(PSPCLI.java:82)
>>>        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>        at
>>>
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>>>        at
>>>
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>        at java.lang.reflect.Method.invoke(Method.java:616)
>>>        at
>>>
>>> edu.internet2.middleware.grouper.app.gsh.GrouperShell.handleSpecialCase(GrouperShell.java:188)
>>>        at
>>>
>>> edu.internet2.middleware.grouper.app.gsh.GrouperShell.main(GrouperShell.java:128)
>>>        at
>>>
>>> edu.internet2.middleware.grouper.app.gsh.GrouperShellWrapper.main(GrouperShellWrapper.java:16)
>>> Caused by: edu.internet2.middleware.ldappc.exception.LdappcException:
>>> Unable
>>> to determine schema entity for
>>> cn=comAdHocAEC_M0000-FSES,ou=groups,dc=univ-lille1,dc=fr
>>>        at
>>>
>>> edu.internet2.middleware.ldappc.spml.provider.LdapTargetProvider.getPSODefinition(LdapTargetProvider.java:798)
>>>        at
>>>
>>> edu.internet2.middleware.ldappc.spml.provider.LdapTargetProvider.getPSO(LdapTargetProvider.java:702)
>>>        at
>>>
>>> edu.internet2.middleware.ldappc.spml.provider.LdapTargetProvider.execute(LdapTargetProvider.java:453)
>>>        ... 24 more
>>> 2011-07-19 16:48:12,978: [main] ERROR PSP.execute(322) -  -
>>>
>>> LookupResponse[pso=<null>,status=failure,error=customError,errorMessages={Target
>>> did not return a lookup
>>> response.},requestID=2011/07/19-16:48:12.966_Q0K9KBV1]
>>> 2011-07-19 16:48:12,978: [main] ERROR PSP.execute(227) -  -
>>>
>>> DiffResponse[id=lille1:groupesdetravail:avancementsec:comadhocaecm0000fses,status=failure,error=customError,errorMessages={Lookup
>>> request failed.},requestID=2011/07/19-16:48:12.232_Q0K9KBVA]
>>> 2011-07-19 16:48:12,984: [main] INFO  PSP.execute(163) -  -
>>>
>>> CalcRequest[id=lille1:groupesdetravail:avancementsec:comadhocaecm0000fses,requestID=2011/07/19-16:48:12.984_Q0K9KBV2,returnData=identifier,schemaEntityRef=SchemaEntityRef[targetID=<null>,entityName=groupAEC,isContainer=false]]
>>> 2011-07-19 16:48:13,013: [main] INFO  PSP.execute(200) -  -
>>>
>>> CalcResponse[id=lille1:groupesdetravail:avancementsec:comadhocaecm0000fses,status=success,requestID=2011/07/19-16:48:12.984_Q0K9KBV2,pso=PSO[psoID=PSOIdentifier[id='cn=comAdHocAEC_M0000-FSES,ou=groups,dc=univ-lille1,dc=fr',targetID=ldap,containerID=<null>]]]
>>> 2011-07-19 16:48:13,014: [main] ERROR PSP.execute(650) -  -
>>>
>>> BulkDiffResponse[responses=1,status=failure,error=<null>,errorMessages={},requestID=2011/07/19-16:48:12.179_Q0K9KBU7]
>>> 2011-07-19 16:48:13,014: [main] INFO  PSP.execute(747) -  -
>>>
>>> BulkSyncResponse[responses=0,status=success,requestID=2011/07/19-16:48:12.179_Q0K9KBU6]
>>> 2011-07-19 16:48:13,015: [main] INFO  PSPCLI.run(184) -  - End of
>>> ldappcng
>>> execution : 840 ms
>>> ~
>>>
>>> It seems that BulkDiff doesn't ok with this syntax but I don't understand
>>> why ?
>>>
>>> Thanks.
>>> Brigitte
>>>
>>> Le 15/07/2011 20:27, Tom Zeller a écrit :
>>>>
>>>> If everyone is in the same ldap ou, perhaps a script attribute
>>>> definition will suffice, something like :
>>>>
>>>> ldappcng.xml :
>>>> <attribute name="owner" ref="ownerScript" />
>>>>
>>>> ldappc-resolver.xml :
>>>> <resolver:AttributeDefinition xsi:type="Script"
>>>>   xmlns="urn:mace:shibboleth:2.0:resolver:ad"
>>>>   id="ownerScript">
>>>>   <resolver:Dependency ref="GroupDataConnectorAED" />
>>>>   <Script><![CDATA[
>>>>
>>>>
>>>> importPackage(Packages.edu.internet2.middleware.shibboleth.common.attribute.provider);
>>>>    // value = "dallende";
>>>>    value = owner.getValues().get(0);
>>>>    ownerScript = new BasicAttribute("ownerScript");
>>>>    ownerScript.getValues().add(value +
>>>> ",ou=people,dc=univ-lille1,dc=fr");
>>>>  ]]></Script>
>>>> </resolver:AttributeDefinition>
>>>>
>>>> I have not tried this. At first, I used "owner" as the name of the
>>>> AttributeDefinition, but "owner" is also the name of a grouper
>>>> attribute, and I thought they may collide.
>>>>
>>>> [1]
>>>>
>>>> https://wiki.shibboleth.net/confluence/display/SHIB2/ResolverScriptAttributeDefinition
>>>>
>>>>> Hello,
>>>>>
>>>>> Still one question :
>>>>>  I try to do the same format attribute with a simple attribute that
>>>>> contains
>>>>> the uid of 1 person :
>>>>> owner=dallende -->    uid=dallende,ou=people,dc=univ-lille1,dc=fr
>>>>> "dallende" is writed manually, not via the person's search...
>>>>>
>>>>> I have this response :
>>>>>
>>>>> <ldappc:calcResponse status='failure'
>>>>> requestID='2011/07/15-16:05:03.354_Q0FH9FRZ' error='customError'>
>>>>> <errorMessage>Unable to resolve attribute, dependency value is not a
>>>>> Member</errorMessage>
>>>>> <ldappc:id
>>>>> ID='lille1:groupesdetravail:avancementsec:comadhocaecm0000fses'/>
>>>>> </ldappc:calcResponse>
>>>>>
>>>>> I use the same syntax as for supannGroupeAdminDN or member for ldappcng
>>>>> but
>>>>> probably not possible because of the nature of attribute : string ?
>>>>> Must I use a list, even if there will be always only one person in that
>>>>> attribute or is there another possibility ?
>>>>>
>>>>> in ldappcng.xml :
>>>>> <references name="owner" emptyValue="">
>>>>> <reference ref="owner" toObject="member" />
>>>>> </references>
>>>>>
>>>>> in ldappc-resolver.xml :
>>>>> <resolver:AttributeDefinition id="owner" xsi:type="grouper:Member"
>>>>> sourceAttributeID="owner">
>>>>> <resolver:Dependency ref="GroupDataConnectorAEC" />
>>>>> <grouper:Attribute id="id" source="lille1:ldap" />
>>>>> </resolver:AttributeDefinition>
>>>>>
>>>>>
>>>>>
>>>>> Thanks.
>>>>> Cordialement
>>>>> Brigitte
>>>>>
>>>>>
>>>>> Le 15/07/2011 12:43, Tom Zeller a écrit :
>>>>>>>
>>>>>>> So I can't publish in my ldap : the bulkSync take only one group :
>>>>>>> the
>>>>>>> first
>>>>>>> declared in my ldappcng.xml
>>>>>>> Perhaps an option could help me ?
>>>>>>
>>>>>> Looking at ldappcng.xml posted in the other thread, each object should
>>>>>> have a unique id :
>>>>>>
>>>>>> <object id="group2" authoritative="false">
>>>>>>  <identifier ref="group-dn2" baseId="${groupsOU}">
>>>>>>
>>>>>> <object id="group" authoritative="false">
>>>>>>   <identifier ref="group-dn" baseId="${groupsOU}">
>>>>>>
>>>>>> Your configuration has<object id="group" ... />      twice, which I
>>>>>> think
>>>>>> is the issue.
>>>>>>
>>>>>> If this is the case, ldappcng should throw a configuration error, and
>>>>>> the failure to do so is a bug.
>>>>>
>>>>> --
>>>>> Brigitte Wallaert-Taquet
>>>>> Ingénieure d'études
>>>>> Chargée d'étude
>>>>> Espace collaboratif de Documents
>>>>> Université Lille1
>>>>> Sciences et Technologies
>>>>>
>>>>>
>>>
>>> --
>>> Brigitte Wallaert-Taquet
>>> Ingénieure d'études
>>> Chargée d'étude
>>> Espace collaboratif de Documents
>>> Université Lille1
>>> Sciences et Technologies
>>>
>>>
>
>
> --
> Brigitte Wallaert-Taquet
> Ingénieure d'études
> Chargée d'étude
> Espace collaboratif de Documents
> Université Lille1
> Sciences et Technologies
>
>



Archive powered by MHonArc 2.6.16.

Top of Page