[389-users] memberOf task problem
Andrey Ivanov
andrey.ivanov at polytechnique.fr
Thu May 21 13:59:58 UTC 2009
2009/5/21 John A. Sullivan III <jsullivan at opensourcedevel.com>
> Thank you, Andrey. I did do an updatedb and then locate - no
> fixup-member0f.pl - just template.fixup-memberOf.pl :-(
It is very strange. Normally during the server installation the template
should be converted to the "normal" perl script.
Have you verified the configuration of the memberOf plugin, especially the
arguments/attributes "memberofgroupattr" and "memberofattr" ?
>
> Unless I'm missing something, you're ldapmodify looks just like mine
> except for the cn (I believe the documentation says it can be called
> anything) and I did not use a filter (again, I believe the documentation
> says it is optional and our dit is still rather small).
If you do not put the filter into the ldif then the default filter is used :
"(objectClass=inetuser)". Do all your user entries include this objectClass
(inetuser)? If not, you should add this objectClass to all the entries where
you want the memberOf attribute to appear.
>
>
> I did create a new group and add myself to it as you suggested (thank
> you). Surprisingly, it did not appear to work. I did not see a
> memberOf attribute populated for me. I then thought I would see if I
> need to manually add that attribute to each user (I hope not!) and I did
> not see memberOf as an attribute I could add to my user object.
No. You should not add it manually, the memberOf attribute is maintained
automatically based on the group membership.
Do you see any message in error log? There should be something about the
impossibility to write the memberof attribute i think.
If you cannot add this attribute manually to your entry it means that your
entry does not containe "objectClass: inetuser". Add this objectClass to all
the entries that should be "managed" by the plug-in to allow the attribute
memberOf to be written to that entries.
>
>
> I have verified that the plugin is defined in dse.ldif and it is
> enabled. I also see memberOf defined in 20subscriber.ldif and did not
> see anything in the documentation about needing to extend the schema.
No, you don't need to extend the schema but you need to make sure that your
entries include the objectClass "inetuser":
objectClasses: ( 2.16.840.1.113730.3.2.130 NAME 'inetUser' DESC 'Auxiliary
class which must be present in an entry for delivery of subscriber services'
SUP top AUXILIARY MAY ( uid $ inetUserStatus $ inetUserHTTPURL $
userPassword $ memberOf ) X-ORIGIN 'Netscape subscriber interoperability' )
>
>
> So, at this point, I am still at a loss for what I did wrong. What do I
> check next? Thanks - John
Try to add the "objectClass: inetuser" to the entries concerned and take a
closer look to the "errors" log file.
@+
>
>
> On Thu, 2009-05-21 at 12:59 +0200, Andrey Ivanov wrote:
> > Hi,
> >
> > there are two things to be verified and/or taken into account:
> > * the pair of the attributes that is maintained (the arguments
> > "memberofgroupattr" and "memberofattr" of the plug-in)
> > * presence of these two attributes in the classes of your users and
> > groups
> >
> > To find fixup-memberof.pl try "locate fixup-memberof.pl".
> >
> > To launch it manually you need to add something like that to the
> > server (with ldapmodify) :
> > dn: cn=memberOf_fixup_2009_5_21_12_39_21, cn=memberOf task, cn=tasks,
> > cn=config
> > changetype: add
> > objectclass: top
> > objectclass: extensibleObject
> > cn: memberOf_fixup_2009_5_21_12_39_21
> > basedn: dc=example,dc=com
> > filter: (objectClass=inetOrgPerson)
> >
> >
> > As for your account, you may remove/add yourself from a group to see
> > if it changes the memberof attribute. Verify the objectClass of your
> > entry and make sure the attribute memberOf is an optional attribute of
> > at least one of these objectClasses...
> >
> >
> >
> > 2009/5/21 John A. Sullivan III <jsullivan at opensourcedevel.com>
> > Hello, all. We are in the process of upgrading from 8.0 to
> > 8.1. We've
> > hit a few glitches along the way but most has gone well.
> > However, we
> > wanted to implement the new memberOf functionality. We
> > successfully
> > added the plugin by editing dse.ldif and enabled it from the
> > console.
> > However, we've been unsuccessful in having existing group
> > membership
> > assigned to the memberOf attribute.
> >
> > We first tried to run fixup-memberOf.pl but the script does
> > not exist.
> > There is a template.fixup-memberOf.pl but this does not seem
> > to have
> > been built into a final script.
> >
> > We then thought we would use the new task feature of the
> > console. We
> > went to cn=memberof task,cn=tasks,cn=config and tried to
> > create the task
> > object. There was no nsDirectoryServerTask objectclass. We
> > added an
> > nstask but then found there was no basedn attribute we could
> > add. We
> > then created an extensibleobject instead but still not basedn
> > attribute.
> >
> > Finally, we resorted to ldapmodify (we hesitated just because
> > we are not
> > very familiar with the command line tools). First, we did:
> >
> > dn: cn=fixMemberOf,cn=memberof task,cn=tasks,cn=config
> > changetype: add
> > objectclass: top
> > objectclass: extensibleObject
> > cn: fixMemberOf
> > basedn: o=Internal,dc=ssiservices,dc=biz
> >
> > The Internal Organization has several organizations under it
> > (for
> > various clients) and then user organizational units under
> > those
> > organizations. Although it generated no errors, it did not
> > seem to
> > work. Perhaps I just don't know how to test it. However, the
> > following
> > did not return an memberOf data:
> >
> > /usr/lib64/mozldap/ldapsearch -b
> > "ou=Users,o=client1,o=Internal,dc=ssiservices,dc=biz" -D
> > "cn=Directory
> > Manager" -w - -h ldap uid=myid memberOf
> >
> > Doing /usr/lib64/mozldap/ldapsearch -b
> > "ou=Users,o=client1,o=Internal,dc=ssiservices,dc=biz" -D
> > "cn=Directory
> > Manager" -w - -h ldap uid=myid
> > showed me plenty of attributes but nothing for memberOf
> >
> > I also tried creating the task with a basedn of
> > ou=Users,o=client1,o=Internal,dc=ssiservices,dc=biz in case it
> > did not
> > change objects lower in the tree. Still no success.
> >
> > Finally I tried:
> >
> > dn: cn=fixMemberOf,cn=memberof task,cn=tasks,cn=config
> > changetype: add
> > objectclass: top
> > objectclass: nsDirectoryServerTask
> > cn: fixMemberOf
> > basedn: o=Internal,dc=ssiservices,dc=biz
> >
> > adding new entry cn=fixMemberOf,cn=memberof
> > task,cn=tasks,cn=config
> > ldap_add: Object class violation
> > ldap_add: additional info: unknown object class
> > "nsDirectoryServerTask"
> >
> > And received the expected unknown object class error.
> >
> > What are we doing wrong? Are these documentation bugs? Are
> > there
> > application bugs or do we simply not know what we are doing
> > with tasks
> > and memberOf? How do we get the memberOf information into our
> > existing
> > user objects? Thanks - John
> >
> >
> > --
> > John A. Sullivan III
> > Open Source Development Corporation
> > +1 207-985-7880
> > jsullivan at opensourcedevel.com
> >
> > http://www.spiritualoutreach.com
> > Making Christianity intelligible to secular society
> >
> > --
> > Fedora-directory-users mailing list
> > Fedora-directory-users at redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-directory-users
> >
> > --
> > Fedora-directory-users mailing list
> > Fedora-directory-users at redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-directory-users
> --
> John A. Sullivan III
> Open Source Development Corporation
> +1 207-985-7880
> jsullivan at opensourcedevel.com
>
> http://www.spiritualoutreach.com
> Making Christianity intelligible to secular society
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-directory-users/attachments/20090521/644b89eb/attachment.htm>
More information about the Fedora-directory-users
mailing list