Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] Re: [signet-dev] Proposal for ldappc provision scoping behavior

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] Re: [signet-dev] Proposal for ldappc provision scoping behavior

Chronological Thread 
  • From: "Michael R. Gettes" <>
  • To: Tom Barton <>
  • Cc: Grouper Dev <>, Signet <>
  • Subject: Re: [grouper-dev] Re: [signet-dev] Proposal for ldappc provision scoping behavior
  • Date: Thu, 14 Aug 2008 10:45:50 -0400

On Aug 14, 2008, at 9:22, Tom Barton wrote:

Michael R. Gettes wrote:
Tom - ok, I have read this a few times now, with a pause of a couple of hours
in between, pondering as I go. I don't buy (or fully appreciate) your
argument that managing by use of group identifiers is a bad idea.

My point was that we shouldn't *decorate* group identifiers in LDAP to manage multiple provisioners. We can certainly *use* group identifiers to manage the problem.

So, in short, help me understand why assigning each ldappc instance
it's own stem(s) to manage is a bad idea?

Assigning each ldappc instance its own stems is a perfectly fine idea, and is the first alternative I wrote about. It's just that this aproach doesn't work if your group space is flat or if you're provisioning group UUIDs or group extensions rather than group names into isMemberOf. It'll work for multiple COmanages but not for LSE.

Likewise, regexes will not help LSE.

Sorry if the LSE case was discussed here before and I
wasn't paying attention. But from this I glean LSE
is using a flat namespace. I think LSE needs to
consider using some simple hierarchy. Doing things
completely flat, to me, is a sign of poor planning.
Sorry, but that's how I feel about it. If this is
a "common" problem, then maybe we need to discuss
a strategy - but if it is LSE and LSE alone at this
point - I think LSE needs to consider changing.

and thank you for taking the time to clarify.


Archive powered by MHonArc 2.6.16.

Top of Page