30 MB of log files accumulate for each run of Brown's LDAPpc instance. This makes the log file unusable, because most of the log entries are due to errors resulting from a single issue. LDAPpc searches the LDAP directory for groups that are included by other groups. Not all included groups are provisioned into LDAP, so searching for groups that don't exist in LDAP produces 2 lengthy log entries per record searched.
In Brown's case, groups in the SIS stem exist in MACE Grouper for every course the Registrar sends in the feed from Banner. Every SIS course is included in a course group in the COURSE stem. LDAPpc only provisions LDAP with COURSE groups. But LDAPpc tries to find the SIS group in the LDAP directory, which produces the logged errors. This wastes time and creates unnecessarily voluminous log files that preclude useful debugging.
Brown is investigating 3 possible solutions to this problem:
1. Only store person subjects in the hasMember attribute. This has potential best practice implications that may prevent operations with applications that support nested groups. In Brown's case, this would be acceptable, since we flatten all groups anyway. But it's not the best path for compatibility reasons.
2. Only look up person objects in LDAP. This works for Brown because we do not use the hasMember data for group data, and we would in fact prefer not to have groups included in the hasMember attribute. but again, for compatibility reasons, this is not the best solution.
3. Only include in the hasMember attribute group dns that belong in a stem identified as a provisioned stem in the ldappc.xml config file's stem-list values. This will work for any implementation that filters the groups to provision into LDAP by stem, but would have to be generalized more in order to also work for attribute-filtered installations.
I'm open to suggestions on how to best design this to prevent this issue from impacting the logs in such an extreme way for all instances.