there are two things to be verified and/or taken into account:
* the pair of the attributes that is maintained (the arguments "memberofgroupattr" and "memberofattr" of the plug-in)
* presence of these two attributes in the classes of your users and groups

To find fixup-memberof.pl try "locate fixup-memberof.pl". 

To launch it manually  you need to add something like that to the server (with ldapmodify) :
dn: cn=memberOf_fixup_2009_5_21_12_39_21, cn=memberOf task, cn=tasks, cn=config
changetype: add
objectclass: top
objectclass: extensibleObject
cn: memberOf_fixup_2009_5_21_12_39_21
basedn: dc=example,dc=com
filter: (objectClass=inetOrgPerson)

As for your account, you may remove/add yourself from a group to see if it changes the memberof attribute. Verify the objectClass of your entry and make sure the attribute memberOf is an optional attribute of at least one of these objectClasses...

2009/5/21 John A. Sullivan III <jsullivan@opensourcedevel.com>
Hello, all.  We are in the process of upgrading from 8.0 to 8.1.  We've
hit a few glitches along the way but most has gone well.  However, we
wanted to implement the new memberOf functionality.  We successfully
added the plugin by editing dse.ldif and enabled it from the console.
However, we've been unsuccessful in having existing group membership
assigned to the memberOf attribute.

We first tried to run fixup-memberOf.pl but the script does not exist.
There is a template.fixup-memberOf.pl but this does not seem to have
been built into a final script.

We then thought we would use the new task feature of the console.  We
went to cn=memberof task,cn=tasks,cn=config and tried to create the task
object.  There was no nsDirectoryServerTask objectclass.  We added an
nstask but then found there was no basedn attribute we could add.  We
then created an extensibleobject instead but still not basedn attribute.

Finally, we resorted to ldapmodify (we hesitated just because we are not
very familiar with the command line tools).  First, we did:

dn: cn=fixMemberOf,cn=memberof task,cn=tasks,cn=config
changetype: add
objectclass: top
objectclass: extensibleObject
cn: fixMemberOf
basedn: o=Internal,dc=ssiservices,dc=biz

The Internal Organization has several organizations under it (for
various clients) and then user organizational units under those
organizations.  Although it generated no errors, it did not seem to
work.  Perhaps I just don't know how to test it.  However, the following
did not return an memberOf data:

/usr/lib64/mozldap/ldapsearch -b
"ou=Users,o=client1,o=Internal,dc=ssiservices,dc=biz" -D "cn=Directory
Manager" -w - -h ldap uid=myid memberOf

Doing /usr/lib64/mozldap/ldapsearch -b
"ou=Users,o=client1,o=Internal,dc=ssiservices,dc=biz" -D "cn=Directory
Manager" -w - -h ldap uid=myid
showed me plenty of attributes but nothing for memberOf

I also tried creating the task with a basedn of
ou=Users,o=client1,o=Internal,dc=ssiservices,dc=biz in case it did not
change objects lower in the tree.  Still no success.

Finally I tried:

dn: cn=fixMemberOf,cn=memberof task,cn=tasks,cn=config
changetype: add
objectclass: top
objectclass: nsDirectoryServerTask
cn: fixMemberOf
basedn: o=Internal,dc=ssiservices,dc=biz

adding new entry cn=fixMemberOf,cn=memberof task,cn=tasks,cn=config
ldap_add: Object class violation
ldap_add: additional info: unknown object class "nsDirectoryServerTask"

And received the expected unknown object class error.

What are we doing wrong? Are these documentation bugs? Are there
application bugs or do we simply not know what we are doing with tasks
and memberOf? How do we get the memberOf information into our existing
user objects? Thanks - John

John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880

Making Christianity intelligible to secular society

Fedora-directory-users mailing list