openldap-technical

openldap-technical@openldap.org

9897 discussions

Re: 2.4.45 slapadd segfault
by Howard Chu 31 Aug '17

31 Aug '17

Christopher Wood wrote: > Good morning, long time no list. > > For backstory, I downloaded the 2.4.45 source tarball from https://www.openldap.org/software/download/, compiled, ran "make test" (which was fine as near as I can tell), but doing a slapadd of cn=config caused a segfault. > > I used the points on http://www.openldap.org/faq/data/cache/59.html to create the following backtrace: > > https://gist.github.com/christopherwood/701fbc70ef352a3bf2d2893a9ae0a65e > > And this is the ldif (temporary password is fakepass333): > > https://gist.github.com/christopherwood/2cf46f5a3384f9edc89e7eabbefc465e > > Does anything jump out at you as obviously wrong or a good place to look? I've chopped the ldif down from the original with confidential data and am still reducing, but it's still segfaulting. Yes. Look at your LDIF line 62 more carefully. Compare it to line 65 if it's still not obvious to you. Granted it shouldn't SEGV but the backtrace shows it was shutting itself down already because it (correctly) rejected your input. -- -- 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

2.4.45 slapadd segfault
by Christopher Wood 31 Aug '17

31 Aug '17

Good morning, long time no list. For backstory, I downloaded the 2.4.45 source tarball from https://www.openldap.org/software/download/, compiled, ran "make test" (which was fine as near as I can tell), but doing a slapadd of cn=config caused a segfault. I used the points on http://www.openldap.org/faq/data/cache/59.html to create the following backtrace: https://gist.github.com/christopherwood/701fbc70ef352a3bf2d2893a9ae0a65e And this is the ldif (temporary password is fakepass333): https://gist.github.com/christopherwood/2cf46f5a3384f9edc89e7eabbefc465e Does anything jump out at you as obviously wrong or a good place to look? I've chopped the ldif down from the original with confidential data and am still reducing, but it's still segfaulting. More details: OpenLDAP 2.4.45 Release (2017/06/01) [root@poc209 ~]# uname -a Linux poc209 3.10.0-514.26.2.el7.x86_64 #1 SMP Tue Jul 4 15:04:05 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux [root@poc209 ~]# cat /etc/redhat-release CentOS Linux release 7.3.1611 (Core) / and /var are ext4. Configure was like this, albeit on one line: ./configure --enable-debug --enable-dynamic --enable-syslog --enable-proctitle --enable-ipv6 --enable-local --enable-slapd --enable-dynacl --enable-aci --enable-cleartext --enable-crypt --enable-lmpasswd --enable-spasswd --enable-modules --enable-rewrite --enable-rlookups --enable-slapi --disable-slp --enable-wrappers --enable-backends=mod --enable-bdb=yes --enable-hdb=yes --enable-mdb=yes --enable-monitor=yes --disable-ndb --enable-overlays=mod --disable-static --enable-shared --with-cyrus-sasl --without-fetch --with-threads --with-pic --with-tls=openssl --with-gnu-ld --prefix=/opt/openldap

1 0

Re: syncrepl error (53) with 3-way delta-mmr (consumer state is newer than provider)
by Quanah Gibson-Mount 31 Aug '17

31 Aug '17

--On Wednesday, August 30, 2017 3:51 PM +0200 Sven Mäder <maeder(a)phys.ethz.ch> wrote: > SEARCH RESULT tag=101 err=53 nentries=0 text=consumer state is > newer than provider! This would generally indicate that the accesslog DB was empty at startup, and it generated a new CSN. This is a general problem with delta-syncrepl -- If the accesslog DB goes empty, there are a host of issues that can ensue (See ITS#8100 for example). Generally you need a script that writes a change on all masters in your cluster on a regular interval so that the DB is never purged, and there is always an active contextCSN value that's stored in the DB for each serverID. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Removing Berkeley DB Log Files
by Douglas Duckworth 30 Aug '17

30 Aug '17

Thanks for the reply, Howard. Thanks for pointing me in the right direction. From what I have read there are two options. 1) Copy /usr/share/openldap-servers/DB_CONFIG.example to /var/lib/domain then rebuild the database. 2) Enable checkpointing in slapd.conf Does enabling checkpointing in slapd.conf require rebuilding the database or can I simply restart slapd.conf? We are not using online configuration. Best Doug Thanks, Douglas Duckworth, MSc, LFCS HPC System Administrator Scientific Computing Unit Physiology and Biophysics Weill Cornell Medicine E: doug(a)med.cornell.edu O: 212-746-6305 F: 212-746-8690 On Fri, Aug 25, 2017 at 8:55 AM, Howard Chu <hyc(a)symas.com> wrote: > Douglas Duckworth wrote: > > Hi > > > > I am running openldap-servers-2.4.40-16.el6.x86_64 cluster on Centos > 6.9. My > > /var/lib/ldap directory contains many 10MB log files. /var partition > rather > > small... > > > > I've read they can be removed either by running "sudo db_archive -d -h > > /var/lib/ldap/domain" or by defining "DB_LOG_AUTOREMOVE" within the file > > "DB_CONFIG." That file does not presently exist whereas the db_archive > > command does not actually remove any of the log files. > > If the db_archive command doesn't remove anything, that means it thinks > all of > the log files are still in active use. > > Read the docs more carefully. > https://urldefense.proofpoint.com/v2/url?u=http-3A__docs. > oracle.com_cd_E17076-5F05_html_programmer-5Freference_ > transapp-5Flogfile.html&d=DwICaQ&c=lb62iw4YL4RFalcE2hQUQealT9- > RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e-CbhH6xUjnRkaqPFUS2wTJ2cw&m= > WP95x8mwSiEHHqUWRqJv6WdpfcTtJDAUAKN756yEEDA&s= > Kfi27b4v7vABZjPQYMkeo4xBqUyDGZeyB8pHAFin8xY&e= > > > > > Can I remove the old log files manually using rm? > > Not if the above is true, you will corrupt the logs and the DB will fail to > open on a subsequent restart. > > > If not should I create > > /var/lib/ldap/DB_CONFIG then restart slapd to make this removal > automatic? > > > Do you have any idea why db_archive does not work or produce any helpful > error > > to stdout? > > There's no error message because there's no error, everything is working as > designed. > > You need to do periodic checkpoints to allow log files to be closed, and > then > db_archive will be able to remove some of them. > > -- > -- Howard Chu > CTO, Symas Corp. https://urldefense.proofpoint. > com/v2/url?u=http-3A__www.symas.com&d=DwICaQ&c=lb62iw4YL4RFalcE2hQUQealT9- > RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e-CbhH6xUjnRkaqPFUS2wTJ2cw&m= > WP95x8mwSiEHHqUWRqJv6WdpfcTtJDAUAKN756yEEDA&s=IT7tNF72SCugdO8WpRd- > oNsk4nPNpdjE2aUFL4R4X_M&e= > Director, Highland Sun https://urldefense.proofpoint. > com/v2/url?u=http-3A__highlandsun.com_hyc_&d=DwICaQ& > c=lb62iw4YL4RFalcE2hQUQealT9-RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e- > CbhH6xUjnRkaqPFUS2wTJ2cw&m=WP95x8mwSiEHHqUWRqJv6WdpfcTtJDAUAKN756yEEDA&s= > XqfYCnjG9ibPbeW05QZOlWdl9u0ZH-7IXkxx0gh238k&e= > Chief Architect, OpenLDAP https://urldefense.proofpoint. > com/v2/url?u=http-3A__www.openldap.org_project_&d=DwICaQ&c= > lb62iw4YL4RFalcE2hQUQealT9-RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e- > CbhH6xUjnRkaqPFUS2wTJ2cw&m=WP95x8mwSiEHHqUWRqJv6WdpfcTtJDAUAKN756yEEDA&s=- > tGdeTJRpeaRbljBBUq49XgfNWzVElqiGEgv0LeqspU&e= >

2 5

Re: Removing Berkeley DB Log Files
by Quanah Gibson-Mount 30 Aug '17

30 Aug '17

--On Wednesday, August 30, 2017 1:03 PM -0400 Douglas Duckworth <dod2014(a)med.cornell.edu> wrote: > > Yeah, that worked. You might find <https://wiki.zimbra.com/wiki/OpenLDAP_Performance_Tuning_5.0#Configuring_th…> useful as well as a guideline on how to tune BDB. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: pwdfailuretime with multi-sync
by Quanah Gibson-Mount 30 Aug '17

30 Aug '17

--On Wednesday, August 30, 2017 2:49 PM +0800 Chris Leung <chris(a)q-station.net> wrote: > Sometime, the user password is replicated without problem after switched > to REFRESH, however, sometime password can't be sync. Error 16 means "no such attribute exists". My guess would be you have ACLs that block your replica from replicating userPassword. I'd also guess that you originally loaded the replica via a slapcat of the other master, so some accounts have passwords, and others don't. This is all guesswork of course, but it would match the behavior you're seeing. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

pwdfailuretime with multi-sync
by Chris Leung 29 Aug '17

29 Aug '17

Dear all, I have 2 openldap (2.4.42+dfsg-2ubuntu3.2) bundled with Ubuntu 16 LTS running multi-master mode. The data could be replicated to each other without problem, excpect when updating user password thru admin user. If user entry with pwdFailureTime, then the sync will be fail to REFRESH mode e.g, logged: Aug 29 10:35:41 openldap2 slapd[5277]: do_syncrep2: rid=001 cookie=rid=001,sid=001,csn=20170829023541.693544Z#000000#001#000000 Aug 29 10:35:41 openldap2 slapd[5277]: slap_queue_csn: queueing 0x7f849c1049ce 20170829023541.693544Z#000000#001#000000 Aug 29 10:35:41 openldap2 slapd[5277]: null_callback : error code 0x10 Aug 29 10:35:41 openldap2 slapd[5277]: slap_graduate_commit_csn: removing 0x7f849c104b80 20170829023541.693544Z#000000#001#000000 Aug 29 10:35:41 openldap2 slapd[5277]: syncrepl_message_to_op: rid=001 be_modify uid=xxxxxx.... (16) Aug 29 10:35:41 openldap2 slapd[5277]: do_syncrep2: rid=001 delta-sync lost sync on (reqStart=20170829023541.000002Z,cn=xxxxxx), switching to REFRESH Sometime, the user password is replicated without problem after switched to REFRESH, however, sometime password can't be sync. When I google the problem, it seem the incidence is report as http://www.openldap.org/lists/openldap-technical/201304/msg00195.html I would like to know any advise on the issue? Thanks. Chris

1 0

Re: Antw: Re: RedHat dropping OpenLDAP server support
by Quanah Gibson-Mount 29 Aug '17

29 Aug '17

--On Tuesday, August 29, 2017 9:54 AM +0200 Ulrich Windl <Ulrich.Windl(a)rz.uni-regensburg.de> wrote: > Hi! > > I don't know what Redhat is thinking, but obviously too many users had > problems with OpenLDAP, so they dropped support of it ;-) BTW: Redhat > also dropped support for BtrFS by not including it any longer (is what I > read)... There is a good article somewhere discussing why RH is dropping BtrFS. As for RedHat, I would hazard two reasons: Money and control For the first, RHDS requires a subscription, so having people move to it brings RedHat more money. For the second, RedHat clearly has control of the RHDS & 389 projects, and doesn't have to deal with other developers who may not be fond of their proposed changes, such as the debacle of the MozNSS support for OpenLDAP that caused numerous issues. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: delta syncrepl errors
by Quanah Gibson-Mount 29 Aug '17

29 Aug '17

--On Tuesday, August 22, 2017 12:36 PM +0200 Gerard Ranke <gerard.ranke(a)hku.nl> wrote: > 2017-08-18T14:54:39.153660+02:00 del slapd[25530]: do_syncrep2: rid=001 > got search entry without Sync State control > (reqStart=20170815125023.000001Z,cn=accesslog) You appear to be missing the syncprov overlay from the accesslog DB. I would suggest revisting the configuration on your master. Both the primary database and the accesslog database require having syncprov present, with different options set. It should be something along the lines of: dn: olcOverlay=syncprov,olcDatabase={2}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov olcSpNoPresent: TRUE olcSpReloadHint: TRUE as can be found in test063 --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: RedHat dropping OpenLDAP server support
by Howard Chu 28 Aug '17

28 Aug '17

Robert Heller wrote: > At Mon, 28 Aug 2017 11:44:27 -0700 Quanah Gibson-Mount <quanah(a)symas.com> wrote: > >> >> Hello All, >> >> As noted in the RHEL7.4 release notes >> (<https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/ht…>), >> RedHat will no longer support OpenLDAP Server starting with RHEL8. > > Will RedHat be supporting an alternitive Lightweight Directory Access Protocol > server? Or is RedHat dropping all sopport for Lightweight Directory Access > Protocol servers? RedHat is supporting their commercial server, RedHat Directory Server. It's the commercial version of 389DS, derived from the old Netscape LDAP server. Worth noting that that lineage of code has been abandoned by everyone else (e.g. Sun/Oracle DSEE has also been EOL'd). > >> >> This is likely a good time to start planning your migration plans if you >> currently rely on RedHat's build of OpenLDAP. I would note that Symas >> provides certified builds for OpenLDAP with various support options >> available. An alternative for those who do not require support and do not >> wish to build OpenLDAP themselves would be to use the LTB project builds. >> >> Regards, >> Quanah >> >> -- >> >> Quanah Gibson-Mount >> Product Architect >> Symas Corporation >> Packaged, certified, and supported LDAP solutions powered by OpenLDAP: >> <http://www.symas.com> >> >> >> > -- -- 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical