Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] [ldappcng] change log ordering when renaming stems with child groups ?

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] [ldappcng] change log ordering when renaming stems with child groups ?


Chronological Thread 
  • From: Tom Zeller <>
  • To: Grouper Dev <>
  • Subject: Re: [grouper-dev] [ldappcng] change log ordering when renaming stems with child groups ?
  • Date: Fri, 4 Nov 2011 09:48:43 -0500

So, in general, I am thinking that a possible approach is to perform a
full-sync whenever the ldappcng change log consumer encounters a
change log entry that it can not provision incrementally. Otherwise,
there may be a variety of errors until a full-sync is run.

Thoughts ?

On Thu, Nov 3, 2011 at 12:30 PM, Shilen Patel
<>
wrote:
> The original ordering issue you mentioned is resolved now by the way.
>
> Thanks!
>
> -- Shilen
>
> On 11/3/11 1:20 PM, "Chris Hyzer"
> <>
> wrote:
>
>>Sounds good to me, if that's the way we go, lets open a jira for it for
>>2.2
>>
>>-----Original Message-----
>>From:
>>
>>
>>[mailto:]
>> On Behalf Of Tom
>>Zeller
>>Sent: Thursday, November 03, 2011 12:31 PM
>>To: Grouper Dev
>>Subject: Re: [grouper-dev] [ldappcng] change log ordering when renaming
>>stems with child groups ?
>>
>>So, how should we handle provisioning a renamed stem to ldap via the
>>change log ?
>>
>>Some (maybe most) ldap servers only allow non-leaf objects to be renamed.
>>
>>When renaming a stem with child stems and groups, we would need to
>>create the new stem structure, move groups via renaming, and then
>>delete the old stem structure. I would categorize this as non-trivial.
>>
>>My suggestion for 2.1 is that we say we do not support renaming
>>non-empty stems via the change log. A full-sync will create new
>>objects and delete old ones, rather than renaming or moving.
>>
>>Thoughts ?
>>
>>TomZ
>>
>>> Before you get too far, a quick check against my local openldap
>>> reminds me that some directory servers support subtree renaming, and
>>> others may not.
>>>
>>> For example, given
>>>
>>>  ou=stem,dc=edu
>>>   ou=child,ou=stem,dc=edu
>>>
>>> I cannot moddn ou=stem since it is non-leaf. And I cannot rename
>>> ou=child first since the parent does not exist yet. I would need to
>>> create a new ou=newStem, move ou=child over to it, then delete
>>> ou=stem. Which would not be renaming. I guess we care about renaming
>>> stems for Active Directory since access privileges may be assigned to
>>> ous, not sure.
>>>
>>> Hmm.
>>>
>>> On Wed, Nov 2, 2011 at 8:08 AM, Shilen Patel
>>> <>
>>> wrote:
>>>> I think the ordering is inconsistent.  I'll fix this to make the stems
>>>> come before the child objects.  Let me know if anybody is expecting the
>>>> opposite order.
>>>>
>>>> Thanks!
>>>>
>>>> -- Shilen
>>>>
>>>> On 11/1/11 7:48 PM, "Tom Zeller"
>>>> <>
>>>> wrote:
>>>>
>>>>>When a stem containing child groups is renamed via
>>>>>setExtension("newExtension"), the change log entries for group renames
>>>>>occur before the stem rename.
>>>>>
>>>>>This makes it difficult to rename child groups on a target ldap
>>>>>directory, since the renamed stem (i.e. the OU) has not been renamed
>>>>>yet.
>>>>>
>>>>>Is it possible to change the change log order ? maybe configurably ?
>>>>>
>>>>>Otherwise, I would need to gather all change log events for the stem
>>>>>rename context id, and reorder them somehow, shudder.
>
>



Archive powered by MHonArc 2.6.16.

Top of Page