openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

Re: (ITS#6641) Syncrepl failure with 'overlay unique'
by ondrej.kuznik＠acision.com 29 Nov '10

29 Nov '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/09/2010 03:50 PM, ondrej.kuznik(a)acision.com wrote: > On 09/07/2010 03:26 PM, andrew.findlay(a)skills-1st.co.uk wrote: >> It would certainly help to keep the apparent promises made by things >> like the uniqueness overlay. Alternatively you could take the view >> that the data will converge eventually and that is all that the LDAP >> standards promise. > > We've hit a similar problem and decided to go this way, i.e. allowing > the replication to bypass the uniqueness constraints. > > [...] > > I have put a preliminary version of patches that modify the unique > overlay here > ftp://ftp.openldap.org/incoming/ondrej-kuznik-20101109-unique_bypass_v1.tgz > > [...] > > Howard and/or others, do you consider this solution valid for this ITS? > If yes, could you help me address the things that should be sorted out? > Hi, I am resurrecting this ITS since there has been no comment on the idea since, nor has it been explicitly rejected by anyone. Does it seem valid to you? If so, could you spare a pointer or two to help me resolve some of the issues with the patch I have pointed out so that I can make it more fit for inclusion? Regards, Ondrej Kuznik -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzzx1gACgkQ9GWxeeH+cXuhQACcCQVydbRBhQJqhONrgeqwXLQ8 xwwAnj0NBBBY3xkazS+QfBRKB/GVGFHm =ZYQI -----END PGP SIGNATURE----- This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

1 0

Re: RE : (ITS#6720) back-ldap core dump
by masarati＠aero.polimi.it 29 Nov '10

29 Nov '10

olivier.chirossel(a)sfr.com wrote: > Thanks for the report. I've reproduced the bug; it appears to be inside=20 > slapo-rwm(5). The core dump is related to a double free, which I'm=20 > trying to track. Please test the latest commit of overlays/rwm.c (should apply fine to 2.4.23) and report. It fixes the double free. With respect to your problem description, "lastmod off" means that the backend will not *generate* modification-related operational attributes; however they are proxied. Moreover, you can't strip them off with mapping unless the remapping is part of a replication process (i.e. the backend contains syncrepl or "updatedn" is set and the operation is performed with that identity). p.

1 0

RE: RE : (ITS#6720) back-ldap core dump
by olivier.chirossel＠sfr.com 29 Nov '10

29 Nov '10

Thank's for your time, the write can't be stop, i have to reinstall all the replica , and my plann= ing, for the second step, take 3 months ... Regards, Olivier -----Message d'origine----- De=A0: Pierangelo Masarati [mailto:masarati@aero.polimi.it]=20 Envoy=E9=A0: lundi 29 novembre 2010 15:21 =C0=A0: CHIROSSEL, Olivier Cc=A0: openldap-its(a)openldap.org Objet=A0: Re: RE : (ITS#6720) back-ldap core dump olivier.chirossel(a)sfr.com wrote: > Thank's for you reply, >=20 > you can get a tar file containing a simple case which reproduce the probl= em=3D > here ( i don't put rewriting rules in proxy conf, just strip of operati= on=3D > nal attribut ) >=20 > wget http://olivier:its6720@84.103.237.12/its6720.tar >=20 >=20 > the lance.sh inititialise the tests=3D20 > (the slapd suppose to be in /usr/local/libexec) >=20 > and you reproduce it with the command : >=20 > ldapmodify -D "cn=3D3Dmanager,dc=3D3Dneuf,dc=3D3Dfr" -H "ldap://127.0.0.1= :489" -=3D > w secret -f mod >=20 > i try to explain you my need=3D20 >=20 > 1) For the moment i have a master in 2.3.x with many replica in 2.3.x wit= h =3D > slurpd replication >=20 > 2) my goal is to migrate to a mirror mode master infrastructure with sync= re=3D > pl replication >=20 > 3) the first step is to install my mirror mode infrastructure and replica= te=3D > with slurpd from my old master. >=20 > 4) second step re install replica one by one with syncrepl replication to= m=3D > y new mirror mode infrastructure >=20 > 5) third step write directly to my mirror mode infrastructure >=20 > For the first step i put a proxy ldap between my old master and my mirror= m=3D > ode infrastructure to do rewrite rules and strip operationnal attribut (i= n=3D > eed, at the end, have a new clean infrastructure with entryCSN contains = th=3D > e ServerId of my new master, for checks the replcation status between my = ma=3D > ster and between my replica and my mirror mode architcture) > =3D20 > The ldapmodify command reproduce the replication operations which highlig= ht=3D > the problem.. >=20 > PS:=3DA0before strip attribute with rwm-map directives i try to put "last= mod =3D > off" in proxy ldap configuration without success ... Thanks for the report. I've reproduced the bug; it appears to be inside=20 slapo-rwm(5). The core dump is related to a double free, which I'm=20 trying to track. In any case, since as far as I understand the only reason you need=20 slapo-rwm(5) is to modify data during the migration, you should probably=20 do it offline, after exporting your data and before importing in the new=20 system. p.

1 0

Re: RE : (ITS#6720) back-ldap core dump
by masarati＠aero.polimi.it 29 Nov '10

29 Nov '10

olivier.chirossel(a)sfr.com wrote: > Thank's for you reply, > > you can get a tar file containing a simple case which reproduce the problem= > here ( i don't put rewriting rules in proxy conf, just strip of operation= > nal attribut ) > > wget http://olivier:its6720@84.103.237.12/its6720.tar > > > the lance.sh inititialise the tests=20 > (the slapd suppose to be in /usr/local/libexec) > > and you reproduce it with the command : > > ldapmodify -D "cn=3Dmanager,dc=3Dneuf,dc=3Dfr" -H "ldap://127.0.0.1:489" -= > w secret -f mod > > i try to explain you my need=20 > > 1) For the moment i have a master in 2.3.x with many replica in 2.3.x with = > slurpd replication > > 2) my goal is to migrate to a mirror mode master infrastructure with syncre= > pl replication > > 3) the first step is to install my mirror mode infrastructure and replicate= > with slurpd from my old master. > > 4) second step re install replica one by one with syncrepl replication to m= > y new mirror mode infrastructure > > 5) third step write directly to my mirror mode infrastructure > > For the first step i put a proxy ldap between my old master and my mirror m= > ode infrastructure to do rewrite rules and strip operationnal attribut (i n= > eed, at the end, have a new clean infrastructure with entryCSN contains th= > e ServerId of my new master, for checks the replcation status between my ma= > ster and between my replica and my mirror mode architcture) > =20 > The ldapmodify command reproduce the replication operations which highlight= > the problem.. > > PS:=A0before strip attribute with rwm-map directives i try to put "lastmod = > off" in proxy ldap configuration without success ... Thanks for the report. I've reproduced the bug; it appears to be inside slapo-rwm(5). The core dump is related to a double free, which I'm trying to track. In any case, since as far as I understand the only reason you need slapo-rwm(5) is to modify data during the migration, you should probably do it offline, after exporting your data and before importing in the new system. p.

1 0

Re: (ITS#6532) Support for common orderingMatching rules in extensible match filters
by h.b.furuseth＠usit.uio.no 28 Nov '10

28 Nov '10

BTW, it occurred to me that it might be an idea to add comments instead of removing yours. slapd/schema_init.c (rev 1.474) now explains how it works, as far as I understand it. -- Hallvard

1 0

Re: (ITS#6727) ./scripts/test047-ldap: line 599: 26709 Segmentation fault
by michael＠stroeder.com 28 Nov '10

28 Nov '10

Now I got running this test: "WhoAmI failed (34)!" See gdb output below. I could provide content of testrun/ if necessary. $ ./run -b bdb -l 30 test047 Cleaning up test run directory leftover from previous run. Running ./scripts/test047-ldap for bdb... Running 1 of 30 iterations running defines.sh Starting slapd on TCP/IP port 9011... Using ldapsearch to check that slapd is running... Using ldapadd to populate the database... Starting slapd on TCP/IP port 9012... Using ldapsearch to check that slapd is running... Using ldapadd to populate the database... Starting slapd on TCP/IP port 9013... Using ldapsearch to check that slapd is running... Searching base="o=Example,c=US"... Searching base="ou=Meta,o=Example,c=US"... Modifying database "o=Example,c=US"... Searching base="o=Example,c=US"... base="o=Example,c=US"... Searching filter="(seeAlso=cn=all staff,ou=Groups,o=Example,c=US)" attrs="seeAlso" base="o=Example,c=US"... Searching filter="(uid=example)" attrs="uid" base="o=Example,c=US"... Searching filter="(member=cn=Another Added Group,ou=Groups,o=Example,c=US)" attrs="member" base="o=Example,c=US"... Waiting 10 seconds for cached connections to timeout... Searching with a timed out connection... Checking server-enforced size limit... Checking client-requested size limit... Filtering ldapsearch results... Filtering original ldif used to create database... Comparing filter output... Changing password to database "o=Example,c=US"... Binding with newly changed password to database "o=Example,c=US"... Binding as newly added user to database "o=Example,c=US"... WhoAmI failed (34)! (gdb) info threads * 1 Thread 31230 0x00007f9e739109e5 in raise () from /lib64/libc.so.6 (gdb) thread apply all bt Thread 1 (Thread 31230): #0 0x00007f9e739109e5 in raise () from /lib64/libc.so.6 #1 0x00007f9e73911ee6 in abort () from /lib64/libc.so.6 #2 0x00007f9e73909235 in __assert_fail () from /lib64/libc.so.6 #3 0x0000000000475d13 in at_delete_names () at at.c:242 #4 at_destroy () at at.c:323 #5 0x000000000046fef3 in schema_destroy () at schema_init.c:6768 #6 0x000000000040ad0f in main (argc=<value optimized out>, argv=<value optimized out>) at main.c:1037

1 0

Re: (ITS#6727) ./scripts/test047-ldap: line 599: 26709 Segmentation fault
by michael＠stroeder.com 28 Nov '10

28 Nov '10

It seems this only happens occasionally. I'll try to get a stack trace...

1 0

(ITS#6727) ./scripts/test047-ldap: line 599: 26709 Segmentation fault
by michael＠stroeder.com 28 Nov '10

28 Nov '10

Full_Name: Michael Ströder Version: HEAD OS: openSUSE Linux URL: Submission from: (NULL) (84.163.34.72) >>>>> Starting test047-ldap for bdb... running defines.sh Starting slapd on TCP/IP port 9011... Using ldapsearch to check that slapd is running... Using ldapadd to populate the database... Starting slapd on TCP/IP port 9012... Using ldapsearch to check that slapd is running... Using ldapadd to populate the database... Starting slapd on TCP/IP port 9013... Using ldapsearch to check that slapd is running... Searching base="o=Example,c=US"... Searching base="ou=Meta,o=Example,c=US"... Modifying database "o=Example,c=US"... Searching base="o=Example,c=US"... base="o=Example,c=US"... Searching filter="(seeAlso=cn=all staff,ou=Groups,o=Example,c=US)" attrs="seeAlso" base="o=Example,c=US"... Searching filter="(uid=example)" attrs="uid" base="o=Example,c=US"... Searching filter="(member=cn=Another Added Group,ou=Groups,o=Example,c=US)" attrs="member" base="o=Example,c=US"... Waiting 10 seconds for cached connections to timeout... Searching with a timed out connection... Checking server-enforced size limit... Checking client-requested size limit... Filtering ldapsearch results... Filtering original ldif used to create database... Comparing filter output... Changing password to database "o=Example,c=US"... Binding with newly changed password to database "o=Example,c=US"... Binding as newly added user to database "o=Example,c=US"... ./scripts/test047-ldap: line 599: 26709 Segmentation fault $SLAPD -f $CONF3 -h $URI3 -d $LVL $TIMING > $LOG3 2>&1 WhoAmI failed (255)! ./scripts/test047-ldap: line 614: kill: (26709) - No such process >>>>> ./scripts/test047-ldap failed for bdb (exit 255) make[2]: *** [bdb-yes] Error 255 make[2]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' make: *** [test] Error 2

1 0

RE : (ITS#6720) back-ldap core dump
by olivier.chirossel＠sfr.com 26 Nov '10

26 Nov '10

Hi Thank's for you reply, you can get a tar file containing a simple case which reproduce the problem= here ( i don't put rewriting rules in proxy conf, just strip of operation= nal attribut ) wget http://olivier:its6720@84.103.237.12/its6720.tar the lance.sh inititialise the tests=20 (the slapd suppose to be in /usr/local/libexec) and you reproduce it with the command : ldapmodify -D "cn=3Dmanager,dc=3Dneuf,dc=3Dfr" -H "ldap://127.0.0.1:489" -= w secret -f mod i try to explain you my need=20 1) For the moment i have a master in 2.3.x with many replica in 2.3.x with = slurpd replication 2) my goal is to migrate to a mirror mode master infrastructure with syncre= pl replication 3) the first step is to install my mirror mode infrastructure and replicate= with slurpd from my old master. 4) second step re install replica one by one with syncrepl replication to m= y new mirror mode infrastructure 5) third step write directly to my mirror mode infrastructure For the first step i put a proxy ldap between my old master and my mirror m= ode infrastructure to do rewrite rules and strip operationnal attribut (i n= eed, at the end, have a new clean infrastructure with entryCSN contains th= e ServerId of my new master, for checks the replcation status between my ma= ster and between my replica and my mirror mode architcture) =20 The ldapmodify command reproduce the replication operations which highlight= the problem.. PS:=A0before strip attribute with rwm-map directives i try to put "lastmod = off" in proxy ldap configuration without success ... Regards, Olivier ________________________________________ De : openldap-its(a)OpenLDAP.org [openldap-its(a)OpenLDAP.org] Date d'envoi : lundi 22 novembre 2010 17:43 =C0 : CHIROSSEL, Olivier Objet : Re: (ITS#6720) back-ldap core dump *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System. Your report has been assigned the tracking number ITS#6720. One of our support engineers will look at your report in due course. Note that this may take some time because our support engineers are volunteers. They only work on OpenLDAP when they have spare time. If you need to provide additional information in regards to your issue report, you may do so by replying to this message. Note that any mail sent to openldap-its(a)openldap.org with (ITS#6720) in the subject will automatically be attached to the issue report. mailto:openldap-its@openldap.org?subject=3D(ITS#6720) You may follow the progress of this report by loading the following URL in a web browser: http://www.OpenLDAP.org/its/index.cgi?findid=3D6720 Please remember to retain your issue tracking number (ITS#6720) on any further messages you send to us regarding this report. If you don't then you'll just waste our time and yours because we won't be able to properly track the report. Please note that the Issue Tracking System is not intended to be used to seek help in the proper use of OpenLDAP Software. Such requests will be closed. OpenLDAP Software is user supported. http://www.OpenLDAP.org/support/ -------------- Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.

1 0

Re: (ITS#6724) Feature request: support for PKCS11 pin input callback in public TLS api
by hyc＠symas.com 26 Nov '10

26 Nov '10

silvan(a)kernelconcepts.de wrote: > Full_Name: Silvan Marco Fin > Version: > OS: Ubuntu Linux 10.04 > URL: > Submission from: (NULL) (217.146.132.69) > > > Support for PKCS #11 devices in TLS via MozNSS in OpenLDAP currently lacks the > possibility to "ask" for a PIN via callback. The methods supplied in tls_m.c are > reading a PIN from a file or alternativly reading a PIN from STDIN. > > To add the needed flexibility to the MozNSS part, an additional callback > argument to the init function or alternatively an additional set function for > the callback would be needed. > > http://www.mozilla.org/projects/security/pki/nss/ref/ssl/pkfnc.html#1023128 > > provides the signature for the callback function. > > Since GnuTLS and OpenSSL provide PKCS #11 support by themselves in some way, I > propose to add an additional set function to OpenLDAPs public TLS API to > register a callback with the corresponding security library. > Probably a good idea. Feel free to submit a patch for review. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

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