(ITS#6405) test043-delta-syncrepl failed - producer and consumer databases differ
by michael@stroeder.com
Full_Name: Michael Ströder
Version: 2.4.20
OS: SLES 10
URL:
Submission from: (NULL) (84.163.87.167)
SLES 10 32 Bit
gcc version 4.1.0 (SUSE Linux)
BDB 4.8
>>>>> Starting test043-delta-syncrepl for bdb...
running defines.sh
Starting producer slapd on TCP/IP port 9011...
Using ldapsearch to check that producer slapd is running...
Using ldapadd to create the context prefix entries in the producer...
Starting consumer slapd on TCP/IP port 9012...
Using ldapsearch to check that consumer slapd is running...
Using ldapadd to populate the producer directory...
Waiting 7 seconds for syncrepl to receive changes...
Stopping the provider, sleeping 10 seconds and restarting it...
Using ldapsearch to check that producer slapd is running...
Using ldapmodify to modify producer directory...
Waiting 7 seconds for syncrepl to receive changes...
Stopping consumer to test recovery...
Modifying more entries on the producer...
Restarting consumer...
Waiting 7 seconds for syncrepl to receive changes...
Try updating the consumer slapd...
Waiting 7 seconds for syncrepl to receive changes...
Using ldapsearch to read all the entries from the producer...
Using ldapsearch to read all the entries from the consumer...
Filtering producer results...
Filtering consumer results...
Comparing retrieved entries from producer and consumer...
test failed - producer and consumer databases differ
>>>>> ./scripts/test043-delta-syncrepl failed for bdb (exit 1)
make[2]: *** [bdb-mod] Error 1
make[2]: Leaving directory `/source/openldap-2.4.20/tests'
make[1]: *** [test] Error 2
make[1]: Leaving directory `/source/openldap-2.4.20/tests'
make: *** [test] Error 2
13 years, 6 months
Re: (ITS#6270) Conflict between ppolicy (pwdReset flag) and unique overlays
by hyc@symas.com
clem.oudot(a)gmail.com wrote:
> Full_Name: Clement OUDOT
> Version: 2.4.16
> OS: RHEL 5.2
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (83.145.72.122)
>
>
> Hello,
>
> I use both ppolicy and unique overlays.
>
> I try to modify the password of an account whose pwdReset attribute is set to
> TRUE. I get this LDAP error:
>
> ldap_modify: Insufficient access (50)
> additional info: unique_search failed
>
> In OpenLDAP logs, we can see:
>
> connection restricted to password changing only
> send_ldap_result: conn=20 op=2 p=3
> send_ldap_result: err=50 matched="" text="Operations are restricted to
> bind/unbind/abandon/StartTLS/modify password"
> send_ldap_result: conn=20 op=2 p=3
> send_ldap_result: err=50 matched="" text="unique_search failed"
> send_ldap_response: msgid=3 tag=103 err=50
>
>
> So it seems the unique overlay cannot do a search because the connection is
> restricted by the ppolicy overlay.
Given the configuration you provided, this should now be fixed with the
unique.c in CVS HEAD.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
13 years, 6 months
(ITS#6404) tests return success on failure
by h.b.furuseth@usit.uio.no
Full_Name: Hallvard B Furuseth
Version: HEAD, RE24
OS:
URL:
Submission from: (NULL) (129.240.6.233)
Submitted by: hallvard
Some tests exit with the result code of the last failed command,
even when that is 0 (success) and the command should have failed:
if test $RC != 10 ; then
echo "ldapmodify should have returned referral ($RC)!"
test $KILLSERVERS != no && kill -HUP $KILLPIDS
exit 1
fi
Fixing most cases I've spotted.
However someone who knows pcache should look at test020-proxycache.
It has 'exit 0's which look intentional, some which look like errors
(says "should have failed"), and some 'return $RC's which RC can be 0.
13 years, 6 months
(ITS#6403) crash with translucent + back-null
by h.b.furuseth@usit.uio.no
Full_Name: Hallvard B Furuseth
Version: HEAD
OS: Linux
URL:
Submission from: (NULL) (129.240.6.233)
Submitted by: hallvard
Callers of bi->bi_entry_get_rw(,,,,,Entry **ent) should set *ent = NULL.
Translucent doesn't. null_back_entry_get() assert()s it. Crash.
Happens with ./run -b null test034-translucent.
I'll fix translucent for now, but I assume a saner fix would be to
change that "calling convention" - which I suspect exists in the first
place because I once gave a bug just like this the same minimal fix.
13 years, 6 months
Re: (ITS#6402) Mismatched parentheses in LBER_INVALID macro
by h.b.furuseth@usit.uio.no
julianfoad(a)btopenworld.com writes:
> The definition of the macro LBER_INVALID in 'include/lber.h' has
> mismatched (unbalanced) parentheses, meaning that it cannot be used as
> a valid C expression by itself.
Wow. You are the first to notice for 10 years. The test is incomplete
too. I guess I can come up with bit hack for a better test is anyone is
interested, but otherwise we can just delete it.
The macro only existed without a parse error for one month in 1999, in
revision 1.17 through 1.30. Next revision broke it with commit message
"Fix bad LBER_INVALID macro":-)
--
Hallvard
13 years, 6 months
(ITS#6402) Mismatched parentheses in LBER_INVALID macro
by julianfoad@btopenworld.com
Full_Name: Julian Foad
Version: CVS head (include/lber.h r1.111)
OS: Linux
URL: ftp://ftp.openldap.org/incoming/julian-foad-091127.patch
Submission from: (NULL) (217.169.20.120)
The definition of the macro LBER_INVALID in 'include/lber.h' has mismatched
(unbalanced) parentheses, meaning that it cannot be used as a valid C expression
by itself.
This error was noticed when parsing the file with 'ctypesgen' as part of
building the ctypes-python bindings of Subversion.
The patch to fix it, in Unidiff format, looks like this:
#define LBER_INVALID(t) (((t) & (ber_tag_t) 0x080UL) \
- && (((t) & (ber_tag_t) ~ 0x0FF))
+ && ((t) & (ber_tag_t) ~ 0x0FF))
I uploaded the patch file; URL is filled in below.
The macro is not used within the openldap source, so this problem and this fix
makes no difference to the building and testing of openldap itself.
13 years, 6 months