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
--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>
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=
>
--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>
--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>
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
--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>
--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>
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/
They want you to buy their identity management server which is based upon
389 directory server. Or you could go with freeipa
https://www.freeipa.org/page/Main_Page
Will this change also affect centos?
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 Mon, Aug 28, 2017 at 4:19 PM, Robert Heller <heller(a)deepsoft.com> 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://urldefense.proofpoint.com/v2/url?u=https-
> 3A__access.redhat.com_documentation_en-2DUS_Red-
> 5FHat-5FEnterprise-5FLinux_7_html_7.4-5FRelease-5FNotes_
> chap-2DRed-5FHat-5FEnterprise-5FLinux-2D7.4-5FRelease-
> 5FNotes-2DDeprecated-5FFunctionality.html-23idp12778832&d=DwIBAg&c=
> lb62iw4YL4RFalcE2hQUQealT9-RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e-
> CbhH6xUjnRkaqPFUS2wTJ2cw&m=-nX2P-9jJkqd2VhDD2sJ3alWs9cDEp6jpNb6
> lhNQAiY&s=rcOr9W4Z0-adDX11ERL8Oq5r0dEwVwaS9V-qnhKeslA&e=>),
> > 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?
>
> >
> > 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:
> > <https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__www.symas.com&d=DwIBAg&c=lb62iw4YL4RFalcE2hQUQealT9-
> RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e-CbhH6xUjnRkaqPFUS2wTJ2cw&m=-nX2P-
> 9jJkqd2VhDD2sJ3alWs9cDEp6jpNb6lhNQAiY&s=oU0KzuQoUpgOc_GP-
> Td3CN9qNf1XHk2_Z2zUALSywxg&e=>
> >
> >
> >
>
> --
> Robert Heller -- 978-544-6933
> Deepwoods Software -- Custom Software Services
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.
> deepsoft.com_&d=DwIBAg&c=lb62iw4YL4RFalcE2hQUQealT9-
> RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e-CbhH6xUjnRkaqPFUS2wTJ2cw&m=-nX2P-
> 9jJkqd2VhDD2sJ3alWs9cDEp6jpNb6lhNQAiY&s=s5sTP_
> 3py5Bv17Mc1dePXqoepTBDYF9TXZuokHV3Thw&e= -- Linux Administration Services
> heller(a)deepsoft.com -- Webhosting Services
>
>
>