openldap-technical

openldap-technical@openldap.org

22 participants
9803 discussions

How to Modify OpenLDAP Entry for Replication
by Scott McLane Gardner 12 Mar '12

12 Mar '12

OpenLDAP newbie here, hopefully this is the right list to send this sort of thing to. I have successfully set up two OpenLDAP servers one as the master and the other replicating the masters database using the instructions in the ubuntu documentation, here: https://help.ubuntu.com/11.10/serverguide/C/openldap-server.html#openldap-s erver-replication What I'd like to do now is change the admin password on the master, but that will break the replication. How can I change the consumer configuration (further down the page linked above) to update it with the new password? I'm sure that using ldapmodify is probably what I want, I just don't know enough to do it correctly.

1 0

Large delay before transmitting search result
by Rene B. Elgaard 12 Mar '12

12 Mar '12

Hello, OpenLDAP 2.4.26 + BerkeleyDB 5.2.28, also seen on OpenLDAP 2.4.22 + BerkeleyDB 4.6.21 I am trying to investigate a response time issue. Basically I am doing a search with ldapsearch that results in the transfer of an 8.5 Mb binary entry. This takes around 800 ms measured on the server itself from the request has been received until the response has been delivered.. Looking at what is going on on the network I see a large delay between slapd receiving the search request and the actual start of the transfer. This delay accounts for around 600ms. So what is going on during this time ? I am on Solaris 10, so I use dtrace to look at slapd, and it turns out that it calls memmove(<ADDR>,<ADDR> + 1, ~8.5 Mb). That is it shifts the result 1 byte, and it does this 4 times. Each memmove takes around 150 ms, which accounts almost completely for the delay before doing the transfer over network. I have written a small C program which does the same memmove and verified that on my setup, it does indeed take 150ms to shift 8.5 Mb 1 byte. The stacktrace up until each memmove is 0 42451 memmove:entry *** Moving from 213650401 to 213650402 *** libc.so.1`memmove slapd`0x82461c9 slapd`ber_printf+0x4ff slapd`slap_send_search_entry+0x1a94 slapd`bdb_search+0x1ce0 slapd`fe_op_search+0x574 slapd`do_search+0xc82 slapd`0x80927a9 slapd`0x8092d21 slapd`0x8210034 The first line shows the source and destination address for memmove. The numbers themselves are not interesting, but the difference (1) is. Why is it shifting the buffer 1 byte ? If this could be optimized somehow, it could lead to a huge improvement in response time. Thanks, Rene

4 3

Re: slow or inconsistent syncrepl
by Amol Kulkarni 11 Mar '12

11 Mar '12

I see that I'm outdated in my tuning as per http://wiki.zimbra.com/wiki/OpenLDAP_Performance_Tuning. I'll do these changes and observe the servers. In the mean time a new observation regarding syncrepl is that if I do ldapmodify for 5 - 10 entries in one go the changes get replicated but if I change about 300 entries in one go, then some entries do not get replicated on some servers. These changes dont get replicated until I change those entries again. Does this indicate provider resource problem or consumer resource problem ( or normal behaviour ) ? ----- Original Message ----- From: Quanah Gibson-Mount Sent: 03/11/12 02:05 AM To: Amol Kulkarni, Howard Chu Subject: Re: slow or inconsistent syncrepl --On Saturday, March 10, 2012 2:34 PM +0100 Amol Kulkarni <amolkulkarni(a)gmx.com> wrote: > > >>> That depends entirely on the speed of your server and network. > > Taking the server part first - I'm also doubt that my provider server is > underpowered. > > Following are the ldap specific parameters on our provider server : > > entries : 0.5 million > avg entry size : 1k to 4k > cachesize : 0.5 million > dncachesize : 0.5 million > database type : bdb > bdb cachesize : 3 gb > ldap threads : 16 > > Foll is hardware configuration of the provider server : > ram : 8gb > swap : 8gb > cpu : Virtual machine with 4 cpus. (vmware vsphere) > architecture : 64 bit > > Also we have some administrative services/tasks running on the provider > server other than openldap. But the sar output seems normal i.e iowait > below 10 and idle time above 50. > > Does the hardware configuration seem ok for the given ldap size and > configuration ? > > If not, can u suggest some changes? You don't provide any useful information for suggesting changes. I would advise you read over <http://wiki.zimbra.com/wiki/OpenLDAP_Performance_Tuning> -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

2 1

Re: slow or inconsistent syncrepl
by Amol Kulkarni 10 Mar '12

10 Mar '12

>>That depends entirely on the speed of your server and network. Taking the server part first - I'm also doubt that my provider server is underpowered. Following are the ldap specific parameters on our provider server : entries : 0.5 million avg entry size : 1k to 4k cachesize : 0.5 million dncachesize : 0.5 million database type : bdb bdb cachesize : 3 gb ldap threads : 16 Foll is hardware configuration of the provider server : ram : 8gb swap : 8gb cpu : Virtual machine with 4 cpus. (vmware vsphere) architecture : 64 bit Also we have some administrative services/tasks running on the provider server other than openldap. But the sar output seems normal i.e iowait below 10 and idle time above 50. Does the hardware configuration seem ok for the given ldap size and configuration ? If not, can u suggest some changes? Thanks and Regards, Amol Kulkarni. ----- Original Message ----- From: Howard Chu Sent: 03/10/12 01:29 PM To: Amol Kulkarni Subject: Re: slow or inconsistent syncrepl Amol Kulkarni wrote: > Dear Quanah, > > Thanks a lot for these 2 pointers. I'll check out the 2.4.30 version. > We had used delta syncrepl earlier but our accesslog size used to grow > suddenly sometimes and the disk used to get full crashing/hanging the ldap > service itself on the provider. But at that time we had kept the max age for > the accesslog to be 7 days. I'll reduce it and give it a try again. > > Also it would be helpful if you can throw some light on : > > 2. On a really busy ldap server, can replication slow down drastically? i.e > does the read operations affect the replication in any way? Syncrepl executes as an LDAP Search operation, so of course it competes for server resources with other Search activity on the server. > 4. We are currently having about 60 consumers - is this too much ? What can be > the max numbers of consumers ? That depends entirely on the speed of your server and network. If you're seeing that replication speed is inconsistent, you probably should reduce the load on the provider. A simple approach in your scenario would be to just point the 10 consumers on the fast LAN at the provider, and configure these consumers to act as providers for your WAN nodes (i.e., cascaded replication). > 5. Sometimes we urgently need some particular node to be present on the > consumer - for which we cannot wait - in that case we get ldif of that node > from provider and do ldapadd on the consumer ( mirrormode is ON on the > consumers ). Is this safe and correct or could it cause some side effects ? Is > there a better way to handle it? If you have configured distinct serverIDs for each consumer, this might work. Otherwise, no, not safe, not correct. Fix your configuration layout, or fix your apps. If your apps can't wait then they are mis-designed; there is no such thing as instantaneous propagation of information in the real world. > Thanks and Regards, > Amol Kulkarni. > >> ----- Original Message ----- >> >> From: Quanah Gibson-Mount >> >> Sent: 03/09/12 11:57 PM >> >> To: Amol Kulkarni, openldap-technical(a)openldap.org >> >> Subject: Re: slow or inconsistent syncrepl >> >> >> >> --On Friday, March 09, 2012 2:20 PM +0100 Amol Kulkarni >> <amolkulkarni(a)gmx.com> wrote: >> >> > I have a following openldap setup with syncrepl : >> > - openldap version 2.4.23 >> >> This is your #1 issue. >> >> > - 1 provider and about 10 consumers in lan and 50 consumers on wan >> >> This is your #2 issue. >> >> Upgrade to a stable release. Use delta-syncrepl, which uses significantly >> less bandwidth than syncrepl. >> >> --Quanah >> >> -- >> >> Quanah Gibson-Mount >> Sr. Member of Technical Staff >> Zimbra, Inc >> A Division of VMware, Inc. >> -------------------- >> Zimbra :: the leader in open source messaging and collaboration -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

OpenLDAP 2.4 : replication doesn't work when customer is stopped
by PROST Frédéric 10 Mar '12

10 Mar '12

Hello, I configured MirrorMode replication between 2 openldap 2.4 node installed on Debian (from apt). Everything is working fine when the two nodes are online but if I stop the second node, and add new datas to the first node, then restart the second node, the new data are not synced. However, if I then add new datas on node 1, they are replicated to node2 without problem. Here is a scenario of this problem : 1/ node1 and node 2 are online : I add user1 to node 1 => user1 appears on node2 => ok 2/ node1 is online and node2 is off : I add user2 on node1 => nothing happens on node2 as it is off => ok 3/ I restart node2 => user2 is not replicated to node2 => not ok 4/ node1 and node 2 are online : I add user3 to node 1 => user3 appears on node2 => ok At the end of this scenario, node1 contains user1, user2 and user3 and node2 contains only user1 and user3 (but not user2). How can I slove this problem ? Thank you for your help, Best regards, Fred Here is my config : version: 1 dn: cn=config objectClass: olcGlobal cn: config olcAllows: bind_v2 olcArgsFile: /var/run/slapd/slapd.args olcLogLevel: any olcPidFile: /var/run/slapd/slapd.pid olcServerID: 1 ldap://192.168.1.103 olcServerID: 2 ldap://192.168.1.104 olcSizeLimit: 1000000 olcToolThreads: 1 dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModuleLoad: {0}back_hdb olcModuleLoad: {1}syncprov olcModulePath: /usr/lib/ldap dn: olcBackend={0}hdb,cn=config objectClass: olcBackendConfig olcBackend: {0}hdb dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=extern al,cn=auth manage by * break olcAccess: {1}to dn.exact="" by * read olcAccess: {2}to dn.base="cn=Subschema" by * read olcSizeLimit: 500 dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by dn.exact="uid=syncrepl,dc=tracteur91,dc=local" read by * break olcAccess: {1}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=extern al,cn=auth manage by * break olcLimits: {0}dn.exact="uid=syncrepl,dc=tracteur91,dc=local" size=unlimited olcMirrorMode: TRUE olcRootDN: cn=admin,cn=config olcRootPW: {MD5}BkY718PMIcgBNjpfXmGpOA== olcSyncrepl: {0}rid=001 provider="ldap://192.168.1.103" searchbase="cn=confi g" type=refreshAndPersist bindmethod=simple binddn="uid=syncrepl,dc=tracteu r91,dc=local" credentials="Tr@cteur91" retry="30 +" network-timeout=5 timeo ut=30 olcSyncrepl: {1}rid=002 provider="ldap://192.168.1.104" searchbase="cn=confi g" type=refreshAndPersist bindmethod=simple binddn="uid=syncrepl,dc=tracteu r91,dc=local" credentials="Tr@cteur91" retry="30 +" network-timeout=5 timeo ut=30 dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpCheckpoint: 100 5 dn: olcDatabase={1}hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {1}hdb olcDbDirectory: /var/lib/ldap olcAccess: {0}to * by dn.exact="uid=syncrepl,dc=tracteur91,dc=local" read by * break olcAccess: {1}to attrs=userPassword,shadowLastChange by self write by anonym ous auth by dn="cn=admin,dc=tracteur91,dc=local" write by * none olcAccess: {2}to dn.base="" by * read olcAccess: {3}to * by self write by dn="cn=admin,dc=tracteur91,dc=local" wri te by * read olcDbCheckpoint: 512 30 olcDbConfig: {0}set_cachesize 0 2097152 0 olcDbConfig: {1}set_lk_max_objects 1500 olcDbConfig: {2}set_lk_max_locks 1500 olcDbConfig: {3}set_lk_max_lockers 1500 olcDbIndex: objectClass eq olcDbIndex: uid eq olcDbIndex: cn eq olcDbIndex: ou eq olcDbIndex: dc eq olcDbIndex: entryCSN eq olcDbIndex: entryUUID eq olcLastMod: TRUE olcLimits: {0}dn.exact="uid=syncrepl,dc=tracteur91,dc=local" size=unlimited olcMirrorMode: TRUE olcRootDN: cn=admin,dc=tracteur91,dc=local olcRootPW: {SSHA}ZtvvlHUQYloI17cv2/cjPFmx51+Ut/+5 olcSuffix: dc=tracteur91,dc=local olcSyncrepl: {0}rid=003 provider="ldap://192.168.1.103" searchbase="dc=tract eur91,dc=local" type=refreshAndPersist bindmethod=simple binddn="uid=syncre pl,dc=tracteur91,dc=local" credentials="Tr@cteur91" retry="30 +" network-ti meout=5 timeout=30 olcSyncrepl: {1}rid=004 provider="ldap://192.168.1.104" searchbase="dc=tract eur91,dc=local" type=refreshAndPersist bindmethod=simple binddn="uid=syncre pl,dc=tracteur91,dc=local" credentials="Tr@cteur91" retry="30 +" network-ti meout=5 timeout=30 dn: olcOverlay={0}syncprov,olcDatabase={1}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpCheckpoint: 100 5

3 8

Re: slow or inconsistent syncrepl
by Amol Kulkarni 10 Mar '12

10 Mar '12

Dear Quanah, Thanks a lot for these 2 pointers. I'll check out the 2.4.30 version. We had used delta syncrepl earlier but our accesslog size used to grow suddenly sometimes and the disk used to get full crashing/hanging the ldap service itself on the provider. But at that time we had kept the max age for the accesslog to be 7 days. I'll reduce it and give it a try again. Also it would be helpful if you can throw some light on : 2. On a really busy ldap server, can replication slow down drastically? i.e does the read operations affect the replication in any way? 4. We are currently having about 60 consumers - is this too much ? What can be the max numbers of consumers ? 5. Sometimes we urgently need some particular node to be present on the consumer - for which we cannot wait - in that case we get ldif of that node from provider and do ldapadd on the consumer ( mirrormode is ON on the consumers ). Is this safe and correct or could it cause some side effects ? Is there a better way to handle it? Thanks and Regards, Amol Kulkarni. ----- Original Message ----- From: Quanah Gibson-Mount Sent: 03/09/12 11:57 PM To: Amol Kulkarni, openldap-technical(a)openldap.org Subject: Re: slow or inconsistent syncrepl --On Friday, March 09, 2012 2:20 PM +0100 Amol Kulkarni <amolkulkarni(a)gmx.com> wrote: > I have a following openldap setup with syncrepl : > - openldap version 2.4.23 This is your #1 issue. > - 1 provider and about 10 consumers in lan and 50 consumers on wan This is your #2 issue. Upgrade to a stable release. Use delta-syncrepl, which uses significantly less bandwidth than syncrepl. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

2 1

slow or inconsistent syncrepl
by Amol Kulkarni 09 Mar '12

09 Mar '12

I have a following openldap setup with syncrepl : - openldap version 2.4.23 - 1 provider and about 10 consumers in lan and 50 consumers on wan - The replication type is push - refreshAndPersist. - There are about 0.5 million nodes - The physical size of ldap folder is about 5gb. - All the lan servers have identical hardware configuration. I have following problems/questions. 1. We observe that LDAP replication works better on one server as opposed to another in same LAN and having the same configuration ? Is ldap replication affected by the ldap read operations on the consumers? So if 2 consumers are getting different amount of ldap reads, will replication speed be different? 2. On a really busy ldap server, can replication slow down drastically? 3. We find that even though the contextcsn of provider & consumer is same - actually there are nodes which are different and there are nodes which are not added or deleted. So we have created a custom script which compares entrycsn's of each and every node. Is this ok ? 4. We are currently having about 60 consumers - is this too much ? What can be the max numbers of consumers ? 5. Sometimes we urgently need some particular node to be present on the consumer - for which we cannot wait - in that case we get ldif of that node from provider and do ldapadd on the consumer ( mirrormode is ON on the consumers ). Is this safe and correct or could it cause some side effects ? Kindly help me in troubleshooting these issues. Right now I cant think of what server configuration I could provide so I dint give it in this mail so pls tell me if anyone needs some particular configuration. Thanks and Regards, Amol Kulkarni.

4 4

Re: configure options
by Brett ＠Google 09 Mar '12

09 Mar '12

Turned out there was an LD_LIBRARY_PATH used for the already running openldap, but was set, so the "make test" prior to installation, was run against the installed libraries, instead of the newly compiled (but as yet uninstalled) ones in the build directory. Arguably the test could "unset LD_LIBRARY_PATH" but that variable might be used to find berkeley dn or other thrid part libraries, so maybe LD_LIBRARY_PATH="`pwd`/libraries/liblber/.libs `pwd`/libraries/libldap/.libs" to the script that launches tests ? Has there ever been any thought of having a --with-bdb=<prefix> which implies the addition of CPPFLAGS="-I<prefix>/include" and LDFLAGS="-L<prefix>/lib" and similarly for things like --with-ssl=<another prefix> ? Personally i alway have to add -R<prefix>/lib also, but this varies by platform, eg. linux has removed this in preference of a gcc option which passes options through to the linker, so it's probably hard to do in a platform-agnostic manner. On Fri, Mar 9, 2012 at 12:07 PM, Howard Chu <hyc(a)symas.com> wrote: > Quanah Gibson-Mount wrote: > >> --On Friday, March 09, 2012 10:49 AM +1000 "Brett @Google" >> <brett.maxfield(a)gmail.com> wrote: >> >> Hello, >>> >>> Are the tests in test050 (multimaster concurrency) for release 2.4.30, >>> still likely or expected to fail on solaris 10 with bdb 4.8.30 ? >>> >>> We dont use multimaster, but at one point in recent history the tests in >>> test050 (multimaster concurrency) were expected to fail. >>> >>> I'll log an ITS if it is now unexpected for this test to fail.. >>> >>> Cheers >>> Brett >>> >>> Waiting 5 seconds for slapd to start... >>> Waiting 5 seconds for slapd to start... >>> 29490 Segmentation Fault - core dumped >>> >> >> segmentation faults are never expected. You should file an ITS with the >> backtrace on the core file. >> > > And the last few lines of slapd.1.log. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/**project/<http://www.openldap.org/project/> > -- *The only thing that interferes with my learning is my education.* * Albert Einstein*

1 0

fw: multimaster
by Brett ＠Google 09 Mar '12

09 Mar '12

Hello, Are the tests in test050 (multimaster concurrency) for release 2.4.30, still likely or expected to fail on solaris 10 with bdb 4.8.30 ? We dont use multimaster, but at one point in recent history the tests in test050 (multimaster concurrency) were expected to fail. I'll log an ITS if it is now unexpected for this test to fail.. Cheers Brett Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... 29490 Segmentation Fault - core dumped Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... ldapsearch failed (255)! ./scripts/test050-syncrepl-multimaster: kill: no such process >>>>> test050-syncrepl-multimaster failed for hdb (exit 255) *** Error code 255 The following command caused the error: ./run -b hdb all make: Fatal error: Command failed for target `hdb-yes' Current working directory /home/govops/build/openldap/openldap-2.4.30/tests *** Error code 1 The following command caused the error: make hdb make: Fatal error: Command failed for target `test' Current working directory /home/govops/build/openldap/openldap-2.4.30/tests gmake: *** [test] Error 1 -- *The only thing that interferes with my learning is my education.* * Albert Einstein*

3 2

multi-master syncrepl with sasl/gssapi authentication
by travis.bean＠assuretech.net 08 Mar '12

08 Mar '12

I am having trouble getting multi-master syncrepl to sync when using "bindmethod=sasl" and "saslmech=gssapi". I achieved success when I tried "bindmethod=simple", so at least I know it has been narrowed down to a sasl/gssapi authentication problem (incorrect/missing sasl AuthzRegexp or perhaps an incorrect/missing slapd ACL?). My syncrepl config is as follows (do I need to specify an authcid/authzid or is this id automatically obtained from gssapi?): olcMirrorMode: TRUE olcSyncRepl: rid=001 provider=ldap://or-dc1-db.example.corp retry="5 10 30 +" bindmethod=sasl saslmech=gssapi type=refreshAndPersist searchbase="cn=config" olcSyncRepl: rid=002 provider=ldap://or-dc2-db.example.corp retry="5 10 30 +" bindmethod=sasl saslmech=gssapi type=refreshAndPersist searchbase="cn=config" # Syncprov overlay dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov olcMirrorMode: TRUE olcSyncRepl: rid=003 provider=ldap://or-dc1-db.example.corp retry="5 10 30 +" bindmethod=sasl saslmech=gssapi type=refreshAndPersist searchbase="dc=example,dc=corp" olcSyncRepl: rid=004 provider=ldap://or-dc2-db.example.corp retry="5 10 30 +" bindmethod=sasl saslmech=gssapi type=refreshAndPersist searchbase="dc=example,dc=corp" # Syncprov overlay dn: olcOverlay=syncprov,olcDatabase={1}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov My access control: olcAccess: to attrs=userPassword,shadowLastChange by dn="uid=ldap-admin,ou=people,dc=example,dc=corp" write by dn="uid=ldap/or-dc1-db.example.corp,cn=example.corp,cn=gssapi,cn=auth" write by dn="uid=ldap/or-dc2-db.example.corp,cn=example.corp,cn=gssapi,cn=auth" write by anonymous auth by self write by * none olcAccess: to dn.subtree="ou=krb5,dc=example,dc=corp" by dn="cn=kdc-srv,ou=krb5,dc=example,dc=corp" read by dn="cn=adm-srv,ou=krb5,dc=example,dc=corp" write by * none olcAccess: to * by dn="uid=ldap-admin,ou=people,dc=example,dc=corp" write by dn="uid=ldap/or-dc1-db.example.corp,cn=example.corp,cn=gssapi,cn=auth" write by dn="uid=ldap/or-dc2-db.example.corp,cn=example.corp,cn=gssapi,cn=auth" write by peername.ip="192.168.0.0%255.255.255.0" read My sasl AuthzRegexp: olcAuthzRegexp: uid=([^,]+),cn=example.corp,cn=gssapi,cn=auth uid=$1,ou=people,dc=example,dc=corp I know sasl/gssapi are working since ldapwhoami on or-dc1-db returns: SASL/GSSAPI authentication started SASL username: ldap/or-dc1-db.example.corp(a)EXAMPLE.CORP SASL SSF: 56 SASL data security layer installed. dn:uid=ldap/or-dc1-db.example.corp,ou=people,dc=example,dc=corp ldapwhoami on or-dc2-db returns: SASL/GSSAPI authentication started SASL username: ldap/or-dc2-db.example.corp(a)EXAMPLE.CORP SASL SSF: 56 SASL data security layer installed. dn:uid=ldap/or-dc2-db.example.corp,ou=people,dc=example,dc=corp I get the following /var/log/syslog errors on or-dc1-db: OR-DC1-DB slapd[5446]: slap_client_connect: URI=ldap://or-dc2-db.example.corp ldap_sasl_interactive_bind_s failed (-2) OR-DC1-DB slapd[5446]: do_syncrepl: rid=004 rc -2 retrying OR-DC1-DB slapd[5446]: slap_client_connect: URI=ldap://or-dc2-db.example.corp ldap_sasl_interactive_bind_s failed (-2) OR-DC1-DB slapd[5446]: do_syncrepl: rid=002 rc -2 retrying /var/log/syslog errors on or-dc2-db: OR-DC2-DB slapd[5455]: slap_client_connect: URI=ldap://or-dc1-db.example.corp ldap_sasl_interactive_bind_s failed (-2) OR-DC2-DB slapd[5455]: do_syncrepl: rid=003 rc -2 retrying OR-DC2-DB slapd[5455]: slap_client_connect: URI=ldap://or-dc1-db.example.corp ldap_sasl_interactive_bind_s failed (-2) OR-DC2-DB slapd[5455]: do_syncrepl: rid=001 rc -2 retrying

3 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical