Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] Grouper design call, Tuesday, 22 Nov 2011, 1200EST (1700Z)

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] Grouper design call, Tuesday, 22 Nov 2011, 1200EST (1700Z)


Chronological Thread 
  • From: Tom Zeller <>
  • To: Tom Barton <>
  • Cc: Grouper Dev <>
  • Subject: Re: [grouper-dev] Grouper design call, Tuesday, 22 Nov 2011, 1200EST (1700Z)
  • Date: Mon, 21 Nov 2011 17:28:45 -0700

> 5. ldappcng update

In case I miss the call tomorrow :

I do not remember if I posted that I committed code for real-time
incremental provisioning to trunk, slated for 2.1.0. I fixed some
other bugs and refactored the grouper-shibboleth plugin and tried to
complete javadoc or comments on any file I touched. Object renaming
will be supported, including renaming, moving, or copying stems, empty
or not. A gallant explorer could experiment with RTP now, by looking
at junit test configs in trunk/src/test/resources/.../spml/*.

There are a few places where the code is truly horrible, and I should
document those heavily. Unfortunately, hopes of patching the openspml2
toolkit are likely not practical, and my workaround is an abomination.

I will need to spend more time with jira to document changes. For the
first time, there will be a change to the grouper-shibboleth plugin
configuration file, which would break a deployment if only jars are
upgraded. Impact should be minimal, and given that we changed major
version numbers, not too surprising. It will be important to
communicate this effectively.

I abandoned a configuration approach that seemed too complicated, and
on the third try found a setup that should allow deployers to
uncomment sections if they want RTP. If I implemented Shibboleth
reloadable services correctly, a restart may be unnecessary ;-) We
will also be largely abandoning running ldappcng via gsh in lieu of
the loader and cron statements, both for real-time as well as full
synchronizations. Hopefully we can take advantage of the loader's
reporting and monitoring capabilities.

Speaking of documentation, that remains to be done. As well as testing
other than junit.

I think we decided I should fire up ldappcng on the grouperdemo
server, which should help me with documentation. I am thinking of a
separate ldap hierarchy for each grouper version :

ou=groups,dc=grouper-2.0,dc=grouperdemo,dc=internet2,dc=edu
ou=groups, dc=grouper-2.0.1,dc=grouperdemo,dc=internet2,dc=edu

with people accounts (for auth[NZ] to the grouper-ui ?) in

ou=people,dc=grouperdemo,dc=internet2,dc=edu

What do you think ? Should jdbc subjects be provisioned via ldappcng ?
Should we add an ldap source to grouperdemo ?

After grouperdemo, I think I should reach out to beta testers willing
to give RTP a whirl in a non-production environment first. Looking at
the calendar, I should have documentation and examples completed and
ready at the start of the new year. I was aiming for early November,
but that would have been without object renaming. It would be great if
we could work out any runtime issues before DC.

TomZ



Archive powered by MHonArc 2.6.16.

Top of Page