[389-users] memberOf task problem
John A. Sullivan III
jsullivan at opensourcedevel.com
Tue May 26 10:43:02 UTC 2009
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 at 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 at 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 at 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 at 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 at 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 at 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 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
> > > > >
> > > > >
<snip>
>
--
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
More information about the Fedora-directory-users
mailing list