[389-users] memberOf task problem
Rich Megginson
rmeggins at redhat.com
Thu May 21 14:27:44 UTC 2009
Andrey Ivanov wrote:
>
>
> 2009/5/21 John A. Sullivan III <jsullivan at opensourcedevel.com
> <mailto:jsullivan at 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 at opensourcedevel.com
> <mailto: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
> <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 at opensourcedevel.com
> <mailto: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
> <mailto: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
> <mailto: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 <mailto: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
> <mailto: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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3258 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-directory-users/attachments/20090521/2c62bd44/attachment.bin>
More information about the Fedora-directory-users
mailing list