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:
/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(a)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(a)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(a)opensourcedevel.com
>
>
http://www.spiritualoutreach.com
> Making Christianity intelligible to secular society
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users(a)redhat.com
>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users(a)redhat.com
>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
--
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan(a)opensourcedevel.com
http://www.spiritualoutreach.com
Making Christianity intelligible to secular society
--
Fedora-directory-users mailing list
Fedora-directory-users(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-directory-users
--
Fedora-directory-users mailing list
Fedora-directory-users(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-directory-users --
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan(a)opensourcedevel.com
http://www.spiritualoutreach.com
Making Christianity intelligible to secular society