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@opensourcedevel.com http://www.spiritualoutreach.com Making Christianity intelligible to secular society
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@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@opensourcedevel.com > > http://www.spiritualoutreach.com > Making Christianity intelligible to secular society > > -- > Fedora-directory-users mailing list > Fedora-directory-users@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users >
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@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@opensourcedevel.com > > http://www.spiritualoutreach.com > Making Christianity intelligible to secular society > > -- > Fedora-directory-users mailing list > Fedora-directory-users@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > -- > Fedora-directory-users mailing list > Fedora-directory-users@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users-- John A. Sullivan III Open Source Development Corporation +1 207-985-7880 jsullivan@opensourcedevel.com http://www.spiritualoutreach.com Making Christianity intelligible to secular society
2009/5/21 John A. Sullivan III <jsullivan@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 - 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@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@opensourcedevel.com > > > > http://www.spiritualoutreach.com > > Making Christianity intelligible to secular society > > > > -- > > Fedora-directory-users mailing list > > Fedora-directory-users@redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > -- > > Fedora-directory-users mailing list > > Fedora-directory-users@redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -- > John A. Sullivan III > Open Source Development Corporation > +1 207-985-7880 > jsullivan@opensourcedevel.com > > http://www.spiritualoutreach.com > Making Christianity intelligible to secular society > > -- > Fedora-directory-users mailing list > Fedora-directory-users@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users >
Andrey Ivanov wrote:> > > 2009/5/21 John A. Sullivan III <jsullivan@opensourcedevel.com > <mailto:jsullivan@opensourcedevel.com>> > > 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.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 "" {{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 - 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@opensourcedevel.com > <mailto:jsullivan@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 > <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@opensourcedevel.com > <mailto:jsullivan@opensourcedevel.com> > > > > http://www.spiritualoutreach.com > > Making Christianity intelligible to secular society > > > > -- > > Fedora-directory-users mailing list > > Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > -- > > Fedora-directory-users mailing list > > Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -- > John A. Sullivan III > Open Source Development Corporation > +1 207-985-7880 > jsullivan@opensourcedevel.com <mailto:jsullivan@opensourcedevel.com> > > http://www.spiritualoutreach.com > Making Christianity intelligible to secular society > > -- > Fedora-directory-users mailing list > Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com> > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > ------------------------------------------------------------------------ > > -- > Fedora-directory-users mailing list > Fedora-directory-users@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users >
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@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@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@opensourcedevel.com > > > > http://www.spiritualoutreach.com > > Making Christianity intelligible to secular society > > > > -- > > Fedora-directory-users mailing list > > Fedora-directory-users@redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > -- > > Fedora-directory-users mailing list > > Fedora-directory-users@redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > -- > > John A. Sullivan III > Open Source Development Corporation > +1 207-985-7880 > jsullivan@opensourcedevel.com > > http://www.spiritualoutreach.com > Making Christianity intelligible to secular society > > -- > Fedora-directory-users mailing list > Fedora-directory-users@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > -- > Fedora-directory-users mailing list > Fedora-directory-users@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users-- John A. Sullivan III Open Source Development Corporation +1 207-985-7880 jsullivan@opensourcedevel.com http://www.spiritualoutreach.com Making Christianity intelligible to secular society
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@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@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@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@opensourcedevel.com > > > > > > http://www.spiritualoutreach.com > > > Making Christianity intelligible to secular society > > > > > > -- > > > Fedora-directory-users mailing list > > > Fedora-directory-users@redhat.com > > > > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > > > -- > > > Fedora-directory-users mailing list > > > Fedora-directory-users@redhat.com > > > > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > -- > > > > John A. Sullivan III > > Open Source Development Corporation > > +1 207-985-7880 > > jsullivan@opensourcedevel.com > > > > http://www.spiritualoutreach.com > > Making Christianity intelligible to secular society > > > > -- > > Fedora-directory-users mailing list > > Fedora-directory-users@redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > > > -- > > Fedora-directory-users mailing list > > Fedora-directory-users@redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -- > John A. Sullivan III > Open Source Development Corporation > +1 207-985-7880 > jsullivan@opensourcedevel.com > > http://www.spiritualoutreach.com > Making Christianity intelligible to secular society > > -- > Fedora-directory-users mailing list > Fedora-directory-users@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users >
Ah, I did not do that as I thought the filter would make the change to users with objectClass inetOrgPerson. I am virtually certain the users do not explicitly have inetUser as an object class. Are they supposed to? 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!). objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: posixAccount objectClass: account objectClass: posixgroup objectClass: shadowaccount 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@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@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@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@opensourcedevel.com > > > > > > http://www.spiritualoutreach.com > > > Making Christianity intelligible to > secular society > > > > > > -- > > > Fedora-directory-users mailing list > > > Fedora-directory-users@redhat.com > > > > > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > > > -- > > > Fedora-directory-users mailing list > > > Fedora-directory-users@redhat.com > > > > > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > -- > > > > John A. Sullivan III > > Open Source Development Corporation > > +1 207-985-7880 > > jsullivan@opensourcedevel.com > > > > http://www.spiritualoutreach.com > > Making Christianity intelligible to secular society > > > > -- > > Fedora-directory-users mailing list > > Fedora-directory-users@redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > > > -- > > Fedora-directory-users mailing list > > Fedora-directory-users@redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -- > John A. Sullivan III > Open Source Development Corporation > +1 207-985-7880 > jsullivan@opensourcedevel.com > > http://www.spiritualoutreach.com > Making Christianity intelligible to secular society > > -- > Fedora-directory-users mailing list > Fedora-directory-users@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > -- > Fedora-directory-users mailing list > Fedora-directory-users@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users-- John A. Sullivan III Open Source Development Corporation +1 207-985-7880 jsullivan@opensourcedevel.com http://www.spiritualoutreach.com Making Christianity intelligible to secular society
2009/5/22 John A. Sullivan III <jsullivan@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@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@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@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@opensourcedevel.com > > > > > > > > http://www.spiritualoutreach.com > > > > Making Christianity intelligible to > > secular society > > > > > > > > -- > > > > Fedora-directory-users mailing list > > > > Fedora-directory-users@redhat.com > > > > > > > > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > > > > > -- > > > > Fedora-directory-users mailing list > > > > Fedora-directory-users@redhat.com > > > > > > > > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > > > -- > > > > > > John A. Sullivan III > > > Open Source Development Corporation > > > +1 207-985-7880 > > > jsullivan@opensourcedevel.com > > > > > > http://www.spiritualoutreach.com > > > Making Christianity intelligible to secular society > > > > > > -- > > > Fedora-directory-users mailing list > > > Fedora-directory-users@redhat.com > > > > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > > > > > > -- > > > Fedora-directory-users mailing list > > > Fedora-directory-users@redhat.com > > > > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > -- > > John A. Sullivan III > > Open Source Development Corporation > > +1 207-985-7880 > > jsullivan@opensourcedevel.com > > > > http://www.spiritualoutreach.com > > Making Christianity intelligible to secular society > > > > -- > > Fedora-directory-users mailing list > > Fedora-directory-users@redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > > > -- > > Fedora-directory-users mailing list > > Fedora-directory-users@redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -- > John A. Sullivan III > Open Source Development Corporation > +1 207-985-7880 > jsullivan@opensourcedevel.com > > http://www.spiritualoutreach.com > Making Christianity intelligible to secular society > > -- > Fedora-directory-users mailing list > Fedora-directory-users@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users >
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: jsullivan@example.com
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 <jsullivan@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@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@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@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@opensourcedevel.com
> > > >
> > > >
http://www.spiritualoutreach.com
> > > > Making Christianity
intelligible
> to
> > secular society
> > > >
> > > > --
> > > > Fedora-directory-users
mailing
> list
> > > >
> Fedora-directory-users@redhat.com
> > > >
> > >
> >
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
> > > >
> > > > --
> > > > Fedora-directory-users mailing list
> > > > Fedora-directory-users@redhat.com
> > > >
> > >
> >
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
> > >
> > > --
> > >
> > > John A. Sullivan III
> > > Open Source Development Corporation
> > > +1 207-985-7880
> > > jsullivan@opensourcedevel.com
> > >
> > > http://www.spiritualoutreach.com
> > > Making Christianity intelligible to
> secular society
> > >
> > > --
> > > Fedora-directory-users mailing list
> > > Fedora-directory-users@redhat.com
> > >
> >
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
> > >
> > >
> > > --
> > > Fedora-directory-users mailing list
> > > Fedora-directory-users@redhat.com
> > >
> >
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
> > --
> > John A. Sullivan III
> > Open Source Development Corporation
> > +1 207-985-7880
> > jsullivan@opensourcedevel.com
> >
> > http://www.spiritualoutreach.com
> > Making Christianity intelligible to secular society
> >
> > --
> > Fedora-directory-users mailing list
> > Fedora-directory-users@redhat.com
> >
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
> >
> >
> > --
> > Fedora-directory-users mailing list
> > Fedora-directory-users@redhat.com
> >
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
> --
> John A. Sullivan III
> Open Source Development Corporation
> +1 207-985-7880
> jsullivan@opensourcedevel.com
>
> http://www.spiritualoutreach.com
> Making Christianity intelligible to secular society
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
--
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan@opensourcedevel.com
http://www.spiritualoutreach.com
Making Christianity intelligible to secular society
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 <jsullivan@opensourcedevel.com>> 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: jsullivan@example.com > 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 <jsullivan@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@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@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@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@opensourcedevel.com > > > > > > > > > > http://www.spiritualoutreach.com > > > > > Making Christianity intelligible > > to > > > secular society > > > > > > > > > > -- > > > > > Fedora-directory-users mailing > > list > > > > > > > Fedora-directory-users@redhat.com > > > > > > > > > > > > > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > > > > > > > -- > > > > > Fedora-directory-users mailing list > > > > > Fedora-directory-users@redhat.com > > > > > > > > > > > > > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > > > > > -- > > > > > > > > John A. Sullivan III > > > > Open Source Development Corporation > > > > +1 207-985-7880 > > > > jsullivan@opensourcedevel.com > > > > > > > > http://www.spiritualoutreach.com > > > > Making Christianity intelligible to > > secular society > > > > > > > > -- > > > > Fedora-directory-users mailing list > > > > Fedora-directory-users@redhat.com > > > > > > > > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > > > > > > > > > -- > > > > Fedora-directory-users mailing list > > > > Fedora-directory-users@redhat.com > > > > > > > > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > -- > > > John A. Sullivan III > > > Open Source Development Corporation > > > +1 207-985-7880 > > > jsullivan@opensourcedevel.com > > > > > > http://www.spiritualoutreach.com > > > Making Christianity intelligible to secular society > > > > > > -- > > > Fedora-directory-users mailing list > > > Fedora-directory-users@redhat.com > > > > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > > > > > > -- > > > Fedora-directory-users mailing list > > > Fedora-directory-users@redhat.com > > > > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > -- > > John A. Sullivan III > > Open Source Development Corporation > > +1 207-985-7880 > > jsullivan@opensourcedevel.com > > > > http://www.spiritualoutreach.com > > Making Christianity intelligible to secular society > > > > -- > > Fedora-directory-users mailing list > > Fedora-directory-users@redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > > > -- > > Fedora-directory-users mailing list > > Fedora-directory-users@redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -- > John A. Sullivan III > Open Source Development Corporation > +1 207-985-7880 > jsullivan@opensourcedevel.com > > http://www.spiritualoutreach.com > Making Christianity intelligible to secular society > > -- > Fedora-directory-users mailing list > Fedora-directory-users@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users >
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
3. One must change the default memberofgroupattr from member to
uniqueMember
4. The fixup-memberof.pl script is not generated from the template.
Thanks very much for your help - John
On Tue, 2009-05-26 at 09:38 +0200, Andrey Ivanov wrote:> 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 <jsullivan@opensourcedevel.com>
> 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: jsullivan@example.com
> 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
> <jsullivan@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@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@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@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
> > > > >
> > > > >
<snip>>
--
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan@opensourcedevel.com
http://www.spiritualoutreach.com
Making Christianity intelligible to secular society
John A. Sullivan III wrote:> 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 >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.> 3. One must change the default memberofgroupattr from member to > uniqueMember >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.> 4. The fixup-memberof.pl script is not generated from the template. >Yes, this appears to be a bug related to in-place upgrades. Please file a bug on this.> Thanks very much for your help - John > > On Tue, 2009-05-26 at 09:38 +0200, Andrey Ivanov wrote: > >> 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 <jsullivan@opensourcedevel.com> >> 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: jsullivan@example.com >> 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 >> <jsullivan@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@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@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@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 >> > > > > >> > > > > >> > <snip> >
David (Dave) Donnan
2009-Dec-18 11:36 UTC
Re: [389-users] memberOf task problem template-fixup-memberof.pl into a crontab ?
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):
./ldapmodify -P "$DIR/scripts/cert8.db" -c -h ${DEST_HOST} -p
${DEST_PORT} -D "${DEST_BIND}" -w $DESTDN_PASSWORD <<EOF
dn: uid=${TGI},ou=People,${DEST_SUFFIX}
changetype: modify
add: objectClass
objectClass: inetuser
EOF
I made the following change to template-fixup-memberof.pl:
# Following line changed by david.donnan@thalesgroup.com
# open(FOO, "| ldapmodify $vstr -h {{SERVER-NAME}} -p
{{SERVER-PORT}} -D \"$rootdn\" -w \"$passwd\"
-a" );
open(FOO, "| ldapmodify $vstr -h localhost -p {{SERVER-PORT}}
-D \"$rootdn\" -w \"$passwd\" -a" );
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> John A. Sullivan III wrote:
>> 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
>>
> 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.
>> 3. One must change the default memberofgroupattr from member to
>> uniqueMember
>>
> 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.
>> 4. The fixup-memberof.pl script is not generated from the
template.
>>
> Yes, this appears to be a bug related to in-place upgrades. Please
> file a bug on this.
>> Thanks very much for your help - John
>>
>> On Tue, 2009-05-26 at 09:38 +0200, Andrey Ivanov wrote:
>>
>>> 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
<jsullivan@opensourcedevel.com>
>>> 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: jsullivan@example.com
>>> 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
>>> <jsullivan@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@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@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@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
>>> > > > >
>>> > > > >
>>>
>> <snip>
>>
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>