Re: (ITS#7249) slapd segfault with memberof overlay on frontend db
by hyc＠symas.com
This is a multi-part message in MIME format.
--------------080305040400020709070605
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
jvcelak(a)redhat.com wrote:
>> What happens is that the memberof overlay, when stacked on the frontend
>> database, keeps looping until the stack is exhausted, since internal
>> modifications keep calling the frontend's modify hook rather than the
>> actual one that needs to be called.
>
> I have no idea how to fix it. I probably do not understand the manipulation
> with BackedInfo structures fully.
>
> It is obious that it is caused by doing a search from the modrdn operation
> callback memberof_res_modrdn() which is set up in memberof_op_modrdn(). Other
> backends does not call any backend operation at the same moment (op->callback).
>
> Frontend fe_op_search() is called. It tries to choose the right backend with
> select_backend(). Which returns the overlay backend (bi_type == "over"),
> over_op_walk() then selects fe_op_search() again, and we are looping infinitely.
>
> I have no clue how to hide or temporarily deactivate the overlay in
> memberof_res_modrdn() to make the select_backend() function to choose the right
> underlaying backend. Or maybe I have choosen a wrong way of fixing it.
>
> All ideas are welcomed. :-)
The attached diff fixes this particular problem. I haven't spent any time to
see if the other be_* invocations need to be protected the same way.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
--------------080305040400020709070605
Content-Type: text/plain; charset=UTF-8;
name="dif.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="dif.txt"
diff --git a/servers/slapd/overlays/memberof.c b/servers/slapd/overlays/memberof.c
index 502cb46..555d5d9 100644
--- a/servers/slapd/overlays/memberof.c
+++ b/servers/slapd/overlays/memberof.c
@@ -285,7 +285,8 @@ memberof_isGroupOrMember( Operation *op, memberof_cbinfo_t *mci )
op2.ors_filterstr = mo->mo_groupFilterstr;
op2.ors_filter = &mo->mo_groupFilter;
- op2.o_bd->bd_info = (BackendInfo *)on->on_info;
+ if (bi->bi_type == memberof.on_bi.bi_type)
+ op2.o_bd->bd_info = (BackendInfo *)on->on_info;
(void)op->o_bd->be_search( &op2, &rs2 );
op2.o_bd->bd_info = bi;
@@ -307,9 +308,9 @@ memberof_isGroupOrMember( Operation *op, memberof_cbinfo_t *mci )
op2.ors_filterstr = mo->mo_memberFilterstr;
op2.ors_filter = &mo->mo_memberFilter;
- op2.o_bd->bd_info = (BackendInfo *)on->on_info;
+ if (bi->bi_type == memberof.on_bi.bi_type)
+ op2.o_bd->bd_info = (BackendInfo *)on->on_info;
(void)op->o_bd->be_search( &op2, &rs2 );
- op2.o_bd->bd_info = bi;
if ( mc.foundit ) {
iswhat |= MEMBEROF_IS_MEMBER;
--------------080305040400020709070605--
11 years, 1 month
Re: (ITS#7249) slapd segfault with memberof overlay on frontend db
by jvcelak＠redhat.com
> What happens is that the memberof overlay, when stacked on the frontend
> database, keeps looping until the stack is exhausted, since internal
> modifications keep calling the frontend's modify hook rather than the
> actual one that needs to be called.
I have no idea how to fix it. I probably do not understand the manipulation
with BackedInfo structures fully.
It is obious that it is caused by doing a search from the modrdn operation
callback memberof_res_modrdn() which is set up in memberof_op_modrdn(). Other
backends does not call any backend operation at the same moment (op->callback).
Frontend fe_op_search() is called. It tries to choose the right backend with
select_backend(). Which returns the overlay backend (bi_type == "over"),
over_op_walk() then selects fe_op_search() again, and we are looping infinitely.
I have no clue how to hide or temporarily deactivate the overlay in
memberof_res_modrdn() to make the select_backend() function to choose the right
underlaying backend. Or maybe I have choosen a wrong way of fixing it.
All ideas are welcomed. :-)
Thanks & Regards,
Jan
11 years, 1 month
(ITS#7261) ldapsearch with base specified does not return anything
by ashish＠sendmail.com
Full_Name: Ashish Gawarikar
Version: 2.4.31
OS: Redhat 5.8
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (63.211.143.38)
Configure slapd with multiple databases:
database bdb
directory /var/ldap/openldap-bdb24
suffix "sendmailMTAMapName=virtuser,sendmailMTACluster=hub,dc=example,dc=com"
subordinate advertise
dbconfig set_lg_dir /var/ldap/openldap-bdb24/log
database bdb
directory /var/ldap/openldap-bdb23
suffix "sendmailMTAMapName=stduser,sendmailMTACluster=hub,dc=example,dc=com"
subordinate advertise
dbconfig set_lg_dir /var/ldap/openldap-bdb23/log
database bdb
directory /var/ldap/openldap-bdb22
suffix "sendmailMTAMapName=generics,sendmailMTACluster=hub,dc=example,dc=com"
subordinate advertise
dbconfig set_lg_dir /var/ldap/openldap-bdb22/log
database bdb
directory /var/sendmail/ldap/openldap-bdb21
suffix "sendmailMTAAliasGrouping=aliases,sendmailMTACluster=hub,dc=example,dc=com"
subordinate advertise
dbconfig set_lg_dir /var/ldap/openldap-bdb21/log
database bdb
directory /var/ldap/openldap-bdb20
suffix "sendmailMTACluster=hub,dc=example,dc=com"
subordinate advertise
dbconfig set_lg_dir /var/ldap/openldap-bdb20/log
database bdb
directory /var/ldap/openldap-bdb13
suffix "sendmailMTAMapName=b,sendmailMTACluster=QQQ,dc=example,dc=com"
subordinate advertise
dbconfig set_lg_dir /var/ldap/openldap-bdb13/log
database bdb
directory /var/ldap/openldap-bdb12
suffix "sendmailMTAMapName=E,sendmailMTACluster=QQQ,dc=example,dc=com"
subordinate advertise
dbconfig set_lg_dir /var/ldap/openldap-bdb12/log
database bdb
directory /var/ldap/openldap-bdb11
suffix "sendmailMTAMapName=Es,sendmailMTACluster=QQQ,dc=example,dc=com"
subordinate advertise
dbconfig set_lg_dir /var/ldap/openldap-bdb11/log
database bdb
directory /var/ldap/openldap-bdb10
suffix "sendmailMTACluster=QQQ,dc=example,dc=com"
subordinate advertise
dbconfig set_lg_dir /var/ldap/openldap-bdb10/log
database hdb
directory /var/ldap/openldap-bdb
suffix ""
===
10 ldifs:
1.ldif
dn: sendmailMTAMapName=virtuser,sendmailMTACluster=hub,dc=example,dc=com
objectClass: sendmailMTAMap
objectClass: sendmailMTA
objectClass: top
objectClass: extensibleObject
sendmailMTACluster: hub
sendmailMTAMapName: virtuser
2.ldif
dn: sendmailMTAMapName=stduser,sendmailMTACluster=hub,dc=example,dc=com
objectClass: sendmailMTAMap
objectClass: sendmailMTA
objectClass: top
objectClass: extensibleObject
sendmailMTACluster: hub
sendmailMTAMapName: stduser
3.ldif
dn: sendmailMTAMapName=generics,sendmailMTACluster=hub,dc=example,dc=com
objectClass: sendmailMTAMap
objectClass: sendmailMTA
objectClass: top
objectClass: extensibleObject
sendmailMTACluster: hub
sendmailMTAMapName: generics
4.ldif
dn: sendmailMTAAliasGrouping=aliases,sendmailMTACluster=hub,dc=example,dc=com
objectClass: sendmailMTAAlias
objectClass: sendmailMTA
objectClass: top
objectClass: extensibleObject
sendmailMTAAliasGrouping: aliases
sendmailMTACluster: hub
5.ldif
dn: sendmailMTACluster=hub,dc=example,dc=com
objectClass: sendmailMTA
objectClass: top
objectClass: extensibleObject
sendmailMTACluster: hub
6.ldif
dn: sendmailMTAMapName=b,sendmailMTACluster=QQQ,dc=example,dc=com
objectClass: sendmailMTAMap
objectClass: sendmailMTA
objectClass: top
objectClass: extensibleObject
sendmailMTACluster: QQQ
sendmailMTAMapName: b
7.ldif
dn: sendmailMTAMapName=E,sendmailMTACluster=QQQ,dc=example,dc=com
objectClass: sendmailMTAMap
objectClass: sendmailMTA
objectClass: top
objectClass: extensibleObject
sendmailMTACluster: QQQ
sendmailMTAMapName: E
8.ldif
dn: sendmailMTAMapName=Es,sendmailMTACluster=QQQ,dc=example,dc=com
objectClass: sendmailMTAMap
objectClass: sendmailMTA
objectClass: top
objectClass: extensibleObject
sendmailMTACluster: QQQ
sendmailMTAMapName: Es
9.ldif
dn: sendmailMTACluster=QQQ,dc=example,dc=com
objectClass: sendmailMTA
objectClass: top
objectClass: extensibleObject
sendmailMTACluster: QQQ
10.ldif
dn: dc=example,dc=com
objectClass: top
objectClass: extensibleObject
dc: example
dn: dc=com
objectClass: top
objectClass: extensibleObject
Add entries in the db using:
slapadd -w -l 1.ldif -b
sendmailMTAMapName=virtuser,sendmailMTACluster=hub,dc=example,dc=com
slapadd -w -l 2.ldif -b
sendmailMTAMapName=stduser,sendmailMTACluster=hub,dc=example,dc=com
slapadd -w -l 3.ldif -b
sendmailMTAMapName=generics,sendmailMTACluster=hub,dc=example,dc=com
slapadd -w -l 4.ldif -b
sendmailMTAAliasGrouping=aliases,sendmailMTACluster=hub,dc=example,dc=com
slapadd -w -l 5.ldif -b sendmailMTACluster=hub,dc=example,dc=com
slapadd -w -l 6.ldif -b
sendmailMTAMapName=b,sendmailMTACluster=QQQ,dc=example,dc=com
slapadd -w -l 7.ldif -b
sendmailMTAMapName=E,sendmailMTACluster=QQQ,dc=example,dc=com
slapadd -w -l 8.ldif -b
sendmailMTAMapName=Es,sendmailMTACluster=QQQ,dc=example,dc=com
slapadd -w -l 9.ldif -b sendmailMTACluster=QQQ,dc=example,dc=com
# rest in the default bucket
slapadd -w -l 10.ldif -b ''
===========
Do an ldapsearch without the base specified:
ldapsearch -x
# aliases, hub, example.com
dn: sendmailMTAAliasGrouping=aliases,sendmailMTACluster=hub,dc=example,dc=com
objectClass: sendmailMTAAlias
objectClass: sendmailMTA
objectClass: top
objectClass: extensibleObject
sendmailMTAAliasGrouping: aliases
sendmailMTACluster: hub
# hub, example.com
dn: sendmailMTACluster=hub,dc=example,dc=com
objectClass: sendmailMTA
objectClass: top
objectClass: extensibleObject
sendmailMTACluster: hub
...
Do an ldapsearch with base:
ldapsearch -x -b "dc=example,dc=com"
# extended LDIF
#
# LDAPv3
# base <dc=example,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# search result
search: 2
Similar search works on Openldap 2.3.x
=================================================================================
sendmail.schema file
# Copyright (c) 2000-2002, 2005 Sendmail, Inc. and its suppliers.
# All rights reserved.
#
# By using this file, you agree to the terms and conditions set
# forth in the LICENSE file which can be found at the top level of
# the sendmail distribution.
#
# $Id: sendmail.schema,v 8.22 2005/09/16 20:18:14 ca Exp $
# Note that this schema is experimental at this point as it has had little
# public review. Therefore, it may change in future versions. Feedback
# via sendmail-YYYY(a)support.sendmail.org is encouraged (replace YYYY with
# the current year, e.g., 2005).
# OID arcs for Sendmail
# enterprise: 1.3.6.1.4.1
# sendmail: enterprise.6152
# sendmail-at: sendmail.3.1
# sendmail-oc: sendmail.3.2
###########################################################################
#
# The Sendmail MTA attributes and objectclass
#
###########################################################################
# attribute sendmailMTACluster cis
attributetype ( 1.3.6.1.4.1.6152.10.3.1.10
NAME 'sendmailMTACluster'
DESC 'cluster name associated with a set of MTAs'
EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )
# attribute sendmailMTAHost cis
attributetype ( 1.3.6.1.4.1.6152.10.3.1.11
NAME 'sendmailMTAHost'
DESC 'host name associated with a MTA cluster'
EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )
#objectClass sendmailMTA
# requires
# objectClass
# allows
# sendmailMTACluster,
# sendmailMTAHost,
# Description
objectclass ( 1.3.6.1.4.1.6152.10.3.2.10
NAME 'sendmailMTA'
SUP top STRUCTURAL
DESC 'Sendmail MTA definition'
MAY ( sendmailMTACluster $ sendmailMTAHost $ Description ) )
###########################################################################
#
# The Sendmail MTA shared attributes
#
###########################################################################
# attribute sendmailMTAKey cis
attributetype ( 1.3.6.1.4.1.6152.10.3.1.13
NAME 'sendmailMTAKey'
DESC 'key (left hand side) of an aliases or map entry'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
###########################################################################
#
# The Sendmail MTA Map attributes and objectclasses
#
###########################################################################
# attribute sendmailMTAMapName cis
attributetype ( 1.3.6.1.4.1.6152.10.3.1.14
NAME 'sendmailMTAMapName'
DESC 'identifier for the particular map'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} SINGLE-VALUE )
# attribute sendmailMTAMapValue cis
attributetype ( 1.3.6.1.4.1.6152.10.3.1.16
NAME 'sendmailMTAMapValue'
DESC 'value (right hand side) of a map entry'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
# attribute sendmailMTAMapSearch cis
attributetype ( 1.3.6.1.4.1.6152.10.3.1.24
NAME 'sendmailMTAMapSearch'
DESC 'recursive search for values of a map entry'
EQUALITY caseExactMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
# attribute sendmailMTAMapURL cis
attributetype ( 1.3.6.1.4.1.6152.10.3.1.25
NAME 'sendmailMTAMapURL'
DESC 'recursive search URL for values of a map entry'
EQUALITY caseExactMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
#objectClass sendmailMTAMap
# requires
# objectClass,
# sendmailMTAMapName,
# allows
# sendmailMTACluster,
# sendmailMTAHost,
# Description
objectclass ( 1.3.6.1.4.1.6152.10.3.2.11
NAME 'sendmailMTAMap'
SUP sendmailMTA STRUCTURAL
DESC 'Sendmail MTA map definition'
MUST sendmailMTAMapName
MAY ( sendmailMTACluster $ sendmailMTAHost $ Description ) )
#objectClass sendmailMTAObject
# requires
# objectClass,
# sendmailMTAMapName,
# sendmailMTAKey,
# allows
# sendmailMTACluster,
# sendmailMTAHost,
# sendmailMTAMapValue,
# sendmailMTAMapSearch,
# sendmailMTAMapURL,
# Description
objectclass ( 1.3.6.1.4.1.6152.10.3.2.12
NAME 'sendmailMTAMapObject'
SUP sendmailMTAMap STRUCTURAL
DESC 'Sendmail MTA map object'
MUST ( sendmailMTAMapName $ sendmailMTAKey )
MAY ( sendmailMTACluster $ sendmailMTAHost $
sendmailMTAMapValue $ sendmailMTAMapSearch $
sendmailMTAMapURL $ Description ) )
###########################################################################
#
# The Sendmail MTA Alias attributes and objectclasses
#
###########################################################################
# attribute sendmailMTAAliasGrouping cis
attributetype ( 1.3.6.1.4.1.6152.10.3.1.18
NAME 'sendmailMTAAliasGrouping'
DESC 'name that identifies a particular aliases grouping'
EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )
# attribute sendmailMTAAliasValue cis
attributetype ( 1.3.6.1.4.1.6152.10.3.1.20
NAME 'sendmailMTAAliasValue'
DESC 'value (right hand side) of an alias'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
# attribute sendmailMTAAliasSearch cis
attributetype ( 1.3.6.1.4.1.6152.10.3.1.26
NAME 'sendmailMTAAliasSearch'
DESC 'recursive search for values of an alias'
EQUALITY caseExactMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
# attribute sendmailMTAAliasURL cis
attributetype ( 1.3.6.1.4.1.6152.10.3.1.27
NAME 'sendmailMTAAliasURL'
DESC 'recursive search URL for values of an alias'
EQUALITY caseExactMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
#objectClass sendmailMTAAlias
# requires
# objectClass,
# allows
# sendmailMTAAliasGrouping,
# sendmailMTACluster,
# sendmailMTAHost,
# Description
objectclass ( 1.3.6.1.4.1.6152.10.3.2.13
NAME 'sendmailMTAAlias'
SUP sendmailMTA STRUCTURAL
DESC 'Sendmail MTA alias definition'
MAY ( sendmailMTAAliasGrouping $
sendmailMTACluster $ sendmailMTAHost $ Description ) )
#objectClass sendmailMTAAliasObject
# requires
# objectClass,
# sendmailMTAKey,
# allows
# sendmailMTAAliasGrouping,
# sendmailMTACluster,
# sendmailMTAHost,
# sendmailMTAAliasValue,
# sendmailMTAAliasSearch,
# sendmailMTAAliasURL,
# Description
objectclass ( 1.3.6.1.4.1.6152.10.3.2.14
NAME 'sendmailMTAAliasObject'
SUP sendmailMTAAlias STRUCTURAL
DESC 'Sendmail MTA alias object'
MUST sendmailMTAKey
MAY ( sendmailMTAAliasGrouping $ sendmailMTACluster $
sendmailMTAHost $ sendmailMTAAliasValue $
sendmailMTAAliasSearch $ sendmailMTAAliasURL $ Description ) )
###########################################################################
#
# The Sendmail MTA Class attributes and objectclass
#
###########################################################################
# attribute sendmailMTAClassName cis
attributetype ( 1.3.6.1.4.1.6152.10.3.1.22
NAME 'sendmailMTAClassName'
DESC 'identifier for the class'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} SINGLE-VALUE )
# attribute sendmailMTAClassValue cis
attributetype ( 1.3.6.1.4.1.6152.10.3.1.23
NAME 'sendmailMTAClassValue'
DESC 'member of a class'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
# attribute sendmailMTAClassSearch cis
attributetype ( 1.3.6.1.4.1.6152.10.3.1.28
NAME 'sendmailMTAClassSearch'
DESC 'recursive search for members of a class'
EQUALITY caseExactMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
# attribute sendmailMTAClassURL cis
attributetype ( 1.3.6.1.4.1.6152.10.3.1.29
NAME 'sendmailMTAClassURL'
DESC 'recursive search URL for members of a class'
EQUALITY caseExactMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
#objectClass sendmailMTAClass
# requires
# objectClass,
# sendmailMTAClassName,
# allows
# sendmailMTACluster,
# sendmailMTAHost,
# sendmailMTAClassValue,
# sendmailMTAClassSearch,
# sendmailMTAClassURL,
# Description
objectclass ( 1.3.6.1.4.1.6152.10.3.2.15
NAME 'sendmailMTAClass'
SUP sendmailMTA STRUCTURAL
DESC 'Sendmail MTA class definition'
MUST sendmailMTAClassName
MAY ( sendmailMTACluster $ sendmailMTAHost $
sendmailMTAClassValue $ sendmailMTAClassSearch $
sendmailMTAClassURL $ Description ) )
11 years, 1 month
Re: (ITS#7249) slapd segfault with memberof overlay on frontend db
by masarati＠aero.polimi.it
> Hello,
>
>> Enabling memberof overlay on frontend database causes slapd to
>> SEGFAULT due to stack overflow when renaming an entry.
>
> please, can somebody confirm that this configuration is wrong and
> that it should not be allowed? Or that this configuration is
> correct and the "overlay effect" should be inherited by backend
> database?
>
> I would like to help with fixing this, but I have no idea what
> is the expected behavior. Documentation says nothing about this.
What happens is that the memberof overlay, when stacked on the frontend
database, keeps looping until the stack is exhausted, since internal
modifications keep calling the frontend's modify hook rather than the
actual one that needs to be called.
I don't recall testing it this way during development, but I don't see any
reason to prevent it from working this way. Feel free to look at it, I
probably won't have time to do it soon.
Thanks, p.
11 years, 1 month
Re: (ITS#7249) slapd segfault with memberof overlay on frontend db
by jvcelak＠redhat.com
Hello,
> Enabling memberof overlay on frontend database causes slapd to
> SEGFAULT due to stack overflow when renaming an entry.
please, can somebody confirm that this configuration is wrong and
that it should not be allowed? Or that this configuration is
correct and the "overlay effect" should be inherited by backend
database?
I would like to help with fixing this, but I have no idea what
is the expected behavior. Documentation says nothing about this.
Jan
11 years, 1 month
Re: (ITS#7258) Possible suffixmassage and syncrepl bug
by masarati＠aero.polimi.it
> Full_Name: Jon C. Kidder
> Version: 2.4.30
> OS: rhel 5.0
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (167.239.77.30)
>
>
> Gentlemen, I need some help. I've been working on a problem for a couple
> of
> weeks and I can't seem to find a solution. I have encountered at least one
> bug
> and possibly two.
>
> I am building a new directory for my company using OpenLDAP 2.4.30 and BDB
> 5.3.15. I am trying to pull in records from a foreign directory and map
> them
> into my directory. All of the foreign records are proxied into 3 child
> nodes of
> my directory. I am able to do this successfully using back-ldif and
> overlay-rwm.
> The problem I am encountering is that I have setup multi-master
> replication of
> the entire new directory with a filter to exclude the proxied nodes
> because each
> of my directory servers independently proxies those nodes. When the
> replication
> starts syncrepl causes an ABEND on every node that attempts replication. I
> have
> discovered that the ABEND occurs because my filter does not work and
> syncrepl is
> trying to replicate the proxied records. I have also discovered that my
> filter
> is not working because rwm-suffixmassage does not appear to be rewriting
> the
> entryDN of my proxied records. If my entryDN problem is configuration
> related I
> could use some help figuring it out. I am still submitting this as a bug
> because
> even if the entryDN problem is not a bug syncrepl should detect the
> replication/proxy conflict and abort the replication gracefully rather
> than
> ABEND the directory server.
>
> I love the work the OpenLDAP team is doing. I am a very strong advocate of
> open
> source products at my company. I would love to take a deep dive into the
> code
> and resolve this issue myself but unfortunately can not. I am an
> administrator/operator by day and a single parent of 6 year old triplet
> boys by
> night. I am not afforded as many opportunities to exercise my development
> skills
> as I would like. Any assistance the OpenLDAP team can render would be
> greatly
> appreciated. I can try to build a complete test suite that will allow
> recreation/testing of these 2 issues if needed.
>
> Sample ldapsearch result showing inconsistent DN rewrite (DN is rewritten
> but
> entryDN is not):
>
> /appl/openldap/bin/ldapsearch -x -D "cn=Directory
> Manager,dc=Global,dc=aep,dc=com" -y $HOME/buildpwd -s sub -b
> 'dc=Global,dc=aep,dc=com' '(cn=s012235)' '+'
> # extended LDIF
> #
> # LDAPv3
> # base <dc=Global,dc=aep,dc=com> with scope subtree
> # filter: (cn=s012235)
> # requesting: +
> #
>
> # s012235, Information Technology, AD_Corp, Employees, Users,
> Global.aep.com
> dn: cn=s012235,ou=Information
> Technology,ou=AD_Corp,ou=Employees,ou=Users,dc=G
> lobal,dc=aep,dc=com
> entryDN: cn=s012235,ou=Information Technology,ou=LOB
> Users,dc=corp,dc=aepsc,dc
> =com
> subschemaSubentry: cn=Subschema
slapo-rwm(5) explicitly skips entryDN (and removes it from attributes
returned by searches) because entryDN is (re-)added by the frontend.
Of course both events appear to be erroneous; unless they result from a
misconfiguration (and in any case for the sigsegv) they need to be
addressed.
I suggest you create a minimal setup that shows the problem (either one
for each problem, or one for both) and upload it according to instructions
here <http://www.openldap.org/devel/contributing.html#submitting>.
Attaching it to an email is not an option because the ITS does not handle
attachments well.
p.
11 years, 1 month
Re: (ITS#7260) problem with 2.4.30 to 2.4.31 upgrade
by masarati＠aero.polimi.it
> Full_Name: Andrzej Tobola
> Version: 2.4.31
> OS: FreeBSD 9.0 amd64
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (194.29.146.94)
>
>
> I run slapd from a long time on FreeBSD stable amd64 and it is started
> with
> args:
>
> slapd -4 -h "ldapi://%2fvar%2frun%2fslapd.socket ldap://localhost/
> ldap://ldap2/ ldaps://ldap2/" -u ldap -g ldap
>
> After upgrade from 2.4.30 to 2.4.31 my server can't start:
> slapd[29221]: read_config: no serverID / URL match found. Check slapd -h
> arguments.
> Nothing was change in en environment - only ldap was upgraded.
>
> After backing-off only this one commit to bconfg.c:
> http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commitdiff;h=b4...
>
> all is working again.
> Any clue ?
> and IHMO this message shod be more informative for casual user.
This message (and the related commit) adds a sanity check (ITS#7200).
Apparently, your system is (and was) misconfigured. So I'd try to
understand what the misconfiguration is, rather than backing up to a
version without sanity check.
This discussion belongs to openldap-technical(a)openldap.org rather than to
the ITS. You showed the value of -h, can you show your serverID /
olcServerID?
p.
11 years, 1 month
(ITS#7260) problem with 2.4.30 to 2.4.31 upgrade
by ato＠iem.pw.edu.pl
Full_Name: Andrzej Tobola
Version: 2.4.31
OS: FreeBSD 9.0 amd64
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (194.29.146.94)
I run slapd from a long time on FreeBSD stable amd64 and it is started with
args:
slapd -4 -h "ldapi://%2fvar%2frun%2fslapd.socket ldap://localhost/
ldap://ldap2/ ldaps://ldap2/" -u ldap -g ldap
After upgrade from 2.4.30 to 2.4.31 my server can't start:
slapd[29221]: read_config: no serverID / URL match found. Check slapd -h
arguments.
Nothing was change in en environment - only ldap was upgraded.
After backing-off only this one commit to bconfg.c:
http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commitdiff;h=b4...
all is working again.
Any clue ?
and IHMO this message shod be more informative for casual user.
11 years, 1 month
