2009/5/22 John A. Sullivan III <jsullivan@xxxxxxxxxxxxxxxxxxx>
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
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...
-------------
dn: uid=jasiii,ou=Desks,o=a100,o=Internal,dc=ssiservices,dc=biz
changetype: add
objectclass: inetUser
-------------
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@xxxxxxxxxxxxxxxxxxx>
> 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@xxxxxxxxxxxxxxxxxxx>
> > 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@xxxxxxxxxxxxxxxxxxx>
> > > 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@xxxxxxxxxxxxxxxxxxx
> > >
> > > http://www.spiritualoutreach.com
> > > Making Christianity intelligible to
> secular society
> > >
> > > --
> > > Fedora-directory-users mailing list
> > > Fedora-directory-users@xxxxxxxxxx
> > >
> >
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
> > >
> > > --
> > > Fedora-directory-users mailing list
> > > Fedora-directory-users@xxxxxxxxxx
> > >
> >
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
> >
> > --
> >
> > John A. Sullivan III
> > Open Source Development Corporation
> > +1 207-985-7880
> > jsullivan@xxxxxxxxxxxxxxxxxxx
> >
> > http://www.spiritualoutreach.com
> > Making Christianity intelligible to secular society
> >
> > --
> > Fedora-directory-users mailing list
> > Fedora-directory-users@xxxxxxxxxx
> >
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
> >
> >
> > --
> > Fedora-directory-users mailing list
> > Fedora-directory-users@xxxxxxxxxx
> >
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
> --
> John A. Sullivan III
> Open Source Development Corporation
> +1 207-985-7880
> jsullivan@xxxxxxxxxxxxxxxxxxx
>
> http://www.spiritualoutreach.com
> Making Christianity intelligible to secular society
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
--
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan@xxxxxxxxxxxxxxxxxxx
http://www.spiritualoutreach.com
Making Christianity intelligible to secular society
--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users
-- Fedora-directory-users mailing list Fedora-directory-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
