[389-users] monitoring

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

[389-users] Re: monitoring

y 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 <gera...@gmail.com > <mailto:gera...@gmail.com>> wrote: > Hello, > > I’m trying to set up collectd to mo

[389-users] Re: performance tuning

PM, William Brown <wibr...@redhat.com> 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 >

[389-users] Re: performance tuning

Thanks, Mark!! > On Nov 17, 2017, at 10:58 AM, Mark Reynolds <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-d

[389-users] Re: performance tuning

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 <gera...@gmail.com> wrote: > > Thanks, Mark!! > >> On Nov 17, 2017, at 10:58 AM, Mark Reynolds <mreyno...@redhat.com >> <

[389-users] Re: performance tuning

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 >

[389-users] Re: performance tuning

> 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

[389-users] Re: performance tuning

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:

[389-users] performance tuning

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:

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

>> 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 > >

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

> To look at the replication changelog you need to use the cli tool "cl-dump.pl" > >

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

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] Re: Changelog, its location, ways to view, max life

> 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

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

>> 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

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

>> 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

[389-users] Re: Solving Naming Conflicts

Sergei > On Nov 7, 2017, at 4:44 PM, William Brown <wibr...@redhat.com> 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 (h

[389-users] Re: Solving Naming Conflicts

> 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: >> >>

[389-users] Re: Solving Naming Conflicts

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

[389-users] Re: Solving Naming Conflicts

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

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

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 <gera...@gmail.com> 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

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

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 +]

[389-users] Solving Naming Conflicts

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

[389-users] Re: BER Size

at.com> wrote: > > Hi, > On Wed, Dec 06 2017 at 10:34:05 -0600, Sergei Gerasenko <gera...@gmail.com> > wrote: >> Hi, >> >> I just discovered that I have a mismatch of BER sizes (nsslapd-maxbersize) >> between some of my masters. On the masters that

[389-users] BER Size

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

[389-users] Re: repl-monitor

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

[389-users] Re: repl-monitor

>> 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 >

[389-users] Re: repl-monitor

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] Re: repl-monitor

and the maxcsn in the RUV? Thanks! Sergei > On Oct 29, 2017, at 10:36 AM, Sergei Gerasenko <gera...@gmail.com> 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

[389-users] Re: repl-monitor

. What’s that an indication of? Thank you Sergei > On Oct 29, 2017, at 4:59 PM, Mark Reynolds <marey...@redhat.com> wrote: > > > > On 10/29/2017 03:20 PM, Sergei Gerasenko wrote: >> My question now is: what’s the difference between the maxcsn of the >> ag

[389-users] Re: repl-monitor

>> 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

[389-users] Re: repl-monitor

> 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

[389-users] Re: monitoring

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 =

[389-users] Re: monitoring

-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 > >

[389-users] Re: monitoring

> 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

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

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,

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

Thank you for that information, William. > On Jan 29, 2018, at 5:11 PM, William Brown <wibr...@redhat.com> 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

[389-users] Re: monitoring

on the errors metric? Thanks, Sergei > On Dec 21, 2017, at 5:46 PM, Marc Sauton <msau...@redhat.com> wrote: > > That should work. > Thanks, > M. > > On Thu, Dec 21, 2017 at 1:49 PM, Sergei Gerasenko <gera...@gmail.com > <mailto:gera...@gmail.com>> wro

[389-users] Re: monitoring

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

[389-users] Re: monitoring

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 <gera...@gmail.com> wrote: > >> What is an &q

[389-users] Re: monitoring

tml#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 <gera...@gmail.com> wrote: > > So does anybody have more details on the errors attribute under > cn=s

[389-users] Re: monitoring

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

[389-users] Re: monitoring

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 <gera...@gmail.com> wrote: > > Ok, thank you. I think the exact description of that counter is (from

[389-users] Re: monitoring

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 <mreyno...@redhat.com> wrote: > > > > On 01/03/2018 12:37 PM, Sergei Gerasenko wrote: >> Digging deeper

[389-users] Re: monitoring

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] Re: user privileges needed to run repl-monitor.pl

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

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

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:

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

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 run

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

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

[389-users] Failed modrdn operation

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

[389-users] Re: Failed modrdn operation

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:

[389-users] repl-monitor.pl

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

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

> 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?

[389-users] Re: autosizing the cache

ng 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 <gera...@gmail.co

[389-users] Re: autosizing the cache

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:

[389-users] DNA Plugin Troubles

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!

[389-users] Help with ldapsearch query

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,

[389-users] Re: Help with ldapsearch query

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 <gera...@g

[389-users] Re: Help with ldapsearch query

It does seem to be permission issue. Thank you. > On Apr 16, 2018, at 2:05 PM, Mark Reynolds <mreyno...@redhat.com> 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 ipaS

[389-users] Re: a replication problem

t 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

[389-users] Re: autosizing the cache

> 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.

[389-users] Re: a replication problem

5:05 PM, Sergei Gerasenko <gera...@gmail.com> 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

[389-users] Re: replication question

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

[389-users] Re: a replication problem

> 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

[389-users] Re: a replication problem

message is not there. I saw your commit 5 years ago on this issue. > On Mar 23, 2018, at 6:48 AM, Mark Reynolds <mreyno...@redhat.com> wrote: > > > > On 03/23/2018 12:07 AM, Sergei Gerasenko wrote: >> The error I’m basically getting is: >> >> [23/M

[389-users] Re: a replication problem

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

[389-users] Re: a replication problem

.@redhat.com> wrote: > > > > On 03/23/2018 10:01 AM, Sergei Gerasenko wrote: >> >> >>> On Mar 23, 2018, at 8:58 AM, Mark Reynolds <mreyno...@redhat.com >>> <mailto:mreyno...@redhat.com>> wrote: >>> >>> kinit -k -t /

[389-users] a replication problem

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

[389-users] Re: autosizing the cache

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

[389-users] Re: autosizing the cache

own <will...@blackhats.net.au> 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 &

[389-users] Re: a replication problem

rberos, 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

[389-users] Re: a replication problem

n supply more info. Thank you! Sergei > On Mar 23, 2018, at 6:48 AM, Mark Reynolds <mreyno...@redhat.com> 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 +] -

[389-users] Re: autosizing the cache

> 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

[389-users] autosizing the cache

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: ...

[389-users] Re: autosizing the cache

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

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

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

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

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

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

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 maintai