openldap-bugs April 2015

openldap-bugs@openldap.org

29 participants
104 discussions

Re: (ITS#7145) cn=Connection 0
by michael＠stroeder.com 10 Apr '15

10 Apr '15

hguo(a)suse.com wrote: > The patch is a proposed resolution to the issue. > > To prevent monitor backend from returning invalid result about > Connection 0, it will simply not report information about the connection 0. Indeed I do understand what your patch does. But what is the real problem with Connection 0 you're trying to solve? Note that slapd internally access the database(s). So your monitoring checks should simply ignore this Connection 0. Ciao, Michael.

1 0

Re: (ITS#7145) cn=Connection 0
by hguo＠suse.com 10 Apr '15

10 Apr '15

The patch is a proposed resolution to the issue. To prevent monitor backend from returning invalid result about Connection 0, it will simply not report information about the connection 0. Kind regards, Howard On 10/04/15 11:41, Michael Ströder wrote: > hguo(a)suse.com wrote: >> I created a patch against the latest source code and uploaded the patch >> "howard-guo-2015-04-10.patch" onto the FTP server. With the patch, >> monitor backend no longer returns connection ID 0 to the LDAP client. > > I'm curious: Which problem do you want to solve? > > Ciao, Michael. >

1 0

Re: (ITS#7145) cn=Connection 0
by michael＠stroeder.com 10 Apr '15

10 Apr '15

hguo(a)suse.com wrote: > I created a patch against the latest source code and uploaded the patch > "howard-guo-2015-04-10.patch" onto the FTP server. With the patch, > monitor backend no longer returns connection ID 0 to the LDAP client. I'm curious: Which problem do you want to solve? Ciao, Michael.

1 0

Re: (ITS#7145) cn=Connection 0
by hguo＠suse.com 10 Apr '15

10 Apr '15

Good day! The appearance of connections with ID 0 in the Monitor backend seems entirely cosmetic and does not affect the normal operation of OpenLDAP server. I created a patch against the latest source code and uploaded the patch "howard-guo-2015-04-10.patch" onto the FTP server. With the patch, monitor backend no longer returns connection ID 0 to the LDAP client. Please review - many thanks. Kind regards, Howard Guo SUSE LINUX Products GmbH

1 0

(ITS#8101) facsimileTelephoneNumber
by bernhard.pfeiffer＠brz.gv.at 09 Apr '15

09 Apr '15

Full_Name: Bernhard Pfeiffer Version: 2.4.40 OS: SUSE Linux 11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (85.158.227.32) Hey! There is a problem in core-Schema with facsimileTelephoneNumber and jpegPhoto. It is not possible to modify these attributes, for example: version: 1 dn: uid=testsimon,ou=people,ou=test,dc=gv,dc=at changetype: modify delete: facsimileTelephoneNumber facsimileTelephoneNumber: +43 123 234 34234123 ldap_modify: Inappropriate matching (18) additional info: modify/delete: facsimileTelephoneNumber: no equality matching rule It is only possible, to delete it completly or replace it. Is there any Bugfix in plan?

1 0

(ITS#8100) Empty accesslog causes issues with delta-syncrepl MMR configurations
by quanah＠openldap.org 08 Apr '15

08 Apr '15

Full_Name: Quanah Gibson-Mount Version: 2.4.39 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (50.25.188.166) When one has an MMR setup using delta-syncrepl, and the masters get into a situation where one is out of sync, or adding a new MMR node to an existing cluster, things will be broken until the new/reloaded node has a write op that goes to the accesslog DB. In an existing cluster, where a node is being reloaded, it causes all nodes to go into an endless looping fallback sync until that write occurs.

1 0

Re: (ITS#8099) Documentation bug with 'tls_cipher(_)suite' option
by quanah＠zimbra.com 08 Apr '15

08 Apr '15

--On Wednesday, April 08, 2015 11:52 AM +0000 matt(a)bodgit-n-scarper.com wrote: > Full_Name: Matt Dainty > Version: 2.4.40 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (173.38.209.6) > > > Documentation makes reference to `tls_ciphersuite=` option for > olcSyncrepl/syncrepl settings however I got an error when trying to use > it. Thanks for the report, this is now fixed in openldap.master/RE25/RE24. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8057) slapo-unique can be bypassed by anyone
by ondra＠mistotebe.net 08 Apr '15

08 Apr '15

A fix for that is at ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20150408-ITS-8057-uniqueness-… The above patch is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the above patches were developed by Ondrej Kuznik <ondra(a)mistotebe.net>. I have not assigned rights and/or interest in this work to any party. I, Ondrej Kuznik, hereby place the above modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice

1 0

(ITS#8099) Documentation bug with 'tls_cipher(_)suite' option
by matt＠bodgit-n-scarper.com 08 Apr '15

08 Apr '15

Full_Name: Matt Dainty Version: 2.4.40 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (173.38.209.6) Documentation makes reference to `tls_ciphersuite=` option for olcSyncrepl/syncrepl settings however I got an error when trying to use it. On a hunch, I tried using `tls_cipher_suite=` instead matching the style of the equivalent ldap.conf setting and this worked. Confirmed what the code was doing here: http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=servers/sl… slapd-config(5), slapd.conf(5) are affected as well as the admin guide, potentially slapd-meta(5) and slapd-ldap(5) too if those backends reuse the same config code.

1 0

Re: (ITS#8098) Memory leakage
by quanah＠zimbra.com 07 Apr '15

07 Apr '15

--On Tuesday, April 07, 2015 11:12 AM +0000 rolandsytt(a)yahoo.com wrote: > Full_Name: Roland S.tt > Version: 2.4.40 > OS: CentOS Linux release 7.0.1406 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.126.102.178) > > > Slapd memory usage increases endlessly. It's same in 2.4.39 (from CentOS 7 > repository). During some simple activity (e.g ldapsearch) memory usage > increases, but it's not decreases after the activity end. You're likely seeing the numerous issues known to occur when using glibc as the default allocator. OpenLDAP is routinely profiled for memory leaks, and there are none currently known to exist. It is always strongly advised to use a different memory allocator with OpenLDAP, such as tcmalloc. For example, I wrap slapd with: quanah@zre-ldap001:~/p4/zimbra/main/ThirdParty/openldap/patches$ more ../../../ZimbraServer/src/libexec/zmslapd #!/bin/bash # # ***** BEGIN LICENSE BLOCK ***** # Zimbra Collaboration Suite Server # Copyright (C) 2007, 2008, 2009, 2010, 2012, 2013, 2014 Zimbra, Inc. # # This program is free software: you can redistribute it and/or modify it under # the terms of the GNU General Public License as published by the Free Software Foundation, # version 2 of the License. # # This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; # without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. # See the GNU General Public License for more details. # You should have received a copy of the GNU General Public License along with this program. # If not, see <http://www.gnu.org/licenses/>. # ***** END LICENSE BLOCK ***** # ulimit -n 32768 ulimit -c unlimited ulimit -v unlimited export LD_PRELOAD=/opt/zimbra/tcmalloc/lib/libtcmalloc_minimal.so exec /opt/zimbra/openldap/sbin/slapd "$@" As there is no actionable bug report here, this bug will be closed. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2015