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
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
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
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
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
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
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 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>
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
389-users@lists.fedoraproject.org