openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#8995) OpenLdap (SyncRepl + Mirror Mode) issue
by quanah＠symas.com 19 Mar '19

19 Mar '19

--On Tuesday, March 19, 2019 3:33 PM +0530 abhishek negi <abhisheknegi684(a)gmail.com> wrote: > > Hi Quanah, > > > If want to replicate Production (DC) site with Recovery (DR) site at real > time without any time lag which replication,DB and openldap verison would > be best to implement. I've already stated you need to upgrade to the current OpenLDAP release. I do not know how to make that any clearer. Additionally, it would literally defy physics to have instantaneous replication. There will always be some amount of delay. I would generally recommend the current OpenLDAP release using back-mdb as the database engine and delta-syncrepl using refreshAndPersist. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8995) OpenLdap (SyncRepl + Mirror Mode) issue
by abhisheknegi684＠gmail.com 19 Mar '19

19 Mar '19

--00000000000026eeeb05846ec7bd Content-Type: text/plain; charset="UTF-8" Hi Quanah, If want to replicate Production (DC) site with Recovery (DR) site at real time without any time lag which replication,DB and openldap verison would be best to implement. Earlier in version 2.4.38 , we used syncrepl +mirror mode replication but getting some time-lag. Please suggest On Mon 18 Mar, 2019, 7:18 PM Quanah Gibson-Mount <quanah(a)symas.com wrote: > --On Monday, March 18, 2019 2:24 PM +0000 abhisheknegi684(a)gmail.com wrote: > > > Full_Name: abhishek negi > > Version: 2.4.38 > > Hello, > > The 2.4.38 release is over 5 years old. There have literally been > hundreds > of bugs fixed with replication since that time. Please upgrade to a > current, modern release. No replication related issues will be examined > around such an ancient build of OpenLDAP. > > <https://www.openldap.org/software/release/changes.html> > > This ITS will be closed. > > Regards, > Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > > --00000000000026eeeb05846ec7bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto">Hi Quanah,<div dir=3D"auto"><br></div><div dir=3D"auto">I= f want to replicate Production (DC) site with Recovery (DR) site at real ti= me without any time lag which replication,DB and openldap verison would be = best to implement.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Earli= er in version 2.4.38 , we used syncrepl +mirror mode replication but gettin= g some time-lag.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Please = suggest</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon 1= 8 Mar, 2019, 7:18 PM Quanah Gibson-Mount <<a href=3D"mailto:quanah@symas= .com">quanah(a)symas.com</a> wrote:<br></div><blockquote class=3D"gmail_quote= " style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">-= -On Monday, March 18, 2019 2:24 PM +0000 <a href=3D"mailto:abhisheknegi684@= gmail.com" target=3D"_blank" rel=3D"noreferrer">abhisheknegi684(a)gmail.com</= a> wrote:<br> <br> > Full_Name: abhishek negi<br> > Version: 2.4.38<br> <br> Hello,<br> <br> The 2.4.38 release is over 5 years old.=C2=A0 There have literally been hun= dreds <br> of bugs fixed with replication since that time.=C2=A0 Please upgrade to a <= br> current, modern release.=C2=A0 No replication related issues will be examin= ed <br> around such an ancient build of OpenLDAP.<br> <br> <<a href=3D"https://www.openldap.org/software/release/changes.html" rel= =3D"noreferrer noreferrer" target=3D"_blank">https://www.openldap.org/softw= are/release/changes.html</a>><br> <br> This ITS will be closed.<br> <br> Regards,<br> Quanah<br> <br> <br> --<br> <br> Quanah Gibson-Mount<br> Product Architect<br> Symas Corporation<br> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:<br> <<a href=3D"http://www.symas.com" rel=3D"noreferrer noreferrer" target= =3D"_blank">http://www.symas.com</a>><br> <br> </blockquote></div> --00000000000026eeeb05846ec7bd--

1 0

Re: (ITS#8995) OpenLdap (SyncRepl + Mirror Mode) issue
by quanah＠symas.com 18 Mar '19

18 Mar '19

--On Monday, March 18, 2019 2:24 PM +0000 abhisheknegi684(a)gmail.com wrote: > Full_Name: abhishek negi > Version: 2.4.38 Hello, The 2.4.38 release is over 5 years old. There have literally been hundreds of bugs fixed with replication since that time. Please upgrade to a current, modern release. No replication related issues will be examined around such an ancient build of OpenLDAP. <https://www.openldap.org/software/release/changes.html> This ITS will be closed. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8995) OpenLdap (SyncRepl + Mirror Mode) issue
by abhisheknegi684＠gmail.com 18 Mar '19

18 Mar '19

Full_Name: abhishek negi Version: 2.4.38 OS: Linux 6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (182.77.13.52) PLease suggest a way to rectify the delay observed while replication. Below are the details: Replication used: SyncRepl + Mirror Mode (active-active setup) Replication Issue summary: Replication from DC-->DR is working fine with no time-lag b/w the packets/data. Facing issue with replication from DR--x-->DC setup. Sometimes, data/packets from DR flows with a delay to DC. This case doesn't follow any pattern, the setup works perfectly fine for 4-5 days, then suddenly packets/data flows with delay/time-lag. This delay is only observed from DR to DC. syncrepl rid=841 provider=ldap://<DC-IP>:389 bindmethod=simple binddn="cn=root,ou=test,o=test1,c=in" credentials=XXXXXXXXXXX searchbase="ou=test,o=test1,c=in" schemachecking=on attrs=* interval=00:00:00:10 type=refreshAndPersist retry="5 5 300 5" syncrepl rid=842 provider=ldap://<DR-IP>:389 bindmethod=simple binddn="cn=root,ou=test,o=test1,c=in" credentials=XXXXXXXXXXX searchbase="ou=test,o=test1,c=in" schemachecking=on attrs=* interval=00:00:00:10 type=refreshAndPersist retry="5 5 300 5" index entryCSN eq index entryUUID eq mirrormode TRUE overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100

1 0

Re: (ITS#8992) LDAP Over TLS causing reload
by quanah＠symas.com 14 Mar '19

14 Mar '19

--On Thursday, March 14, 2019 10:47 AM +0000 soneshkumar.patel(a)tcs.com wrote: > Full_Name: Sonesh Patel > Version: 2.4.46 > OS: FreeBSD > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (45.249.219.13) > > > Hi, > > We have introduced LDAP client using OpenLDAP 2.4.46 on FreeBSD server > and we are using LibreSSL 2.3.6 to perform SSL operations. We are using > SSL_CTX_add_extra_chain_cert API to add CA certificate into SSL context > and connection to LDAP server is successful. OpenLDAP does not support LibreSSL. Any build of OpenLDAP compiled against LibreSSL was hacked into place and is not supported by the OpenLDAP project. If you can reproduce the same behavior using a supported TLS library (OpenSSL or GnuTLS), feel free to follow up. > We already sent mail to the forum (openldap-its(a)openldap.org) dated Fri 7 > Dec, 2018 but no response till now. The list is for traffic regarding existing ITSes. It is not a general email list. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8992) LDAP Over TLS causing reload
by soneshkumar.patel＠tcs.com 14 Mar '19

14 Mar '19

Full_Name: Sonesh Patel Version: 2.4.46 OS: FreeBSD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (45.249.219.13) Hi, We have introduced LDAP client using OpenLDAP 2.4.46 on FreeBSD server and we are using LibreSSL 2.3.6 to perform SSL operations. We are using SSL_CTX_add_extra_chain_cert API to add CA certificate into SSL context and connection to LDAP server is successful. But when client initiate 100 parallel secure connection per second towards LDAP server by calling ldap_start_tls_s() API. FreeBSD server is going for Reload due to software exception reported from SSL library. We are using blocking socket to send and receive LDAP queries. With non-secure LDAP connection, client able to initiate 900 parallel connection towards LDAP server per second, but with secure LDAP connection, FreeBSD server is going for reload at 100 parallel connection per second itself. Does anyone observed similar issues with secure LDAP connection? We already sent mail to the forum (openldap-its(a)openldap.org) dated Fri 7 Dec, 2018 but no response till now. Appreciate for your response on above query. Regards, Sonesh

1 0

Re: (ITS#8991) Error while trying to create database with attribute olcSuffix in internationalized UTF-8 DN format.
by hyc＠symas.com 13 Mar '19

13 Mar '19

uneex(a)ya.ru wrote: > Full_Name: Varnava Sergey > Version: openldap-sasl-server-2.4.47 > OS: FreeBSD 12.0-RELEASE > URL: > Submission from: (NULL) (86.62.75.82) > > > slapd configured to use cn=config > > I'm trying to create database under cn=config with olcSuffix attribute set to DN > with international UTF-8 characters. > > `cat adddb.ldif` > dn: olcDatabase=mdb > objectClass: olcDatabaseConfig > objectClass: olcMdbConfig > olcDatabase: mdb > olcSuffix:: ZGM90KHQvtC70L3Ri9GI0LrQvixkYz3QlNGD0YDQlNC+0LwK > olcRootDN:: Y2490JTQuNGA0LXQutGC0L7RgCxkYz3QodC+0LvQvdGL0YjQutC+LGRjPdCU0YPRgNCU0L7QvAo= > olcRootPW:: e1NTSEF9ZHVyc2VjcmV0Cg== > olcDbIndex: objectClass eq > olcDbDirectory: /var/db/openldap-data > > When doing `ldapadd -x -w secret -f /root/adddb.ldif` > I'm getting this error: > > adding new entry "olcDatabase=mdb" > ldap_add: Invalid syntax (21) > additional info: olcSuffix: value #0 invalid per syntax Your DN is using "dc" attribute, whose syntax doesn't allow the characters you're using. This is not an OpenLDAP bug, this ITS will be closed. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8991) Error while trying to create database with attribute olcSuffix in internationalized UTF-8 DN format.
by uneex＠ya.ru 13 Mar '19

13 Mar '19

Full_Name: Varnava Sergey Version: openldap-sasl-server-2.4.47 OS: FreeBSD 12.0-RELEASE URL: Submission from: (NULL) (86.62.75.82) slapd configured to use cn=config I'm trying to create database under cn=config with olcSuffix attribute set to DN with international UTF-8 characters. `cat adddb.ldif` dn: olcDatabase=mdb objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: mdb olcSuffix:: ZGM90KHQvtC70L3Ri9GI0LrQvixkYz3QlNGD0YDQlNC+0LwK olcRootDN:: Y2490JTQuNGA0LXQutGC0L7RgCxkYz3QodC+0LvQvdGL0YjQutC+LGRjPdCU0YPRgNCU0L7QvAo= olcRootPW:: e1NTSEF9ZHVyc2VjcmV0Cg== olcDbIndex: objectClass eq olcDbDirectory: /var/db/openldap-data When doing `ldapadd -x -w secret -f /root/adddb.ldif` I'm getting this error: adding new entry "olcDatabase=mdb" ldap_add: Invalid syntax (21) additional info: olcSuffix: value #0 invalid per syntax Some debug from log file: ... Mar 13 20:32:00 ldap slapd[2181]: send_ldap_result: conn=1004 op=0 p=3 Mar 13 20:32:00 ldap slapd[2181]: send_ldap_response: msgid=1 tag=97 err=0 Mar 13 20:32:00 ldap slapd[2181]: daemon: activity on 1 descriptor Mar 13 20:32:00 ldap slapd[2181]: daemon: activity on: Mar 13 20:32:00 ldap slapd[2181]: 13r Mar 13 20:32:00 ldap slapd[2181]: Mar 13 20:32:00 ldap slapd[2181]: daemon: read activity on 13 Mar 13 20:32:00 ldap slapd[2181]: daemon: select: listen=6 active_threads=0 tvp=NULL Mar 13 20:32:00 ldap slapd[2181]: daemon: select: listen=7 active_threads=0 tvp=NULL Mar 13 20:32:00 ldap slapd[2181]: daemon: select: listen=8 active_threads=0 tvp=NULL Mar 13 20:32:00 ldap slapd[2181]: connection_get(13): got connid=1004 Mar 13 20:32:00 ldap slapd[2181]: connection_read(13): checking for input on id=1004 Mar 13 20:32:00 ldap slapd[2181]: op tag 0x68, time 1552498320 Mar 13 20:32:00 ldap slapd[2181]: conn=1004 op=1 do_add Mar 13 20:32:00 ldap slapd[2181]: daemon: activity on 1 descriptor Mar 13 20:32:00 ldap slapd[2181]: daemon: waked Mar 13 20:32:00 ldap slapd[2181]: daemon: select: listen=6 active_threads=0 tvp=NULL Mar 13 20:32:00 ldap slapd[2181]: daemon: select: listen=7 active_threads=0 tvp=NULL Mar 13 20:32:00 ldap slapd[2181]: daemon: select: listen=8 active_threads=0 tvp=NULL Mar 13 20:32:00 ldap slapd[2181]: >>> dnPrettyNormal: <olcDatabase=mdb> Mar 13 20:32:00 ldap slapd[2181]: <<< dnPrettyNormal: <olcDatabase=mdb>, <olcDatabase=mdb> Mar 13 20:32:00 ldap slapd[2181]: >>> dnPretty: <dc=Солн<D1>M-^K<D1>M-^Hко,dc=<D0>M-^T<D1>M-^C<D1>M-^@<D0>M-^Tом > Mar 13 20:32:00 ldap slapd[2181]: send_ldap_result: conn=1004 op=1 p=3 Mar 13 20:32:00 ldap slapd[2181]: send_ldap_response: msgid=2 tag=105 err=21 Mar 13 20:32:00 ldap slapd[2181]: daemon: activity on 1 descriptor Mar 13 20:32:00 ldap slapd[2181]: daemon: activity on: Mar 13 20:32:00 ldap slapd[2181]: 13r Mar 13 20:32:00 ldap slapd[2181]: Mar 13 20:32:00 ldap slapd[2181]: daemon: read activity on 13 Mar 13 20:32:00 ldap slapd[2181]: daemon: select: listen=6 active_threads=0 tvp=NULL Mar 13 20:32:00 ldap slapd[2181]: daemon: select: listen=7 active_threads=0 tvp=NULL Mar 13 20:32:00 ldap slapd[2181]: daemon: select: listen=8 active_threads=0 tvp=NULL Mar 13 20:32:00 ldap slapd[2181]: connection_get(13): got connid=1004 Mar 13 20:32:00 ldap slapd[2181]: connection_read(13): checking for input on id=1004 Mar 13 20:32:00 ldap slapd[2181]: op tag 0x42, time 1552498320 Mar 13 20:32:00 ldap slapd[2181]: ber_get_next on fd 13 failed errno=0 (No error: 0) Mar 13 20:32:00 ldap slapd[2181]: connection_read(13): input error=-2 id=1004, closing. Mar 13 20:32:00 ldap slapd[2181]: connection_closing: readying conn=1004 sd=13 for close Mar 13 20:32:00 ldap slapd[2181]: connection_close: deferring conn=1004 sd=13 Mar 13 20:32:00 ldap slapd[2181]: conn=1004 op=2 do_unbind Mar 13 20:32:00 ldap slapd[2181]: connection_resched: attempting closing conn=1004 sd=13 Mar 13 20:32:00 ldap slapd[2181]: connection_close: conn=1004 sd=13 Mar 13 20:32:00 ldap slapd[2181]: daemon: removing 13 Mar 13 20:32:00 ldap slapd[2181]: daemon: activity on 1 descriptor Mar 13 20:32:00 ldap slapd[2181]: daemon: waked Mar 13 20:32:00 ldap slapd[2181]: daemon: select: listen=6 active_threads=0 tvp=NULL Mar 13 20:32:00 ldap slapd[2181]: daemon: select: listen=7 active_threads=0 tvp=NULL Mar 13 20:32:00 ldap slapd[2181]: daemon: select: listen=8 active_threads=0 tvp=NULL ... Is it possible to solve this problem?

1 0

(ITS#7770) mdb_stat in cn=monitor
by michael＠stroeder.com 12 Mar '19

12 Mar '19

I'm currently testing this feature back-ported to RE24 branch. I noticed that these attributes are set to empty values: creatorsName: modifiersName: Rest of entry looks good: dn: cn=Database 1,cn=Databases,cn=Monitor objectClass: monitoredObject objectClass: olmMDBDatabase structuralObjectClass: monitoredObject cn: Database 1 creatorsName: modifiersName: createTimestamp: 20190312102553Z modifyTimestamp: 20190312102553Z monitoredInfo: mdb monitorIsShadow: FALSE namingContexts: cn=accesslog readOnly: FALSE monitorOverlay: noopsrch seeAlso: cn=Overlay 1,cn=Overlays,cn=Monitor seeAlso: cn=Backend 2,cn=Backends,cn=Monitor olmMDBPagesMax: 97656 olmMDBPagesUsed: 33695 olmMDBPagesFree: 88 olmMDBReadersMax: 126 olmMDBReadersUsed: 3 olmDbDirectory: /var/lib/ldap/accesslog/ entryDN: cn=Database 1,cn=Databases,cn=Monitor subschemaSubentry: cn=Subschema hasSubordinates: TRUE

1 0

(ITS#8990) accesslog overlay misses SLAP_MOD_SOFT mod ops
by hyc＠openldap.org 11 Mar '19

11 Mar '19

Full_Name: Howard Chu Version: 2.4 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.233.37.163) Submitted by: hyc The delta-sync consumer turns incoming delete modops with no value into Soft deletes, to avoid the need for an error check. The accesslog overlay is ignoring these modops.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs