Andrey Ivanov wrote:
I think that is the problem here. The script is not created if you already have an installation and just do an upgrade. If you want to use the script with existing instances, just copy the template file somewhere, and replace these tokens: {{DS-ROOT}} - replace with the empty string - for FHS systems, this is just ""2009/5/21 John A. Sullivan III <jsullivan@xxxxxxxxxxxxxxxxxxx <mailto:jsullivan@xxxxxxxxxxxxxxxxxxx>>Thank you, Andrey. I did do an updatedb and then locate - no fixup-member0f.pl - just template.fixup-memberOf.pl <http://template.fixup-memberOf.pl> :-(It is very strange. Normally during the server installation the template should be converted to the "normal" perl script.
{{SERVER-NAME}} - your server FQDN
{{SERVER-PORT}} - your server port number (e.g. 389)
The script is really pretty simple - all it does is create an LDIF task
entry and add it using ldapmodify.
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 - JohnTry 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 <mailto: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 <http://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 <mailto:jsullivan@xxxxxxxxxxxxxxxxxxx> > > http://www.spiritualoutreach.com > Making Christianity intelligible to secular society > > -- > Fedora-directory-users mailing list > Fedora-directory-users@xxxxxxxxxx <mailto:Fedora-directory-users@xxxxxxxxxx>> https://www.redhat.com/mailman/listinfo/fedora-directory-users> > -- > Fedora-directory-users mailing list > Fedora-directory-users@xxxxxxxxxx <mailto: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 <mailto:jsullivan@xxxxxxxxxxxxxxxxxxx> http://www.spiritualoutreach.com Making Christianity intelligible to secular society -- Fedora-directory-users mailing list Fedora-directory-users@xxxxxxxxxx <mailto: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
<<attachment: smime.p7s>>
-- Fedora-directory-users mailing list Fedora-directory-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
