Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] LDAPPC restart after a crash

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] LDAPPC restart after a crash


Chronological Thread 
  • From: Tom Barton <>
  • To: Tom Zeller <>
  • Cc: Grouper Dev <>,
  • Subject: Re: [grouper-dev] LDAPPC restart after a crash
  • Date: Thu, 19 Feb 2009 10:59:39 -0600

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:>> 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:>>

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:>




--
Arnaud Deman
GIP RECIA
Parc d'activités les Aulnaies
151 rue de la Juine - 45160 OLIVET
Tel : 02 38 42 14 63 <mailto:>






Archive powered by MHonArc 2.6.16.

Top of Page