openldap-bugs

openldap-bugs@openldap.org

1 participants
20953 discussions

Re: (ITS#4811) refreshAndPersist and Monitor -> slapd core dump
by ando＠sys-net.it 22 Jan '07

22 Jan '07

This bug report is missing the most important part: a backtrace of the core dumped when the problem occurs. Please provide one. p.

1 0

(ITS#4811) refreshAndPersist and Monitor -> slapd core dump
by niels＠signaturgruppen.dk 22 Jan '07

22 Jan '07

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

1 0

Re: (ITS#4810) syncprov follows referrals
by hyc＠symas.com 22 Jan '07

22 Jan '07

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/

1 0

Re: (ITS#4810) syncprov follows referrals
by ando＠sys-net.it 22 Jan '07

22 Jan '07

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.

1 0

(ITS#4810) syncprov follows referrals
by dieter＠dkluenter.de 21 Jan '07

21 Jan '07

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

1 0

Re: (ITS#4809) Replication of operational attributes when performing modrdn operation
by ando＠sys-net.it 20 Jan '07

20 Jan '07

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.

1 0

(ITS#4809) Replication of operational attributes when performing modrdn operation
by Thomas.Fritz＠bam.de 19 Jan '07

19 Jan '07

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.

1 0

(ITS#4808) erroneous error code testing in back-ldap
by ando＠sys-net.it 17 Jan '07

17 Jan '07

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.

1 0

(ITS#4807) CLOCK-Pro cache replacement
by hyc＠OpenLDAP.org 16 Jan '07

16 Jan '07

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.

1 0

(ITS#4806) allow internal operations to require more specific access privileges
by ando＠sys-net.it 16 Jan '07

16 Jan '07

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.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs