Re: (ITS#8495) slaped service unable to restart
by quanah＠zimbra.com
--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
6 years, 6 months
Re: (ITS#8496) Error while launching LDAP
by quanah＠zimbra.com
--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
6 years, 6 months
(ITS#8496) Error while launching LDAP
by kshtijdasture＠gmail.com
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$
6 years, 6 months
(ITS#8495) slaped service unable to restart
by ritesh.s＠litmusit.com
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 ~]$
6 years, 6 months
Re: (ITS#8493) Under heavy modrdn load, masters desync
by quanah＠zimbra.com
--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
6 years, 6 months
Re: (ITS#8493) Under heavy modrdn load, masters desync
by quanah＠zimbra.com
--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
6 years, 6 months
Re: (ITS#8486) Syncprov sessionlog is inefficient, kills perf
by quanah＠zimbra.com
--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
6 years, 6 months
