Re: (ITS#7145) cn=Connection 0
by michael＠stroeder.com
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.
7 years, 7 months
Re: (ITS#7145) cn=Connection 0
by hguo＠suse.com
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.
>
7 years, 7 months
Re: (ITS#7145) cn=Connection 0
by michael＠stroeder.com
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.
7 years, 7 months
Re: (ITS#7145) cn=Connection 0
by hguo＠suse.com
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
7 years, 7 months
(ITS#8101) facsimileTelephoneNumber
by bernhard.pfeiffer＠brz.gv.at
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?
7 years, 7 months
(ITS#8100) Empty accesslog causes issues with delta-syncrepl MMR configurations
by quanah＠openldap.org
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.
7 years, 7 months
Re: (ITS#8099) Documentation bug with 'tls_cipher(_)suite' option
by quanah＠zimbra.com
--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
7 years, 7 months
Re: (ITS#8057) slapo-unique can be bypassed by anyone
by ondra＠mistotebe.net
A fix for that is at
ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20150408-ITS-8057-uniquenes...
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
7 years, 7 months
Re: (ITS#8098) Memory leakage
by quanah＠zimbra.com
--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
7 years, 7 months
