Grouper Developers Forum

[Kathryn Huxtable <>]

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.

-K

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.
>
> Tom
>
> 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
> > >
> > > ou=grouper,ou=groups,dc=ku,dc=edu
> > >
> > > Would that work for you?
> > >
> > > -K
> > >
> > > 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
> > > > easier...
> > > >
> > > > Regards,
> > > >
> > > > --Owen
> > > >
> > > > --
> > > > Owen Cliffe                    Systems & Networks Administrator
> > > > Bath University Computer Services            University of Bath
> > > > Tel: 01225 386047
> <tbarton.vcf>