Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] ldappc edu.internet2.middleware.ldappc.synchronize.GroupEntrySynchronizer.clearRoot()

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] ldappc edu.internet2.middleware.ldappc.synchronize.GroupEntrySynchronizer.clearRoot()

Chronological Thread 
  • From: "Michael R. Gettes" <>
  • To: Tom Barton <>
  • Cc: Grouper Dev <>
  • Subject: Re: [grouper-dev] ldappc edu.internet2.middleware.ldappc.synchronize.GroupEntrySynchronizer.clearRoot()
  • Date: Fri, 25 Apr 2008 17:33:17 -0400

From empirical observation - LDAPPC with respect to grouper
does NOT currently own all groups in a corresponding OU of
the DIT - this comment is directed at 1.0 and not what KH
has been working on. LDAPPC only operates on the namespace(s)
it is defined as owning within an OU of the DIT. I submit
this is proper operation. LDAPPC, 1.0, does NOT apply the
same methodology for signet permissions - it currently owns
all value spaces for edupermission - and I think this is broken
as it should only be responsible for the value spaces defined
similarly to how it handles grouper groups.

Is this any clearer?


On Apr 25, 2008, at 16:06, Tom Barton wrote:
I think I understand the use case, but perhaps not your statement of gap between that and current Ldappc capabilities. Are you saying that Ldappc currently deals with groups as needed, but not with privs? So that there would not need to be a relaxing of the requirement that an Ldappc instance "own" all groups in a corresponding ou in the DIT?


Michael R. Gettes wrote:
I think have a reasonable use case for doing this...
comanage - where you have multiple COs working against
the same directory. If you view a CO as a signet/grouper
pair - then an individual LDAPPC instance working against
the signet/grouper pair publishing to a SINGLE directory
to be the amalgamation (?) of various COs thusly implies
LDAPPC only manage entities it knows. Now, we could say
each CO is represented by an appropriate name space and
LDAPPC would only manage the defined name space (name space
being defined as a value space and NOT a portion of a DIT)
and then you can have multiple COs operate in the same portion
of the DIT. This is the feature I was wanting for comanage to
fix in LDAPPC for signet - for grouper LDAPPC was already shown
to do the right thing.
I hope this makes sense.
On Apr 25, 2008, at 14:22, Kathryn Huxtable wrote:
A good point. I think it's a bad idea to mix grouper-managed groups and non-grouper-managed groups.

Anyway, I didn't think there'd be enough interest to add that feature.


On Apr 24, 2008, at 11:22 PM, Tom Barton wrote:
If this behavior is changed, you'll need to find another way to delete groups in LDAP that have been deleted from the grouper db. At least until the grouper API can notify Ldappc of incremental changes to the grouper db (and Ldappc can act on that info), which is one of the next enhancements planned for the API.


Kathryn Huxtable wrote:
I meant to send this to the list as well. -K
Begin forwarded message:
*From: *Kathryn Huxtable < <mailto: >>
*Date: *April 24, 2008 2:30:35 PM CDT
*To: *Owen Cliffe < <mailto: >>
*Subject: **Re: [grouper-dev] ldappc edu .internet2 .middleware .ldappc.synchronize.GroupEntrySynchronizer.clearRoot()*

I suppose it could be made optional if there's much demand for it.

At KU, I just put the grouper-generated groups into a separate ou from the groups managed by other systems. So they were under


Would that work for you?


On Apr 24, 2008, at 7:06 AM, Owen Cliffe wrote:
I've noticed that ldappc clears the entire provisioned OU of all objects
which don't match the provisioned groups' object class. While I can of
understand the motivation for this, I was wondering if it is absolutely
necessary, or it could be made optional.

We have a (possibly unusual) scenario where we have some LDAP groups
(which have a different objectClass to the ldappc provisioned groups)
which are managed by a separate system to our grouper maintained
groups. At present we can't easily migrate the maintenance of these
groups into grouper (although It's something which we might consider in
the future).

For historical reasons we would like to preserve these groups under the
same DN as the grouper provisioned groups. The only way I've found to
work around this for now is to comment out the clearRoot() call in
GroupEntrySynchronizer.initialize(). This doesn't seem to cause any
problems for us, although I suppose that there is a risk of a namespace
clash if a grouper group ends up with the same cn as an existing group,
this isn't a problem for us as the CNs for the "other" groups cannot
contain semicolons.

As an aside, I was wondering why ldappc doesn't use a properties file
like grouper to configure application-level options on top of the
ldappc.xml file, it might make adding minor options like this a bit



--Owen Cliffe Systems & Networks Administrator
Bath University Computer Services University of Bath
Tel: 01225 386047



Archive powered by MHonArc 2.6.16.

Top of Page