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: Kathryn Huxtable <>
  • Cc: Tom Barton <>, Grouper Dev <>
  • Subject: Re: [grouper-dev] ldappc edu.internet2.middleware.ldappc.synchronize.GroupEntrySynchronizer.clearRoot()
  • Date: Fri, 25 Apr 2008 15:12:09 -0400

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