Skip to Content.
Sympa Menu

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

Subject: Grouper Developers Forum

List archive

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

Chronological Thread 
  • From: Tom Barton <>
  • To: Grouper Dev <>
  • Subject: Re: Fwd: [grouper-dev] ldappc edu.internet2.middleware.ldappc.synchronize.GroupEntrySynchronizer.clearRoot()
  • Date: Thu, 24 Apr 2008 23:22:03 -0500

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

*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

fn:Tom Barton
org:University of Chicago;Networking Services & Information Technology
adr;dom:1155 E. 60th St.;;Rm 309, 1155 Bldg;Chicago;IL;60637
title:Sr. Director - Integration
tel;work:+1 773 834 1700

Archive powered by MHonArc 2.6.16.

Top of Page