(ITS#4811) refreshAndPersist and Monitor -> slapd core dump
by niels＠signaturgruppen.dk
Full_Name: Niels Frimodt Sørensen
Version: 2.3.32
OS: Solaris
URL:
Submission from: (NULL) (80.160.139.81)
Hi,
refreshAndPersist mode of syncrepl seems to have problems with Monitor. The
slave is dumping core when I do ldapsearch against cn=Connections, cn=Monitor.
The system is running on Solaris 9 and based on OpenLDAP 2.3.32.
Replication works just fine.
If I change syncrepl type to refreshOnly then the ldapsearch is completed
without core dump.
Further information on configuration and debug below.
The Master has the following conf:
# slapd.conf
# Schema
include /opt/ldap/content2/schema/core.schema
# Control files
pidfile /opt/ldap/backend2/var/slapd.pid
argsfile /opt/ldap/backend2/var/slapd.args
database bdb
suffix "c=NO"
rootdn "cn=Manager,c=NO"
rootpw Test1234
directory /opt/ldap/content2/data
checkpoint 128 10
# Indices to maintain
index objectclass,entryCSN,entryUUID eq
index serialNumber pres,eq
index mail pres,eq
index cn pres,eq
cachesize 100000
threads 64
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
database monitor
The slave has the following conf:
# slapd.conf
# Schema
include /opt/ldap/content-buslave/schema/core.schema
# Control files
pidfile /opt/ldap/backend-buslave/var/slapd.pid
argsfile /opt/ldap/backend-buslave/var/slapd.args
# database defs
database bdb
suffix "c=NO"
rootdn "cn=Manager,c=NO"
rootpw Test1234
directory /opt/ldap/content-buslave/data
checkpoint 128 10
# Indices to maintain
index objectclass,entryCSN,entryUUID eq
index serialNumber pres,eq
index mail pres,eq
index cn pres,eq
cachesize 100000
threads 32
syncrepl rid=123
provider=ldap://127.0.0.1:3892
type=refreshAndPersist
searchbase="c=NO"
filter="(objectClass=*)"
scobe=sub
attrs=""
schemachecking=off
bindmethod=simple
updatedn="cn=Manager,c=NO"
binddn="cn=Manager,c=NO"
credentials="Test1234"
database monitor
The ldapsearch output that indicate the problem:
ldapsearch -h localhost -p 3891 -b "cn=Monitor" "cn=Connections" +
# extended LDIF
#
# LDAPv3
# base <cn=Monitor> with scope subtree
# filter: cn=Connections
# requesting: +
#
# Connections, Monitor
dn: cn=Connections,cn=Monitor
structuralObjectClass: monitorContainer
creatorsName:
modifiersName:
createTimestamp: 20070122103402Z
modifyTimestamp: 20070122103402Z
entryDN: cn=Connections,cn=Monitor
subschemaSubentry: cn=Subschema
hasSubordinates: TRUE
ldap_result: Can't contact LDAP server (-1)
The slave debugs the following during the search:
...
=> test_filter
EQUALITY
=> access_allowed: search access to "cn=Connections,cn=Monitor" "cn" requested
=> access_allowed: backend default search access granted to "(anonymous)"
<= test_filter 6
=> send_search_entry: conn 0 dn="cn=Connections,cn=Monitor"
=> access_allowed: read access to "cn=Connections,cn=Monitor" "entry" requested
=> access_allowed: backend default read access granted to "(anonymous)"
=> access_allowed: read access to "cn=Connections,cn=Monitor"
"structuralObjectClass" requested
=> access_allowed: backend default read access granted to "(anonymous)"
=> access_allowed: read access to "cn=Connections,cn=Monitor" "creatorsName"
requested
=> access_allowed: backend default read access granted to "(anonymous)"
=> access_allowed: read access to "cn=Connections,cn=Monitor" "modifiersName"
requested
=> access_allowed: backend default read access granted to "(anonymous)"
=> access_allowed: read access to "cn=Connections,cn=Monitor" "createTimestamp"
requested
=> access_allowed: backend default read access granted to "(anonymous)"
=> access_allowed: read access to "cn=Connections,cn=Monitor" "modifyTimestamp"
requested
=> access_allowed: backend default read access granted to "(anonymous)"
=> access_allowed: read access to "cn=Connections,cn=Monitor" "entryDN"
requested
=> access_allowed: backend default read access granted to "(anonymous)"
=> access_allowed: read access to "cn=Connections,cn=Monitor"
"subschemaSubentry" requested
=> access_allowed: backend default read access granted to "(anonymous)"
=> access_allowed: read access to "cn=Connections,cn=Monitor" "hasSubordinates"
requested
=> access_allowed: backend default read access granted to "(anonymous)"
ber_flush: 308 bytes to sd 13
0000: 30 82 01 30 02 01 02 64 82 01 29 04 19 63 6e 3d 0..0...d..)..cn=
0010: 43 6f 6e 6e 65 63 74 69 6f 6e 73 2c 63 6e 3d 4d Connections,cn=M
0020: 6f 6e 69 74 6f 72 30 82 01 0a 30 2b 04 15 73 74 onitor0...0+..st
0030: 72 75 63 74 75 72 61 6c 4f 62 6a 65 63 74 43 6c ructuralObjectCl
0040: 61 73 73 31 12 04 10 6d 6f 6e 69 74 6f 72 43 6f ass1...monitorCo
0050: 6e 74 61 69 6e 65 72 30 12 04 0c 63 72 65 61 74 ntainer0...creat
0060: 6f 72 73 4e 61 6d 65 31 02 04 00 30 13 04 0d 6d orsName1...0...m
0070: 6f 64 69 66 69 65 72 73 4e 61 6d 65 31 02 04 00 odifiersName1...
0080: 30 24 04 0f 63 72 65 61 74 65 54 69 6d 65 73 74 0$..createTimest
0090: 61 6d 70 31 11 04 0f 32 30 30 37 30 31 32 32 31 amp1...200701221
00a0: 30 30 39 34 32 5a 30 24 04 0f 6d 6f 64 69 66 79 00942Z0$..modify
00b0: 54 69 6d 65 73 74 61 6d 70 31 11 04 0f 32 30 30 Timestamp1...200
00c0: 37 30 31 32 32 31 30 30 39 34 32 5a 30 26 04 07 70122100942Z0&..
00d0: 65 6e 74 72 79 44 4e 31 1b 04 19 63 6e 3d 43 6f entryDN1...cn=Co
00e0: 6e 6e 65 63 74 69 6f 6e 73 2c 63 6e 3d 4d 6f 6e nnections,cn=Mon
00f0: 69 74 6f 72 30 23 04 11 73 75 62 73 63 68 65 6d itor0#..subschem
0100: 61 53 75 62 65 6e 74 72 79 31 0e 04 0c 63 6e 3d aSubentry1...cn=
0110: 53 75 62 73 63 68 65 6d 61 30 19 04 0f 68 61 73 Subschema0...has
0120: 53 75 62 6f 72 64 69 6e 61 74 65 73 31 06 04 04 Subordinates1...
0130: 54 52 55 45 TRUE
ldap_write: want=308, written=308
0000: 30 82 01 30 02 01 02 64 82 01 29 04 19 63 6e 3d 0..0...d..)..cn=
0010: 43 6f 6e 6e 65 63 74 69 6f 6e 73 2c 63 6e 3d 4d Connections,cn=M
0020: 6f 6e 69 74 6f 72 30 82 01 0a 30 2b 04 15 73 74 onitor0...0+..st
0030: 72 75 63 74 75 72 61 6c 4f 62 6a 65 63 74 43 6c ructuralObjectCl
0040: 61 73 73 31 12 04 10 6d 6f 6e 69 74 6f 72 43 6f ass1...monitorCo
0050: 6e 74 61 69 6e 65 72 30 12 04 0c 63 72 65 61 74 ntainer0...creat
0060: 6f 72 73 4e 61 6d 65 31 02 04 00 30 13 04 0d 6d orsName1...0...m
0070: 6f 64 69 66 69 65 72 73 4e 61 6d 65 31 02 04 00 odifiersName1...
0080: 30 24 04 0f 63 72 65 61 74 65 54 69 6d 65 73 74 0$..createTimest
0090: 61 6d 70 31 11 04 0f 32 30 30 37 30 31 32 32 31 amp1...200701221
00a0: 30 30 39 34 32 5a 30 24 04 0f 6d 6f 64 69 66 79 00942Z0$..modify
00b0: 54 69 6d 65 73 74 61 6d 70 31 11 04 0f 32 30 30 Timestamp1...200
00c0: 37 30 31 32 32 31 30 30 39 34 32 5a 30 26 04 07 70122100942Z0&..
00d0: 65 6e 74 72 79 44 4e 31 1b 04 19 63 6e 3d 43 6f entryDN1...cn=Co
00e0: 6e 6e 65 63 74 69 6f 6e 73 2c 63 6e 3d 4d 6f 6e nnections,cn=Mon
00f0: 69 74 6f 72 30 23 04 11 73 75 62 73 63 68 65 6d itor0#..subschem
0100: 61 53 75 62 65 6e 74 72 79 31 0e 04 0c 63 6e 3d aSubentry1...cn=
0110: 53 75 62 73 63 68 65 6d 61 30 19 04 0f 68 61 73 Subschema0...has
0120: 53 75 62 6f 72 64 69 6e 61 74 65 73 31 06 04 04 Subordinates1...
0130: 54 52 55 45 TRUE
conn=0 op=1 ENTRY dn="cn=connections,cn=monitor"
<= send_search_entry: conn 0 exit.
Segmentation Fault - core dumped
--
Venlig hilsen/Kind regards
Niels Frimodt Sørensen
Signaturgruppen A/S
www.signaturgruppen.dk
15 years, 4 months
Re: (ITS#4810) syncprov follows referrals
by hyc＠symas.com
ando(a)sys-net.it wrote:
> dieter(a)dkluenter.de wrote:
>> Full_Name: Dieter Kluenter
>> Version: 2.4.2alpha
>> When adding a alias abject to the provider, syncprov fowllows the referral and
>> is not updating the alias object to the consumer,
>
> Dieter,
>
> are you talking about aliases or referrals?
>
> I also note that, AFAIK, 2.4.2alpha is way out of sync with HEAD. While
> a new 2.4 release might be desirable, I suggest you test HEAD instead.
I note that this code has been present in syncprov, unchanged, for quite a
long time (throughout 2.3 to current):
if ( op->ors_deref & LDAP_DEREF_SEARCHING ) {
send_ldap_error( op, rs, LDAP_PROTOCOL_ERROR, "illegal value for
derefAliases" );
return rs->sr_err;
}
which would prevent syncprov from chasing aliases during a search. As such, I
think you need provide a test case that illustrates the problem.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/
15 years, 4 months
Re: (ITS#4810) syncprov follows referrals
by ando＠sys-net.it
dieter(a)dkluenter.de wrote:
> Full_Name: Dieter Kluenter
> Version: 2.4.2alpha
> OS: linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (84.142.177.66)
>
>
> When adding a alias abject to the provider, syncprov fowllows the referral and
> is not updating the alias object to the consumer,
Dieter,
are you talking about aliases or referrals?
I also note that, AFAIK, 2.4.2alpha is way out of sync with HEAD. While
a new 2.4 release might be desirable, I suggest you test HEAD instead.
p.
15 years, 4 months
Re: (ITS#4809) Replication of operational attributes when performing modrdn operation
by ando＠sys-net.it
Apparently, according to slurpd's replog, no operational attrs are
modified on modrdn. In fact, modrdn is replicated as a plain modrdn,
which does not alter the write-related operational attrs (nor it is
allowed to, according to LDIF, as per RFC 2849). Rep-logging an
additional modify that only changes the write-related operational attrs
could fix the problem, at the cost of not making it atomical. A
"cleaner" solution would be to wrap a modify with a control that gets
added to the modrdn operation by slurpd, which modifies modifiersName,
modifyTimestamp and entryCSN using the "relax" control. Or, the (yet
unpublished) "relax" control could be redefined to allow an optional
control value that contains a modification required to maintain
consistency of the final entry, or something like that.
This definitely needs investigation, but it could be considered yet
another reason for dropping slurpd.
p.
15 years, 4 months
(ITS#4809) Replication of operational attributes when performing modrdn operation
by Thomas.Fritz＠bam.de
Full_Name: Thomas Fritz
Version: 2.3.33
OS: Debian Gnu/Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (141.63.61.111)
We are using OpenLDAP 2.3.33 in a master/slave setup with slurpd and hdb
backend.
When performing the modrdn operation against the master, no update directives
for the attributes 'modifiersName', 'modifyTimestamp', and 'entryCSN' are
written to the replog file. Hence, the databases of master and slave differ by
the values of these attributes after replication.
This bug can be reproduced using e.g. the ldapmodrdn tool. OpenLDAP versions
back to (at least) 2.3.24 are affected.
15 years, 4 months
(ITS#4808) erroneous error code testing in back-ldap
by ando＠sys-net.it
Full_Name: Pierangelo Masarati
Version: HEAD,re23
OS: irrelevant
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (81.72.89.40)
Submitted by: ando
in a couple of places, LDAP_SERVER_DOWN is tested after client library error
codes have already been mapped to response codes (LDAP_SERVER_DOWN =>
LDAP_UNAVAILABLE). As a consequence, delete and modrdn are not retried as
appropriate.
p.
15 years, 4 months
(ITS#4807) CLOCK-Pro cache replacement
by hyc＠OpenLDAP.org
Full_Name: Howard Chu
Version: HEAD
OS:
URL: ftp://ftp.openldap.org/incoming/hyc-20070116.txt
Submission from: (NULL) (76.168.84.21)
Submitted by: hyc
This is a rough implementation of the CLOCK-Pro cache replacement algorithm for
back-bdb. It's based on the paper published here
http://www.cse.ohio-state.edu/hpcs/WWW/HTML/publications/abs05-3.html
Currently the performance is not very good; the algorithm can invoke multiple
scans of the Clock list and our lock overhead for those scans is too high. I'm
not planning to do any more with this at the moment, just wanted to post it so
it doesn't get lost, in case someone else is interested. I didn't want to commit
it behind #ifdef's because that would get too messy.
This implementation deviates from the paper in two major respects:
1) it's possible for an EntryInfo node to get its Reference bit set even when
the entry is not Resident. This happens very frequently, in cache_find_ndn. As
such, EntryInfo nodes without an Entry, but that have been Referenced, do not
get flushed by HANDtest.
2) Nodes can get their Reference bit cleared at many points during the Clock-Pro
processing, so the bit is not a good indication of whether a node is currently
in use and may be safely freed. So, elaborate lock checks are used at each point
where the original algorithm would simply free a node (HANDcold, HANDtest).
It would be nice if our locking setup could be simplified. If someone else wants
to jump in and clean it up, it may be worth committing down the road.
15 years, 4 months
(ITS#4806) allow internal operations to require more specific access privileges
by ando＠sys-net.it
Full_Name: Pierangelo Masarati
Version: HEAD,re23
OS: irrelevant
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (81.72.89.40)
Submitted by: ando
Occasionally, internal operations, and significantly searches, are performed for
some given purpose which would require different access privileges than, for
example in case of searches, "search" on the filter and "read" on the data. In
those cases, it may be useful to allow issuers of internal operations to change
the access privilege that's requested.
This feature (is implemented to address an issue with slapo-dynlist(5) which
uses an internal search to collect data for compare, and thus checks "search"
access on the filter of the memberURL and "read" on the datum to be compared.
See <http://www.openldap.org/lists/openldap-devel/200701/msg00056.html> for
discussion.
15 years, 4 months
