Re: (ITS#6471) dynlist overlay only acknowledging last dynlist-attrset statement

[j@gropefruit.com]

Pierangelo,=20

Thanks for responding.  Here are some hopefully helpful answers:

We have an Openfire (Java-based XMPP server, supporting ldap user/group =
lookups) server that will, when deployed, have thousands of users.  =
Openfire works quite well with openldap, however we wanted to avoid =
manually maintaining the group objects since (as I said) they would be =
highly populated.

Openfire supports two types of groups (in their terms): posix and =
non-posix.  Basically what this means is that when in posix mode, =
Openfire looks for groups (e.g: cn=3Dusers) that contain UID-like =
objects (single username strings).  When in NON-POSIX mode, however, =
Openfire will look for groups that contain DN-based members. =20

The member Attribute names (e.g: memberUid, uniqueMember, etc) are fully =
configurable to openfire, but we had limited success when trying =
different permutations.  Some attribute-mappings work, some do not.  =
Eventually, we found that the following works for Openfire:

overlay	dynlist
dynlist-attrset groupOfURLs memberURL memberUid

With this record being returned when queried:

dn: cn=3Dusers,cn=3Dgroups,dc=3Dexample,dc=3Dcom
cn: users
memberURL: =
ldap:///cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom?uid?one?(objectClass=3D=
simpleSecurityObject)
objectClass: groupOfURLs
memberUid: uid=3Dopenfire-admin,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom=

memberUid: uid=3Duser1,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom
memberUid: uid=3Duser2,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom
memberUid: uid=3Duser3,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom
memberUid: uid=3Duser4,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom
memberUid: uid=3Duser5,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom
memberUid: uid=3Duser6,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom
memberUid: uid=3Duser7,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom
memberUid: uid=3Duser8,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom
memberUid: uid=3Duser9,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom

I know this doesn't look right (obviously memberUid is not typically a =
DN-based value) BUT THIS WORKS FOR OPENFIRE (which in the end, will be =
the only client that makes use of this record).  We'd prefer to use =
DN-based member groups (e.g: this would be "Non-Posix" groups to =
openfire) since this is the only method that works with Openfire.

HOWEVER on the other side of the situation, we want to begin using =
Dynamic Posix Groups, like so:

overlay dynlist
dynlist-attrset posixGroup memberURL memberUid:uid

With this record being returned when queried:

dn: cn=3Dadmins,cn=3Dposix,cn=3Dgroups,dc=3Dexample,dc=3Dcom
objectClass: posixGroup
objectClass: top
objectClass: extensibleObject
cn: systems
gidNumber: 9001
memberURL: =
ldap:///cn=3Dplain,cn=3Dauth,dc=3Dexample,dc=3Dcom?uid?one?(objectClass=3D=
adminUser)
memberUid: admin1
memberUid: admin2
memberUid: admin3
memberUid: admin4
memberUid: admin5

.... Which works wonderfully!  Using shell commands like 'id' , 'groups' =
will work quite nicely on the posix/shell level.

But all goes to crap when combining the above dynlist-attrsets.  As I =
said, only one seems to be evaluated.  I have tried incorporating the =
optional URI parameter into the dynlist-attrsets, but this totally broke =
the groups altogether (didn't expand at all).

I guess I don't understand what role the first ObjectClass listed in the =
dynlist-attrset parameter plays - i assumed it would act appropriately =
for objects that are using the same OC that is listed in the rule.

Hope this clarifies the situation for you.  Thanks again for your time =
......

J=