Grouper Developers Forum

[Tom Barton <>]

Thanks for getting to the bottom of that. I wonder when that approach 
was introduced? I don't recall it ever being discussed.

Can you create a jira issue for this?

Tom

Tom Zeller wrote:
> In summary : when provisioning memberships, AttributeModifier uses the 
> number of values, not the values themselves, of the currently 
> provisioned attribute to determine whether or not to replace or 
> add/delete values - really not a good idea.
>
> To highlight this issue of ldappc incorrectly provisioning memberships 
> after an incomplete run under 'special' circumstances, I created two 
> groups, each with one and the same member:
>
> groupA
> members: subjectA
>
> groupB
> members: subjectA
>
> I then provisioned via ldappc :
>
> cn=subjectA
> isMemberOf : groupA
> isMemberOf : groupB
>
> I then deleted via ldap one of the isMemberOf values :
>
> cn=subjectA
> isMemberOf : groupA
>
> After provisioning via ldappc -memberships :
>
> cn=subjectA
> isMemberOf : groupB
>
> and again after ldappc -memberships
>
> cn=subjectA
> isMemberOf : groupA
>
> ad nauseum.
>
> When provisioning the group whose membership was deleted out-of-band, 
> ldappc will replace instead of adding values. When creating the 
> AttributeModifier, ldappc searches using
>
> (&(uid=*)(isMemberOf=groupB)(objectClass=eduMember))
>
> which will return 0 in this case. Since the AttributeModifier is 
> initialized with 0 entries, AttributeModifier.deletes is empty and 
> AttributeModifier.deletesCnt = 0, and AttributeModifier.adds contains 1 
> item, cn=subjectA. Then, since 'if (deletes.size == deletesCnt)' 
> evaluates to true in AttributeModifier.getModifications(), attribute 
> values are replaced !
>
> On Thu, Feb 19, 2009 at 10:59 AM, Tom Barton < 
> <mailto:>> wrote:
>
>     Tom,
>
>     I'm not sure I understand the difference between the LDAP entry
>     needing 2 memberships added because of a previous Ldappc crash, or
>     because the corresponding Subject was added to 2 new groups since
>     the previous Ldappc cycle. Can you explain?
>
>     Thanks,
>     Tom
>
>     Tom Zeller wrote:
>
>
>         At first I thought there was an error in the ldappc code, but
>         that's not really the case. The 'bug' is that ldappc assumes it
>         is the only-cook-in-the-kitchen, and that
>         all-recipes-complete-successfully.
>
>         Perhaps a solution is to provide a command line option which
>         instructs ldappc whether or not to always add and delete
>         attribute values, instead of trying to optimize using replace,
>         e.g. --donotreplace.
>
>         So, someone could always use --donotreplace, or only after
>         ldappc fails to complete successfully.
>
>         Thoughts?
>
>         On Wed, Feb 18, 2009 at 5:15 AM, Arnaud Deman
>         
> <
>  
> <mailto:>
>         
> <mailto:
>  
> <mailto:>>>
>         wrote:
>
>            Hi Tom,
>
>            I have made a temporary fix by replacing REPLACE_ATTRIBUTE with
>            ADD_ATTRIBUTE in the part of
>          AttributeModifier.getModifications()
>            below.
>            This seems to work in our case but it's not clean as I don't
>         know if
>            it will not introduce a bug elsewhere.
>
>                 if (adds.size() > 0)
>                        {
>                            //
>                            // Replace the current value(s) with the
>         additions
>                            //
>                            modItem = new
>         ModificationItem(DirContext.ADD_ATTRIBUTE,
>                                    makeAttribute(adds));
>                        }
>
>            Arnaud.
>
>            Tom Zeller a écrit :
>
>                Looks like a bug indeed in AttributeModifier. I don't
>             have a fix
>                in mind yet, we'll see.
>
>                https://bugs.internet2.edu/jira/browse/GRP-227
>
>                2009/2/17 Arnaud Deman 
> <
>             
> <mailto:>
>                
> <mailto:
>             
> <mailto:>>>
>
>
>                    Hi everyone,
>
>                    I have got a problem with ldappc when restarting it
>             after a
>                    crash, when the people branch is not completely
>             provisionned.
>                    When I restart ldappc, if a person has only a part of its
>                    groups in the attribute isMemberOf, then there is a swap
>                    between these groups and the missing ones.
>
>                    For instance, the user F08001ph is member of the
>              groups :
>                         is a member of :
>             Groupesco:sarapis:local:sarapis_GIP_RECIA
>                         is an indirect member of :
>                    Groupesco:sarapis:local:sarapis_CLAUDE DE FRANCE_0410017W
>                         is an indirect member of :
>                    Groupesco:sarapis:local:sarapis_LEONARD DE VINCI_0370001A
>                         is a member of : Groupesco:sarapis:central
>
>                    The content of the attribute isMemeberOf, for the
>             ldap entry
>                    before running ldappc is:
>                         isMemberOf: esco:sarapis:local:sarapis_LEONARD DE
>                    VINCI_0370001A
>                         isMemberOf: esco:sarapis:local:sarapis_GIP_RECIA
>
>                    And the result of the run of ldappc is:
>                        isMemberOf: esco:sarapis:central
>                        isMemberOf: esco:sarapis:local:sarapis_CLAUDE DE
>                    FRANCE_0410017W
>
>                    The content of the temporary file used by the process
>             is :
>                        uid=F08001ph,ou=people,dc=esco-centre,dc=fr     2
>                          esco:sarapis:central
>                        uid=F08001ph,ou=people,dc=esco-centre,dc=fr     2
>                          esco:sarapis:local:sarapis_CLAUDE DE
>             FRANCE_0410017W
>
>                    I think the "2" which mean "Replace Attribute" in
>             this file
>                    should be "1" (Add attribute). I would say it is
>             related to
>                    the method AttributeModifier.getModifications() but I
>             can't go
>                    further because I dont understand very well the
>             method. In
>                    fact, I even don't understand when a Replace
>             operation should
>                    be used as we are working on multi-valued attributes.
>
>                    I have done this test with ldappc in the grouper
>             1.4.1 package
>                    but I will have also to fixe it for the 1.2.1 version
>             as we
>                    use it in production.
>
>
>
>                    Thanks for your help,
>                    Arnaud.
>
>
>
>
>
>
>
>
>
>
>                    --
>                    Arnaud Deman
>                    GIP RECIA
>                    Parc d'activités les Aulnaies
>                    151 rue de la Juine - 45160 OLIVET
>                    Tel : 02 38 42 14 63 
>
>             
> <mailto:>
>                    
> <mailto:
>             
> <mailto:>>
>
>
>
>
>            --
>            Arnaud Deman
>            GIP RECIA
>            Parc d'activités les Aulnaies
>            151 rue de la Juine - 45160 OLIVET
>            Tel : 02 38 42 14 63    
>
>         
> <mailto:>
>  
> <mailto:
>         
> <mailto:>>