Ah, I did not do that as I thought the filter would make the change to
users with objectClass inetOrgPerson. I am virtually certain the users
do not explicitly have inetUser as an object class. Are they supposed
to? 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!).
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: account
objectClass: posixgroup
objectClass: shadowaccount
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(a)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(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
--
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