Skip to Content.
Sympa Menu

grouper-users - Re: [grouper-users] oops with Ldappc v1.0

Subject: Grouper Users - Open Discussion List

List archive

Re: [grouper-users] oops with Ldappc v1.0


Chronological Thread 
  • From: Kathryn Huxtable <>
  • To: Tom Barton <>, Grouper Users <>
  • Subject: Re: [grouper-users] oops with Ldappc v1.0
  • Date: Mon, 15 Jan 2007 15:09:05 -0600

That's what I wanted. Thanks! -K


On 1/15/07 11:56 AM, "Tom Barton"
<>
wrote:

> Right. Ldappc persists nothing on its own behalfand changes nothing in
> grouper or signet database. You should be able to provision more than
> one target with multiple Ldappc instances, the only proviso being that
> one Ldappc instance must "own" its target, where "target" is the
> conjunction of ldap server, DIT area, and ldap schema declared in an
> Ldappc XML config file. So, you can also have multiple Ldappc instances
> provisioning to different areas within one directory.
>
> Kathryn Huxtable wrote:
>> So there's no action queue or anything like that that would prevent two
>> copies provisioning groups to two different LDAP directories... -K
>>
>>
>> On 1/15/07 8:34 AM, "Tom Barton"
>> <>
>> wrote:
>>
>>> <taking this to just the grouper-users list>
>>>
>>>
>>>
>>> Kathryn Huxtable wrote:
>>>> 1) can we run multiple copies of ldappc to provision two separate
>>>> directories, e.g. a SunJava directory server for most uses and an Active
>>>> Directory server for our Exchange distribution lists? Will they collide
>>>> in
>>>> any way?
>>>>
>>>> I guess I'm asking how ldappc knows that a change has occurred in Grouper
>>>> or
>>>> Signet.
>>> Ldappc essentially computes a logical diff between the groups,
>>> memberships, and permissions selected from the grouper and signet
>>> databases and those that are in the configured schema and DIT areas in
>>> the target directory. It makes no change whatsoever to the grouper or
>>> signet databases.
>>>
>>>> 2) Are there any plans for a JDBC source connector configuration in this?
>>>> We
>>>> don't generally use JNDI for our sources. We *can*, but I'm not sure why
>>>> we'd want to.
>>> No. We focused specifically on ldap since that covers the largest number
>>> of potential deployments.
>>>
>>> The ldappc code might give you a leg up, though, on building a
>>> provisioning connector for some other target technology. It's
>>> architected with pieces that face grouper & signet and separate pieces
>>> that face the target. You might be able to reuse the former and the
>>> overall application architecture.
>>>
>>




Archive powered by MHonArc 2.6.16.

Top of Page