2009/5/22 John A. Sullivan III <jsullivan at opensourcedevel.com> > Ah, I did not do that as I thought the filter would make the change to > users with objectClass inetOrgPerson. No. The filter just searches what you have in your directory > I am virtually certain the users > do not explicitly have inetUser as an object class. Are they supposed > to? Yes. The set of the attributes that your entry can hold is defined by the classes listed in "objectClass". And the attribute memberOf is part of the "inetUser" objectClass. > Is this done by default or is the need to add this object class to > all users in order to use memberOf missing from the documentation (or > overlooked by me!). No. It is not done by default, you need to add the "objectClass: inetUser" (or any other objectClass containing the memberOf attribute) to each user entry. You can make a small perl script that does for all your users something like ------------- dn: uid=jasiii,ou=Desks,o=a100,o=Internal,dc=ssiservices,dc=biz changetype: add objectclass: inetUser ------------- You can test it with the GUI of the console for one or two user entries just to be sure the attribute memberOf works as you wish... > > > objectClass: top > objectClass: person > objectClass: organizationalPerson > objectClass: inetOrgPerson > objectClass: posixAccount > objectClass: account > objectClass: posixgroup > objectClass: shadowaccount > The origin of your problem is the absence of "objectClass: inetUser" necessary to add memberOf attribute to the entry... > > Thanks - John > > On Fri, 2009-05-22 at 08:31 +0200, Andrey Ivanov wrote: > > Can you show me the result of > > /usr/lib64/mozldap/ldapsearch -b > > "ou=Desks,o=a100,o=Internal,dc=ssiservices,dc=biz" -D "cn=Directory > > Manager" -w - -h ldap uid=jasiii objectClass > > > > It will list all the objectClasses of your entry. If "objectClass: > > inetUser" is not present in the result of this search you should, as i > > said in the previous message, add this objectClass to all the entries > > you're going to manage with memberOf plug-in, smth like: > > > > dn: uid=jasiii,ou=Desks,o=a100,o=Internal,dc=ssiservices,dc=biz > > changetype: add > > objectclass: inetUser > > > > > > Hope it helps . > > > > > > > > 2009/5/22 John A. Sullivan III <jsullivan at opensourcedevel.com> > > 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: > > It should be visible as an attribute you can add (provided your entry > > has "objectClass: inetUser") > > > > > > > > > > /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 at opensourcedevel.com> > > > 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 at 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 > > > > jsullivan at opensourcedevel.com > > > > > > > > http://www.spiritualoutreach.com > > > > Making Christianity intelligible to > > secular society > > > > > > > > -- > > > > Fedora-directory-users mailing list > > > > Fedora-directory-users at redhat.com > > > > > > > > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > > > > > -- > > > > Fedora-directory-users mailing list > > > > Fedora-directory-users at redhat.com > > > > > > > > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > > > -- > > > > > > John A. Sullivan III > > > Open Source Development Corporation > > > +1 207-985-7880 > > > jsullivan at opensourcedevel.com > > > > > > http://www.spiritualoutreach.com > > > Making Christianity intelligible to secular society > > > > > > -- > > > Fedora-directory-users mailing list > > > Fedora-directory-users at redhat.com > > > > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > > > > > > -- > > > Fedora-directory-users mailing list > > > Fedora-directory-users at redhat.com > > > > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > -- > > John A. Sullivan III > > Open Source Development Corporation > > +1 207-985-7880 > > jsullivan at opensourcedevel.com > > > > http://www.spiritualoutreach.com > > Making Christianity intelligible to secular society > > > > -- > > Fedora-directory-users mailing list > > Fedora-directory-users at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > > > -- > > Fedora-directory-users mailing list > > Fedora-directory-users at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -- > John A. Sullivan III > Open Source Development Corporation > +1 207-985-7880 > jsullivan at opensourcedevel.com > > http://www.spiritualoutreach.com > Making Christianity intelligible to secular society > > -- > Fedora-directory-users mailing list > Fedora-directory-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.fedoraproject.org/pipermail/389-users/attachments/20090522/3dfb723b/attachment.html
