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