Micro Focus Frequent Contributor
Micro Focus Frequent Contributor
536 views

Differences of information in replica ring eDir 9.0.3.1

Hi,

My customer has eDirectory 9.0.3.1 on SLES 12 SP2

They have 4 servers in replica ring.

Using an LDAP client, a query is made to the 4 servers to the container "ou=employees,o=data" with 9000 user type objects


When making the query to:

-Server 1 (master), the result of the query is 9000
-Server 2 (RW), the result of the query is 8940
-server 3 (RW), the result of the query is 9000
-server 4 (Filter RW), the result of the query is 7640

Note: Filter is object class User (cn, sn, fullname, groupmembership)

What is the cause of this difference?
Is there a mechanism to synchronize the information and leave it the same?

TIA
Labels (1)
0 Likes
3 Replies
Knowledge Partner Knowledge Partner
Knowledge Partner

Re: Differences of information in replica ring eDir 9.0.3.1

Inconsistencies among full replicas (Master, read/write, or read/only,
meaning nothing filtered) should not happen for actual objects, though
attribute differences will exist as some attributes in schema are meant to
be per-replica. As a result, you should not need to do anything to make
this work correctly.

Whether or not anything is NOT working correctly is something to prove.
How are yo testing to count these objects? Which LDAP client is used, and
does it give you any errors at the end of the query, and what are the
parameters sent to the server when the query starts? LADP clients and
servers can each impose limits on search results in terms of objects
returned, time taken, or how other hings are shown. Further, if there is
an error it usually shows up at the end.

Also, I've seen "counts" in the past vary because of errors in how counts
are taken. I usually use the command-line ldapsearch client because it
does not allow many mistakes, but even then there are default settings
that can change its behavior. Still, counting the number of objects
returned may look like this:


/usr/bin/ldapsearch -x -LLL -b 'ou=employees,o=data' -s sub | grep -c -e
'^dn:' #notice the wrapping line here potentially


Having the ndstrace output showing LDAP trace settings of the start and
end of the query could also be useful:


ldapconfig set 'LDAP Screen Level=all'

ndstrace
set dstrace=nodebug
dstrace +time +tags +ldap
set dstrace=*m9999999
dstrace file on
set dstrace=*r
#perform query here
dstrace file off
quit


By default the ndstrace.log file is at
/var/opt/novell/eDirectory/log/ndstrace.log

Each LDAP server may also have a proxy user defined, or a different user
may be used for the connections, and as a result different ACLs/rights may
apply to the query, meaning different objects may be returned or omitted
because the querying user (or [Public] or a proxy user if the bind is
anonymous) does not have rights to access everything.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
0 Likes
Micro Focus Frequent Contributor
Micro Focus Frequent Contributor

Re: Differences of information in replica ring eDir 9.0.3.1

Hi,

I tried with ldapsearch, with user admin, in two servers in replica ring, the results is:

1. a query for total users is iqual in all servers.
2. a query for total groups is iqual in all servers.
3. a query for total users and groupMemberShip for each user is different in servers, for example:

ldapsearch -LLL -h server1 -p 389 -x -D "cn=admin,o=services" -W -b "o=users" "(&(objectclass=user)(CN=*))" -s sub| grep -c -e '^groupMembership:'

Result = 310226

ldapsearch -LLL -h server2 -p 389 -x -D "cn=admin,o=services" -W -b "o=users" "(&(objectclass=user)(CN=*))" -s sub| grep -c -e '^groupMembership:'

Result = 311097

Is there any command to synchronize the information in the replica ring?

TIA
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

Re: Differences of information in replica ring eDir 9.0.3.1

On 10/11/2017 06:04 AM, esilva wrote:
>
> I tried with ldapsearch, with user admin, in two servers in replica
> ring, the results is:
>
> 1. a query for total users is iqual in all servers.
> 2. a query for total groups is iqual in all servers.
> 3. a query for total users and groupMemberShip for each user is
> different in servers, for example:


How many partitions are defined in your tree? By default you have one for
[root] and then you may have added others manually. If there are others,
where are they defined, for what reason, and do all servers (other than
the Filtered replica which I presume we are not considering at this point)
have real (Master/Read-Write/Read-Only) replicas of all of the same
partitions?

If you have different partitioning, then even if all servers hold all of
one type of object in one partition, they may not hold others in other
partitions. That may not always matter, but it could if you are using
nested groups, or dynamic groups, or filtered replicas.

> ldapsearch -LLL -h server1 -p 389 -x -D "cn=admin,o=services" -W -b
> "o=users" "(&(objectclass=user)(CN=*))" -s sub| grep -c -e
> '^groupMembership:'
>
> Result = 310226
>
> ldapsearch -LLL -h server2 -p 389 -x -D "cn=admin,o=services" -W -b
> "o=users" "(&(objectclass=user)(CN=*))" -s sub| grep -c -e
> '^groupMembership:'
>
> Result = 311097


Assuming this is reproducible over time, and not just the result of
differences while lots of changes happen, it seems odd. This is also only
true of the boxes all have real replicas of the same partitions. The
first three servers added within the boundaries of a partition
automatically get a real replica of that partition (read/write replicas by
default) but your fourth server would not have done that, or could be in
another part/partition of the tree, meaning it would have different
replicas present. Consistency matters with some types of queries (dynamic
and nested groups).

> Is there any command to synchronize the information in the replica
> ring?


You can force a heartbeat, but changes replicate automatically and have
for a couple decades. To do so use ndstrace and give it the command 'set
dstrace=*h' but, again, that only matters if the system sees changes to be
sent.

This leads to another possibility: networking issues. If you make changes
on server-a, and there are no barriers to it reaching server-b, server-c,
and server-d, then everything will replica to those other servers quickly.
If you make a change on server-d, just because server-a can reach it does
not mean it can send unsolicited changes back to server-a. Be sure that
(by default) TCP 524 can be reached on every box from every other
eDirectory box. This is easily tested with something like netcat or nmap.
If any one way does not work, then replication will not usually be
stopped, but it could be delayed unexpectedly.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.