Thank you, Andrey. I did do an updatedb and then locate - no fixup-member0f.pl - just template.fixup-memberOf.pl :-( Unless I'm missing something, you're ldapmodify looks just like mine except for the cn (I believe the documentation says it can be called anything) and I did not use a filter (again, I believe the documentation says it is optional and our dit is still rather small). I did create a new group and add myself to it as you suggested (thank you). Surprisingly, it did not appear to work. I did not see a memberOf attribute populated for me. I then thought I would see if I need to manually add that attribute to each user (I hope not!) and I did not see memberOf as an attribute I could add to my user object. I have verified that the plugin is defined in dse.ldif and it is enabled. I also see memberOf defined in 20subscriber.ldif and did not see anything in the documentation about needing to extend the schema. So, at this point, I am still at a loss for what I did wrong. What do I check next? Thanks - John On Thu, 2009-05-21 at 12:59 +0200, Andrey Ivanov wrote: > Hi, > > 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@xxxxxxxxxxxxxxxxxxx> > 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 > jsullivan@xxxxxxxxxxxxxxxxxxx > > http://www.spiritualoutreach.com > Making Christianity intelligible to secular society > > -- > Fedora-directory-users mailing list > Fedora-directory-users@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > -- > Fedora-directory-users mailing list > Fedora-directory-users@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/fedora-directory-users -- John A. Sullivan III Open Source Development Corporation +1 207-985-7880 jsullivan@xxxxxxxxxxxxxxxxxxx http://www.spiritualoutreach.com Making Christianity intelligible to secular society -- Fedora-directory-users mailing list Fedora-directory-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
