Re: (ITS#6393) test045-syncreplication-proxied for bdb: ldapsearch failed at slave (32)!
by quanah＠zimbra.com
--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
14 years
Re: (ITS#6392) olcAuthIDRewrite handler exited with 1
by quanah＠zimbra.com
--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
14 years
(ITS#6393) test045-syncreplication-proxied for bdb: ldapsearch failed at slave (32)!
by michael＠stroeder.com
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)!
14 years
Re: (ITS#6390) test020 seg faults
by michael＠stroeder.com
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.
14 years
(ITS#6392)
by wgillespie＠es2eng.com
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--
14 years
(ITS#6392)
by wgillespie＠es2eng.com
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?
14 years
(ITS#6392) olcAuthIDRewrite handler exited with 1
by wgillespie＠es2eng.com
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.
14 years
Re: (ITS#6390) test020 seg faults
by quanah＠zimbra.com
--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
14 years
Re: (ITS#6390) test020 seg faults
by michael＠stroeder.com
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.
14 years
