openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#9154) RFE: Number of entries in MDB database in cn=monitor
by hyc＠symas.com 18 Jan '20

18 Jan '20

michael(a)stroeder.com wrote: > Full_Name: Michael Str.der > Version: master > OS: > URL: > Submission from: (NULL) (213.240.182.99) > > > As a system engineer I want to see the number of entries within a mdb database > in the monitoring (e.g. to alarm unusual fast changes due to false deletions). > > While one can use mdb_stat or other custom scripts to monitor the number of > entries of the id2e sub-DB this requires read access to the MDB environment. But > for security reasons this should be avoided. > > olmMDBDatabase entries in cn=monitor already have attributes for MDB page > counts. > The number of entries could be added there as attribute 'olmMDBEntries' or > similar. Added in git master -- -- 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#9154) RFE: Number of entries in MDB database in cn=monitor
by michael＠stroeder.com 17 Jan '20

17 Jan '20

Full_Name: Michael Str.der Version: master OS: URL: Submission from: (NULL) (213.240.182.99) As a system engineer I want to see the number of entries within a mdb database in the monitoring (e.g. to alarm unusual fast changes due to false deletions). While one can use mdb_stat or other custom scripts to monitor the number of entries of the id2e sub-DB this requires read access to the MDB environment. But for security reasons this should be avoided. olmMDBDatabase entries in cn=monitor already have attributes for MDB page counts. The number of entries could be added there as attribute 'olmMDBEntries' or similar.

1 0

(ITS#9153) replication.sdf inconsistent whitespace
by ryan＠openldap.org 14 Jan '20

14 Jan '20

Full_Name: Ryan Tandy Version: RE24 OS: URL: https://github.com/openldap/openldap/compare/OPENLDAP_REL_ENG_2_4...rtandy:… Submission from: (NULL) (70.66.128.207) Submitted by: ryan This patch fixes indentation of two 'maxsize' lines in the 'Syncrepl Proxy' example. For RE24 only as master lacks these lines (will fix separately).

1 0

(ITS#9152) Configuring autoca before database exists crashes slapd
by quanah＠openldap.org 13 Jan '20

13 Jan '20

Full_Name: Quanah Gibson-Mount Version: HEAD OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.143.26) If you configure autoca via cn=config when the underlying DB does not yet exist, slapd will crash. i.e., I added this entry to my cn=config db: dn: olcOverlay=autoca,olcDatabase={1}mdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcACAConfig olcOverlay: autoca olcACAlocalDN: cn=anvil4.rb.symas.net,ou=Servers,dc=rb,dc=symas,dc=net while the mdb database was not yet populated.

1 0

Re: (ITS#9126) add: pwdChangedTime leads to seg fault
by michael＠stroeder.com 13 Jan '20

13 Jan '20

This still happens with current RE24 snapshot. Is more information needed to address this?

1 0

Re: (ITS#9151) slapd-sock - stumped
by matthew＠schlutech.com 12 Jan '20

12 Jan '20

I will move this there thank you. It is difficult to know where to go - this seems like a bug as the behavior is pervasive in all my testing. I have now tried multiple OS and multiple versions of OpenLDAP. As for the path differences - that was just me copying/pasting from two separate tests. I assure you the problem persists when the paths are correct. As you pointed out - inconsistent in the information I provided therein - not in actual testing. Thank you. On 1/12/20 3:30 AM, Michael Ströder wrote: > On 1/11/20 9:03 PM, matthew(a)schlutech.com wrote: >> Always results in socket connect failed. >> >> database sock >> socketpath /tmp/example.sock >> [..] >> Always: socket connect(/root/example.sock) failed > /tmp/example.sock != /root/example.sock > > Either something's inconsistent in your config or the information you > provided herein. > > Also this does not seem to be a bug report but the ITS is only for > reporting bugs. Please send usage questions to openldap-technical > mailing list. > > Ciao, Michael. > >

1 0

Re: (ITS#9151) slapd-sock - stumped
by michael＠stroeder.com 12 Jan '20

12 Jan '20

On 1/11/20 9:03 PM, matthew(a)schlutech.com wrote: > Always results in socket connect failed. > > database sock > socketpath /tmp/example.sock > [..] > Always: socket connect(/root/example.sock) failed /tmp/example.sock != /root/example.sock Either something's inconsistent in your config or the information you provided herein. Also this does not seem to be a bug report but the ITS is only for reporting bugs. Please send usage questions to openldap-technical mailing list. Ciao, Michael.

1 0

(ITS#9151) slapd-sock - stumped
by matthew＠schlutech.com 11 Jan '20

11 Jan '20

Full_Name: W. Matthew Schlueter Version: 2.4.45+dfsg-1ubuntu1.4 OS: Ubuntu 18.04.3 LTS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (172.101.204.19) Always results in socket connect failed. Using the examples from the source tree: modulepath /usr/lib/ldap moduleload back_sock.so include /etc/ldap/schema/core.schema database sock socketpath /tmp/example.sock suffix "dc=test,dc=com" Starting slapd: slapd -4 -f /etc/ldap/slapd.conf -u root -g root -d1 Using the perl script example from the source tree plus tried endless debugging with my own code. File permissions all look correct. Scoured for answers. Stumped. Always: socket connect(/root/example.sock) failed

1 0

Re: (ITS#9150) olcDbNoSync: FALSE has the same effect as olcDbNoSync: TRUE
by hyc＠symas.com 10 Jan '20

10 Jan '20

maxime.besson(a)worteks.com wrote: > Full_Name: Maxime Besson > Version: 2.4.48 > OS: Debian Buster / CentOS7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2a01:cb00:802:8400:2cbe:3c60:fca6:e50b) > > > While migrating configuration from slapd.conf to cn=config, I noticed something > pretty strange related to the dbnosync option Thanks for the report, fixed now in git master. > > The result of converting the following config: > > include ./core.schema > pidfile ./slapd.1.pid > argsfile ./slapd.1.args > > > database mdb > suffix "dc=example,dc=com" > rootdn "cn=Manager,dc=example,dc=com" > rootpw secret > directory db.1.a > index objectClass eq > index cn,sn,uid pres,eq,sub > index entryUUID,entryCSN eq > > > Is (only interested in MDB config): > # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. > # CRC32 3df9c3d6 > dn: olcDatabase={1}mdb > objectClass: olcDatabaseConfig > objectClass: olcMdbConfig > olcDatabase: {1}mdb > olcSuffix: dc=example,dc=com > olcAddContentAcl: FALSE > olcLastMod: TRUE > olcMaxDerefDepth: 15 > olcReadOnly: FALSE > olcRootDN: cn=Manager,dc=example,dc=com > olcRootPW:: c2VjcmV0 > olcSyncUseSubentry: FALSE > olcMonitoring: TRUE > olcDbDirectory: db.1.a > olcDbNoSync: FALSE > olcDbIndex: objectClass eq > olcDbIndex: entryUUID eq > olcDbIndex: entryCSN eq > olcDbIndex: cn pres,eq,sub > olcDbIndex: uid pres,eq,sub > olcDbIndex: sn pres,eq,sub > olcDbMaxReaders: 0 > olcDbMaxSize: 10485760 > olcDbMode: 0600 > olcDbSearchStack: 16 > olcDbMaxEntrySize: 0 > olcDbRtxnSize: 10000 > > > As you can see, olcDbNoSync has the value FALSE, because there was no "dbnosync" > option in slapd.conf, however, performance testing shows a dramatic increase in > write speed after slapd.d migration. Which seems odd to me. It seems like the > MDB database was not syncing to disk anymore despite olcDbNoSync being FALSE > > Removing olcDbNoSync: FALSE from cn=config did restore previous performance and > syncing behavior > > Looking at servers/slapd/back-mdb/config.c:723 I found this: > > case MDB_DBNOSYNC: > if ( c->value_int ) > mdb->mi_dbenv_flags |= MDB_NOSYNC; > else > mdb->mi_dbenv_flags ^= MDB_NOSYNC; > > > The else case seems wrong, I replaced it with > > case MDB_DBNOSYNC: > if ( c->value_int ) > mdb->mi_dbenv_flags |= MDB_NOSYNC; > else > mdb->mi_dbenv_flags &= ~MDB_NOSYNC; > > And it solves the issue on my system. > > Reproduced on master, and 2.4.48, on Debian > > -- -- 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

Re: (ITS#9147) syncrepl connexion leak when provider uses an expired certificate
by hyc＠symas.com 10 Jan '20

10 Jan '20

maxime.besson(a)worteks.com wrote: > Full_Name: Maxime Besson > Version: 2.4.48 > OS: Debian Buster / CentOS7 > URL: https://cloud.worteks.com/index.php/s/9CE6ALLaAfrxZW4/download > Submission from: (NULL) (92.184.104.113) Thanks for the report and testcase, fixed now in git master. > > > I have two OpenLDAP (2.4.48, Ubuntu) servers running with syncrepl in > mirrormode. > > One of my server's X509 certificates has recently expired, and I noticed that > while it was expired, the other node's connection count kept climbing until it > a "Max open files" condition. It seems that when a Syncrepl consumer encounters > a certificate error, the outgoing LDAP connection to the provider is never > closed. > > Attached to this bug you will find a test case to reproduce this behavior > > # runs a provider with a bogus certificate > # and a consumer with retry=3+ > sh test.sh > ... > TLS certificate verification: Error, self signed certificate > TLS trace: SSL3 alert write:fatal:unknown CA > TLS trace: SSL_connect:error in error > TLS: can't connect: error:1416F086:SSL > routines:tls_process_server_certificate:certificate verify failed (self signed > certificate). > 5e160966 slap_client_connect: URI=ldaps://127.0.1.1:6636/ > DN="cn=manager,dc=example,dc=com" ldap_sasl_bind_s failed (-1) > 5e160966 do_syncrepl: rid=001 rc -1 retrying > ... > and so on, every 3 seconds > > While the consumer retries, running lsof on its PID will reveal the connection > leak: > > 42u TCP localhost:45964->localhost.lan:6636 (CLOSE_WAIT) > 43u TCP localhost:45966->localhost.lan:6636 (CLOSE_WAIT) > 44u TCP localhost:45968->localhost.lan:6636 (CLOSE_WAIT) > 45u TCP localhost:45970->localhost.lan:6636 (CLOSE_WAIT) > 46u TCP localhost:45972->localhost.lan:6636 (CLOSE_WAIT) > 47u TCP localhost:45974->localhost.lan:6636 (CLOSE_WAIT) > 48u TCP localhost:45976->localhost.lan:6636 (CLOSE_WAIT) > 49u TCP localhost:45978->localhost.lan:6636 (CLOSE_WAIT) > 50u TCP localhost:45980->localhost.lan:6636 (CLOSE_WAIT) > 51u TCP localhost:45982->localhost.lan:6636 (CLOSE_WAIT) > 52u TCP localhost:45984->localhost.lan:6636 (CLOSE_WAIT) > 53u TCP localhost:45986->localhost.lan:6636 (CLOSE_WAIT) > 54u TCP localhost:45988->localhost.lan:6636 (CLOSE_WAIT) > 55u TCP localhost:45990->localhost.lan:6636 (CLOSE_WAIT) > 56u TCP localhost:45992->localhost.lan:6636 (CLOSE_WAIT) > 57u TCP localhost:45994->localhost.lan:6636 (CLOSE_WAIT) > 58u TCP localhost:45996->localhost.lan:6636 (CLOSE_WAIT) > 59u TCP localhost:45998->localhost.lan:6636 (CLOSE_WAIT) > 60u TCP localhost:46000->localhost.lan:6636 (CLOSE_WAIT) > 61u TCP localhost:46002->localhost.lan:6636 (CLOSE_WAIT) > 62u TCP localhost:46004->localhost.lan:6636 (CLOSE_WAIT) > 63u TCP localhost:46006->localhost.lan:6636 (CLOSE_WAIT) > 64u TCP localhost:46008->localhost.lan:6636 (CLOSE_WAIT) > > > Modifying the provider URL in slapd.2.conf with a wrong port causes the > syncrepl > consumer to fail and retry just as much, but without connection piling up in > CLOSE_WAIT state. > > This is not a very critical issue because it only affects servers who are in > already degraded condition (broken replication, invalid certificate on the > provider) but I thought it still was worth reporting. > > I was able to reproduce this issue on the git master branch, on released 2.4.48, > on Centos7 and on Debian Buster. > OpenSSL version on the debian system: 1.1.1d-0+deb10u2 > > -- -- 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

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