openldap-bugs

openldap-bugs@openldap.org

1 participants
20965 discussions

Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by Frank.Swasey＠uvm.edu 06 Apr '16

06 Apr '16

WWVzdGVyZGF5LCBJIGJ1aWx0IGFuZCB0ZXN0ZWQgMi40LjQ0LCAyLjQuNDMsIGFuZCAyLjQuNDIg d2l0aG91dCB0aGUgbm9ybWFsIG1vZGlmaWNhdGlvbnMgdGhhdCBJIG1ha2UgdG8gdGhlIGNvZGUg YmFzZS4gIA0KDQpJIGhhdmUgZm91bmQgdGhhdCBib3RoIDIuNC40NCBhbmQgMi40LjQzIGhhdmUg dGhpcyBmYWlsdXJlIHdpdGhpbiBhbiBob3VyIG9mIHN0YXJ0aW5nIHRoZSBwcmltYXJ5IHNlcnZl ciBhbmQgb25jZSBhbiBob3VyIGFmdGVyIGl0IGZpcnN0IGhhcHBlbnMuICBUaGUgMi40LjQyIGNv ZGUgaGFzIGJlZW4gcnVubmluZyBmb3Igb3ZlciBmaWZ0ZWVuIGhvdXJzIG5vdyBoYXMgbm90IGZh aWxlZCBhdCBhbGwuDQoNClRoZSBzY3JpcHQgSSB1c2VkIHRvIGJ1aWxkIHRoZXNlIGlzIGF2YWls YWJsZSBoZXJlOg0KDQpodHRwOi8vd3d3LnV2bS5lZHUvfmZjcy9vcGVubGRhcF9pdHMvYnVpbGQt b3BlbmxkYXAuc2gNCg0K4oCUDQpGcmFuayBTd2FzZXkNClN5c3RlbXMgQXJjaGl0ZWN0dXJlICYg QWRtaW5pc3RyYXRpb24NCg0K

1 0

Re: (ITS#8397) Unable to start LDAP Service in Windows
by hyc＠symas.com 06 Apr '16

06 Apr '16

charisse.ann.m.jorge(a)accenture.com wrote: > Full_Name: charisse.ann.m.jorge > Version: 2.3.7 > OS: Windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (170.248.16.158) > > > Hi > > we are experiencing the same issue as ITS#6106, the only difference is our LDAP > Version is 2.3.7. > > 1) Start the LDAP Service in Windows > 2) System will prompt error: > Windows could not start the Hyperion Foundation OpenLDAP on local computer. > For more information, review the system event log. If this is non-Microsoft > Service, contact the service vendor, and refer to service-specific error code > 16. > > 3) Go to Windows Event Viewer, System Log > Notice that there's an error log with description: > The Hyperion Foundation OpenLDAP Service terminated with service-specific > error 16 > > i tried running slapd.exe -d -1 > > E:\Hyperion\products\Foundation\openLDAP>slapd.exe -d -1 > @(#) $OpenLDAP: slapd 2.3.7 (Sep 28 2005 17:09:57) $ > @DILEEP:/c/opldap15/openldap-2.3.7/servers/slapd > daemon_init: ldap://$J(LOCALHOSTNAMESHORT):58089/ > daemon_init: listen on ldap://$J(LOCALHOSTNAMESHORT):58089/ > daemon_init: 1 listeners to open... > ldap_url_parse_ext(ldap://$J(LOCALHOSTNAMESHORT):58089/) > daemon: invalid host $J(LOCALHOSTNAMESHORT)slapd stopped. > connections_destroy: nothing to destroy. > > please advise. Do as the error message says and contact your service vendor. Apparently that's Hyperion Foundation. Not us. Closing this ITS. -- -- 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#8397) Unable to start LDAP Service in Windows
by charisse.ann.m.jorge＠accenture.com 06 Apr '16

06 Apr '16

Full_Name: charisse.ann.m.jorge Version: 2.3.7 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (170.248.16.158) Hi we are experiencing the same issue as ITS#6106, the only difference is our LDAP Version is 2.3.7. 1) Start the LDAP Service in Windows 2) System will prompt error: Windows could not start the Hyperion Foundation OpenLDAP on local computer. For more information, review the system event log. If this is non-Microsoft Service, contact the service vendor, and refer to service-specific error code 16. 3) Go to Windows Event Viewer, System Log Notice that there's an error log with description: The Hyperion Foundation OpenLDAP Service terminated with service-specific error 16 i tried running slapd.exe -d -1 E:\Hyperion\products\Foundation\openLDAP>slapd.exe -d -1 @(#) $OpenLDAP: slapd 2.3.7 (Sep 28 2005 17:09:57) $ @DILEEP:/c/opldap15/openldap-2.3.7/servers/slapd daemon_init: ldap://$J(LOCALHOSTNAMESHORT):58089/ daemon_init: listen on ldap://$J(LOCALHOSTNAMESHORT):58089/ daemon_init: 1 listeners to open... ldap_url_parse_ext(ldap://$J(LOCALHOSTNAMESHORT):58089/) daemon: invalid host $J(LOCALHOSTNAMESHORT)slapd stopped. connections_destroy: nothing to destroy. please advise.

1 0

Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by quanah＠zimbra.com 05 Apr '16

05 Apr '16

--On Tuesday, April 05, 2016 11:35 PM +0000 Frank.Swasey(a)uvm.edu wrote: It's ok, it is trivial to run through a mime decoder. So the regression was added in 2.4.43. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by Frank.Swasey＠uvm.edu 05 Apr '16

05 Apr '16

U2Vjb25kIGF0dGVtcHQgLSBzb21ldGhpbmcgYWJvdXQgbXkgZmlyc3QgYXR0ZW1wdCBzZWVtcyB0 byBoYXZlIHRyaXBwZWQgdGhlIHNwYW0gZmlsdGVyIGF0IGdhdXNzLg0KDQpUb2RheSwgSSBoYXZl IGJ1aWx0IGFuZCB0ZXN0ZWQgMi40LjQ0LCAyLjQuNDMsIGFuZCAyLjQuNDIgd2l0aG91dCB0aGUg bm9ybWFsIG1vZGlmaWNhdGlvbnMgdGhhdCBJIG1ha2UgdG8gdGhlIGNvZGUgYmFzZS4gIEkgaGF2 ZSBmb3VuZCB0aGF0IGJvdGggMi40LjQ0IGFuZCAyLjQuNDMgaGF2ZSB0aGlzIGZhaWx1cmUgd2l0 aGluIGFuIGhvdXIgb2Ygc3RhcnRpbmcgdGhlIHByaW1hcnkgc2VydmVyIGFuZCBvbmNlIGFuIGhv dXIgYWZ0ZXIgaXQgZmlyc3QgaGFwcGVucy4gIFRoZSAyLjQuNDIgY29kZSBoYXMgYmVlbiBydW5u aW5nIGZvciBvdmVyIHR3byBob3VycyBub3cgKGFuZCBqdXN0IGFzIGluIG15IHByb2R1Y3Rpb24g ZW52aXJvbm1lbnQpIGhhcyBub3QgZmFpbGVkIGF0IGFsbC4NCg0KVGhlIG9wdGlvbnMgSSBhbSB1 c2luZyB3aXRoIGNvbmZpZ3VyZSBhcmU6DQoNCmV4cG9ydCBDRkxBR1M9Ii1ETkRFQlVHIC1EX1JF RU5UUkFOVCAtZlBJQyINCmV4cG9ydCBMSUJTPSItbHB0aHJlYWQiDQouL2NvbmZpZ3VyZSBcDQog ICAgICAgIC1xIFwNCiAgICAgICAgLS1lbmFibGUtZHluYW1pYyBcDQogICAgICAgIC0tZW5hYmxl LXN0YXRpYyBcDQogICAgICAgIC0td2l0aC10aHJlYWRzPXBvc2l4IFwNCiAgICAgICAgLS13aXRo LXRscz1vcGVuc3NsIFwNCiAgICAgICAgLS13aXRoLWN5cnVzLXNhc2wgXA0KICAgICAgICAtLWVu YWJsZS13cmFwcGVycyBcDQogICAgICAgIC0tZW5hYmxlLXBhc3N3ZCBcDQogICAgICAgIC0tZW5h YmxlLWNsZWFydGV4dCBcDQogICAgICAgIC0tZW5hYmxlLWNyeXB0IFwNCiAgICAgICAgLS1lbmFi bGUtc3Bhc3N3ZCBcDQogICAgICAgIC0tZW5hYmxlLWxtcGFzc3dkIFwNCiAgICAgICAgLS1lbmFi bGUtbW9kdWxlcyBcDQogICAgICAgIC0tZW5hYmxlLWlwdjYgXA0KICAgICAgICBcDQogICAgICAg IC0tZW5hYmxlLXNsYXBkIFwNCiAgICAgICAgLS1lbmFibGUtYmFja2VuZHM9bW9kIFwNCiAgICAg ICAgLS1kaXNhYmxlLW5kYiBcDQogICAgICAgIC0tZGlzYWJsZS1zcWwgXA0KICAgICAgICAtLWRp c2FibGUtcGVybCBcDQogICAgICAgIC0tZGlzYWJsZS1zaGVsbCBcDQogICAgICAgIC0tZW5hYmxl LW92ZXJsYXlzPW1vZA0KDQoNCuKAlA0KRnJhbmsgU3dhc2V5DQpTeXN0ZW1zIEFyY2hpdGVjdHVy ZSAmIEFkbWluaXN0cmF0aW9uDQo=

1 0

Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by Frank.Swasey＠uvm.edu 05 Apr '16

05 Apr '16

VG9kYXksIEkgaGF2ZSBidWlsdCBhbmQgdGVzdGVkIDIuNC40NCwgMi40LjQzLCBhbmQgMi40LjQy IHdpdGhvdXQgdGhlIG5vcm1hbCBtb2RpZmljYXRpb25zIHRoYXQgSSBtYWtlIHRvIHRoZSBjb2Rl IGJhc2UuICBJIGhhdmUgZm91bmQgdGhhdCBib3RoIDIuNC40NCBhbmQgMi40LjQzIGhhdmUgdGhp cyBmYWlsdXJlIHdpdGhpbiBhbiBob3VyIG9mIHN0YXJ0aW5nIHRoZSBwcmltYXJ5IHNlcnZlciBh bmQgb25jZSBhbiBob3VyIGFmdGVyIGl0IGZpcnN0IGhhcHBlbnMuICBUaGUgMi40LjQyIGNvZGUg aGFzIGJlZW4gcnVubmluZyBmb3Igb3ZlciB0d28gaG91cnMgbm93IChhbmQganVzdCBhcyBpbiBt eSBwcm9kdWN0aW9uIGVudmlyb25tZW50KSBoYXMgbm90IGZhaWxlZCBhdCBhbGwuDQoNClRoZSBv cHRpb25zIEkgYW0gdXNpbmcgd2l0aCBjb25maWd1cmUgYXJlOg0KDQpleHBvcnQgQ0ZMQUdTPSIt RE5ERUJVRyAtRF9SRUVOVFJBTlQgLWZQSUMiDQpleHBvcnQgTElCUz0iLWxwdGhyZWFkIg0KLi9j b25maWd1cmUgXA0KICAgICAgICAtcSBcDQogICAgICAgIC0tZW5hYmxlLWR5bmFtaWMgXA0KICAg ICAgICAtLWVuYWJsZS1zdGF0aWMgXA0KICAgICAgICAtLXdpdGgtdGhyZWFkcz1wb3NpeCBcDQog ICAgICAgIC0td2l0aC10bHM9b3BlbnNzbCBcDQogICAgICAgIC0td2l0aC1jeXJ1cy1zYXNsIFwN CiAgICAgICAgLS1lbmFibGUtd3JhcHBlcnMgXA0KICAgICAgICAtLWVuYWJsZS1wYXNzd2QgXA0K ICAgICAgICAtLWVuYWJsZS1jbGVhcnRleHQgXA0KICAgICAgICAtLWVuYWJsZS1jcnlwdCBcDQog ICAgICAgIC0tZW5hYmxlLXNwYXNzd2QgXA0KICAgICAgICAtLWVuYWJsZS1sbXBhc3N3ZCBcDQog ICAgICAgIC0tZW5hYmxlLW1vZHVsZXMgXA0KICAgICAgICAtLWVuYWJsZS1pcHY2IFwNCiAgICAg ICAgXA0KICAgICAgICAtLWVuYWJsZS1zbGFwZCBcDQogICAgICAgIC0tZW5hYmxlLWJhY2tlbmRz PW1vZCBcDQogICAgICAgIC0tZGlzYWJsZS1uZGIgXA0KICAgICAgICAtLWRpc2FibGUtc3FsIFwN CiAgICAgICAgLS1kaXNhYmxlLXBlcmwgXA0KICAgICAgICAtLWRpc2FibGUtc2hlbGwgXA0KICAg ICAgICAtLWVuYWJsZS1vdmVybGF5cz1tb2QNCg0KDQrigJQNCkZyYW5rIFN3YXNleQ0KU3lzdGVt cyBBcmNoaXRlY3R1cmUgJiBBZG1pbmlzdHJhdGlvbg0KDQoNCg0KDQoNCg==

1 0

Re: (ITS#8395) DH Params code causes startTLS failure while slapd initializes the code
by quanah＠zimbra.com 04 Apr '16

04 Apr '16

--On Sunday, April 03, 2016 3:34 AM +0000 quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: RE24 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.52.177) Closing this ITS, it was related to a bug in the code in our side that sets the DH Param bits for slapd, that has a race condition, where the file may be 0 sized initially. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

(ITS#8396) syncprov hourly fails to answer syncrepl
by Frank.Swasey＠uvm.edu 04 Apr '16

04 Apr '16

Full_Name: Francis Swasey Version: 2.4.44 OS: Red Hat Enterprise Linux Server release 7.2 (Maipo) URL: http://www.uvm.edu/~fcs/openldap_its/syncprov_files.tar.gz Submission from: (NULL) (132.198.104.198) Once an hour, the primary server logs a syncprov_sendresp that does not include a csn. When that happens, the replica misses that there were changes and does not update and therefore falls behind. The URI provides files for the primary and replica. replica/slapd_db.ldif -- starting database replica/slapd.conf -- replica's slapd configuration file (you'll need to create your own ssl certs) replica/syncrepl_audit.sh -- Runs on the replica (edit the email address and the path to check_syncrepl replica/check_syncrepl -- Used by nagios to report csn being in sync or not primary/slapd_db.ldif -- starting database (almost exactly like the replica's version) primary/slapd.conf -- primary's slapd configuration file (you'll need to create your own ssl certs) primary/syncprov_audit.sh -- greps the system log (edit the path) looking for the syncprov error primary/makechanges.sh -- edit to change the name of the ldap server and run this to make constant changes The bad log entries that coincide with check_syncrepl finding the replica has fallen behind are like: Apr 4 13:18:27 ldap7p slapd[27800]: syncprov_sendresp: cookie=rid=100 Apr 4 13:18:27 ldap7p slapd[27800]: syncprov_sendresp: cookie=rid=100 Apr 4 14:18:53 ldap7p slapd[27800]: syncprov_sendresp: cookie=rid=100 Apr 4 14:18:53 ldap7p slapd[27800]: syncprov_sendresp: cookie=rid=100 They appear once an hour.

1 0

Re: (ITS#8394) LMDB fails GCC5 without -fno-strict-aliasing
by bdallen＠nps.edu 04 Apr '16

04 Apr '16

My initial report was garbled. What I mean is that a protection violation occurs in mdb.c when I add a 13'th item to a multiset and I compile with one of the mentioned compilers and with -fPIC -O3. The code works fine when compiled with older GCC compilers or with -O0 or with -fno-strict-aliasing. Given what I read at https://gcc.gnu.org/bugs/ under section "Casting does not work as expected when optimization is turned on", I suspect the problem is simply that a pointer variable is not following the ISO C aliasing rules and breaks with the new, more aggressive compiler optimization. Here is the part that fails: for (i=0; i<NUMKEYS(fp); i++) mp->mp_ptrs[i] = fp->mp_ptrs[i] + offset; If this turns out to not be straightforward, I can try building a small test program to reproduce the problem. On 04/03/2016 09:44 AM, Howard Chu wrote: > bdallen(a)nps.edu wrote: >> Full_Name: Bruce Allen >> Version: 2.4.44 >> OS: Fedora 23 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (205.155.65.226) >> >> >> LMDB v0.9.18 crashes with segmentation fault in mdb.c line 6590 when >> compiled >> using these compilers: >> * gcc (GCC) 5.3.1 20151207 (Red Hat 5.3.1-2) >> * x86_64-w64-mingw32-gcc (GCC) 5.2.0 20150716 (Fedora MinGW >> 5.2.0-1.fc23) >> >> The crash happens afterrititing the 12'th item (with the same key but >> different >> value using flags MDB_NODUPDATA and MDB_DUPSORT). > > Your message appears garbled here. Please send a test case with steps > to reproduce. >> >> The problem goes away when compiling mdb.c with the >> -fno-strict-aliasing flag. >> >> > >

1 0

Re: (ITS#8394) LMDB fails GCC5 without -fno-strict-aliasing
by hyc＠symas.com 03 Apr '16

03 Apr '16

bdallen(a)nps.edu wrote: > Full_Name: Bruce Allen > Version: 2.4.44 > OS: Fedora 23 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (205.155.65.226) > > > LMDB v0.9.18 crashes with segmentation fault in mdb.c line 6590 when compiled > using these compilers: > * gcc (GCC) 5.3.1 20151207 (Red Hat 5.3.1-2) > * x86_64-w64-mingw32-gcc (GCC) 5.2.0 20150716 (Fedora MinGW 5.2.0-1.fc23) > > The crash happens afterrititing the 12'th item (with the same key but different > value using flags MDB_NODUPDATA and MDB_DUPSORT). Your message appears garbled here. Please send a test case with steps to reproduce. > > The problem goes away when compiling mdb.c with the -fno-strict-aliasing flag. > > -- -- 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