openldap-bugs November 2009

openldap-bugs@openldap.org

40 participants
183 discussions

Re: (ITS#6393) test045-syncreplication-proxied for bdb: ldapsearch failed at slave (32)!
by quanah＠zimbra.com 21 Nov '09

21 Nov '09

--On Saturday, November 21, 2009 1:20 PM +0000 michael(a)stroeder.com wrote: > Full_Name: Michael Str?der > Version: HEAD > OS: openSUSE Linux 11.2 (x86_64) > URL: > Submission from: (NULL) (84.163.70.93) As I noted yesterday, constant changes were ongoing in HEAD. Please re-sync your sources and try now, I think Howard's done with what he was doing. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6392) olcAuthIDRewrite handler exited with 1
by quanah＠zimbra.com 21 Nov '09

21 Nov '09

--On Saturday, November 21, 2009 3:22 AM +0000 wgillespie(a)es2eng.com wrote: > Full_Name: Willie Gillespie > Version: 2.4.X (from CVS) > OS: Ubuntu 9.10 x64 > URL: > Submission from: (NULL) (208.47.173.116) Please update your CVS RE24 checkout and test. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6393) test045-syncreplication-proxied for bdb: ldapsearch failed at slave (32)!
by michael＠stroeder.com 21 Nov '09

21 Nov '09

Full_Name: Michael Ströder Version: HEAD OS: openSUSE Linux 11.2 (x86_64) URL: Submission from: (NULL) (84.163.70.93) Running ./scripts/test045-syncreplication-proxied for bdb... running defines.sh Starting master slapd on TCP/IP port 9011... Using ldapsearch to check that master slapd is running... Using ldapadd to create the context prefix entry in the master... Starting slave slapd on TCP/IP port 9012... Using ldapsearch to check that slave slapd is running... Starting proxy slapd on TCP/IP port 9013... Using ldapsearch to check that proxy slapd is running... 1 > Using ldapadd to populate the master directory... Waiting 7 seconds for syncrepl to receive changes... Waiting 7 seconds for syncrepl to receive changes... Waiting 7 seconds for syncrepl to receive changes... 1 < Comparing retrieved entries from master and slave... 2 > Stopping the provider, sleeping 15 seconds and restarting it... Using ldapsearch to check that master slapd is running... Using ldapmodify to modify master directory... Waiting 7 seconds for syncrepl to receive changes... ldapsearch failed at slave (32)!

1 0

Re: (ITS#6390) test020 seg faults
by michael＠stroeder.com 21 Nov '09

21 Nov '09

quanah(a)zimbra.com wrote: > --On Friday, November 20, 2009 11:29 PM +0000 michael(a)stroeder.com wrote: > >> I think this is the right issue since Howard wrote to me: >>> Your source seems to be corrupt or out of date. There is no call to >>> memrchr anywhere near line 2889 in syncrepl.c > > > This has been fixed in RE24, please try now. :) Seems to be ok now (100 test runs) Ciao, Michael.

1 0

Re: (ITS#6392)
by hyc＠symas.com 21 Nov '09

21 Nov '09

wgillespie(a)es2eng.com wrote: > I tracked down the bug by going through the source code. > Any way I can help with any of this? It's already been fixed in CVS, a few hours ago. -- -- 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

(ITS#6392)
by wgillespie＠es2eng.com 21 Nov '09

21 Nov '09

This is a multi-part message in MIME format. --------------040503050400050604020005 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Okay, so apparently it was a little easier to code than I anticipated. The supplied patch removes the error message I was seeing. Whether or not authid-rewrite actually works is a different question which I have yet to figure out. The second patch (for config.c) isn't directly related to this bug, but would be nice. I've never done a patch before, so I have no idea if I created these correctly. I used the command: diff -c oldfile newfile > file.diff Is this the proper way to do that? --------------040503050400050604020005 Content-Type: text/x-patch; name="config.c.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="config.c.diff" *** config.c 2009-01-21 17:00:58.000000000 -0700 --- config.c.new 2009-11-21 00:56:08.000000000 -0700 *************** *** 288,294 **** } else { Debug( LDAP_DEBUG_ANY, "[%s:%d] unknown command '%s'\n", ! fname, lineno, "" ); return -1; } --- 288,294 ---- } else { Debug( LDAP_DEBUG_ANY, "[%s:%d] unknown command '%s'\n", ! fname, lineno, argv[0] ); return -1; } --------------040503050400050604020005 Content-Type: text/x-patch; name="saslauthz.c.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="saslauthz.c.diff" *** saslauthz.c 2009-01-21 17:01:03.000000000 -0700 --- saslauthz.c.new 2009-11-21 00:52:15.000000000 -0700 *************** *** 1284,1289 **** --- 1284,1290 ---- ) { int rc; + int i; char *savearg0; /* init at first call */ *************** *** 1291,1300 **** sasl_rwinfo = rewrite_info_init( REWRITE_MODE_USE_DEFAULT ); } - /* strip "authid-" prefix for parsing */ savearg0 = argv[0]; argv[0] += STRLENOF( "authid-" ); rc = rewrite_parse( sasl_rwinfo, fname, lineno, argc, argv ); argv[0] = savearg0; return rc; --- 1292,1310 ---- sasl_rwinfo = rewrite_info_init( REWRITE_MODE_USE_DEFAULT ); } savearg0 = argv[0]; + /* temporarily shift argv to get rid of argv[0] */ + for ( i = 1; i <= argc; i++ ) { + argv[i-1] = argv[i]; + } + argc--; + /* strip "authid-" prefix for parsing */ argv[0] += STRLENOF( "authid-" ); rc = rewrite_parse( sasl_rwinfo, fname, lineno, argc, argv ); + argc++; + for ( i = argc; i >= 1; i-- ) { + argv[i] = argv[i-1]; + } argv[0] = savearg0; return rc; --------------040503050400050604020005--

1 0

(ITS#6392)
by wgillespie＠es2eng.com 20 Nov '09

20 Nov '09

I tracked down the bug by going through the source code. Basically, slap_sasl_rewrite_config() in servers/slapd/saslauthz.c passes the information to rewrite_parse() in libraries/librewrite/config.c. However, what slap_sasl_rewrite_config() sends is NOT what rewrite_parse() expects to get. It looks like rewrite_parse is a generic function which is called all over the place. Probably not best to mess with that. However, slap_sasl_rewrite_config() is only called from servers/slapd/bconfig.c, so any changes could take place in either of those two places relatively easily. Anyway, what slap_sasl_rewrite_config has in my little test: fname = "slapd" lineno = 0 argc = 3 argv[0] = "olcAuthIDRewrite" argv[1] = "authid-rewriteEngine" argv[2] = "on" In rewrite_parse(), it expects it to be set up more like this: fname = "slapd" lineno = 0 argc = 2 argv[0] = "rewriteEngine" argv[1] = "on" So all that needs to happen in slap_sasl_rewrite_config() is: argc--; and Get rid of argv[0] and shift everything down in the array (1 ==> 0, 2 ==> 1, etc.) (?and then put it all back when finished?) Anyway, I'm not sure how to do that, so the most I can really help out here is by filing this report so you don't have to spend your time tracking down the issue. Second note: it would have helped with debugging had a particular debug command been properly finished. See libraries/librewrite/config.c, line 289-291. The debug command has the %s placeholder for the third argument, but is passed "" instead of something more useful like: argv[0]. Probably just a little oversight. Any way I can help with any of this?

1 0

(ITS#6392) olcAuthIDRewrite handler exited with 1
by wgillespie＠es2eng.com 20 Nov '09

20 Nov '09

Full_Name: Willie Gillespie Version: 2.4.X (from CVS) OS: Ubuntu 9.10 x64 URL: Submission from: (NULL) (208.47.173.116) Modify the attribute olcAuthIDRewrite in cn=config and you get: conn=0 op=7 RESULT tag=103 err=80 text=<olcAuthIDRewrite> handler exited with 1 It seems to do this with 2.4.18 and 2.4.19 as well as the version I downloaded from the CVS tonight (2009-11-20). If others don't seem to have the same problem, I'd be happy to list more information about my setup. This is my first ITS bug, so if you need more info about something, let me know and I can provide.

1 0

Re: (ITS#6390) test020 seg faults
by quanah＠zimbra.com 20 Nov '09

20 Nov '09

--On Friday, November 20, 2009 11:29 PM +0000 michael(a)stroeder.com wrote: > I think this is the right issue since Howard wrote to me: >> Your source seems to be corrupt or out of date. There is no call to >> memrchr anywhere near line 2889 in syncrepl.c This has been fixed in RE24, please try now. :) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6390) test020 seg faults
by michael＠stroeder.com 20 Nov '09

20 Nov '09

quanah(a)zimbra.com wrote: > --On Friday, November 20, 2009 3:53 PM +0000 quanah(a)zimbra.com wrote: > >> --On Friday, November 20, 2009 12:35 PM +0000 rhafer(a)suse.de wrote: >> >>> Hm, I get the following warning during the make run: >>> >>> =2E./../../servers/slapd/syncrepl.c:2861 is: >>> comma =3D ber_bvrchr( &ptr, ',' ); >>> with ber_bvrchr being a macro around memrchr(). So it seems that >>> memrchr() = is=20 >>> undefined in syncrepl.c. >> >> Please don't add secondary issues to an ITS. File a new one. > > Unless you're saying that is the issue, which isn't clear to me in what you > wrote. :P I think this is the right issue since Howard wrote to me: > Your source seems to be corrupt or out of date. There is no call to memrchr > anywhere near line 2889 in syncrepl.c Ciao, Michael.

1 0

← Newer
1
2
3
4
5
6
7
8
...
19
Older →

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 November 2009