[389-users] Re: repl-monitor

[Sergei Gerasenko]

After looking at the code for a couple of days, I finally see how the 
difference is calculated:

Delta = Max Consumer CSN - Max Agreement CSN

Thus, instead of the max CSN of the RUV, the agreement's maxcsn is used?

My question now is: what’s the difference between the maxcsn of the agreement 
and the maxcsn in the RUV?

Thanks!
  Sergei


> On Oct 29, 2017, at 10:36 AM, Sergei Gerasenko  wrote:
> 
> Hi,
> 
> I’m using the repl-monitor script and I’m not sure the output I’m getting is 
> right. If you look at the attached image, you will see that the supplier 
> replica (122) is at "10/28/2017 23:37:06”. The supplier column correctly 
> lists the supplier. But the Supplier Max CSN column doesn’t use the max CSN 
> in the master header (10/28/2017 23:37:06). Instead it uses the Max CSN of 
> the supplier local to the consumer?
> 
> According to the screenshot, the lag is 0 secs. But the lag is actually 
> 10/28/2017 23:37:06 minus 10/27/2017 21:54:14?
> 
> Thanks,
>   Sergei
> 
> 

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: repl-monitor

[Sergei Gerasenko]

Hi Mark,

Thank you for the quick response. I’m just beginning to unravel the mysteries 
of replication, so I really appreciate an expert’s help.

As you can see in the screenshot, the max db csn is quite a bit ahead. Is that 
an indication of a problem? Should the server not try to minimize the 
difference? I’m theorizing that some of the changes that might occur should not 
be replicated — causing the RUV maxcsn to increase but not the agreement’s?

Also, the Last Modify Time column for some servers shows “1/1/1970 00:00:00”. 
I’ve verified that that’s how it comes from the search query. What’s that an 
indication of?

Thank you
  Sergei


> On Oct 29, 2017, at 4:59 PM, Mark Reynolds  wrote:
> 
> 
> 
> On 10/29/2017 03:20 PM, Sergei Gerasenko wrote:
>> My question now is: what’s the difference between the maxcsn of the
>> agreement and the maxcsn in the RUV?
> The maxcsn in the RUV is where the database is at, the agreement maxcsn
> is what the repl agreement has processed.
> 

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: repl-monitor

[Sergei Gerasenko]

Hi Mark,

>> The replication is working. I wrote a script that makes a change on each 
>> member of the topology and verifies that it got to all the other members. 
>> So, it appears that all is good.
> 
> Yup, the monitor output looks good

Cool!

> Okay, so FreeIPA uses fractional replication and stripped attributes.  In a 
> freeipa deployment not all updates are replicated, and this is probably why 
> the maxcsn's tend to drift (until you do an update that is replicated).  For 
> example, in FreeIPA each kerberos login updates the database (and its RUV), 
> but these updates not replicated via the fractional replication configuration 
> - so the agmt maxcsn will not be incremented for such operations.
> Anyway it all looks correct to me.

That’s VERY useful information. Thanks a ton. What are other examples of the 
events that could increment the local RUV?

I think I found a small bug in the repl-monitor script, which however doesn’t 
affect its operation (miraculously). Is there a place to submit a patch for 
that?

Thanks again,
  Sergei___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: repl-monitor

[Sergei Gerasenko]

> Look for:  nsDS5ReplicatedAttributeList
> 
> nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE memberof idnssoaserial
>   entryusn krblastsuccessfulauth krblastfailedauth krbloginfailedcount
> 
> In this case any update to any one of these attributes is NOT replicated.  So 
> if you update "memberOf", the agmt maxcsn will not advance while the database 
> RUV did.

Got it.

>> I think I found a small bug in the repl-monitor script, which however 
>> doesn’t affect its operation (miraculously). Is there a place to submit a 
>> patch for that?
> https://pagure.io/389-ds-base/new_issue 
> 

Excellent!

Question 1, in the script, the list of RUVs is retrieved like so:

$ruv = $conn->search($replicaroot, "one",
   
"(&(nsuniqueid=---)(objectClass=nsTombstone))",
   0, qw(nsds50ruv nsruvReplicaLastModified nsds5AgmtMaxCSN));


For the life of me I don’t understand what nsTombstone records have to do with 
querying for RUVs. What am I missing? I might be not understanding the 
ldapsearch syntax there.


Question 2:

The Last Modify Time column in the report has 1/1/1970 for a consumer. What 
could be the reason for that?

Thank you!

Sergei



___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: repl-monitor

[Sergei Gerasenko]

>> Question 1, in the script, the list of RUVs is retrieved like so:
>> 
>> $ruv = $conn->search($replicaroot, "one",
>>
>> "(&(nsuniqueid=---)(objectClass=nsTombstone))",
>>0, qw(nsds50ruv nsruvReplicaLastModified nsds5AgmtMaxCSN));
>> 


> So the RUV entry of the database is just a special entry, and the short story 
> is that this is the only way to search for it.

Well, curiously I can do it like this:

attrs="nsds50ruv nsruvReplicaLastModified nsds5AgmtMaxCSN"
ldapsearch -xLLL -h $HOST -D "cn=directory manager” -W -b cn=config cn=replica 
$attrs -o ldif-wrap=no


Is that not a correct way to search for RUVs (both local and agreements’)? I 
get the same results as in the code

>> The Last Modify Time column in the report has 1/1/1970 for a consumer. What 
>> could be the reason for that?
> Maybe that replica/consumer was never directly updated?  That value comes 
> from the database ruv maxcsn.

Ok, I don’t think that’s a concern right now.

One final question…

When I connect to any of the masters with a graphical LDAP browser (JXplorer 
for example), I can’t find all the RUV information. But ldapsearch can do it no 
problem. Why?___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: repl-monitor

[Sergei Gerasenko]

>> Is that not a correct way to search for RUVs (both local and agreements’)? I 
>> get the same results as in the code
> Right, entries under cn=config are not "special entries".  Only the database 
> tombstone/RUV entry is.  So to see a backend database RUV you need to use 
> "(&(nsuniqueid=---)(objectClass=nsTombstone))",
>  but you don't need any "special filter" to search for entries under 
> cn=config.

Thanks, Mark!
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: repl-monitor

[Sergei Gerasenko]

Say I want to create a nagios check when the lags are getting long. Obviously I 
don’t want to use the directory manager’s account to retrieve the RUV 
information. How can I create a user with read-only privileges for this data? 
If you have a quick pointer, that should be sufficient.

Thank you!
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Changelog, its location, ways to view, max life

[Sergei Gerasenko]

Hello,

Some basic questions about the changelog:

1. What’s the location of the changelog where I can look up a CSN?
2. How do I see the setting for the max life of a CSN?
3. How do I view a particular CSN (i.e. its contents)?

Thanks,
  Sergei

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: Changelog, its location, ways to view, max life

[Sergei Gerasenko]

> To look at the replication changelog you need to use the cli tool "cl-dump.pl"
> 
> https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwit5tqk5qLXAhVK7iYKHaacB40QFggmMAA&url=https%3A%2F%2Faccess.redhat.com%2Fdocumentation%2Fen-US%2FRed_Hat_Directory_Server%2F8.0%2Fhtml%2FConfiguration_and_Command_Reference%2FConfiguration_Command_File_Reference-cl_dump.pl_Dump_and_decode_changelog.html&usg=AOvVaw0EeBRb66mKeGlybKkp0z1O
>  
> 

Ok, thank you

> 
>> 2. How do I see the setting for the max life of a CSN?
> There is no "max life" of a csn.

Ok, what brought this up is that about every week, one of the machines in our 
environment breaks the replication with messages like this:

[01/Nov/2017:17:12:52.815891904 +] agmt="cn=meTo" - Can't locate CSN 
59f9d98a0076 in the changelog (DB rc=-30988). If replication stops, the 
consumer may need to be reinitialized.
[01/Nov/2017:17:12:52.820619690 +] NSMMReplicationPlugin - changelog 
program - agmt="cn=me": CSN 59f9d98a0076 not found, we aren't as up 
to date, or we purged
[01/Nov/2017:17:12:52.828626595 +] NSMMReplicationPlugin - 
agmt="cn=meTo": Data required to update replica has been purged from the 
changelog. The replica must be reinitialized.

So it made me think that perhaps the CSN record is removed too early? The ’76’ 
in the CSN is the machine having the problem. What do you think could cause 
problems of this kind?

> There is replication purging and changelog trimming that uses csns in RUV's 
> to determine what can be removed.  The admin guide talks about these in more 
> detail.
>> 3. How do I view a particular CSN (i.e. its contents)?
> csn:
> 
> 59f9e54700020001
> 
> Breaks down like this:
> 
> 59f9e547 0002 0001 

Yep, found that info previously, but thank you still!___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: Changelog, its location, ways to view, max life

[Sergei Gerasenko]

>> Ok, what brought this up is that about every week
> Ahh yes, this is the default replication purge interval (7 days)
> 
> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.1/html/Administration_Guide/Managing_Replication-Configuring-Replication-cmd.html
>  
> 
> 
> Look for nsDS5ReplicaPurgeDelay
> 
> It could also be changelog trimming:
> 
> http://www.port389.org/docs/389ds/FAQ/changelog-trimming.html 
> 
> 
> 
> So what this is telling me is that one of your replication agreements was 
> over a week behind from the other replicas (not good).  Was that agreement 
> disabled for a while, and then enabled, for some reason?


Not that I’m aware of. I’m using the repl-monitor script to monitor our 
replication and everything is inline (no CSN mismatch) until all of a sudden 
that happens.

Since I’m not an expert on ldap, do you mind posting the ldapsearch command to 
look up the value of nsDS5ReplicaPurgeDelay. I’m getting an empty value back. 
The subdirs of /var/lib/dirsrv/INSTANCE are:

bak  
cldb 
db
ldif

Is cldb the changelog db?___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: Changelog, its location, ways to view, max life

[Sergei Gerasenko]

> ldapsearch -D "cn=directory manger" -W -b cn=config objectClass=nsDS5Replica

nsDS5ReplicaPurgeDelay is not set listed in the output :(. It must be at the 
default value of one week? 

Also, you mentioned that the agreement might have been disabled. What field of 
the nsds5replicationagreement class shows that?

Given the error in the log, and the low likelihood of the agreement being 
disabled for a week, what else can cause a node not to find a CSN?

Thanks!!___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: Changelog, its location, ways to view, max life

[Sergei Gerasenko]

>> Also, you mentioned that the agreement might have been disabled. What field 
>> of the nsds5replicationagreement class shows that?
> nsds5ReplicaEnabled

Thank you

>> Given the error in the log, and the low likelihood of the agreement being 
>> disabled for a week, what else can cause a node not to find a CSN?
> Have you restored from a backup recently? 

No

> You need to look through all the logs to further troubleshoot this.   For now 
> I would get everyone in sync then monitor replication, and archive your logs 
> for the next week.  That way you have a full data set to investigate if 
> something goes wrong.

Ok, I’ll try to plow through the logs. I might still have them.

> What version of 389 are you on?  rpm -qa | grep 389-ds-base

389-ds-base-libs-1.3.5.10-21.el7_3.x86_64
389-ds-base-1.3.5.10-21.el7_3.x86_64

What does this tell you:

[25/Oct/2017:18:16:43.389794105 +] connection - conn=167482 fd=121 Incoming 
BER Element was 3 bytes, max allowable is 2097152 bytes. Change the 
nsslapd-maxbersize attribute in cn=config to increase.

This is confusing, it was 3 bytes which is < 2097152 and still the log message.
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: Changelog, its location, ways to view, max life

[Sergei Gerasenko]

>> 389-ds-base-libs-1.3.5.10-21.el7_3.x86_64
>> 389-ds-base-1.3.5.10-21.el7_3.x86_64
> Actually you might be running into a known bug which is fixed in 1.3.6
> and up.  Sorry 1.3.5/el7_3 is no longer supported or maintained.

Interesting! Can you link me to the bug?

>> 
>> What does this tell you:
>> 
>> [25/Oct/2017:18:16:43.389794105 +] connection - conn=167482 fd=121 
>> Incoming BER Element was 3 bytes, max allowable is 2097152 bytes. Change the 
>> nsslapd-maxbersize attribute in cn=config to increase.
>> 
>> This is confusing, it was 3 bytes which is < 2097152 and still the log 
>> message.
> This happens when you try to open a ssl connection on the non-secure
> port.  We have a bug open on this to make that error message means
> something useful (the message should be fixed in 1.3.7)

OK, so this is benign more or less?
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Solving Naming Conflicts

[Sergei Gerasenko]

Hi,

I was going through RedHat’s documentation on naming conflicts. Here’s what it 
says at the beginning 
(https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/managing_replication-solving_common_replication_conflicts
 
):

14.23.1. Solving Naming Conflicts
When two entries are created with the same DN on different servers, the 
automatic conflict resolution procedure during replication renames the last 
entry created, including the entry's unique identifier in the DN. Every 
directory entry includes a unique identifier given by the operational attribute 
nsuniqueid. When a naming conflict occurs, this unique ID is appended to the 
non-unique DN.
 <>
What I don’t understand is how conflicts can happen at all if the last one 
wins? 
Also, they are talking about solutions to the conflicts and specifically 
renaming the user that has nsuniqueid prepended. Does that assume that the 
conflicting user is actually another person? Or does it mean the conflicting 
record denotes the same user? If it’s the same user, shouldn’t the conflicting 
record just be removed? 
Really confused about the nature of the problem and the suggested solutions.
Thanks!___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: Solving Naming Conflicts

[Sergei Gerasenko]

Hi,

If I wanted to simulate a conflict the way it’s described in the RedHat 
documentation (14.23.1.1. Renaming an Entry with a Multi-Valued Naming 
Attribute 
<https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/managing_replication-solving_common_replication_conflicts>)
 with a series of LDIF transformations, what would be the LDIFs? I installed 
and set up a 389 instance in a VM for this purpose.

I tried adding:

user1
user2

Then I tried to modrdn user2 to nsuniqueid=VALUE+user1, but got this error:

Rename Result: Server is unwilling to perform (53)
Additional info: new superior is identical to the entry dn

The exact LDIF for the ldapmodrdn command was:

uid=user1,ou=People,dc=example,dc=com
uid=nsuniqueid=82d86a81-c44811e7-b207809a-7d9aed98+user1

I’m just getting my feet wet with LDAP, so bear with me.

Thanks,
  Sergei

> On Nov 7, 2017, at 4:44 PM, William Brown  wrote:
> 
> On Tue, 2017-11-07 at 13:33 -0600, Sergei Gerasenko wrote:
>> Hi,
>> 
>> I was going through RedHat’s documentation on naming conflicts.
>> Here’s what it says at the beginning (https://access.redhat.com/docum
>> entation/en-
>> us/red_hat_directory_server/10/html/administration_guide/managing_rep
>> lication-solving_common_replication_conflicts
>> <https://access.redhat.com/documentation/en-
>> us/red_hat_directory_server/10/html/administration_guide/managing_rep
>> lication-solving_common_replication_conflicts>):
>> 
>> 14.23.1. Solving Naming Conflicts
>> When two entries are created with the same DN on different servers,
>> the automatic conflict resolution procedure during replication
>> renames the last entry created, including the entry's unique
>> identifier in the DN. Every directory entry includes a unique
>> identifier given by the operational attribute nsuniqueid. When a
>> naming conflict occurs, this unique ID is appended to the non-unique
>> DN.
>>  <>
>> What I don’t understand is how conflicts can happen at all if the
>> last one wins? 
> 
> The point is that if the last one wins, what do we do with the first?
> We don't want to just delete it in case the order of operations was not
> what the admin expected. So when you do:
> 
>  Master 1  Master 2
> 
> Time 0  ADD E
> 
> Time 1ADD E
> 
> We are going to keep M1 E, and we'll conflict on M2 E - this becomes
> the conflict entry. 
> 
>> Also, they are talking about solutions to the conflicts and
>> specifically renaming the user that has nsuniqueid prepended. Does
>> that assume that the conflicting user is actually another person? Or
>> does it mean the conflicting record denotes the same user? If it’s
>> the same user, shouldn’t the conflicting record just be removed? 
>> Really confused about the nature of the problem and the suggested
>> solutions.
>> Thanks!
> 
> See above. It's about preserving the duplicate entry incase the
> administrator wishes to revive them or see what happened. :) 
> 
> 
> Hope that helps, Ludwig might have more to say on this. 
> 
>> ___
>> 389-users mailing list -- 389-users@lists.fedoraproject.org
>> To unsubscribe send an email to 389-users-leave@lists.fedoraproject.o
>> rg
> -- 
> Sincerely,
> 
> William Brown
> Software Engineer
> Red Hat, Australia/Brisbane
> ___
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: Solving Naming Conflicts

[Sergei Gerasenko]

Thank you, William. I currently don’t have MMR set up, but I think it should 
not be a hard to do. Currently, I just spun up a VM and installed 389-ds on it. 
The reason why I want to simulate this is because I don’t quite understand the 
technique Redhat employs to resolve the conflict. If you look in that section 
(14.23.1.1), you will see that they first rename the nsunique+uid attribute to 
uid=NewValue keeping the old RDN and then delete the uid=NewValue along with 
the conflict marker. The deletion is done under the new dn of uid=NewValue,….

I think I now understand why the rename has to happen first. Since there are in 
that scenario two “adamss” users, if we just rename the second into “new” and 
delete the old RDN, it will delete the first “adamss” as well, right?

Also, and this is more of a general LDAP question, in the same article they 
talk about removing dangling RUVs. They do a search for: 

dn:cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config

But the ldapsearch command doesn’t specify the whole path. Instead, it’s just 
-b cn=config cn=replica. How does the server find replica under mapping tree if 
we only specified the base of cn=config?

Thank you again,
  Sergei

> No problem. I think there is an easier way to simulate this.
> 
> Make sure you have MMR setup (IE agreement from M1 -> M2, and M2 ->
> M1).
> 
> Then on both, there is an agreement object, something like:
> 
> cn=ExampleAgreement,cn=replica,cn=dc=example\,dc=com,cn=mapping
> tree,cn=config
> 
> To that object on *BOTH* masters add:
> 
> 
> nsds5ReplicaEnabled: off
> 
> This will pause all replication.
> 
> 
> Now, add your "user1" to both M1 and M2. Try to make them have the same
> DN, but different attributes like:
> 
> uid=user,ou=People,
> ...
> description: m1
> 
> uid=user,ou=People,
> ...
> description: m2
> 
> 
> Next, on both masters set:
> 
> 
> nsds5ReplicaEnabled: on
> 
> 
> This will trigger a replication update. You should have conflict
> entries on your servers now :) 
> 
> 
> Anyway, in reality, it's rare you'll ever see conflicts like this, but
> I'm glad you are researching this so thoroughly, 

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: Changelog, its location, ways to view, max life

[Sergei Gerasenko]

Sorry, do you have a link to the bug(s) that might be causing this? Digging a 
bit deeper and using cl-dump to see to dump the changelog, I see that the CSN 
the machines complain about is not actually in any of the changelogs. So, is 
there a good way to make a given machine forget about a particular it tries to 
replay to its consumer(s)?

Thanks, any insight would be very helpful.

> On Nov 3, 2017, at 2:11 PM, Sergei Gerasenko  wrote:
> 
> 
>>> 389-ds-base-libs-1.3.5.10-21.el7_3.x86_64
>>> 389-ds-base-1.3.5.10-21.el7_3.x86_64
>> Actually you might be running into a known bug which is fixed in 1.3.6
>> and up.  Sorry 1.3.5/el7_3 is no longer supported or maintained.
> 
> Interesting! Can you link me to the bug?
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] CSN XXX not found, we aren't as up to date, or we purged

[Sergei Gerasenko]

Hi,

I see these messages in the errors log of on a couple of suppliers.:

08/Nov/2017:22:44:13.612346436 +] NSMMReplicationPlugin - changelog program 
- agmt="cn=meTot": CSN 5a02f2c30002007c not found, we aren't as up to 
date, or we purged
[08/Nov/2017:22:44:13.629490783 +] NSMMReplicationPlugin - 
agmt="cn=meTo": Data required to update replica has been purged from the 
changelog. The replica must be reinitialized.

The documentation from RedHat says:

agmt=%s(%s:%d): Can't locate CSN %s in the changelog (DB rc=%d). The consumer 
may need to be reinitialized. Most likely the changelog was recreated 
because of the disk is full or the server ungracefully shutdown.The 
local server will not be able to send any more change to that consumer until 
the consumer is reinitialized or gets the CSN from other suppliers.If this 
is a single-master replication, reinitialize the consumers. Otherwise, see if 
the consumer can get the CSN from other suppliers. If not, reinitialize the 
consumer.

I’ve used cl-dump to look at the change log but none of the machines have a 
reference to it. So where is the knowledge of that CSN is coming from and what 
can I do besides reinitializing? I’ve tried multiple reinitializations but the 
error just moves to another machine.

The replication doesn’t seem to be affected however. The symptom is error 18 in 
the output of `ipa-replica manage $HOSTNAME list`.

Mark Reynolds did suggest it was possibly a bug in 
389-ds-base-1.3.5.10-21.el7_3.x86_64, but it’s not feasible to upgrade at the 
moment. Any way to manually maneuver out of this without upgrading?

Thanks,
  Sergei___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: Solving Naming Conflicts

[Sergei Gerasenko]

> Not quite. When we have this scenario:
> 
> M1M2
> 
> T0  Add E1
> 
> T1Add E2
...

Thank you, William. 


>> Also, and this is more of a general LDAP question, in the same
>> article they talk about removing dangling RUVs. They do a search
>> for: 
>> 
>> dn:cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
>> 
>> But the ldapsearch command doesn’t specify the whole path. Instead,
>> it’s just -b cn=config cn=replica. How does the server find replica
>> under mapping tree if we only specified the base of cn=config?
> 
> I'm not sure I completely understand the question sorry. 

Sorry I wasn’t clear. Below is the excerpt from the article. Note they are 
saying “cn=replica” under “cn=config”, but the full DN is dn: 
cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config

That is, cn=replica is not _directly_ under cn=config. Doesn’t cn=…,cn=…,cn=… 
imply hierarchy? In other words, I’m confused how ldapsearch could find the 
replica entry if the base was specifying just cn=config and not 
cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config

That’s why I think I might have some conceptual misunderstanding about LDAP in 
general.

Thanks again.


...
List the currently defined and valid replica IDs of all masters which are 
replicating databases by searching the replica configuration entries DN 
cn=replica under the cn=config suffix.
Note

Consumers and read-only nodes always have the replica ID set to 65535, and 
nsDS5ReplicaType: 3 signifies a master.
# ldapsearch -o ldif-wrap=no -xLLL -H m1.example.com m2.example.com -D 
"cn=Directory Manager" -W -b cn=config cn=replica nsDS5ReplicaId 
nsDS5ReplicaType
dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
nsDS5ReplicaId: 1
nsDS5ReplicaType: 3

dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
nsDS5ReplicaId: 20
nsDS5ReplicaType: 3
...


> 
> We only have one cn=replica per mapping tree entry. IE a suffix
> (dc=example,dc=com), can only have one cn=replica. And that cn=replica
> contains all it's RUV's in it. 
> 
> When you do say:
> 
> ldapsearch -b cn=config '(cn=replica)', that's a subtree search for all
> the "cn=replica" under cn=config tree, so we'll show all the replica
> details for all mapping trees,
> 
> Does that help at all? 
> 
>> 
>> Thank you again,
>>   Sergei
>> 
>>> No problem. I think there is an easier way to simulate this.
>>> 
>>> Make sure you have MMR setup (IE agreement from M1 -> M2, and M2 ->
>>> M1).
>>> 
>>> Then on both, there is an agreement object, something like:
>>> 
>>> cn=ExampleAgreement,cn=replica,cn=dc=example\,dc=com,cn=mapping
>>> tree,cn=config
>>> 
>>> To that object on *BOTH* masters add:
>>> 
>>> 
>>> nsds5ReplicaEnabled: off
>>> 
>>> This will pause all replication.
>>> 
>>> 
>>> Now, add your "user1" to both M1 and M2. Try to make them have the
>>> same
>>> DN, but different attributes like:
>>> 
>>> uid=user,ou=People,
>>> ...
>>> description: m1
>>> 
>>> uid=user,ou=People,
>>> ...
>>> description: m2
>>> 
>>> 
>>> Next, on both masters set:
>>> 
>>> 
>>> nsds5ReplicaEnabled: on
>>> 
>>> 
>>> This will trigger a replication update. You should have conflict
>>> entries on your servers now :) 
>>> 
>>> 
>>> Anyway, in reality, it's rare you'll ever see conflicts like this,
>>> but
>>> I'm glad you are researching this so thoroughly, 
>> 
>> ___
>> 389-users mailing list -- 389-users@lists.fedoraproject.org 
>> 
>> To unsubscribe send an email to 389-users-leave@lists.fedoraproject.o 
>> 
>> rg
> -- 
> Sincerely,
> 
> William Brown
> Software Engineer
> Red Hat, Australia/Brisbane
> ___
> 389-users mailing list -- 389-users@lists.fedoraproject.org 
> 
> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org 
> 
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: Solving Naming Conflicts

[Sergei Gerasenko]

Yep, that’s a very good tutorial indeed! To answer my own question then, since 
the default scope is sub and the filter is cn=replica, the replica entry is 
found?


> On Nov 9, 2017, at 5:03 PM, William Brown  wrote:
> 
> Hey mate,
> 
> I think this could really help you. I wrote a series of blog articles
> on starting with ldap. Start here and follow the "LDAP Guide ..." down
> the left.
> 
> Hope it helps you understand more about the datastructure. I think it
> will solve your questions :) 
> 
> https://fy.blackhats.net.au/blog/html/pages/ldap_guide_part_1_foundatio 
> 
> ns.html

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] performance tuning

[Sergei Gerasenko]

Hi,

I’ve been trying to estimate how optimal our settings are. I’ve read about the 
cn=monitor section and I see that there are several paths that have cn=monitor:

dn: cn=monitor,cn=ldbm database,cn=plugins,cn=config
dn: cn=monitor,cn=changelog,cn=ldbm database,cn=plugins,cn=config
dn: cn=monitor,cn=ipaca,cn=ldbm database,cn=plugins,cn=config
dn: cn=monitor,cn=userRoot,cn=ldbm database,cn=plugins,cn=config

First question, what’s the difference between them?

Here’s the output of ldapsearch for the 1st and 4th variants. Does anybody see 
something abnormal?


# => 'cn=monitor,cn=userRoot,cn=ldbm database,cn=plugins,cn=config’


dn: cn=monitor,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
cn: monitor
objectClass: top
objectClass: extensibleObject
database: ldbm database
readonly: 0
entrycachehits: 176959465
entrycachetries: 262445216
entrycachehitratio: 67
currententrycachesize: 10479044
maxentrycachesize: 10485760
currententrycachecount: 1409
maxentrycachecount: -1
dncachehits: 80627325
dncachetries: 80647850
dncachehitratio: 99
currentdncachesize: 1013607
maxdncachesize: 10485760
currentdncachecount: 9375
maxdncachecount: -1
normalizeddncachetries: 634018073
normalizeddncachehits: 633931903
normalizeddncachemisses: 86170
normalizeddncachehitratio: 99
currentnormalizeddncachesize: 19244372
maxnormalizeddncachesize: 20971520
currentnormalizeddncachecount: 86170
dbfilename-0: userRoot/nsds5ReplConflict.db
dbfilecachehit-0: 0
dbfilecachemiss-0: 3
dbfilepagein-0: 3
dbfilepageout-0: 0
dbfilename-1: userRoot/memberOf.db
dbfilecachehit-1: 188045
dbfilecachemiss-1: 4684
dbfilepagein-1: 4684
dbfilepageout-1: 1325
dbfilename-4: userRoot/cn.db
dbfilecachehit-4: 234345675
dbfilecachemiss-4: 69406
dbfilepagein-4: 69406
dbfilepageout-4: 6967
dbfilename-7: userRoot/numsubordinates.db
dbfilecachehit-7: 64
dbfilecachemiss-7: 143
dbfilepagein-7: 143
dbfilepageout-7: 148
dbfilename-8: userRoot/uid.db
dbfilecachehit-8: 23978617
dbfilecachemiss-8: 15927
dbfilepagein-8: 15927
dbfilepageout-8: 38
dbfilename-9: userRoot/fqdn.db
dbfilecachehit-9: 1719355
dbfilecachemiss-9: 187947
dbfilepagein-9: 187947
dbfilepageout-9: 440
dbfilename-10: userRoot/memberallowcmd.db
dbfilecachehit-10: 1615
dbfilecachemiss-10: 492
dbfilepagein-10: 492
dbfilepageout-10: 0
dbfilename-11: userRoot/krbPrincipalName.db
dbfilecachehit-11: 25458823
dbfilecachemiss-11: 484795
dbfilepagein-11: 484789
dbfilepageout-11: 9526
dbfilename-12: userRoot/member.db
dbfilecachehit-12: 114136
dbfilecachemiss-12: 13041
dbfilepagein-12: 13041
dbfilepageout-12: 11865
dbfilename-13: userRoot/memberUser.db
dbfilecachehit-13: 27275
dbfilecachemiss-13: 849
dbfilepagein-13: 849
dbfilepageout-13: 306
dbfilename-14: userRoot/nsuniqueid.db
dbfilecachehit-14: 95501
dbfilecachemiss-14: 11980
dbfilepagein-14: 11980
dbfilepageout-14: 181
dbfilename-16: userRoot/mail.db
dbfilecachehit-16: 196
dbfilecachemiss-16: 209
dbfilepagein-16: 209
dbfilepageout-16: 203
dbfilename-17: userRoot/parentid.db
dbfilecachehit-17: 14494
dbfilecachemiss-17: 2956
dbfilepagein-17: 2956
dbfilepageout-17: 432
dbfilename-19: userRoot/givenName.db
dbfilecachehit-19: 42
dbfilecachemiss-19: 44
dbfilepagein-19: 44
dbfilepageout-19: 38
dbfilename-20: userRoot/uidnumber.db
dbfilecachehit-20: 711150
dbfilecachemiss-20: 12493
dbfilepagein-20: 12493
dbfilepageout-20: 5
dbfilename-21: userRoot/ipauniqueid.db
dbfilecachehit-21: 38595230
dbfilecachemiss-21: 406501
dbfilepagein-21: 406501
dbfilepageout-21: 169
dbfilename-22: userRoot/ipasudorunasgroup.db
dbfilecachehit-22: 812
dbfilecachemiss-22: 242
dbfilepagein-22: 242
dbfilepageout-22: 0
dbfilename-23: userRoot/objectclass.db
dbfilecachehit-23: 1027902225
dbfilecachemiss-23: 49163
dbfilepagein-23: 49163
dbfilepageout-23: 3332
dbfilename-24: userRoot/memberdenycmd.db
dbfilecachehit-24: 803
dbfilecachemiss-24: 251
dbfilepagein-24: 251
dbfilepageout-24: 0
dbfilename-25: userRoot/ipakrbprincipalalias.db
dbfilecachehit-25: 7957213
dbfilecachemiss-25: 226
dbfilepagein-25: 226
dbfilepageout-25: 0
dbfilename-29: userRoot/id2entry.db
dbfilecachehit-29: 255566500
dbfilecachemiss-29: 9612037
dbfilepagein-29: 9612016
dbfilepageout-29: 54967
dbfilename-30: userRoot/ancestorid.db
dbfilecachehit-30: 21700375
dbfilecachemiss-30: 78004
dbfilepagein-30: 78004
dbfilepageout-30: 1112
dbfilename-31: userRoot/aci.db
dbfilecachehit-31: 1
dbfilecachemiss-31: 2
dbfilepagein-31: 2
dbfilepageout-31: 0
dbfilename-32: userRoot/ipasudorunas.db
dbfilecachehit-32: 1875
dbfilecachemiss-32: 512
dbfilepagein-32: 512
dbfilepageout-32: 18
dbfilename-33: userRoot/nscpEntryDN.db
dbfilecachehit-33: 61
dbfilecachemiss-33: 68
dbfilepagein-33: 68
dbfilepageout-33: 69
dbfilename-35: userRoot/sn.db
dbfilecachehit-35: 46
dbfilecachemiss-35: 52
dbfilepagein-35: 52
dbfilepageout-35: 46
dbfilename-36: userRoot/displayname.d

[389-users] Re: performance tuning

[Sergei Gerasenko]

Hi William,Thanks much for the quick response! This is super helpful. I’m attaching my cpu and meminfo info.dn: cn=monitor,cn=ldbm database,cn=plugins,cn=config^ This monitors the general BDB performance.Got it.dn: cn=monitor,cn=changelog,cn=ldbm database,cn=plugins,cn=configdn: cn=monitor,cn=ipaca,cn=ldbm database,cn=plugins,cn=configdn: cn=monitor,cn=userRoot,cn=ldbm database,cn=plugins,cn=config^ These are monitors of unique suffixes and their indexes and othercontent like entrycaches that are per backend. Cool. One question I’ve been meaning to ask — what’s under userRoot in general?entrycachehitratio: 67^ this 5 is super important. This is saying you have only hit 67% ofthe time. You really want this to be 85% or higher, else you areconstantly importing/evicting from the entry cache. Every eviction andinclusion is costly as you have to-reread id2entry which is iointensive.I'd recommend increasing your entry cache size by double at a guess,but I'd want to see your /proc/meminfo and /proc/cpuinfo to adviseproperly. I'd also need to see your ds version and userroot config toreally advise what changes to make. Great info! I think we have plenty of RAM (64G) to make any adjustment we want.I’ve also heard of nsslapd-cachememsize — what does that control?Thanks so much, William!!Sergeicat /proc/cpuinfo
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 63
model name  : Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz
stepping: 2
microcode   : 0x38
cpu MHz : 2799.976
cache size  : 20480 KB
physical id : 0
siblings: 16
core id : 0
cpu cores   : 8
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 15
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss h
t tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts 
rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu
pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 fma cx16 xtpr pdcm 
pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadl
ine_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb pln pts dtherm 
tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_ad
just bmi1 avx2 smep bmi2 erms invpcid cqm xsaveopt cqm_llc cqm_occup_llc
bogomips: 5194.03
clflush size: 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:

processor   : 1
vendor_id   : GenuineIntel
cpu family  : 6
model   : 63
model name  : Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz
stepping: 2
microcode   : 0x38
cpu MHz : 2799.976
cache size  : 20480 KB
physical id : 1
siblings: 16
core id : 0
cpu cores   : 8
apicid  : 16
initial apicid  : 16
fpu : yes
fpu_exception   : yes
cpuid level : 15
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss h
t tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts 
rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu
pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 fma cx16 xtpr pdcm 
pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadl
ine_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb pln pts dtherm 
tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_ad
just bmi1 avx2 smep bmi2 erms invpcid cqm xsaveopt cqm_llc cqm_occup_llc
bogomips: 5198.12
clflush size: 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:

processor   : 2
vendor_id   : GenuineIntel
cpu family  : 6
model   : 63
model name  : Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz
stepping: 2
microcode   : 0x38
cpu MHz : 2799.976
cache size  : 20480 KB
physical id : 0
siblings: 16
core id : 1
cpu cores   : 8
apicid  : 2
initial apicid  : 2
fpu : yes
fpu_exception   : yes
cpuid level : 15
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss h
t tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts 
rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu
pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 fma cx16 xtpr pdcm 
pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadl
ine_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb pln pts dtherm 
tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_ad
just bmi1 avx2 smep bmi2 erms invpcid cqm xsaveopt cqm_llc cqm_occup_llc
bogomips: 5194.03
clflush size: 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:

processor   : 3
vendor_id   : GenuineIntel
cpu family  : 6
model   : 63
model n

[389-users] Re: performance tuning

[Sergei Gerasenko]

Here’s my emergency ldif for now:

dn: cn=changelog,cn=ldbm database,cn=plugins,cn=config
changetype: modify
replace: nsslapd-dncachememsize
nsslapd-dncachememsize: 30
-
replace: nsslapd-cachememsize
nsslapd-cachememsize: 30

dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config
changetype: modify
replace: nsslapd-dncachememsize
nsslapd-dncachememsize: 30
-
replace: nsslapd-cachememsize
nsslapd-cachememsize: 30

I will configure auto cache resizing later. Do I need to restart the service 
after the change?

Thanks,
  Sergei

> On Nov 16, 2017, at 9:37 PM, William Brown  wrote:
> 
> On Thu, 2017-11-16 at 21:00 -0600, Sergei Gerasenko wrote:
>> Hi,
>> 
>> I’ve been trying to estimate how optimal our settings are. I’ve read
>> about the cn=monitor section and I see that there are several paths
>> that have cn=monitor:
> 
> These are all monitors for each database backend. So you have: 
> 
>> 
>> dn: cn=monitor,cn=ldbm database,cn=plugins,cn=config
> ^ This monitors the general BDB performance.
> 
>> dn: cn=monitor,cn=changelog,cn=ldbm database,cn=plugins,cn=config
>> dn: cn=monitor,cn=ipaca,cn=ldbm database,cn=plugins,cn=config
>> dn: cn=monitor,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
>> 
> 
> ^ These are monitors of unique suffixes and their indexes and other
> content like entrycaches that are per backend. 
> 
> So each of them can reveal different info.
> 
> BDB can show you about the interaction between DS and the BDB on disk.
> So this can have some IO related impact for *all* backends. 
> 
> Then each backend monitor can help you understand the performance of
> indexes, entry cache and others. So let me help interpret yours:
> 
> 
>> First question, what’s the difference between them?
>> 
>> Here’s the output of ldapsearch for the 1st and 4th variants. Does
>> anybody see something abnormal?
>> 
>> ---
>> -
>> # => 'cn=monitor,cn=userRoot,cn=ldbm database,cn=plugins,cn=config’
>> ---
>> -
>> 
>> dn: cn=monitor,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
>> cn: monitor
>> objectClass: top
>> objectClass: extensibleObject
>> database: ldbm database
>> readonly: 0
>> entrycachehits: 176959465
>> entrycachetries: 262445216
>> entrycachehitratio: 67
> 
> ^ this 5 is super important. This is saying you have only hit 67% of
> the time. You really want this to be 85% or higher, else you are
> constantly importing/evicting from the entry cache. Every eviction and
> inclusion is costly as you have to-reread id2entry which is io
> intensive.
> 
> I'd recommend increasing your entry cache size by double at a guess,
> but I'd want to see your /proc/meminfo and /proc/cpuinfo to advise
> properly. I'd also need to see your ds version and userroot config to
> really advise what changes to make. 
> 
> 
>> currententrycachesize: 10479044
>> maxentrycachesize: 10485760
>> currententrycachecount: 1409
>> maxentrycachecount: -1
>> dncachehits: 80627325
>> dncachetries: 80647850
>> dncachehitratio: 99
> 
> This number is good, what you want to see. 
> 
>> currentdncachesize: 1013607
>> maxdncachesize: 10485760
>> currentdncachecount: 9375
>> maxdncachecount: -1
>> normalizeddncachetries: 634018073
>> normalizeddncachehits: 633931903
>> normalizeddncachemisses: 86170
>> normalizeddncachehitratio: 99
> 
> Again, also good, 
> 
>> currentnormalizeddncachesize: 19244372
>> maxnormalizeddncachesize: 20971520
>> currentnormalizeddncachecount: 86170
>> dbfilename-0: userRoot/nsds5ReplConflict.db
>> dbfilecachehit-0: 0
>> dbfilecachemiss-0: 3
>> dbfilepagein-0: 3
>> dbfilepageout-0: 0
>> dbfilename-1: userRoot/memberOf.db
>> dbfilecachehit-1: 188045
>> dbfilecachemiss-1: 4684
>> dbfilepagein-1: 4684
>> dbfilepageout-1: 1325
>> dbfilename-4: userRoot/cn.db
>> dbfilecachehit-4: 234345675
>> dbfilecachemiss-4: 69406
>> dbfilepagein-4: 69406
>> dbfilepageout-4: 6967
>> dbfilename-7: userRoot/numsubordinates.db
>> dbfilecachehit-7: 64
>> dbfilecachemiss-7: 143
>> dbfilepagein-7: 143
>> dbfilepageout-7: 148
>> dbfilename-8: userRoot/uid.db
>> dbfilecachehit-8: 23978617
>> dbfilecachemiss-8: 15927
>> dbfilepagein-8: 15927
>> dbfilepageout-8: 38
>> dbfilename-9: userRoot/fqdn.db
>> dbfilecachehit-9: 1719355
>

[389-users] Re: performance tuning

[Sergei Gerasenko]

Thanks, Mark!!

> On Nov 17, 2017, at 10:58 AM, Mark Reynolds  wrote:
> 
> 
> 
> On 11/17/2017 11:45 AM, Sergei Gerasenko wrote:
>> dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config
>> changetype: modify
>> replace: nsslapd-dncachememsize
>> nsslapd-dncachememsize: 30
>> -
>> replace: nsslapd-cachememsize
>> nsslapd-cachememsize: 30
> After these changes you do need to restart
> 

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: performance tuning

[Sergei Gerasenko]

The change went in and the machine’s cache rate is currently at 91. woot!

> On Nov 17, 2017, at 11:46 AM, Sergei Gerasenko  wrote:
> 
> Thanks, Mark!!
> 
>> On Nov 17, 2017, at 10:58 AM, Mark Reynolds > <mailto:mreyno...@redhat.com>> wrote:
>> 
>> 
>> 
>> On 11/17/2017 11:45 AM, Sergei Gerasenko wrote:
>>> dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config
>>> changetype: modify
>>> replace: nsslapd-dncachememsize
>>> nsslapd-dncachememsize: 30
>>> -
>>> replace: nsslapd-cachememsize
>>> nsslapd-cachememsize: 30
>> After these changes you do need to restart
>> 
> 

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: performance tuning

[Sergei Gerasenko]

Hi William,

> So to really answer that I should explain the LDAP data model.
> 
> You have a set of objects, in a tree database. The RootDSE (you can
> search with -b '' -s base by the way with ldapsearch) is the ... well,
> root. Under than you have "suffixes", like dc=com and
> dc=example,dc=com. 

Confirmed

> So we connect those "suffixes" with "mapping trees". Think "routers"
> that connect a suffix to a backend of some kind.
> 
> Then that backend stories entries: that's the "userRoot". It's a
> backend which is connected by a mapping tree to route queries to it.

Ok, so when issue requests for entries under dc=example,dc=com and they get 
translated by a mapping tree to a physical db file. I noticed that if I specify 
the base dn as “cn=config”, I don’t see user account data for example. When I 
bind under “dc=example,dc=com” however, I do! Is that because when I bind under 
cn=config, I don’t go through a mapping tree, but when I bind with 
"dc=example,dc=com” I do? I of course use our company name instead of 
“dc=example,dc=com”.

> You can really get an idea of this by looking at what's in "userRoot".
> If you look at:
> 
> cd /var/lib/dirsrv/slapd-/db/userRoot
> 
> dbscan -f id2entry.db | less

Nice

> So having your entrycache "as large or larger" than id2entry.db is a
> great idea, because then you never need to incur the performance
> penalty of accessing id2entry.

Great info again. Quick question though. There are at least two types of cache 
I’ve seen: the entry cache, and the dn cache. I think the entry cache 
corresponds to id2entry.db, right? What corresponds to the dn cache?

Also: do ipa services need to be stopped when using the ipa-backup utility?

Thanks again,
  Sergei___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: performance tuning

[Sergei Gerasenko]

> cn=config is special, that's why :) You should generally ignore it for
> these discussions about backends and databases. 

not to annoy, but what’s special about it? A quick question about the 
terminology: what’s a backend? The physical db files on disk?

> So if you look at the entries from id2entry you'll notice that they
> don't have dn's rdns. IE:
> 
> uid=william
> 
> Does that help? 

Well explained. Thank you!

So what are the rules of thumb for choosing the sizes of these databases? 
Currently, I just set both cache sizes to 3G because I have the memory.





___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] BER Size

[Sergei Gerasenko]

Hi,

I just discovered that I have a mismatch of BER sizes (nsslapd-maxbersize) 
between some of my masters. On the masters that we consider the authorative 
ones, the BER size is (cough, cough) 209M while in the rest of the environment 
is the default 2M. I do see occasional errors on the 2M masters complaining and 
suggesting to increase the BER size. A couple of questions:

1. If the BER size of the supplier exceeds that of the consumer, will it be 
automatically split into smaller chunks or will the update just fail without 
any retries?
2. Should I match the BER size accross the environment? I think it’s obvious, 
but still asking just in case.

Thanks!
   Sergei
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: BER Size

[Sergei Gerasenko]

389-ds-base-1.3.5.10-21.el7_3.x86_64. I do see errors like:

connection - conn=1414256 fd=745 Incoming BER Element was too long, max 
allowable is 2097152 bytes. Change the nsslapd-maxbersize attribute in 
cn=config to increase.


> On Dec 6, 2017, at 10:47 AM, Viktor Ashirov  wrote:
> 
> Hi,
> On Wed, Dec 06 2017 at 10:34:05 -0600, Sergei Gerasenko  
> wrote:
>> Hi,
>> 
>> I just discovered that I have a mismatch of BER sizes (nsslapd-maxbersize) 
>> between some of my masters. On the masters that we consider the authorative 
>> ones, the BER size is (cough, cough) 209M while in the rest of the 
>> environment is the default 2M. I do see occasional errors on the 2M masters 
>> complaining and suggesting to increase the BER size. A couple of questions:
>> 
>> 1. If the BER size of the supplier exceeds that of the consumer, will it be 
>> automatically split into smaller chunks or will the update just fail without 
>> any retries?
>> 2. Should I match the BER size accross the environment? I think it’s 
>> obvious, but still asking just in case.
> What version of 389-ds-base do you have? BER size should be ignored [1]
> in replication in versions >=389-ds-base-1.3.5.2-1.el7
> 
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1223510
>> 
>> Thanks!
>>   Sergei
>> ___
>> 389-users mailing list -- 389-users@lists.fedoraproject.org
>> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: BER Size

[Sergei Gerasenko]

Another master

> On Dec 6, 2017, at 11:01 AM, Viktor Ashirov  wrote:
> 
> On Wed, Dec 06 2017 at 10:53:49 -0600, Sergei Gerasenko  
> wrote:
>> 389-ds-base-1.3.5.10-21.el7_3.x86_64. I do see errors like:
>> 
>> connection - conn=1414256 fd=745 Incoming BER Element was too long, max 
>> allowable is 2097152 bytes. Change the nsslapd-maxbersize attribute in 
>> cn=config to increase.
> Is this connection coming from the other master? Or some client
> connection?
>> 
>> 
>>> On Dec 6, 2017, at 10:47 AM, Viktor Ashirov  wrote:
>>> 
>>> Hi,
>>> On Wed, Dec 06 2017 at 10:34:05 -0600, Sergei Gerasenko  
>>> wrote:
>>>> Hi,
>>>> 
>>>> I just discovered that I have a mismatch of BER sizes (nsslapd-maxbersize) 
>>>> between some of my masters. On the masters that we consider the 
>>>> authorative ones, the BER size is (cough, cough) 209M while in the rest of 
>>>> the environment is the default 2M. I do see occasional errors on the 2M 
>>>> masters complaining and suggesting to increase the BER size. A couple of 
>>>> questions:
>>>> 
>>>> 1. If the BER size of the supplier exceeds that of the consumer, will it 
>>>> be automatically split into smaller chunks or will the update just fail 
>>>> without any retries?
>>>> 2. Should I match the BER size accross the environment? I think it’s 
>>>> obvious, but still asking just in case.
>>> What version of 389-ds-base do you have? BER size should be ignored [1]
>>> in replication in versions >=389-ds-base-1.3.5.2-1.el7
>>> 
>>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1223510
>>>> 
>>>> Thanks!
>>>>  Sergei
>>>> ___
>>>> 389-users mailing list -- 389-users@lists.fedoraproject.org
>>>> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: BER Size

[Sergei Gerasenko]

> So my advice - Sometimes we see this error when you use ldaps:// to a
> plaintext port IE ldaps://hostname:389. Is this possibly the issue you
> have replication set to SSL to a plaintext port?

I think in that case the message is:

Connection - conn=167482 fd=121 Incoming BER Element was 3 bytes, max allowable 
is 2097152 bytes. Change the nsslapd-maxbersize attribute in cn=config to 
increase.

Note that it mentions the element size of 3 bytes. In the case in this thread 
however I don’t see a size mentioned:

ns-slapd[45565]: [02/Dec/2017:22:47:52.520338378 +] connection - 
conn=1229556 fd=588 Incoming BER Element was too long, max allowable is 2097152 
bytes. Change the nsslapd-maxbersize attribute in cn=config to increase.

This makes me think it’s a different situation. I would imagine it shouldn’t 
have been logged if it was ignored? But it’s possible...

Thanks,
  Sergei___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] monitoring

[Sergei Gerasenko]

Hello,

I’m trying to set up collectd to monitor 389-ds by using the values under 
cn=monitor. Is there something out there (e.g., a collectd plugin?) that could 
do this? I’ve seen this: 
http://directory.fedoraproject.org/docs/389ds/howto/howto-cn-equals-monitor-ldap-monitoring.html
 
,
 but that requires MySQL or Postgres.

Thanks,
  Sergei___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: monitoring

[Sergei Gerasenko]

Thank you for the ref to the post. In absense of anything else, I might go with 
the python solution. If there’s an easier way though, I’m also interested.


> On Dec 14, 2017, at 6:23 PM, Marc Sauton  wrote:
> 
> There is no collectd 389-ds plug-in, but there was a post with an example:
> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org/thread/TTKWB7WA4NEHYM5GDPLDJVIMR34DKNT2/
>  
> <https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org/thread/TTKWB7WA4NEHYM5GDPLDJVIMR34DKNT2/>
> May be other users already run some similar plug-in?
> Should we have such plug-in?
> Thanks,
> M.
> 
> On Thu, Dec 14, 2017 at 2:45 PM, Sergei Gerasenko  <mailto:gera...@gmail.com>> wrote:
> Hello,
> 
> I’m trying to set up collectd to monitor 389-ds by using the values under 
> cn=monitor. Is there something out there (e.g., a collectd plugin?) that 
> could do this? I’ve seen this: 
> http://directory.fedoraproject.org/docs/389ds/howto/howto-cn-equals-monitor-ldap-monitoring.html
>  
> <http://directory.fedoraproject.org/docs/389ds/howto/howto-cn-equals-monitor-ldap-monitoring.html>,
>  but that requires MySQL or Postgres.
> 
> Thanks,
>   Sergei
> 
> ___
> 389-users mailing list -- 389-users@lists.fedoraproject.org 
> <mailto:389-users@lists.fedoraproject.org>
> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org 
> <mailto:389-users-le...@lists.fedoraproject.org>
> 
> 
> ___
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: monitoring

[Sergei Gerasenko]

I’ve implemented the solution described in the thread. My question now is: what 
should I really monitor? 

There are so many metrics to consider. The thread talks about 
cn=snmp,cn=monitor. But there are also cn=monitor suffixes under each backend 
for example. Is there a recommended mininum set of things to monitor?

>> On Dec 14, 2017, at 6:23 PM, Marc Sauton > > wrote:
>> 
>> There is no collectd 389-ds plug-in, but there was a post with an example:
>> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org/thread/TTKWB7WA4NEHYM5GDPLDJVIMR34DKNT2/
>>  
>> 
>> May be other users already run some similar plug-in?
>> Should we have such plug-in?
>> Thanks,

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: monitoring

[Sergei Gerasenko]

Excellent info, Mark. Thank you. I’m using collectd for graphing the results 
and since the backend trees are not readable by everyone, I’m thinking of 
granting read access to the collectd account. 

Is an ldif like the one below the right way to do it:

dn: cn=monitor,cn=ldbm database,cn=plugins,cn=config
changetype: modify
add: aci
aci: (target ="ldap:///cn=monitor,cn=ldbm 
database,cn=plugins,cn=config")(targetattr != "aci || connection")(version 3.0; 
acl “collectd access"; allow( read, search, compare ) userdn = 
"ldap:///uid=collectd,cn=users,cn=accounts,dc=mydomain,dc=net”;)

Thanks!
  Sergei

> On Dec 21, 2017, at 3:20 PM, Marc Sauton  wrote:
> 
> The SNMP counters are not always interesting, but they can provide the system 
> memory use and some LDAP BIND info.
> 
> Under
> cn=monitor , the most important are:
> the difference between opsinitiated and opscompleted
> and also
> threads
> currentconnections
> and
> backendmonitordn
> 
> so under
> cn=monitor,cn=,cn=ldbm\ database,cn=plugins,cn=config 
> objectclass=*
> like for example
> dn: cn=monitor,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
> the following are important:
> entrycachehitratio
> currententrycachesize
> maxentrycachesize
> dncachehitratio
> currentdncachesize
> maxdncachesize
> and the pagein and pageout values if too high
> 
> 
> under
> cn=monitor,cn=ldbm\ database,cn=plugins,cn=config
> nsslapd-db-current-locks
> nsslapd-db-configured-locks
> nsslapd-db-page-ro-evict-rate
> nsslapd-db-page-rw-evict-rate
> 
> 
> the dbmon.sh tool can provide some info/hints/details
> 
> for replication, the attribute
> nsDS5ReplicaLastUpdateStatus
> nsDS5ReplConflict
> nsruvReplicaLastModified
> 
> /usr/bin/ldapsearch -xLLL -h xx -p xx -D "cn=directory manager" -W -b 
> "cn=mapping tree,cn=config" 
> "(&(objectClass=nsDS5ReplicationAgreement)(nsDS5ReplicaHost=*)(nsDS5ReplicaPort=xx))"
>  nsDS5ReplicaChangesSentSinceStartup nsDS5ReplicaLastUpdateStatus 
> nsDS5ReplicaUpdateInProgress nsDS5ReplicaLastUpdateStart 
> nsDS5ReplicaLastUpdateEnd
> 
> /usr/bin/ldapsearch -LLLx -o ldif-wrap=no -D "cn=directory manager" -W -b 
> dc=example,dc=com nsds5ReplConflict=* dn cn 
> 
> see 
> https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/managing_replication-monitoring_replication_status
>  
> <https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/managing_replication-monitoring_replication_status>
> http://www.port389.org/docs/389ds/howto/howto-replicationmonitoring.html 
> <http://www.port389.org/docs/389ds/howto/howto-replicationmonitoring.html>
> 
> there is also an old tool called
> repl-monitor.pl <http://repl-monitor.pl/>
> from the "Admin Express" feature, HTML colored page:
> https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/managing_replication-monitoring_replication_status#replication-monitoring
>  
> <https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/managing_replication-monitoring_replication_status#replication-monitoring>
> 
> I may have forgotten some attributes.
> Thanks,
> M.
> 
> On Thu, Dec 21, 2017 at 11:50 AM, Sergei Gerasenko  <mailto:gera...@gmail.com>> wrote:
> I’ve implemented the solution described in the thread. My question now is: 
> what should I really monitor? 
> 
> There are so many metrics to consider. The thread talks about 
> cn=snmp,cn=monitor. But there are also cn=monitor suffixes under each backend 
> for example. Is there a recommended mininum set of things to monitor?
> 
>>> On Dec 14, 2017, at 6:23 PM, Marc Sauton >> <mailto:msau...@redhat.com>> wrote:
>>> 
>>> There is no collectd 389-ds plug-in, but there was a post with an example:
>>> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org/thread/TTKWB7WA4NEHYM5GDPLDJVIMR34DKNT2/
>>>  
>>> <https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org/thread/TTKWB7WA4NEHYM5GDPLDJVIMR34DKNT2/>
>>> May be other users already run some similar plug-in?
>>> Should we have such plug-in?
>>> Thanks,
> 
> 
> ___
> 389-users mailing list -- 389-users@lists.fedoraproject.org 
> <mailto:389-users@lists.fedoraproject.org>
> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org 
> <mailto:389-users-le...@lists.fedoraproject.org>
> 
> 
> ___
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: monitoring

[Sergei Gerasenko]

Cool. Another question: just going off the snmp,monitor path, I’m graphing 
searchops and errors. Here’s what that looks like:



As you can see, the search ops correspond exactly to the error peaks. The error 
logs are empty though. Is this correlation of any concern? How can I get more 
detail on the errors metric?

Thanks,
  Sergei

> On Dec 21, 2017, at 5:46 PM, Marc Sauton  wrote:
> 
> That should work.
> Thanks,
> M.
> 
> On Thu, Dec 21, 2017 at 1:49 PM, Sergei Gerasenko  <mailto:gera...@gmail.com>> wrote:
> Excellent info, Mark. Thank you. I’m using collectd for graphing the results 
> and since the backend trees are not readable by everyone, I’m thinking of 
> granting read access to the collectd account. 
> 
> Is an ldif like the one below the right way to do it:
> 
> dn: cn=monitor,cn=ldbm database,cn=plugins,cn=config
> changetype: modify
> add: aci
> aci: (target ="ldap:///cn=monitor,cn=ldbm <> 
> database,cn=plugins,cn=config")(targetattr != "aci || connection")(version 
> 3.0; acl “collectd access"; allow( read, search, compare ) userdn = 
> "ldap:///uid=collectd,cn=users,cn=accounts,dc=mydomain,dc=net <>”;)
> 
> Thanks!
>   Sergei
> 
>> On Dec 21, 2017, at 3:20 PM, Marc Sauton > <mailto:msau...@redhat.com>> wrote:
>> 
>> The SNMP counters are not always interesting, but they can provide the 
>> system memory use and some LDAP BIND info.
>> 
>> Under
>> cn=monitor , the most important are:
>> the difference between opsinitiated and opscompleted
>> and also
>> threads
>> currentconnections
>> and
>> backendmonitordn
>> 
>> so under
>> cn=monitor,cn=,cn=ldbm\ database,cn=plugins,cn=config 
>> objectclass=*
>> like for example
>> dn: cn=monitor,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
>> the following are important:
>> entrycachehitratio
>> currententrycachesize
>> maxentrycachesize
>> dncachehitratio
>> currentdncachesize
>> maxdncachesize
>> and the pagein and pageout values if too high
>> 
>> 
>> under
>> cn=monitor,cn=ldbm\ database,cn=plugins,cn=config
>> nsslapd-db-current-locks
>> nsslapd-db-configured-locks
>> nsslapd-db-page-ro-evict-rate
>> nsslapd-db-page-rw-evict-rate
>> 
>> 
>> the dbmon.sh tool can provide some info/hints/details
>> 
>> for replication, the attribute
>> nsDS5ReplicaLastUpdateStatus
>> nsDS5ReplConflict
>> nsruvReplicaLastModified
>> 
>> /usr/bin/ldapsearch -xLLL -h xx -p xx -D "cn=directory manager" -W -b 
>> "cn=mapping tree,cn=config" 
>> "(&(objectClass=nsDS5ReplicationAgreement)(nsDS5ReplicaHost=*)(nsDS5ReplicaPort=xx))"
>>  nsDS5ReplicaChangesSentSinceStartup nsDS5ReplicaLastUpdateStatus 
>> nsDS5ReplicaUpdateInProgress nsDS5ReplicaLastUpdateStart 
>> nsDS5ReplicaLastUpdateEnd
>> 
>> /usr/bin/ldapsearch -LLLx -o ldif-wrap=no -D "cn=directory manager" -W -b 
>> dc=example,dc=com nsds5ReplConflict=* dn cn 
>> 
>> see 
>> https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/managing_replication-monitoring_replication_status
>>  
>> <https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/managing_replication-monitoring_replication_status>
>> http://www.port389.org/docs/389ds/howto/howto-replicationmonitoring.html 
>> <http://www.port389.org/docs/389ds/howto/howto-replicationmonitoring.html>
>> 
>> there is also an old tool called
>> repl-monitor.pl <http://repl-monitor.pl/>
>> from the "Admin Express" feature, HTML colored page:
>> https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/managing_replication-monitoring_replication_status#replication-monitoring
>>  
>> <https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/managing_replication-monitoring_replication_status#replication-monitoring>
>> 
>> I may have forgotten some attributes.
>> Thanks,
>> M.
>> 
>> On Thu, Dec 21, 2017 at 11:50 AM, Sergei Gerasenko > <mailto:gera...@gmail.com>> wrote:
>> I’ve implemented the solution described in the thread. My question now is: 
>> what should I really monitor? 
>> 
>> There are so many metrics to consider. The thread talks about 
>> cn=snmp,cn=monitor. But there are also cn=monitor suffixes under each 
>> backend for example. Is there a recommended mininum set of things to monitor?
>> 

[389-users] Re: monitoring

[Sergei Gerasenko]

> What is an "error" in your data?

The “error” graph graphs the “errors” attribute from cn=snmp,cn=monitor. I 
don’t know what conditions actually increment that value.___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: monitoring

[Sergei Gerasenko]

dn: cn=monitor,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
changetype: modify
add: aci
aci: (target ="ldap:///cn=monitor,cn=userRoot,cn=ldbm 
database,cn=plugins,cn=config")(targetattr != "aci || connection")(version 3.0; 
acl "monitor3"; allow( read, search, compare ) userdn = "ldap:///anyone";;)

Odd, but when I try to apply the above ldif, I get "ldap_modify: Server is 
unwilling to perform (53)”. 

If I stop the server and modify dse.ldif manually, it does seem to work.


___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: monitoring

[Sergei Gerasenko]

So does anybody have more details on the errors attribute under 
cn=snmp,cn=monitor? Should I increase the log level to see what the errors are? 
If so, can you tell me how?

> On Dec 24, 2017, at 10:46 AM, Sergei Gerasenko  wrote:
> 
>> What is an "error" in your data?
> 
> The “error” graph graphs the “errors” attribute from cn=snmp,cn=monitor. I 
> don’t know what conditions actually increment that value.

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: monitoring

[Sergei Gerasenko]

Digging deeper into the access log, I see that certain operations return with 
non-zero error codes. The most prolific are 14 and 32. These are 
LDAP_SASL_BIND_IN_PROGRESS and LDAP_NO_SUCH_OBJECT respectively. So *maybe* the 
SNMP counter is incremented on those error codes. I’m currently looking at the 
source code trying to confirm that. I couldn’t find the definitions of those 
codes in the 389-ds-base source base. I found them here (of all places): 
https://docs.oracle.com/cd/E19957-01/817-6707/resultcodes.html#wp30446 
<https://docs.oracle.com/cd/E19957-01/817-6707/resultcodes.html#wp30446> I know 
it’s a totally different code base, but it appears to share some standards with 
the 389-ds implementation. 

> On Jan 3, 2018, at 10:16 AM, Sergei Gerasenko  wrote:
> 
> So does anybody have more details on the errors attribute under 
> cn=snmp,cn=monitor? Should I increase the log level to see what the errors 
> are? If so, can you tell me how?
> 
>> On Dec 24, 2017, at 10:46 AM, Sergei Gerasenko > <mailto:gera...@gmail.com>> wrote:
>> 
>>> What is an "error" in your data?
>> 
>> The “error” graph graphs the “errors” attribute from cn=snmp,cn=monitor. I 
>> don’t know what conditions actually increment that value.
> 

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: monitoring

[Sergei Gerasenko]

Ok, thank you. I think the exact description of that counter is (from 
389-ds-base-1.3.5.10/ldap/servers/snmp/redhat-directory.mib):

dsErrors  OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
  " Number of operations that could not be serviced
due to errors other than security errors, and
referrals.
A partially serviced operation will not be counted
as an error.
The errors include NameErrors, UpdateErrors, Attribute
errors and ServiceErrors."
REFERENCE
  " CCITT Blue Book Fascicle VIII.8 - Rec. X.511, 1988:
Sections 12.4, 12.5, 12.8 & 12.9. and, RFC1777 Section 4."
::= {dsOpsEntry 20}

Didn’t know about logconv.pl. Nice tip. Running it with -ej produced:

- Errors -

err=0  9560Successful Operations
err=14  330SASL Bind in Progress
err=32  161No Such Object

- Recommendations -

 1.  You have unindexed components, this can be caused from a search on an 
unindexed attribute, or your returned results exceeded the allidsthreshold.  
Unindexed components are not recommended. To refuse unindexed searches, switch 
'nsslapd-require-index' to 'on' under your database entry (e.g. 
cn=UserRoot,cn=ldbm database,cn=plugins,cn=config).

 2.  You have a significant difference between binds and unbinds.  You may want 
to investigate this difference.

For #1, can I identify the unindexed attributes and create the indeces? For #2, 
does it mean that some binds hang around without being closed? What’s the best 
way to investigate #2 further?

Thanks, Mark.



> Any time an error occurs on a search or write operation this counter is 
> incremented.  Look in the DS access logs for anything that is not "err=0" to 
> see what the exact errors are.  I suggest running logconv.pl to make this 
> easier:
> 
> # logconv.pl -e /var/log/dirsrv/slapd-YOUR_INSTANCE/access*
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: monitoring

[Sergei Gerasenko]

For #1, I see the -u option, which does give me the name of the unindexed 
entries. So, I think I can figure this one out from here.

> On Jan 3, 2018, at 11:58 AM, Sergei Gerasenko  wrote:
> 
> Ok, thank you. I think the exact description of that counter is (from 
> 389-ds-base-1.3.5.10/ldap/servers/snmp/redhat-directory.mib):
> 
> dsErrors  OBJECT-TYPE
> SYNTAX Counter64
> MAX-ACCESS read-only
> STATUS current
> DESCRIPTION
>   " Number of operations that could not be serviced
> due to errors other than security errors, and
> referrals.
> A partially serviced operation will not be counted
> as an error.
> The errors include NameErrors, UpdateErrors, Attribute
> errors and ServiceErrors."
> REFERENCE
>   " CCITT Blue Book Fascicle VIII.8 - Rec. X.511, 1988:
> Sections 12.4, 12.5, 12.8 & 12.9. and, RFC1777 Section 4."
> ::= {dsOpsEntry 20}
> 
> Didn’t know about logconv.pl. Nice tip. Running it with -ej produced:
> 
> - Errors -
> 
> err=0  9560Successful Operations
> err=14  330SASL Bind in Progress
> err=32  161No Such Object
> 
> - Recommendations -
> 
>  1.  You have unindexed components, this can be caused from a search on an 
> unindexed attribute, or your returned results exceeded the allidsthreshold.  
> Unindexed components are not recommended. To refuse unindexed searches, 
> switch 'nsslapd-require-index' to 'on' under your database entry (e.g. 
> cn=UserRoot,cn=ldbm database,cn=plugins,cn=config).
> 
>  2.  You have a significant difference between binds and unbinds.  You may 
> want to investigate this difference.
> 
> For #1, can I identify the unindexed attributes and create the indeces? For 
> #2, does it mean that some binds hang around without being closed? What’s the 
> best way to investigate #2 further?
> 
> Thanks, Mark.
> 
> 
> 
>> Any time an error occurs on a search or write operation this counter is 
>> incremented.  Look in the DS access logs for anything that is not "err=0" to 
>> see what the exact errors are.  I suggest running logconv.pl to make this 
>> easier:
>> 
>> # logconv.pl -e /var/log/dirsrv/slapd-YOUR_INSTANCE/access*

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: monitoring

[Sergei Gerasenko]

Cool, you saved me a lot of time. Quick question: where are all these constants 
(LDAP_SUCCESS, etc) defined?

> On Jan 3, 2018, at 12:11 PM, Mark Reynolds  wrote:
> 
> 
> 
> On 01/03/2018 12:37 PM, Sergei Gerasenko wrote:
>> Digging deeper into the access log, I see that certain operations return 
>> with non-zero error codes. The most prolific are 14 and 32. These are 
>> LDAP_SASL_BIND_IN_PROGRESS and LDAP_NO_SUCH_OBJECT respectively. So *maybe* 
>> the SNMP counter is incremented on those error codes. I’m currently looking 
>> at the source code trying to confirm that.
> It's in ldap/servers/slapd/result.c:367
> 
> if (err != LDAP_SUCCESS) {
> /* count the error for snmp */
> /* first check for security errors */
> if (err == LDAP_INVALID_CREDENTIALS || err == LDAP_INAPPROPRIATE_AUTH 
> || err == LDAP_AUTH_METHOD_NOT_SUPPORTED || err == 
> LDAP_STRONG_AUTH_NOT_SUPPORTED || err == LDAP_STRONG_AUTH_REQUIRED || err == 
> LDAP_CONFIDENTIALITY_REQUIRED || err == LDAP_INSUFFICIENT_ACCESS || err == 
> LDAP_AUTH_UNKNOWN) {
> 
> slapi_counter_increment(g_get_global_snmp_vars()->ops_tbl.dsSecurityErrors);
> } else if (err != LDAP_REFERRAL && err != LDAP_OPT_REFERRALS && err 
> != LDAP_PARTIAL_RESULTS) {
> /*madman man spec says not to count as normal errors
> --security errors
> --referrals
> -- partially seviced operations will not be conted as an error
>   */
> 
> slapi_counter_increment(g_get_global_snmp_vars()->ops_tbl.dsErrors);
> }
> }
> 
> And yes err=32 is no such object (common error code especially if you are 
> using the 389-console), and err=14 is normal during GSSAPI binds.

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: monitoring

[Sergei Gerasenko]

Aha, I should have thought of that. Thanks

> On Jan 3, 2018, at 12:51 PM, Mark Reynolds  wrote:
> 
> Checkout /usr/include/ldap.h

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Upgrading from 1.3.5.10-21 to 1.3.6-1.24

[Sergei Gerasenko]

Hello,

I’m getting ready to upgrade from 1.3.5 to 1.3.6 and I’m wondering if there are 
any possible issues with this. I’ve heard that the replication protocol has 
changed in regards to the replication protocol for example. Anything else to be 
concerned about in terms of the schema changes, etc?

Thanks for any insight.

Sergei
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: Upgrading from 1.3.5.10-21 to 1.3.6-1.24

[Sergei Gerasenko]

Thank you for that information, William.

> On Jan 29, 2018, at 5:11 PM, William Brown  wrote:
> 
> On Mon, 2018-01-29 at 16:24 -0600, Sergei Gerasenko wrote:
>> Hello,
>> 
>> I’m getting ready to upgrade from 1.3.5 to 1.3.6 and I’m wondering if
>> there are any possible issues with this. I’ve heard that the
>> replication protocol has changed in regards to the replication
>> protocol for example. Anything else to be concerned about in terms of
>> the schema changes, etc?
> 
> The replication changes just help to prevent conflicts and issues, it
> should be a "safe" upgrade to make, just don't mix the versions for too
> long. 
> 
> There are no other obvious issues I can think of, just be sure to do a
> test upgrade first, and keep backups (even though I doubt anything will
> go wrong, it's just good discipline) 
> 
>> 
>> Thanks for any insight.
>> 
>> Sergei
>> ___
>> 389-users mailing list -- 389-users@lists.fedoraproject.org
>> To unsubscribe send an email to 389-users-leave@lists.fedoraproject.o
>> rg
> -- 
> Sincerely,
> 
> William Brown
> Software Engineer
> Red Hat, Australia/Brisbane
> ___
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] autosizing the cache

[Sergei Gerasenko]

Hello,

My cn=userRoot,cn=ldbm database,cn=plugins,cn=config is currently:

...
nsslapd-cachesize: -1
nsslapd-cachememsize: 1543503872
nsslapd-readonly: off
nsslapd-require-index: off
nsslapd-dncachememsize: 5
…

But cn=config,cn=ldbm database,cn=plugins,cn=config has these settings:
...
nsslapd-cache-autosize: 10
nsslapd-cache-autosize-split: 40
…


Do I understand correctly that if I remove nsslapd-cachememsize and 
nsslapd-dncachememsize from cn=userRoot, the caches will be auto sized? In 
other words, they are preventing the autosizing?

Thanks!
 Sergei
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: autosizing the cache

[Sergei Gerasenko]

Cool. The default setup of 389-ds (version 1.3.5.10) I don’t see either 
nsslapd-cache-autosize or nsslapd-cache-autosize-split. Should I just add them 
to the dse file?

> Correct, set them to 0 for autotuning to take effect

The Redhat docs are a bit confusing on this 
(https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/performance_tuning_guide/memoryusage
 
):

> nsslapd-cache-autosize
> This settings controls if auto-sizing is enabled for the database and entry 
> cache. Auto-sizing is enabled:
> For both the database and entry cache, if the nsslapd-cache-autosize 
> parameter is set to a value greater than 0.
> For the database cache, if the nsslapd-cache-autosize and nsslapd-dbcachesize 
> parameters are set to 0.
> For the entry cache, if the nsslapd-cache-autosize and 
> nsslapd-cachememsizeparameters are set to 0.
You just confirmed bullet 2 and 3. But bullet 1 is not clear: if I 
setnsslapd-cache-autosize to something greater than 0 and both types of caches 
become auto-tuned, why would then I need to set them to 0 (to enable 
auto-tuning) individually?

Also, is there a way to check that auto-tuning is working normally? Is dbmon.sh 
the right way?

Thanks again,
 Sergei___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: autosizing the cache

[Sergei Gerasenko]

> I don't believe autotuning exists in 1.3.5, it was only added to 1.3.6 - 
> sorry :-/

Ah, that makes my life a bit simpler for now :)

>> Also, is there a way to check that auto-tuning is working normally? Is 
>> dbmon.sh the right way?
> The error log at startup will tell you what the server sets the caches to.  
> ldapsearch on nsslapd-dbcachesize will also return the adjusted size if I am 
> correct, but I haven't tried it.  But like I said before... this feature is 
> not present in 389-ds-base-1.3.5

Got it. Thanks, Mark!!___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: autosizing the cache

[Sergei Gerasenko]

Sorry to resurrect this thread, but I’ve upgraded to 1.3.6 and so my question 
is back on the table :)

My cn=userRoot,cn=ldbm database,cn=plugins,cn=config is currently:

...
nsslapd-cachesize: -1
nsslapd-cachememsize: 1543503872
nsslapd-readonly: off
nsslapd-require-index: off
nsslapd-dncachememsize: 5
…

But cn=config,cn=ldbm database,cn=plugins,cn=config has these settings:
...
nsslapd-cache-autosize: 10
nsslapd-cache-autosize-split: 40
…

If you remember, according to the docs, setting nsslapd-cache-autosize to a 
value > 0, enables autosizing for all backends regardless of their cache size 
settings. Is that accurate or must I set them to 0s after all? It looks like 
autosizing is enforced because I got an error when trying to modify the 
changelog backend:

modifying entry "cn=changelog,cn=ldbm database,cn=plugins,cn=config"
ldap_modify: Server is unwilling to perform (53)
additional info: Error: "nsslapd-cachememsize" can not be updated while 
"nsslapd-cache-autosize" is set in "cn=config,cn=ldbm 
database,cn=plugins,cn=config".

Thanks!

> On Mar 1, 2018, at 2:55 PM, Sergei Gerasenko  wrote:
> 
>> I don't believe autotuning exists in 1.3.5, it was only added to 1.3.6 - 
>> sorry :-/
> 
> Ah, that makes my life a bit simpler for now :)
> 
>>> Also, is there a way to check that auto-tuning is working normally? Is 
>>> dbmon.sh the right way?
>> The error log at startup will tell you what the server sets the caches to.  
>> ldapsearch on nsslapd-dbcachesize will also return the adjusted size if I am 
>> correct, but I haven't tried it.  But like I said before... this feature is 
>> not present in 389-ds-base-1.3.5
> 
> Got it. Thanks, Mark!!

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] repl-monitor.pl

[Sergei Gerasenko]

Hi all,

I think this is more a question for Mark since he wrote repl-monitor :)

I built a new node and promoted it to be a domain/ca replica. Everything seems 
to be working fine *except* repl-monitor.pl has ?:??:?? in the lag column for 
the CA segment from the pre-existing CA master to the new node.

Is that normal? The Max CSN is also “Unavailable” in the next column.

Any ideas?

Thanks, 
  Sergei
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: repl-monitor.pl

[Sergei Gerasenko]

> Is this a winsync replication agreement?  If so, the lag time can not be
> determined if I am correct.

No, it’s all Linux servers. Not sure what winsync is.

> This information is all determined from the replication agreement.  Are
> all the servers using the same version of 389-ds-base?  Because older
> versions of 389-ds-base do not have the agreement maxcsn attribute.

The existing servers were upgraded as part of an IPA upgrade. The new server is 
a fresh install. The existing server (from which the replica was made) doesn’t 
see the maxcsn of the new server. Could that be because no change has occurred 
in the CA suffix of the new server and so there’s nothing to replicate?
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: autosizing the cache

[Sergei Gerasenko]

Hi William,

With autosizing on I configured the changelog backend:

dn: cn=changelog,cn=ldbm database,cn=plugins,cn=config
cn: changelog
objectClass: top
objectClass: extensibleObject
objectClass: nsBackendInstance
nsslapd-suffix: cn=changelog
nsslapd-cachesize: -1
nsslapd-cachememsize: 8858370048
nsslapd-readonly: off
nsslapd-require-index: off
nsslapd-directory: /var/lib/dirsrv/slapd-CNVR-NET/db/changelog
nsslapd-dncachememsize: 30

Here’s the ldif:

dn: cn=changelog,cn=ldbm database,cn=plugins,cn=config
changetype: modify
replace: nsslapd-dncachememsize
nsslapd-dncachememsize: 30
-
replace: nsslapd-cachememsize
nsslapd-cachememsize: 30

The server refused to change nsslapd-cachememsize because of autosizing but 
nsslapd-dncachememsize did get changed. So it seems that I can still control 
nsslapd-dncachememsize? When I restart 389-ds, the 3G persists as well.

Does that make sense?

Thank you for a quick response!

Sergei


> On Mar 13, 2018, at 7:40 PM, William Brown  wrote:
> 
> If autosize > 0, we write a new entrychace/cachememsize every start up.
> 
> So you only need to set autosize to between 1 and 99 for it to work.
> 
> There is some other logic in there to account for other scenarioes =
> for example, if you set autosize to 0 AND you set the entry cachesize
> to 0, we'll autosize it at start up anyway. BUT if you have autosize =
> 0, and entry cachesize > 0, we won't touch it.

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: autosizing the cache

[Sergei Gerasenko]

Thank you for the detailed response, William. That’s great info. You mentioned 
FreeIPA in passing and that’s actually what I use 389-ds for. You mentioned 
dogtag eating memory. You mean it has a memory leak or some other memory 
mismanagement issue? 

I have 125G of RAM on my systems. So, I can allocate quite a bit of RAM to the 
caches. My plan is to set nsslapd-cache-autosize to 20% and set the dncache 
size to 5G for all three backends. Does that sound reasonable to you? These are 
dedicated FreeIPA machines, so it’s the main consumer of the memory.

Also, can I set the dncachesize once at the cn=config,cn=ldbm 
database,cn=plugins,cn=config level and have all the other backends inherit 
that? Would I have to remove that parameter from the other backends for it to 
become inherited?

Thanks again, William!
  Sergei
 
> On Mar 18, 2018, at 8:06 PM, William Brown  wrote:
> 
> On Tue, 2018-03-13 at 21:10 -0500, Sergei Gerasenko wrote:
>> Hi William,
>> 
>> With autosizing on I configured the changelog backend:
>> 
>> dn: cn=changelog,cn=ldbm database,cn=plugins,cn=config
>> cn: changelog
>> objectClass: top
>> objectClass: extensibleObject
>> objectClass: nsBackendInstance
>> nsslapd-suffix: cn=changelog
>> nsslapd-cachesize: -1
>> nsslapd-cachememsize: 8858370048
>> nsslapd-readonly: off
>> nsslapd-require-index: off
>> nsslapd-directory: /var/lib/dirsrv/slapd-CNVR-NET/db/changelog
>> nsslapd-dncachememsize: 30
>> 
>> Here’s the ldif:
>> 
>> dn: cn=changelog,cn=ldbm database,cn=plugins,cn=config
>> changetype: modify
>> replace: nsslapd-dncachememsize
>> nsslapd-dncachememsize: 30
>> -
>> replace: nsslapd-cachememsize
>> nsslapd-cachememsize: 30
>> 
>> The server refused to change nsslapd-cachememsize because of
>> autosizing but nsslapd-dncachememsize did get changed. So it seems
>> that I can still control nsslapd-dncachememsize? When I restart 389-
>> ds, the 3G persists as well.
>> 
>> Does that make sense?
> 
> Yes it does.
> 
>> 
>> Thank you for a quick response!
> 
> At the current point in time, dncachememsize is NOT controlled by
> autosizing. There is some ideas in my head about how to improve this,
> but the issue is legacy. We have one control: autosize percentage. But
> this doesn't really represent a complete picture and story about how we
> size our backends and data.
> 
> We have to continue to support the current variables, so I can't easily
> change this from it's current form. 
> 
> *IF* I was given unlimited power (I never will be ;) ) I would probably
> make the interface something like:
> 
> 
> 
> backend-foo:
> autosize-max-memory: 
> entrycache-slice: A%
> dncache-slice: B%
> dbcache-slice: C%
> ndncache-slice: D%
> 
> So how would this work? 
> 
> You have autosize max that is the "total ram" we want to use. Lets say
> 2GB. Each backend would be given it's own "limit". We'd try to detect
> some sane values on your system of course, but we can only do so much
> :) So say ... each backend gets 5-10% of system ram limit. (We have to
> be super conservative due to dogtag in freeipa which eats ram).
> 
> Then we slice that up. So entrycache-slice + dncache-slice + dbcache-
> slice + ndncache-slice = 100%. So by default we might do something
> like:
> 
> entrycache-slice: 75
> dbcache-slice: 10
> dncache-slice: 10
> ndncache-slice: 5
> 
> So this on a 1GB backend translates to:
> 
> 750MB of entrycache
> 100MB of dncache
> 100MB of dbcache
> 50MB of ndncache
> 
> of course some tests would be needed to find the right slice values by
> default.
> 
> 
> Then it's as simple as "if you want more from your backend" just up the
> one memlimit value and "everything" increases in a correct proportional
> rate. Rather than thinking about how to hand tune everything, we make
> informed design decisions, you just say "here's mem max". You have
> control to say each backend gets a different value (say FreeIPA you may
> want 4GB to userRoot, 1GB to CA system backend). you still have lots of
> flexibility as an admin, but you don't have to worry about so many
> moving interacting parts. 
> 
> 
> Hope that helps,
> 
>> 
>> Sergei
>> 
>> 
>>> On Mar 13, 2018, at 7:40 PM, William Brown >> u> wrote:
>>> 
>>> If autosize > 0, we write a new entrychace/cachememsize every start
>>> up.
>>> 
>>> So you only need to set autosize to between 1 and 99 for it to
>>> work.
>&g

[389-users] Re: autosizing the cache

[Sergei Gerasenko]

> Dogtag is Java/Tomcat. It's well known for consuming large volumes of
> ram!

Ah, I thought it was something besides that :)

> Sure, sounds reasonable to me - I'd want to see your database sizes to
> make a complete assesment, but it seems pretty reasonable to me. 

I will get that for you. I’ve used dbmon.sh on a live system and things looked 
pretty well (>=92%). You would like to see the number of entries in the db, 
right?

> Additionally, check that cn=config,cn=ldbm ... is actually
> d'B'cachesize not d’N'cachesize.

Now I’m confused a bit. I thought the dncachesize was what was supposed to be 
set manually while everything else was autosized. Sorry for being slow on this.
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: autosizing the cache

[Sergei Gerasenko]

Hi William,

> On Mar 19, 2018, at 9:18 PM, William Brown  wrote:
> 
> yeah, dncachesize is manual. But I think dncachesize is per backend,
> not part of cn=config,cn=ldbm plugin. 

Yes, I see one for changelog and one for userRoot.

Here’s the data:

> dbscan -f /var/lib/dirsrv/slapd--XXX/db/userRoot/id2entry.db -t 200 | 
> grep -c rdn:
12212

> dbmon.sh
Tue Mar 20 02:16:04 UTC 2018
dbcachefree 432873472 free% 80.629 roevicts 0 hit% 99 pagein 1267 pageout 23191
changelog:ent 616509293897  100.0  4359.2
changelog:dn29262999793332  100.070.6
 userroot:ent  117776408341275   98.4  8594.6
 userroot:dn   117772998722450  100.0   108.5

> ls -lh /var/lib/dirsrv/slapd--XXX/db/userRoot
total 121M
-rw--- 1 dirsrv dirsrv  16K Mar 19 14:41 aci.db
-rw--- 1 dirsrv dirsrv 744K Mar 19 21:04 ancestorid.db
-rw--- 1 dirsrv dirsrv  16K Mar 19 14:41 automountkey.db
-rw--- 1 dirsrv dirsrv 5.7M Mar 19 18:39 cn.db
-rw--- 1 dirsrv dirsrv   51 Mar 19 14:44 DBVERSION
-rw--- 1 dirsrv dirsrv 296K Mar 19 14:41 displayname.db
-rw--- 1 dirsrv dirsrv 4.7M Mar 19 21:04 entryrdn.db
-rw--- 1 dirsrv dirsrv 144K Mar 20 02:23 entryusn.db
-rw--- 1 dirsrv dirsrv 592K Mar 19 18:15 fqdn.db
-rw--- 1 dirsrv dirsrv  56K Mar 19 14:41 gidnumber.db
-rw--- 1 dirsrv dirsrv 176K Mar 19 14:41 givenName.db
-rw--- 1 dirsrv dirsrv  74M Mar 20 02:23 id2entry.db
-rw--- 1 dirsrv dirsrv  16K Mar 19 14:44 ipaallowedtarget.db
-rw--- 1 dirsrv dirsrv  16K Mar 19 14:44 ipaassignedidview.db
-rw--- 1 dirsrv dirsrv  16K Mar 19 18:15 ipakrbprincipalalias.db
-rw--- 1 dirsrv dirsrv  16K Mar 19 14:44 ipalocation.db
-rw--- 1 dirsrv dirsrv  16K Mar 19 14:44 ipaMemberCa.db
-rw--- 1 dirsrv dirsrv  16K Mar 19 14:41 ipaMemberCertProfile.db
-rw--- 1 dirsrv dirsrv 112K Mar 19 14:41 ipasudorunas.db
-rw--- 1 dirsrv dirsrv  16K Mar 19 14:44 ipasudorunasgroup.db
-rw--- 1 dirsrv dirsrv  16K Mar 19 14:44 ipatokenradiusconfiglink.db
-rw--- 1 dirsrv dirsrv 952K Mar 19 21:04 ipauniqueid.db
-rw--- 1 dirsrv dirsrv 2.8M Mar 19 18:15 krbCanonicalName.db
-rw--- 1 dirsrv dirsrv 7.2M Mar 19 18:15 krbPrincipalName.db
-rw--- 1 dirsrv dirsrv  16K Mar 19 14:44 macAddress.db
-rw--- 1 dirsrv dirsrv 416K Mar 19 14:41 mail.db
-rw--- 1 dirsrv dirsrv 8.1M Mar 19 18:15 managedby.db
-rw--- 1 dirsrv dirsrv  16K Mar 19 14:44 manager.db
-rw--- 1 dirsrv dirsrv 264K Mar 19 21:04 memberallowcmd.db
-rw--- 1 dirsrv dirsrv 3.3M Mar 19 19:09 member.db
-rw--- 1 dirsrv dirsrv  16K Mar 19 14:44 memberdenycmd.db
-rw--- 1 dirsrv dirsrv 1.7M Mar 19 14:41 memberHost.db
-rw--- 1 dirsrv dirsrv 2.0M Mar 19 19:09 memberOf.db
-rw--- 1 dirsrv dirsrv 128K Mar 19 14:41 memberservice.db
-rw--- 1 dirsrv dirsrv 472K Mar 19 14:41 memberUser.db
-rw--- 1 dirsrv dirsrv  48K Mar 19 20:12 nscpEntryDN.db
-rw--- 1 dirsrv dirsrv  16K Mar 19 14:41 nsds5ReplConflict.db
-rw--- 1 dirsrv dirsrv  32K Mar 19 20:12 nsTombstoneCSN.db
-rw--- 1 dirsrv dirsrv 920K Mar 19 21:04 nsuniqueid.db
-rw--- 1 dirsrv dirsrv  16K Mar 19 21:04 numsubordinates.db
-rw--- 1 dirsrv dirsrv 1.3M Mar 19 21:04 objectclass.db
-rw--- 1 dirsrv dirsrv  16K Mar 19 14:41 ou.db
-rw--- 1 dirsrv dirsrv  16K Mar 19 14:44 owner.db
-rw--- 1 dirsrv dirsrv 176K Mar 19 21:04 parentid.db
-rw--- 1 dirsrv dirsrv  16K Mar 19 14:44 secretary.db
-rw--- 1 dirsrv dirsrv  16K Mar 19 14:44 seeAlso.db
-rw--- 1 dirsrv dirsrv 200K Mar 19 14:41 sn.db
-rw--- 1 dirsrv dirsrv  16K Mar 19 14:44 sourcehost.db
-rw--- 1 dirsrv dirsrv  16K Mar 19 18:39 telephoneNumber.db
-rw--- 1 dirsrv dirsrv  96K Mar 19 14:41 title.db
-rw--- 1 dirsrv dirsrv 184K Mar 19 14:41 uid.db
-rw--- 1 dirsrv dirsrv  56K Mar 19 14:41 uidnumber.db
-rw--- 1 dirsrv dirsrv  16K Mar 19 14:44 uniquemember.db
-rw--- 1 dirsrv dirsrv 4.4M Mar 19 18:15 userCertificate.db

Thank you!
  Sergei___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] a replication problem

[Sergei Gerasenko]

Hi guys,

I ran into a rather significant problem. I needed to rebuild two nodes in my 
topology and re-include them under the same hostnames. What I’m seeing now is 
that the replication to these new nodes is broken. Replication from them seems 
to work. I suspect that we have some stale metadata somewhere in the topology 
whereby the old nodes are still present somewhere in the agreements under other 
ids?

What’s the best way to troubleshoot this?

Thanks again,
  Sergei
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: a replication problem

[Sergei Gerasenko]

The error I’m basically getting is:

[23/Mar/2018:03:23:29.461074995 +] - ERR - NSMMReplicationPlugin - 
bind_and_check_pwp - agmt=“cn=HOST1-to-HOST2" (ipa203:389) - Replication bind 
with GSSAPI auth failed: LDAP error 49 (Invalid credentials) ()

Any ideas?

> On Mar 22, 2018, at 5:05 PM, Sergei Gerasenko  wrote:
> 
> Hi guys,
> 
> I ran into a rather significant problem. I needed to rebuild two nodes in my 
> topology and re-include them under the same hostnames. What I’m seeing now is 
> that the replication to these new nodes is broken. Replication from them 
> seems to work. I suspect that we have some stale metadata somewhere in the 
> topology whereby the old nodes are still present somewhere in the agreements 
> under other ids?
> 
> What’s the best way to troubleshoot this?
> 
> Thanks again,
>  Sergei
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: a replication problem

[Sergei Gerasenko]

The only other message before that is suspcious:

set_krb5_creds - Could not get initial credentials for principal ... in keytab
[FILE:/etc/dirsrv/ds.keytab]: -1765328203 (Key table entry not found)

I might get more when I get to work, but I think that’s all the errors I found. 
The resume message is not there. I saw your commit 5 years ago on this issue.

> On Mar 23, 2018, at 6:48 AM, Mark Reynolds  wrote:
> 
> 
> 
> On 03/23/2018 12:07 AM, Sergei Gerasenko wrote:
>> The error I’m basically getting is:
>> 
>> [23/Mar/2018:03:23:29.461074995 +] - ERR - NSMMReplicationPlugin - 
>> bind_and_check_pwp - agmt=“cn=HOST1-to-HOST2" (ipa203:389) - Replication 
>> bind with GSSAPI auth failed: LDAP error 49 (Invalid credentials) ()
>> 
>> Any ideas?
> GSSAPI authentication is failing.  Wrong principle name in agreement? 
> KDC issue? I don't know, but that's what the error means.  It could also
> be a red herring as it typically does recover (it logs something like
> "auth resumed").  We need to see more logging from the errors log.
>> 
>>> On Mar 22, 2018, at 5:05 PM, Sergei Gerasenko  wrote:
>>> 
>>> Hi guys,
>>> 
>>> I ran into a rather significant problem. I needed to rebuild two nodes in 
>>> my topology and re-include them under the same hostnames. What I’m seeing 
>>> now is that the replication to these new nodes is broken. Replication from 
>>> them seems to work. I suspect that we have some stale metadata somewhere in 
>>> the topology whereby the old nodes are still present somewhere in the 
>>> agreements under other ids?
>>> 
>>> What’s the best way to troubleshoot this?
>>> 
>>> Thanks again,
>>> Sergei
>> ___
>> 389-users mailing list -- 389-users@lists.fedoraproject.org 
>> <mailto:389-users@lists.fedoraproject.org>
>> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org 
>> <mailto:389-users-le...@lists.fedoraproject.org>
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: a replication problem

[Sergei Gerasenko]

So here’s a more complete snippet from the host (ipa204) that can’t push to its 
partner (ipa203):

[23/Mar/2018:04:09:43.460073218 +] - ERR - NSACLPlugin - acl_parse - The 
ACL target cn=vaults,cn=kra,dc=XXX,dc=net does not exist
[23/Mar/2018:04:09:43.460238115 +] - ERR - NSACLPlugin - acl_parse - The 
ACL target cn=vaults,cn=kra,dc=XXX,dc=net does not exist
[23/Mar/2018:04:09:43.460483444 +] - ERR - NSACLPlugin - acl_parse - The 
ACL target cn=vaults,cn=kra,dc=XXX,dc=net does not exist
[23/Mar/2018:04:09:43.460620709 +] - ERR - NSACLPlugin - acl_parse - The 
ACL target cn=vaults,cn=kra,dc=XXX,dc=net does not exist
[23/Mar/2018:04:09:43.460793082 +] - ERR - NSACLPlugin - acl_parse - The 
ACL target cn=vaults,cn=kra,dc=XXX,dc=net does not exist
[23/Mar/2018:04:09:43.460998306 +] - ERR - NSACLPlugin - acl_parse - The 
ACL target cn=vaults,cn=kra,dc=XXX,dc=net does not exist
[23/Mar/2018:04:09:43.461171061 +] - ERR - NSACLPlugin - acl_parse - The 
ACL target cn=vaults,cn=kra,dc=XXX,dc=net does not exist
[23/Mar/2018:04:09:43.461370548 +] - ERR - NSACLPlugin - acl_parse - The 
ACL target cn=vaults,cn=kra,dc=XXX,dc=net does not exist
[23/Mar/2018:04:09:43.461554598 +] - ERR - NSACLPlugin - acl_parse - The 
ACL target cn=dns,dc=XXX,dc=net does not exist
[23/Mar/2018:04:09:43.462223077 +] - ERR - NSACLPlugin - acl_parse - The 
ACL target cn=ad,cn=etc,dc=XXX,dc=net does not exist
[23/Mar/2018:04:09:43.469236418 +] - ERR - NSACLPlugin - acl_parse - The 
ACL target cn=casigningcert 
cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=XXX,dc=net does not 
exist[23/Mar/2018:04:09:43.469549785 +] - ERR - NSACLPlugin - acl_parse - 
The ACL target cn=casigningcert 
cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=XXX,dc=net does not exist
[23/Mar/2018:04:09:43.526348986 +] - ERR - NSACLPlugin - acl_parse - The 
ACL target cn=automember rebuild membership,cn=tasks,cn=config does not exist
[23/Mar/2018:04:09:43.543200030 +] - ERR - schema-compat-plugin - 
schema-compat-plugin tree scan will start in about 5 seconds!
[23/Mar/2018:04:09:43.543437243 +] - ERR - set_krb5_creds - Could not get 
initial credentials for principal [ldap/ipa204.iad.auth.core.xxx@cnvr.net] 
in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error (see e-text))
[23/Mar/2018:04:09:43.550151255 +] - INFO - slapd_daemon - slapd started.  
Listening on All Interfaces port 389 for LDAP requests
[23/Mar/2018:04:09:43.550328761 +] - INFO - slapd_daemon - Listening on All 
Interfaces port 636 for LDAPS requests
[23/Mar/2018:04:09:43.550525479 +] - INFO - slapd_daemon - Listening on 
/var/run/slapd-XXX-NET.socket for LDAPI requests
[23/Mar/2018:04:09:47.905572763 +] - ERR - NSMMReplicationPlugin - 
bind_and_check_pwp - agmt="cn=ipa204-to-ipa203" (ipa203:389) - Replication bind 
with GSSAPI auth failed: LDAP error 49 (Invalid credentials) ()
[23/Mar/2018:04:09:50.611808868 +] - ERR - schema-compat-plugin - warning: 
no entries set up under cn=computers, cn=compat,dc=XXX,dc=net
[23/Mar/2018:04:09:50.612281544 +] - ERR - schema-compat-plugin - Finished 
plugin initialization.

The 204 has this message:

[23/Mar/2018:01:52:48.624405992 +] - ERR - NSMMReplicationPlugin - 
acquire_replica - agmt="cn=meToipa101..net" (ipa101:389): Unable to acquire 
replica: permission denied. The bind dn "" does not have permission to supply 
replication updates to the replica. Will retry later.

Ipa101 is another host in the topology from which 204 was made.

Let me know if I can supply more info.

Thank you!
  Sergei

> On Mar 23, 2018, at 6:48 AM, Mark Reynolds  wrote:
> 
> 
> 
> On 03/23/2018 12:07 AM, Sergei Gerasenko wrote:
>> The error I’m basically getting is:
>> 
>> [23/Mar/2018:03:23:29.461074995 +] - ERR - NSMMReplicationPlugin - 
>> bind_and_check_pwp - agmt=“cn=HOST1-to-HOST2" (ipa203:389) - Replication 
>> bind with GSSAPI auth failed: LDAP error 49 (Invalid credentials) ()
>> 
>> Any ideas?
> GSSAPI authentication is failing.  Wrong principle name in agreement? 
> KDC issue? I don't know, but that's what the error means.  It could also
> be a red herring as it typically does recover (it logs something like
> "auth resumed").  We need to see more logging from the errors log.
>> 
>>> On Mar 22, 2018, at 5:05 PM, Sergei Gerasenko  wrote:
>>> 
>>> Hi guys,
>>> 
>>> I ran into a rather significant problem. I needed to rebuild two nodes in 
>>> my topology and re-include them under the same hostnames. What I’m seeing 
>>> now is that the replication to these new nodes is broken. Replication from 
>>> them seems to work. I suspect that we have some stale metadata somewhere in 
>>> the topology whereby the old nodes are still present somewhere in the 
>>> agreem

[389-users] Re: replication question

[Sergei Gerasenko]

Looks like I have a replication conflict but I’m not sure if it’s really the 
cause of the problem.

ldapsearch -xLLL -o ldif-wrap=no -D cn='directory manager' -w PWD -h 
ipa102.cnvr.net -b 'dc=CNVR,dc=NET' nsDS5ReplConflict=* dn

cn=System: Read Certmap 
Configuration+nsuniqueid=0cefb68c-0b9111e8-9447e803-d19ee9c0,cn=permissions,cn=pbac,dc=cnvr,dc=net
cn=ipa201-to-ipa202+nsuniqueid=73b7ef20-2e2211e8-bd0bfbd1-7f1a6887,cn=domain,cn=topology,cn=ipa,cn=etc,dc=XXX,dc=net

Those two hosts don’t exist anymore. I rekicked them and changed their names to 
ipa204 and ipa203 respectively.

Do I delete that on each host where the conflict is shown or just one?

> On Mar 23, 2018, at 8:52 AM, Mark Reynolds  wrote:
> 
> 
> 
> On 03/23/2018 09:05 AM, JESSE LUNT wrote:
>> Here is the dse.ldif on 389ds2 (strange that it is in a slapd-389ds1 
>> directory, I thought it was supposed to create a directory named 
>> slapd-hostname. Could this server be a clone? )
> Perhaps, but you can name an instance anything you want.
> 
> I see a problem here: 
> 
> dn: cn=replica,cn=dc\3Dnorthshore\2Cdc\3Dedu,cn=mapping tree,cn=config
> ...
> ...
> nsDS5ReplicaBindDN: cn=directory manager
> 
> 
> nsDS5ReplicaBindDN needs to be one of the replication managers (you have two) 
> - it should not be the "Directory Manager":
> 
> uid=rmanager,cn=config or  uid=RManager2,cn=config
> 
> 
> Then on the replication agreement(s) on 389ds1, make sure the agreement bind 
> dn (and credentials) is for one of these replication managers.
> 
> Fix this first, and lets see what happens.
> 
> Mark
>> 
>> 
>> 
>> On Thu, Mar 22, 2018 at 4:08 PM, Mark Reynolds > > wrote:
>> 
>> 
>> On 03/22/2018 04:04 PM, JESSE LUNT wrote:
>>> When I access the 389ds2 using an ldap browser, I still do not see the user 
>>> Root database. However, would I see it if it hasn't finished initializing? 
>> You said you already created the userRoot database on 389ds2, so you are 
>> saying you don't see it anymore?
>> 
>> Any chance I could see the dse.ldif from 389ds2?  Perhaps 389ds2 is not 
>> properly configured?
>> 
>> Anyway you need to look at the logs next to figure out why the 
>> initialization is not occurring.  The access log should show a connection 
>> coming from 389ds1, and it binding as your replication manager.  The errors 
>> log might also have useful info (on either server).
>> 
>> Mark
>>> 
>>> 
>>> Jesse
>>> 
>>> Sent from my iPhone
>>> 
>>> On Mar 22, 2018, at 1:30 PM, Mark Reynolds >> > wrote:
>>> 
 How man entries are in the 389ds1?
 
 You need to look at the access/errors logs on 389ds2 to see if 389ds1 is 
 making contact and what is it doing.
 
 It's also possible it finished initializing.  Are there any entries on 
 389ds2?  If you make an update on 389ds1 does it appear on 389ds2?
 
 On 03/22/2018 12:51 PM, JESSE LUNT wrote:
> Hello,
> 
>   I am trying to replicate my userRoot database to another 389LDAP 
> server (supplier: 389ds1, consumer: 389ds2). The database on the supplier 
> has not been replicated to any server for more than 2 years. (yikes!!!). 
> 
> I have been successful in backing up the database in question, and am now 
> trying to create a replica agreement. I created the root suffix on the 
> consumer side (389ds2) and then created a replication agreement from the 
> admin console. The admin console has been in the state of wait while 
> consumer is initialized. 
> 
> 
> 
> Here is the output from the repl-monitor script
> 
> Enter password for (:): Master: 389ds1.northshore.edu:389 
>  ldap:// <>389ds1.northshore.edu:389/ 
> 
> Replica ID: 1212
> Replica Root: dc=northshore,dc=edu
> Max CSN: 5ab3dd8f04bc (03/22/2018 12:45:03)
> Use of uninitialized value in string at /usr/bin/repl-monitor.pl 
>  line 814, <> line 1.
> Use of uninitialized value in join or string at /usr/bin/repl-monitor.pl 
>  line 1151, <> line 1.
> Receiver: 389ds2.northshore.edu:389  
> ldap:// <>389ds2.northshore.edu:389/ 
> Type: consumer
> Time Lag: - ?:??:??
> Max CSN: none
> Use of uninitialized value in concatenation (.) or string at 
> /usr/bin/repl-monitor.pl  line 855, <> line 1.
> Last Modify Time:
> Supplier: 389ds1.northshore.edu:389 
> Sent/Skipped: 0 / 0
> Update Status: 0 Replica acquired successfully: Incremental update started
> Update Started: 03/22/2018 12:45:01
> Update Ended: 03/22/2018 12:45:01
> Schedule: always in sync
> SSL: n
> Replica ID: 1971
> Replica Root: o=netscaperoot
> Max CSN: 5ab1364d000407b3 (03

[389-users] Re: a replication problem

[Sergei Gerasenko]

> On Mar 23, 2018, at 8:58 AM, Mark Reynolds  wrote:
> 
> kinit -k -t /etc/dirsrv/ds.keytab

kinit: Keytab contains no suitable keys for host/ipa204.iad.cnvr@cnvr.net 
while getting initial credentials___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: a replication problem

[Sergei Gerasenko]

Yes, there’s something there. Should I follow this and everything should be ok?

http://directory.fedoraproject.org/docs/389ds/howto/howto-kerberos.html 
<http://directory.fedoraproject.org/docs/389ds/howto/howto-kerberos.html>

> On Mar 23, 2018, at 9:10 AM, Mark Reynolds  wrote:
> 
> 
> 
> On 03/23/2018 10:01 AM, Sergei Gerasenko wrote:
>> 
>> 
>>> On Mar 23, 2018, at 8:58 AM, Mark Reynolds >> <mailto:mreyno...@redhat.com>> wrote:
>>> 
>>> kinit -k -t /etc/dirsrv/ds.keytab
>> 
>> kinit: Keytab contains no suitable keys for 
>> host/ipa204.iad.cnvr@cnvr.net <mailto:host/ipa204.iad.cnvr@cnvr.net> 
>> while getting initial credentials
> That's the problem...  Is there anything in the keytab file?  Looks like you 
> might need to setup/get your keytab again...
>> 
>> 
>> ___
>> 389-users mailing list -- 389-users@lists.fedoraproject.org 
>> <mailto:389-users@lists.fedoraproject.org>
>> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org 
>> <mailto:389-users-le...@lists.fedoraproject.org>
> 

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: a replication problem

[Sergei Gerasenko]

Also, and I don’t know if it’s strange, but I get that kinit error on any IPA 
host. I have a 2-master VM environment and trying kinit -k -t 
/etc/dirsrv/ds.keytab gives the same error back — but they are replicating 
without issues.
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: a replication problem

[Sergei Gerasenko]

I think the real command is:

kinit -k -t /etc/dirsrv/ds.keytab ldap/h...@cnvr.net <mailto:ldap/h...@cnvr.net>

That does work

> On Mar 23, 2018, at 9:51 AM, Mark Reynolds  wrote:
> 
> I must admit I don't know too much about troubleshooting kerberos, I
> just know that in your case its broken.  Perhaps ask for help on on the
> FreeIPA users list as they are much more familiar with this than I am:
> 
> freeipa-us...@lists.fedorahosted.org
> 
> On 03/23/2018 10:40 AM, Sergei Gerasenko wrote:
>> Also, and I don’t know if it’s strange, but I get that kinit error on any 
>> IPA host. I have a 2-master VM environment and trying kinit -k -t 
>> /etc/dirsrv/ds.keytab gives the same error back — but they are replicating 
>> without issues.
>> ___
>> 389-users mailing list -- 389-users@lists.fedoraproject.org
>> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
> 

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: a replication problem

[Sergei Gerasenko]

The problem was caused by too much traffic going to the server. The neighboring 
machines couldn’t push their updates to it. Once the traffic was split into 
more servers, everything normalized.

> On Mar 23, 2018, at 9:51 AM, Mark Reynolds  wrote:
> 
> I must admit I don't know too much about troubleshooting kerberos, I
> just know that in your case its broken.  Perhaps ask for help on on the
> FreeIPA users list as they are much more familiar with this than I am:
> 
> freeipa-us...@lists.fedorahosted.org
> 
> On 03/23/2018 10:40 AM, Sergei Gerasenko wrote:
>> Also, and I don’t know if it’s strange, but I get that kinit error on any 
>> IPA host. I have a 2-master VM environment and trying kinit -k -t 
>> /etc/dirsrv/ds.keytab gives the same error back — but they are replicating 
>> without issues.
>> ___
>> 389-users mailing list -- 389-users@lists.fedoraproject.org
>> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
> 
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] DNA Plugin Troubles

[Sergei Gerasenko]

Hi guys,

I’ve replaced all of my environment with new hardware and everything is working 
except that I can’t add users/groups due to a DNA error saying:

"Operations error: Allocation of a new value for range cn=posix 
ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config failed! 
Unable to proceed."

It seems that no replicas have a range defined because (I think) the original 
master on which users used to be creared got decommissioned as well :( So I 
think that’s SOMEHOW the root of the problem. 

What’s the best way to proceed?

Thanks,
  Sergei___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Help with ldapsearch query

[Sergei Gerasenko]

Hi,

I need to get a list of hosts from 389-ds that have ipaSshPubKey set and I’m 
having trouble contructing that. I’ve tried this:

ldapsearch -h HOST -b cn=computers,cn=accounts,dc=cnvr,dc=net 'ipaSshPubKey=*’

… but that doesn’t seem to work.

Am I missing something simple?

Thanks,
Sergei___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: Help with ldapsearch query

[Sergei Gerasenko]

No error per se. I’m just not getting the results I’m expecting. It’s not 
including some hosts that have ipaSshPubKey set. 

> On Apr 16, 2018, at 12:34 PM, Leo Pleiman  wrote:
> 
> What error are you getting if you run this from the command line?
> 
> Leo Pleiman
> Senior System Engineer
> Direct 202-787-3622
> Cell 410-688-3873
> 
> DonorPro merged with Salsa, read about it here. 
> <https://www.salsalabs.com/about/news/salsa-labs-and-donorpro-unite>
> On Mon, Apr 16, 2018 at 1:25 PM, Sergei Gerasenko  <mailto:gera...@gmail.com>> wrote:
> Hi,
> 
> I need to get a list of hosts from 389-ds that have ipaSshPubKey set and I’m 
> having trouble contructing that. I’ve tried this:
> 
> ldapsearch -h HOST -b cn=computers,cn=accounts,dc=cnvr,dc=net 'ipaSshPubKey=*’
> 
> … but that doesn’t seem to work.
> 
> Am I missing something simple?
> 
> Thanks,
> Sergei
> 
> ___
> 389-users mailing list -- 389-users@lists.fedoraproject.org 
> <mailto:389-users@lists.fedoraproject.org>
> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org 
> <mailto:389-users-le...@lists.fedoraproject.org>
> 
> 
> ___
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: Help with ldapsearch query

[Sergei Gerasenko]

It does seem to be permission issue. Thank you.

> On Apr 16, 2018, at 2:05 PM, Mark Reynolds  wrote:
> 
> 
> 
> On 04/16/2018 01:25 PM, Sergei Gerasenko wrote:
>> Hi,
>> 
>> I need to get a list of hosts from 389-ds that have ipaSshPubKey set and I’m 
>> having trouble contructing that. I’ve tried this:
>> 
>> ldapsearch -h HOST -b cn=computers,cn=accounts,dc=cnvr,dc=net 
>> 'ipaSshPubKey=*’
> It could be an access control issue,  You should specify a bind DN and 
> password, and maybe change the search base:
> 
> ldapsearch -D "cn=directory manager" -W -h HOST -p PORT -b "dc=cnvr,dc=net"  
> 'ipaSshPubKey=*’
>> 
>> 
>> … but that doesn’t seem to work.
>> 
>> Am I missing something simple?
>> 
>> Thanks,
>> Sergei
>> 
>> 
>> ___
>> 389-users mailing list -- 389-users@lists.fedoraproject.org 
>> <mailto:389-users@lists.fedoraproject.org>
>> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org 
>> <mailto:389-users-le...@lists.fedoraproject.org>
> 

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Failed modrdn operation

[Sergei Gerasenko]

Hello,

Somebody in my group was using an ipa command to rename a user’s login and the 
operation apparently failed. The audit log shows the operation was:

dn: uid=userX,cn=users,cn=accounts,dc=ourdomain,dc=com
changetype: modrdn
newrdn: uid=userY
deleteoldrdn: 1

… and the result was 1, which I assume is an error.

Doing ldapsearch on "dn: uid=userY" returns nothing, but a search on “dn: 
uid=userX” returns:

> ldapsearch -xLLL -h localhost -b cn=users,cn=accounts,dc=ourdomain,dc=com 
> uid=userX
dn: uid=userY,cn=users,cn=accounts,dc=ourdomain,dc=com
uid: userY
…

So, searching for uid=userX returns uid=userY!

Any ideas what could be going on? Dumping the database with db2ldif shows no 
mention of userY. So, I’m thinking that the transaction wasn’t committed and 
maybe restarting 389-ds will revert the bad change?

Thanks!
  Sergei



___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org/message/3BPMCRJUHVMDBPUQEKBTSNHHCLL5TISA/

[389-users] Re: Failed modrdn operation

[Sergei Gerasenko]

Restarting 389-ds does seem to have taken care of it.

> On Jul 12, 2018, at 10:53 PM, Sergei Gerasenko  wrote:
> 
> Hello,
> 
> Somebody in my group was using an ipa command to rename a user’s login and 
> the operation apparently failed. The audit log shows the operation was:
> 
> dn: uid=userX,cn=users,cn=accounts,dc=ourdomain,dc=com
> changetype: modrdn
> newrdn: uid=userY
> deleteoldrdn: 1
> 
> … and the result was 1, which I assume is an error.
> 
> Doing ldapsearch on "dn: uid=userY" returns nothing, but a search on “dn: 
> uid=userX” returns:
> 
>> ldapsearch -xLLL -h localhost -b cn=users,cn=accounts,dc=ourdomain,dc=com 
>> uid=userX
> dn: uid=userY,cn=users,cn=accounts,dc=ourdomain,dc=com
> uid: userY
> …
> 
> So, searching for uid=userX returns uid=userY!
> 
> Any ideas what could be going on? Dumping the database with db2ldif shows no 
> mention of userY. So, I’m thinking that the transaction wasn’t committed and 
> maybe restarting 389-ds will revert the bad change?
> 
> Thanks!
>  Sergei
> 
> 
> 
> 
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org/message/BJVFD3N56EYV7YJF22VJXRZYVUXGD53V/

[389-users] user privileges needed to run repl-monitor.pl

[Sergei Gerasenko]

Hi,

I’ve been using repl-monitor.pl for monitoring replication problems. I would 
like to use an account with a minimal set of permissions needed for the 
functionality. I created a user and added the permission to Read Replication 
Agreements. Now the user can read the agreements but fails on:

$ruv = $conn->search($replicaroot, "one”, 
"(&(nsuniqueid=---)(objectClass=nsTombstone))”, 
0, qw(nsds50ruv nsruvReplicaLastModified nsds5AgmtMaxCSN));

Rather, the $ruv is empty after that call. When running with a privileged 
account, everything works.

What are the permissions needed for that search to work for a brand new account?

Thanks,
  Sergei___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org/message/GDN34STFNX75CJRSNR55DIR2WDOJ5BFZ/

[389-users] Re: user privileges needed to run repl-monitor.pl

[Sergei Gerasenko]

Thanks, Mark. I think I will have to do this directly in dse.ldif by stopping 
the server, editing the ldif and starting it again? Looks like there’s already 
an ACI for it, but it doesn’t include those attrs. So I think I will need to 
add them. Currently it looks like this:

dn: cn=mapping tree,cn=config
aci: (targetattr = "cn || createtimestamp || description || entryusn || modify
 timestamp || nsds50ruv || nsds5beginreplicarefresh || nsds5debugreplicatimeou
 t || nsds5flags || nsds5replicaabortcleanruv || nsds5replicaautoreferral || n
 sds5replicabackoffmax || nsds5replicabackoffmin || nsds5replicabinddn || nsds
 5replicabindmethod || nsds5replicabusywaittime || nsds5replicachangecount ||
 nsds5replicachangessentsincestartup || nsds5replicacleanruv || nsds5replicacl
 eanruvnotified || nsds5replicacredentials || nsds5replicaenabled || nsds5repl
 icahost || nsds5replicaid || nsds5replicalastinitend || nsds5replicalastinits
 tart || nsds5replicalastinitstatus || nsds5replicalastupdateend || nsds5repli
 calastupdatestart || nsds5replicalastupdatestatus || nsds5replicalegacyconsum
 er || nsds5replicaname || nsds5replicaport || nsds5replicaprotocoltimeout ||
 nsds5replicapurgedelay || nsds5replicareferral || nsds5replicaroot || nsds5re
 plicasessionpausetime || nsds5replicastripattrs || nsds5replicatedattributeli
 st || nsds5replicatedattributelisttotal || nsds5replicatimeout || nsds5replic
 atombstonepurgeinterval || nsds5replicatransportinfo || nsds5replicatype || n
 sds5replicaupdateinprogress || nsds5replicaupdateschedule || nsds5task || nsd
 s7directoryreplicasubtree || nsds7dirsynccookie || nsds7newwingroupsyncenable
 d || nsds7newwinusersyncenabled || nsds7windowsdomain || nsds7windowsreplicas
 ubtree || nsruvreplicalastmodified || nsstate || objectclass || onewaysync ||
  winsyncdirectoryfilter || winsyncinterval || winsyncmoveaction || winsyncsub
 treepair || winsyncwindowsfilter")(targetfilter = "(|(objectclass=nsds5Replic
 a)(objectclass=nsds5replicationagreement)(objectclass=nsDSWindowsReplicationA
 greement)(objectClass=nsMappingTree))")(version 3.0;acl "permission:Read Repl
 ication Agreements";allow (compare,read,search) groupdn = "ldap:///cn=Read Re
 plication Agreements,cn=permissions,cn=pbac,dc=MYDC,dc=net";)

But I think I will also need to add the object class of objectClass=nsTombstone 
to the targetFilter?

Thanks,
  Sergei

> On Aug 17, 2018, at 12:23 PM, Mark Reynolds  wrote:
> 
> Add an ACI to this entry (using your suffix of course) allowing the user or 
> group to read/search/compare:
> 
> dn: cn=replica,cn=o\3Dmark,cn=mapping tree,cn=config
> 
> That should do it :-)

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org/message/47NT5T2TN5UJJIX27PWJJTNHOZ4SLNPH/

[389-users] Re: user privileges needed to run repl-monitor.pl

[Sergei Gerasenko]

Hi Mark,

I have a test instance of 389-ds running on a vm. I’ve tried updating the aci 
like this:

dn: cn=mapping tree,cn=config
changetype: modify
replace: aci
aci: (targetattr = "cn || nsuniqueid || createtimestamp || description || 
entryusn || modify
 timestamp || nsds50ruv || MORE STUFF)(targetfilter = 
"(|(objectclass=nsds5Replic
 a)(objectclass=nsds5replicationagreement)(objectclass=nsDSWindowsReplicationA
 greement)(objectClass=nsMappingTree)(objectClass=nsTombstone))")(version 
3.0;acl "permission:Read Repl
 ication Agreements";allow (compare,read,search) groupdn = "ldap:///cn=Read Re
 plication Agreements,cn=permissions,cn=pbac,dc=MYREALM,dc=net”;)


But still executing the command below produces no output. Executing the command 
as admin does work:

ldapsearch -h localhost -LLL -x -D 
'uid=ipamonitor,cn=users,cn=accounts,dc=sgerasenko,dc=net' -w PWD 
'(&(nsuniqueid=---)(objectClass=nsTombstone))’ 
nsds50ruv

I’ve verified that “ipamonitor" does have "Read Replication Agreements" 
assigned.

Any ideas what could be missing?

Thanks,
  Sergei___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org/message/MCJ7KRVAYEKGFDZJ2K5EE5HYSPAYGCEF/

[389-users] Re: user privileges needed to run repl-monitor.pl

[Sergei Gerasenko]

Ok, might be something having to do with IPA. I’ll play more with it.

Thanks!!
  Sergei

> On Aug 17, 2018, at 4:51 PM, Mark Reynolds  wrote:
> 
> 
> 
> On 08/17/2018 04:59 PM, Sergei Gerasenko wrote:
>> Hi Mark,
>> 
>> I have a test instance of 389-ds running on a vm. I’ve tried updating the 
>> aci like this:
>> 
>> dn: cn=mapping tree,cn=config
>> changetype: modify
>> replace: aci
>> aci: (targetattr = "cn || nsuniqueid || createtimestamp || description || 
>> entryusn || modify
>>  timestamp || nsds50ruv || MORE STUFF)(targetfilter = 
>> "(|(objectclass=nsds5Replic
>>  
>> a)(objectclass=nsds5replicationagreement)(objectclass=nsDSWindowsReplicationA
>>  greement)(objectClass=nsMappingTree)(objectClass=nsTombstone))")(version 
>> 3.0;acl "permission:Read Repl
>>  ication Agreements";allow (compare,read,search) groupdn = "ldap:///cn=Read 
>> <ldap:///cn=Read> Re
>>  plication Agreements,cn=permissions,cn=pbac,dc=MYREALM,dc=net”;)
>> 
>> 
>> But still executing the command below produces no output. Executing the 
>> command as admin does work:
>> 
>> ldapsearch -h localhost -LLL -x -D 
>> 'uid=ipamonitor,cn=users,cn=accounts,dc=sgerasenko,dc=net' -w PWD 
>> '(&(nsuniqueid=---)(objectClass=nsTombstone))’
>>  nsds50ruv
>> 
>> I’ve verified that “ipamonitor" does have "Read Replication Agreements" 
>> assigned.
> Works for me if I add this aci:
> 
> dn: cn=mapping tree,cn=config
> aci: (targetattr = "*")(version 3.0; acl "All user to read agreements"; allow
>  (read,compare,search) (userdn = "ldap:///uid=mark,o=mark"; 
> <ldap:///uid=mark,o=mark>)
> 
> ldapsearch -h localhost -LLL -x -D 'uid=mark,o=mark' -w password -b o=mark 
> "(&(nsuniqueid=---)(objectClass=nsTombstone))"
> dn: cn=replica,cn=o\3Dmark,cn=mapping tree,cn=config
> objectClass: nsDS5Replica
> objectClass: top
> nsDS5ReplicaRoot: o=mark
> nsDS5ReplicaType: 3
> nsDS5Flags: 1
> nsDS5ReplicaId: 1
> nsds5ReplicaPurgeDelay: 604800
> cn: replica
> nsState:: AQDwQHdbAAADAA==
> nsDS5ReplicaName: e8f8e603-a24111e8-9b9de135-a578ede1
> nsds50ruv: {replicageneration} 5b7704130001
> nsds50ruv: {replica 1 ldap://localhost.localdomain:389 
> <ldap://localhost.localdomain:389>} 5b773c21 5
>  b7740f20001
> nsds5agmtmaxcsn: o=mark;f;localhost.localdomain;;unavailable
> nsruvReplicaLastModified: {replica 1 ldap://localhost.localdomain:389 
> <ldap://localhost.localdomain:389>} 000
>  0
> nsds5ReplicaChangeCount: 6
> nsds5replicareapactive: 0
> 
>> 
>> Any ideas what could be missing?
>> 
>> Thanks,
>>   Sergei
>> 
>> 
>> ___
>> 389-users mailing list -- 389-users@lists.fedoraproject.org 
>> <mailto:389-users@lists.fedoraproject.org>
>> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org 
>> <mailto:389-users-le...@lists.fedoraproject.org>
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html 
>> <https://getfedora.org/code-of-conduct.html>
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines 
>> <https://fedoraproject.org/wiki/Mailing_list_guidelines>
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org/message/MCJ7KRVAYEKGFDZJ2K5EE5HYSPAYGCEF/
>>  
>> <https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org/message/MCJ7KRVAYEKGFDZJ2K5EE5HYSPAYGCEF/>
> 

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org/message/IPU6PHOMBXTHR2624IOXQL6ACDFRIEL4/

[389-users] sudoers tree missing on a 389-ds replica

[Sergei Gerasenko]

Hello,

I’ve run into an interesting situatuion with the sudoers tree in 389-ds. All 
the nodes in the 389-ds cluster have it, but one doesn’t. I’ve tried dumping 
the database on a good node with db2ldif and reloading on the bad node with 
ldif2db, but the situation is not changing. I’ve also tried db2index on the bad 
node without much luck.

Any ideas?

Thanks,
  Sergei
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

[389-users] Re: sudoers tree missing on a 389-ds replica

[Sergei Gerasenko]

Looking closer, I see that the sudorules,dc=DC,dc=DC is there, but the combat 
tree (ou=sudoers,dc=DC,dc=DC) is not. Do you maintain the compat plugin?

> On Sep 23, 2019, at 10:15 AM, Sergei Gerasenko  wrote:
> 
> Hello,
> 
> I’ve run into an interesting situatuion with the sudoers tree in 389-ds. All 
> the nodes in the 389-ds cluster have it, but one doesn’t. I’ve tried dumping 
> the database on a good node with db2ldif and reloading on the bad node with 
> ldif2db, but the situation is not changing. I’ve also tried db2index on the 
> bad node without much luck.
> 
> Any ideas?
> 
> Thanks,
>  Sergei
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

[389-users] Re: sudoers tree missing on a 389-ds replica

[Sergei Gerasenko]

The compat plugin was disabled. After enabling, issue was fixed. Hope it helps 
somebody.

> On Sep 23, 2019, at 12:12 PM, Sergei Gerasenko  wrote:
> 
> Looking closer, I see that the sudorules,dc=DC,dc=DC is there, but the combat 
> tree (ou=sudoers,dc=DC,dc=DC) is not. Do you maintain the compat plugin?
> 
>> On Sep 23, 2019, at 10:15 AM, Sergei Gerasenko  wrote:
>> 
>> Hello,
>> 
>> I’ve run into an interesting situatuion with the sudoers tree in 389-ds. All 
>> the nodes in the 389-ds cluster have it, but one doesn’t. I’ve tried dumping 
>> the database on a good node with db2ldif and reloading on the bad node with 
>> ldif2db, but the situation is not changing. I’ve also tried db2index on the 
>> bad node without much luck.
>> 
>> Any ideas?
>> 
>> Thanks,
>> Sergei
> 
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org