I'm starting to feel really stupid here - still not working. I thought the filter must be the problem for sure. I assumed from the documentation that no filter meant the task would add the attribute for everything that could take a memberOf attribute. I did not realize it defaulted to inetuser. So I recreated the task with a filter of (objectClass=inetOrgPerson) but it still did not seem to work. I thought perhaps I was doing ldapmodify wrong (enter the parameters, double enter, then CTL D) so I edited the fixup-memberof.pl script according to Rich's instructions. It ran without error (by the way, it reflects the admin password when using -w - !!!). But still no success. Perhaps I am checking incorrectly. I did not expect to see memberOf listed as an attribute in the advanced console screen for the user since it is a managed attribute. But I did try to view it with an ldapsearch: /usr/lib64/mozldap/ldapsearch -b "ou=Desks,o=a100,o=Internal,dc=ssiservices,dc=biz" -D "cn=Directory Manager" -w - -h ldap uid=jasiii memberOf Is this how I would check for success? There is nothing suspicious in the error log. I do have the audit log enabled. I see the creation and automatic deletion of the task but I do not see any changes to objects to add and populate the memberOf attribute. I'll paste in some excerpts below. What next? Thanks - John time: 20090520221132 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 creatorsName: cn=xxxx modifiersName: cn=xxx createTimestamp: 20090521021132Z modifyTimestamp: 20090521021132Z time: 20090520221333 dn: cn=fixmemberof,cn=memberof task,cn=tasks,cn=config changetype: delete modifiersname: cn=server,cn=plugins,cn=config time: 20090520222242 dn: cn=fixMemberOf,cn=memberof task,cn=tasks,cn=config changetype: add objectClass: top objectClass: extensibleObject cn: fixMemberOf basedn: ou=Desks,o=a100,o=Internal,dc=ssiservices,dc=biz creatorsName: cn=xxxx modifiersName: cn=xxxx createTimestamp: 20090521022242Z modifyTimestamp: 20090521022242Z time: 20090520222442 dn: cn=fixmemberof,cn=memberof task,cn=tasks,cn=config changetype: delete modifiersname: cn=server,cn=plugins,cn=config . . . time: 20090521183523 dn: cn=memberOf_fixup_2009_5_21_18_35_23, cn=memberOf task, cn=tasks, cn=config changetype: add objectClass: top objectClass: extensibleObject cn: memberOf_fixup_2009_5_21_18_35_23 basedn: o=Internal,dc=ssiservices,dc=biz filter: (objectClass=inetOrgPerson) creatorsName: cn=xxxx modifiersName: cn=xxxx createTimestamp: 20090521223523Z modifyTimestamp: 20090521223523Z time: 20090521183724 dn: cn=memberof_fixup_2009_5_21_18_35_23,cn=memberof task,cn=tasks,cn=config changetype: delete modifiersname: cn=server,cn=plugins,cn=config time: 20090521185804 dn: cn=general,ou=1.1,ou=console,ou=cn=xxxxx,ou=userpreferences,ou=ssiservices.biz,o=netscaperoot changetype: modify replace: nsPreference nsPreference:: IwojVGh1IE1heSAyMSAxODo1ODowNSBFRFQgMjAwOQpXaWR0aD0xMjgwClNob3 dTdGF0dXNCYXI9dHJ1ZQpTaG93QmFubmVyQmFyPXRydWUKWT0wCkhlaWdodD03NjkKWD0wCg== - replace: modifiersname modifiersname: cn=xxxxx - replace: modifytimestamp modifytimestamp: 20090521225804Z - On Thu, 2009-05-21 at 15:59 +0200, Andrey Ivanov wrote: > > > 2009/5/21 John A. Sullivan III <jsullivan@xxxxxxxxxxxxxxxxxxx> > Thank you, Andrey. I did do an updatedb and then locate - no > fixup-member0f.pl - just template.fixup-memberOf.pl :-( > It is very strange. Normally during the server installation the > template should be converted to the "normal" perl script. > > Have you verified the configuration of the memberOf plugin, especially > the arguments/attributes "memberofgroupattr" and "memberofattr" ? > > > > > > > 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). > If you do not put the filter into the ldif then the default filter is > used : "(objectClass=inetuser)". Do all your user entries include this > objectClass (inetuser)? If not, you should add this objectClass to all > the entries where you want the memberOf attribute to appear. > > > > > 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. > > No. You should not add it manually, the memberOf attribute is > maintained automatically based on the group membership. > > Do you see any message in error log? There should be something about > the impossibility to write the memberof attribute i think. > If you cannot add this attribute manually to your entry it means that > your entry does not containe "objectClass: inetuser". Add this > objectClass to all the entries that should be "managed" by the plug-in > to allow the attribute memberOf to be written to that entries. > > > > > 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. > No, you don't need to extend the schema but you need to make sure that > your entries include the objectClass "inetuser": > > objectClasses: ( 2.16.840.1.113730.3.2.130 NAME 'inetUser' DESC > 'Auxiliary class which must be present in an entry for delivery of > subscriber services' SUP top AUXILIARY MAY ( uid $ inetUserStatus $ > inetUserHTTPURL $ userPassword $ memberOf ) X-ORIGIN 'Netscape > subscriber interoperability' ) > > > > > > So, at this point, I am still at a loss for what I did wrong. > What do I > check next? Thanks - John > Try to add the "objectClass: inetuser" to the entries concerned and > take a closer look to the "errors" log file. > > @+ > > > > > > 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 > > > -- > 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
