Hello everybody and thanks for all the help.
For the record, we have Centos Directory Server 8.1.0.
I've enabled memberof using the three steps listed below.
If it's of any help (for step #2):
./ldapmodify -P "$DIR/scripts/cert8.db" -c -h
${DEST_HOST} -p ${DEST_PORT} -D "${DEST_BIND}" -w $DESTDN_PASSWORD
<<EOF
dn: uid=${TGI},ou=People,${DEST_SUFFIX}
changetype: modify
add: objectClass
objectClass: inetuser
EOF
I made the following change to template-fixup-memberof.pl:
# Following line changed by
david.donnan@xxxxxxxxxxxxxxx
# open(FOO, "| ldapmodify $vstr -h {{SERVER-NAME}} -p
{{SERVER-PORT}} -D \"$rootdn\" -w \"$passwd\" -a" );
open(FOO, "| ldapmodify $vstr -h localhost -p {{SERVER-PORT}}
-D \"$rootdn\" -w \"$passwd\" -a" );
I've performed a test whereby I've just deleted someone and then added
them again with additional groups. LDAP however did not update.
It updated, however, when I ran template-fixup-memberof.pl.
Question 1: Have I understood that I should put
template-fixup-memberof.pl into a crontab. Are there performance
concerns ?
Thanks again, Dave
---------
Nathan Kinder wrote
John A.
Sullivan III wrote:
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
It all depends on how you provision your users, and what attributes you
are using (they don't have to be "member" and
"memberOf"). It is up to the administrator to use the proper
objectclass that allows the attribute defined as the "memberOfAttr"
config value in the member entries.
3. One must change the default
memberofgroupattr from member to
uniqueMember
This is going to depend on the attribute you use to define grouping.
Some use the "groupOfNames" objectclass for a group
entry, which uses the "member" attribute to define members. It appears
that you are using "groupOfUniqueNames", which
uses "uniqueMember". The memberOf plug-in allows you to use whatever
attributes you want for both the grouping attribute
as well as the membership attribute. In fact, the plug-in could be
used for things completely unrelated to membership.
4. The fixup-memberof.pl script is not
generated from the template.
Yes, this appears to be a bug related to in-place upgrades. Please
file a bug on this.
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@xxxxxxxxxxxxxxxxxxx>
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@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@xxxxxxxxxxx
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@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@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
> 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@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
> > > >
> > > >
<snip>
--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users
|
