<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Hello everybody and thanks for all the help. For the record, we have Centos Directory Server 8.1.0. I've enabled memberof using the three steps listed below. If it's of any help (for step #2): <tt> </tt> <blockquote><tt>./ldapmodify -P "$DIR/scripts/cert8.db" -c -h ${DEST_HOST} -p ${DEST_PORT} -D "${DEST_BIND}" -w $DESTDN_PASSWORD <<EOF</tt> <tt>dn: uid=${TGI},ou=People,${DEST_SUFFIX}</tt> <tt>changetype: modify</tt> <tt>add: objectClass</tt> <tt>objectClass: inetuser</tt> <tt>EOF</tt> </blockquote> I made the following change to template-fixup-memberof.pl: <blockquote> <blockquote><tt># Following line changed by <a class="moz-txt-link-abbreviated" href="mailto:david.donnan@thalesgroup.com">david.donnan@thalesgroup.com</a></tt> <tt># open(FOO, "| ldapmodify $vstr -h {{SERVER-NAME}} -p {{SERVER-PORT}} -D \"$rootdn\" -w \"$passwd\" -a" );</tt> <tt> open(FOO, "| ldapmodify $vstr -h localhost -p {{SERVER-PORT}} -D \"$rootdn\" -w \"$passwd\" -a" );</tt> </blockquote> </blockquote> I've performed a test whereby I've just deleted someone and then added them again with additional groups. LDAP however did not update. It updated, however, when I ran template-fixup-memberof.pl. Question 1: Have I understood that I should put template-fixup-memberof.pl into a crontab. Are there performance concerns ? Thanks again, Dave --------- Nathan Kinder wrote <blockquote cite="mid:4A1C23CC.206@redhat.com" type="cite">John A. Sullivan III wrote: <blockquote type="cite">Very interesting. The shipping dse.ldif which the instructions say to use as a template to edit the 8.0 dse.ldif has memberofgroupattr: member dn: cn=MemberOf Plugin,cn=plugins,cn=config objectClass: top objectClass: nsSlapdPlugin objectClass: extensibleObject cn: MemberOf Plugin nsslapd-pluginpath: libmemberof-plugin nsslapd-plugininitfunc: memberof_postop_init nsslapd-plugintype: postoperation nsslapd-pluginenabled: off nsslapd-plugin-depends-on-type: database memberOfGroupAttr: member memberOfAttr: memberOf When I changed it to uniqueMember, it worked! So it looks like there are several issues/errors/bugs in the instructions and procedures for upgrading from 8.0 to 8.1 1. The memberOf plugin is enabled by default and needs to be manually enabled (not really a bug but it is mentioned nowhere in the docs that I saw) 2. One must manually add the inetuser to each object with which one wishes to use the plugin. This does not appear to be a default objectClass for user creation - at least in 8.0 </blockquote> It all depends on how you provision your users, and what attributes you are using (they don't have to be "member" and "memberOf"). It is up to the administrator to use the proper objectclass that allows the attribute defined as the "memberOfAttr" config value in the member entries. <blockquote type="cite"> 3. One must change the default memberofgroupattr from member to uniqueMember </blockquote> This is going to depend on the attribute you use to define grouping. Some use the "groupOfNames" objectclass for a group entry, which uses the "member" attribute to define members. It appears that you are using "groupOfUniqueNames", which uses "uniqueMember". The memberOf plug-in allows you to use whatever attributes you want for both the grouping attribute as well as the membership attribute. In fact, the plug-in could be used for things completely unrelated to membership. <blockquote type="cite"> 4. The fixup-memberof.pl script is not generated from the template. </blockquote> Yes, this appears to be a bug related to in-place upgrades. Please file a bug on this. <blockquote type="cite">Thanks very much for your help - John On Tue, 2009-05-26 at 09:38 +0200, Andrey Ivanov wrote: <blockquote type="cite">If it still doesn't work, it's a matter of the plug-in configuration and presence. Verify your dse.ldif. You shoud have something like dn: cn=MemberOf Plugin,cn=plugins,cn=config objectClass: top objectClass: nsSlapdPlugin objectClass: extensibleObject cn: MemberOf Plugin nsslapd-pluginPath: libmemberof-plugin nsslapd-pluginInitfunc: memberof_postop_init nsslapd-pluginType: postoperation nsslapd-pluginEnabled: on nsslapd-plugin-depends-on-type: database memberofgroupattr: uniqueMember memberofattr: memberOf nsslapd-pluginId: memberof nsslapd-pluginVersion: 1.2.0 nsslapd-pluginVendor: Fedora Project nsslapd-pluginDescription: memberof plugin The importnant parameters are : nsslapd-pluginEnabled: on memberofgroupattr: uniqueMember memberofattr: memberOf Other than that you may have the plug-in binaries missing... 2009/5/25 John A. Sullivan III <a class="moz-txt-link-rfc2396E" href="mailto:jsullivan@opensourcedevel.com"><jsullivan@opensourcedevel.com></a> Hmm . . . this made perfect sense and I thought it would be the end of my problems for sure. However, I added inetUser, ran fixup_memberof.pl and still see no memberOf populated attribute even if I ask for it explicitly: [root@ldap01 ~]# /usr/lib64/mozldap/ldapsearch -b "ou=Desks,o=a100,o=Internal,dc=ssiservices,dc=biz" -D "cn=Directory Manager" -w - -h ldap01 uid=jasiii Enter bind password: version: 1 dn: uid=jasiii,ou=Desks,o=a100,o=Internal,dc=ssiservices,dc=biz objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: posixAccount objectClass: account objectClass: posixgroup objectClass: shadowaccount objectClass: inetuser physicalDeliveryOfficeName: Kennebunk telephoneNumber: +1 (207) xxx-xxxx mail: <a class="moz-txt-link-abbreviated" href="mailto:jsullivan@example.com">jsullivan@example.com</a> sn: Sullivan III givenName: John A. loginShell: /bin/bash homeDirectory: /home/jasiii gidNumber: 100001 uidNumber: 100001 cn: jasiii uid: jasiii userPassword: {SSHA}p5K8zhxQYqkjCXmu617H2DtnDKDgnom3qTgQAg== shadowLastChange: 14366 l: Kennebunk postalCode: 04043-XXXX postOfficeBox: PO Box XXX st: ME [root@ldap01 ~]# /usr/lib64/mozldap/ldapsearch -b "ou=Desks,o=a100,o=Internal,dc=ssiservices,dc=biz" -D "cn=Directory Manager" -w - -h ldap01 uid=jasiii memberOf Enter bind password: version: 1 dn: uid=jasiii,ou=Desks,o=a100,o=Internal,dc=ssiservices,dc=biz I then explicitly added the memberOf attribute to a user, created a bogus group and added the user to the group. Still no memberOf. What am I doing wrong? Thanks - John On Fri, 2009-05-22 at 22:59 +0200, Andrey Ivanov wrote: > > > 2009/5/22 John A. Sullivan III <a class="moz-txt-link-rfc2396E" href="mailto:jsullivan@opensourcedevel.com"><jsullivan@opensourcedevel.com></a> > 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 > <a class="moz-txt-link-rfc2396E" href="mailto:jsullivan@opensourcedevel.com"><jsullivan@opensourcedevel.com></a> > > 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 > > <a class="moz-txt-link-rfc2396E" href="mailto:jsullivan@opensourcedevel.com"><jsullivan@opensourcedevel.com></a> > > > 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 > > > <a class="moz-txt-link-rfc2396E" href="mailto:jsullivan@opensourcedevel.com"><jsullivan@opensourcedevel.com></a> > > > > 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 > > > > > > > > </blockquote> <snip> </blockquote> -- Fedora-directory-users mailing list <a class="moz-txt-link-abbreviated" href="mailto:Fedora-directory-users@redhat.com">Fedora-directory-users@redhat.com</a> <a class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/fedora-directory-users">https://www.redhat.com/mailman/listinfo/fedora-directory-users</a> </blockquote> </body> </html>