openldap-bugs

openldap-bugs@openldap.org

1 participants
20966 discussions

Re: (ITS#8495) slaped service unable to restart
by quanah＠zimbra.com 09 Sep '16

09 Sep '16

--On Friday, September 09, 2016 8:34 AM +0000 ritesh.s(a)litmusit.com wrote: > Full_Name: Ritesh Supatkar > Version: Openldap-2.4.40 > OS: Rhel 7.2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (103.14.160.193) This looks like an issue with systemd and Redhat. I advise contacting Redhat support. --Quanah -- Quanah Gibson-Mount

1 0

Re: (ITS#8496) Error while launching LDAP
by quanah＠zimbra.com 09 Sep '16

09 Sep '16

--On Friday, September 09, 2016 8:56 AM +0000 kshtijdasture(a)gmail.com wrote: > Full_Name: Kshitij Dasture > Version: 2.4.41 > OS: Windos > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (203.99.214.118) > > > I am starting the LAP by the below command.Below is the show stopper for > the execution of Start command. > > > -bash-4.3$ ./slapd -f slapd.conf -d 1 > ldap.log The ITS system is for reporting bugs, not usage questions. If you have questions on how to use OpenLDAP correctly, please use the openldap-technical list. This ITS will be closed. --Quanah -- Quanah Gibson-Mount

1 0

(ITS#8496) Error while launching LDAP
by kshtijdasture＠gmail.com 09 Sep '16

09 Sep '16

Full_Name: Kshitij Dasture Version: 2.4.41 OS: Windos URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (203.99.214.118) I am starting the LAP by the below command.Below is the show stopper for the execution of Start command. -bash-4.3$ ./slapd -f slapd.conf -d 1 > ldap.log . . . 57d25b6b backend_startup_one: starting "dc=gnf,dc=telekom,dc=m%m" 57d25b6b bdb_db_open: database "dc=gnf,dc=telekom,dc=com": database already in use. 57d25b6b backend_startup_one (type=bdb, suffix="dc=gnf,dc=telekom,dc=com"): bi_db_open failed! (-1) 57d25b6b slapd shutdown: initiated 57d25b6b ====> bdb_cache_release_all 57d25b6b slapd destroy: freeing system resources. 57d25b6b slapd stopped. -bash-4.3$

1 0

(ITS#8495) slaped service unable to restart
by ritesh.s＠litmusit.com 09 Sep '16

09 Sep '16

Full_Name: Ritesh Supatkar Version: Openldap-2.4.40 OS: Rhel 7.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (103.14.160.193) [bbpsadm@hydbbpsldp01 ~]$ sudo systemctl status slapd ● slapd.service - OpenLDAP Server Daemon Loaded: loaded (/usr/lib/systemd/system/slapd.service; enabled; vendor preset: disabled) Active: active (running) since Thu 20169-9-08 18:18:20 IST; 18h ago Docs: man:slapd man:slapd-config man:slapd-hdb man:slapd-mdb file:///usr/share/doc/openldap-servers/guide.html Process: 44574 ExecStart=/usr/sbin/slapd -u ldap -h ${SLAPD_URLS} $SLAPD_OPTIONS (code=exited, status=0/SUCCESS) Process: 44531 ExecStartPre=/usr/libexec/openldap/check-config.sh (code=exited, status=0/SUCCESS) Main PID: 44575 (slapd) CGroup: /system.slice/slapd.service └6%6#9472;44575 /usr/sbin/slapd -u ldap -h ldapi:/// ldap:/// Sep 09 12:34:45 hydbbpsldp01 slapd[44575]: <= bdb_equality_candidates: (uid) not indexed Sep 09 12:34:45 hydbbpsldp01 slapd[44575]: conn=1020 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Sep 09 12:34:45 hydbbpsl0101 slapd[47575]: conn=1020 op=2 SRCH base="dc=npci,dc=co,dc=in" scope=2 deref=0 filter="(&(memberUid=bbpsadm)(objectClass=posixGr...ber=0))))" Sep 09 12:34:45 hydbbpsldp01 slapd[44575]: conn=1020 op=2 SRCH attr=objectClass cn userPassword gidNumber modifyTimestamp modifyTimestamp Sep 09 12:34:45 hydbbpsldp01 slapd[44575]: <= bdb_equality_candidates: (memberUid) not indexed Sep 09 12:34:45 hydbbpsldp01 slapd[44575]: conn=1020 op=2 SEARCH RESULT tag=101 err=0 nentries=0 text= Sep 09 12:34:45 hydbbpsldp01 slapd[44575]: conn=1020 op=3 SRCH base="dc=npci,dc=co,dc=in" scope=2 deref=0 filter="(&(gidNumber=1001)(objectClass=posixGroup...ber=0))))" Sep 09 12:34:45 hydbbpsldp01 slapd[44575]: conn=1020 op=3 SRCH attr=objectClass cn userPassword gidNumber memberuid modifyTimestamp modifyTimestamp Sep 09 12:34:45 hydbbpsldp01 slapd[44575]: <= bdb_equality_candidates: (gidNumber) not indexed Sep 09 12:34:45 hydbbpsldp01 slapd[44575]: conn=1020 op=3 SEARCH RESULT tag=101 err=0 nentries=2 text= Hint: Some lines were ellipsized, use -l to show in full. [bbpsadm@hydbbpsldp01 ~]$ [bbpsadm@hydbbpsldp01 ~]$ sudo systemctl restart slapd Error getting authority: Error initializing authority: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: An SELinux policy prevents thisesender from sending this message to this recipient, 0 matched rules; type="method_call", sender="(null)" (inactive) interface="org.freedesktop.DBus" member="Hello" error name="(unset)" requested_reply="0" destination="org.freedesktop.DBus" (bus) (g-dbus-error-quark, 9) [bbpsadm@hydbbpsldp01 ~]$

1 0

(ITS#8494) doc: Rename 'TLSEphemeralDHParamFile' to 'TLSDHParamFile'
by georg＠riseup.net 08 Sep '16

08 Sep '16

Full_Name: Georg Faerber Version: 2.4 OS: Debian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (91.64.110.191) http://www.openldap.org/doc/admin24/tls.html mentions directive 'TLSEphemeralDHParamFile' whereas slapd.conf(5) mentions 'TLSDHParamFile'. (See [1] as well). [1] http://www.openldap.org/lists/openldap-technical/201309/msg00094.html

1 0

RE: (ITS#8374) LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS
by dog＠pavlov.com 07 Sep '16

07 Sep '16

Actually, ignore me this is still connecting when it should fail. Don't close. ;)

1 0

RE: (ITS#8374) LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS
by dog＠pavlov.com 07 Sep '16

07 Sep '16

This seems to have been resolved at some point in the past in one of the updates: now functions as expected. Fine to close from my perspective.

1 0

Re: (ITS#8493) Under heavy modrdn load, masters desync
by quanah＠zimbra.com 03 Sep '16

03 Sep '16

--On Saturday, September 03, 2016 4:51 PM +0000 quanah(a)zimbra.com wrote: > --On Saturday, September 03, 2016 6:15 AM +0000 quanah(a)openldap.org wrote: > >> Full_Name: Quanah Gibson-Mount >> Version: 2.4.44+ITS8432 >> OS: Linux 2.6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.111.52.177) >> >> >> Trying to reproduce another ITS, I discovered a new bug. When doing >> MODRDN ops on one master, the other master keeps going out of sync. >> Specifically: >> >> Sep 3 01:12:17 zre-ldap002 slapd[29206]: syncrepl_message_to_op: rid=100 >> be_modrdn uid=user.924,ou=people,dc=zre-ldap002,dc=eng,dc=zimbra,dc=com >> (32) Sep 3 01:12:17 zre-ldap002 slapd[29206]: do_syncrep2: rid=100 >> delta-sync lost sync on (reqStart=20160903051215.747829Z,cn=accesslog), >> switching to REFRESH > > > Note that this master also has a replica. The replica never rejected a > single one of these MODRDNs coming from this master. Which means that > either: > > a) The data on the master spontaneously corrupted at some point > > or > > b) The master wrote the MODRDNs to the accesslog, which the replica > picked up, but did not itself make the MODRDN changes to its database. > > In the end, of the 50,000 MODRDNs it was processing, it threw an error 32 > for 441 of them. After the master that was not accepting direct writes re-sync'd with the master accepting writes, it still had 403/50000 entries wrong. So did its replica. So the master isn't writing the changes to the accesslog. So it's option c. The master rejects a valid op, never sync's correctly, and in the end 2/3rds of my servers have invalid databases. I see zero indication that using a sessionlog works around <http://www.openldap.org/its/index.cgi/?findid=8125> at all. I still end up with missed entries even with everything *in* the sessionlog. --Quanah -- Quanah Gibson-Mount

1 0

Re: (ITS#8493) Under heavy modrdn load, masters desync
by quanah＠zimbra.com 03 Sep '16

03 Sep '16

--On Saturday, September 03, 2016 6:15 AM +0000 quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.44+ITS8432 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.52.177) > > > Trying to reproduce another ITS, I discovered a new bug. When doing > MODRDN ops on one master, the other master keeps going out of sync. > Specifically: > > Sep 3 01:12:17 zre-ldap002 slapd[29206]: syncrepl_message_to_op: rid=100 > be_modrdn uid=user.924,ou=people,dc=zre-ldap002,dc=eng,dc=zimbra,dc=com > (32) Sep 3 01:12:17 zre-ldap002 slapd[29206]: do_syncrep2: rid=100 > delta-sync lost sync on (reqStart=20160903051215.747829Z,cn=accesslog), > switching to REFRESH Note that this master also has a replica. The replica never rejected a single one of these MODRDNs coming from this master. Which means that either: a) The data on the master spontaneously corrupted at some point or b) The master wrote the MODRDNs to the accesslog, which the replica picked up, but did not itself make the MODRDN changes to its database. In the end, of the 50,000 MODRDNs it was processing, it threw an error 32 for 441 of them. --Quanah -- Quanah Gibson-Mount

1 0

Re: (ITS#8486) Syncprov sessionlog is inefficient, kills perf
by quanah＠zimbra.com 02 Sep '16

02 Sep '16

--On Monday, August 29, 2016 9:16 PM +0000 quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.44 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.52.177) In doing testing for ITS#8491, I encountered this problem in my lab. Any time a single replica is parsing the session log, all other operations on the server come to a complete halt. I.e., slapd does *nothing* other than handle the sessionlog query. This seems like a fatal problem. --Quanah -- Quanah Gibson-Mount

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