Skip to Content.
Sympa Menu

grouper-users - Re: [grouper-users] Weirdness when provisioning to LDAP

Subject: Grouper Users - Open Discussion List

List archive

Re: [grouper-users] Weirdness when provisioning to LDAP

Chronological Thread 
  • From: David Langenberg <>
  • To: "Peter St. Onge" <>
  • Cc: "" <>
  • Subject: Re: [grouper-users] Weirdness when provisioning to LDAP
  • Date: Tue, 1 Apr 2014 13:27:45 -0600

On the surface, it looks like you may have some inconsistencies between sources.xml and  As for the mysteriously vanishing entries, what kind of LDAP server is this & are there any other provisioning jobs outside of the grouper-PSP which could be trying to maintain the OU you're putting groups into?


On Tue, Apr 1, 2014 at 1:17 PM, Peter St. Onge <> wrote:
I've been experimenting with Grouper locally and have become somewhat
stymied with provisioning.

I'm using a local LDAP as my subject source; it's also where I want
Grouper to  provision groups to. I can search for any of my attributes
of interest from the command line, as well as in the web UI, and get
back the results I expect to see...

gsh 0% GrouperSession.startRootSession()
gsh 1% subj = SubjectFinder.findByIdOrIdentifier("hermesal", false)
subject: id='100000168' type='person' source='ldap' name='Alice Hermes'
[Not a real person; the users in this LDAP were generated]

The Grouper loader is able to write new folders into LDAP without
problem, as well with the empty groups, although I do find this in the
API's grouper_error.log:

2014-04-01 14:36:13,572: [DefaultQuartzScheduler_Worker-1] WARN
Psp.getAllSourceIdentifiers(1584) -  - PSP 'psp' - Unable to resolve
attribute 'groupNames'
2014-04-01 14:36:13,572: [DefaultQuartzScheduler_Worker-1] WARN
Psp.getAllSourceIdentifiers(1584) -  - PSP 'psp' - Unable to resolve
attribute 'memberSubjectIds'

When I try to provision users into groups, the resulting group looks
like this:

dn: cn=tg1,ou=fooroot,ou=grouper,dc=fqdn
objectClass: eduMember
objectClass: groupOfNames
objectClass: top
description: Test Group 1
cn: tg1
structuralObjectClass: groupOfNames
hasMember: Alice Deeds

A peculiarity a couple of us here have noticed is that when stored as
'groupOfNames' the entries seem to disappear after a short amount of

Some caveats - using the above result, our dn's are of this form:

dn: fooid=100000168,dc=fqdn

The fooid is defined in the institutional LDAP schema, and is used
internally. 'fooid' seems to be mapping correctly to the 'id'

When I restart the grouper loader, I see lines like this in
grouper_error.log when it tries to do the full update:

2014-04-01 15:06:02,947: [DefaultQuartzScheduler_Worker-1] INFO
Psp.execute(980) -  - Psp 'psp' - Calc
2014-04-01 15:06:02,948: [DefaultQuartzScheduler_Worker-1] INFO
Psp.execute(984) -  - Psp 'psp' - Calc XML:
<psp:calcRequest xmlns:psp=''
requestID='2014/04/01-15:06:02.947' returnData='everything'>
  <psp:id ID='100000042'/>
  <psp:schemaEntity targetID='ldap' entityName='member'/>

2014-04-01 15:06:02,976: [DefaultQuartzScheduler_Worker-1] ERROR
Psp.execute(1015) -  - Psp 'psp' - Calc
to calculate provisioned object.},requestID=2014/04/01-15:06:02.947]
2014-04-01 15:06:02,984: [DefaultQuartzScheduler_Worker-1] ERROR
Psp.execute(1017) -  - Psp 'psp' - Calc XML:
<psp:calcResponse xmlns:psp=''
status='failure' requestID='2014/04/01-15:06:02.947'
  <errorMessage>Unable to calculate provisioned object.</errorMessage>
  <psp:id ID='100000042'/>

2014-04-01 15:06:02,986: [DefaultQuartzScheduler_Worker-1] ERROR
Psp.execute(1175) -  - Psp 'psp' - Diff
to calculate provisioned object.},requestID=2014/04/01-15:06:02.937]
2014-04-01 15:06:02,996: [DefaultQuartzScheduler_Worker-1] ERROR
Psp.execute(1177) -  - Psp 'psp' - Diff XML:
<psp:diffResponse xmlns:psp=''
status='failure' requestID='2014/04/01-15:06:02.937'
  <errorMessage>Unable to calculate provisioned object.</errorMessage>
  <psp:id ID='100000042'/>

2014-04-01 15:06:02,996: [DefaultQuartzScheduler_Worker-1] ERROR
Psp.execute(1440) -  - Psp 'psp' - Sync
to calculate provisioned object.},requestID=2014/04/01-15:06:02.935]
2014-04-01 15:06:02,997: [DefaultQuartzScheduler_Worker-1] ERROR
Psp.execute(1442) -  - Psp 'psp' - Sync SPML:
<psp:syncResponse xmlns:psp=''
status='failure' requestID='2014/04/01-15:06:02.935'
  <errorMessage>Unable to calculate provisioned object.</errorMessage>
  <psp:id ID='100000042'/>

2014-04-01 15:06:03,000: [DefaultQuartzScheduler_Worker-1] ERROR
Psp.execute(811) -  - Psp 'psp' - BulkSync
2014-04-01 15:06:03,001: [DefaultQuartzScheduler_Worker-1] ERROR
Psp.execute(813) -  - Psp 'psp' -  BulkSync SPML:
<psp:bulkSyncResponse xmlns:psp=''
status='failure' requestID='2014/04/01-15:06:01.574'>
  <psp:syncResponse status='success' requestID='2014/04/01-15:06:01.845'>
    <psp:synchronizedResponse xmlns:psp=''>
      <psp:psoID ID='ou=test,ou=fooroot,ou=grouper,dc=fqdn'
    <psp:id ID='fooroot:test'/>
  <psp:syncResponse status='success' requestID='2014/04/01-15:06:02.131'>
    <psp:synchronizedResponse xmlns:psp=''>
      <psp:psoID ID='cn=tg1,ou=fooroot,ou=grouper,dc=fqfdn'
    <psp:id ID='fooroot:tg1'/>

2014-04-01 15:06:03,005: [DefaultQuartzScheduler_Worker-1] ERROR
PspChangeLogConsumer.fullSync(344) -  - PSP Consumer 'null' - Full sync
was not successful

Any and all questions/pointers appreciated.

Thanks and best, -- pete

Peter St. Onge

David Langenberg
Identity & Access Management
The University of Chicago

Archive powered by MHonArc 2.6.16.

Top of Page