Grouper Developers Forum

[Tom Barton <>]

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?

Tom

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.
>
> /mrg
>
> 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.
> >
> > -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>
begin:vcard
fn:Tom Barton
n:Barton;Tom
org:University of Chicago;Networking Services & Information Technology
adr;dom:1155 E. 60th St.;;Rm 309, 1155 Bldg;Chicago;IL;60637
email;internet:
title:Sr. Director - Integration
tel;work:+1 773 834 1700
version:2.1
end:vcard