Re: (ITS#6963) test050: test failed - server 1 and server 2 configs differ
by hyc@symas.com
michael(a)stroeder.com wrote:
> BTW: This is git master (formerly known as HEAD).
>
> See also: http://www.stroeder.com/temp/openldap-its-6963-testrun.tar.gz
I see, and I was also able to reproduce it here. The difference is that on
server2, 2 of the entries have objectClass: glue instead of their correct
objectclasses. From the diffs, this affected cn=schema,cn=config and
olcDatabase={0}config,cn=config. Looking at the logs, this happened because
during a syncrepl_nonpresent pass, the UUIDs for these two entries didn't
match the UUIDs sent from some other master, so syncrepl attempted to delete them.
Generally this is normal - cn=schema,cn=config and olcDatabase={0},cn=config
are always created automatically by each slapd, so naturally their UUIDs
differ on each server. But, also generally, after the first refresh each
consumer would modify their local entries and overwrite the UUIDs with the
ones received from their provider. Not sure why this didn't happen this time
around.
(back-config explicitly prevents any attempts to delete both of these entries.
When syncrepl fails to delete an entry, it does a modify to change the
objectclass to glue, which explains how they got to their final state when the
test aborted.)
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
12 years, 6 months
(ITS#6963) test050: test failed - server 1 and server 2 configs differ
by michael@stroeder.com
Full_Name:
Version:
OS:
URL:
Submission from: (NULL) (84.163.63.172)
test050 occasionally fails...
$ ./run -l 100 -b bdb test050
[..]
Cleaning up test run directory from this run.
Running 19 of 100 iterations
running defines.sh
Initializing server configurations...
Starting server 1 on TCP/IP port 9011...
Using ldapsearch to check that server 1 is running...
Inserting syncprov overlay on server 1...
Starting server 2 on TCP/IP port 9012...
Using ldapsearch to check that server 2 is running...
Configuring syncrepl on server 2...
Starting server 3 on TCP/IP port 9013...
Using ldapsearch to check that server 3 is running...
Configuring syncrepl on server 3...
Starting server 4 on TCP/IP port 9014...
Using ldapsearch to check that server 4 is running...
Configuring syncrepl on server 4...
Adding schema and databases on server 1...
Using ldapadd to populate server 1...
Waiting 15 seconds for syncrepl to receive changes...
Using ldapsearch to read config from server 1...
Using ldapsearch to read config from server 2...
Using ldapsearch to read config from server 3...
Using ldapsearch to read config from server 4...
Comparing retrieved configs from server 1 and server 2...
test failed - server 1 and server 2 configs differ
12 years, 6 months
Re: (ITS#6947) ldapadd crashes with LDIFs with invalid line termination
by jvcelak@redhat.com
> > adding entries to LDAP database from file using ldapadd tool causes
> > memory
> > corruption error, when the last line of the input file is not
> > terminated by '\n'
> > character.
>
> Don't do that.
I agree. But the tool should not crash on invalid output anyway.
> > I am attaching proposed patch, which fixes this issue.
>
> The patch uses a GNU-specific function. Since GLIBC is not supported
> on all of
> the platforms OpenLDAP supports, the patch is not acceptable as-is.
Sorry, I missed that. I will fix it and resend the patch.
Jan
12 years, 6 months
Re: (ITS#6947) ldapadd crashes with LDIFs with invalid line termination
by hyc@symas.com
jvcelak(a)redhat.com wrote:
> Full_Name: Jan Vcelak
> Version: 2.4.25
> OS: Linux
> URL: ftp://ftp.openldap.org/incoming/jvcelak-20110519-ldif-countlines.patch
> Submission from: (NULL) (209.132.186.34)
>
>
> Hello,
>
> adding entries to LDAP database from file using ldapadd tool causes memory
> corruption error, when the last line of the input file is not terminated by '\n'
> character.
Don't do that.
The LDIF specification says that all LDIF elements are terminated by SEP (CR
LF or LF). Anything not conforming to this is not valid LDIF. As usual,
garbage-in-garbage-out.
The entries are added correctly.
>
> All version since 2.4.23 are affected.
>
> $ cat>/tmp/input.ldif<< EOF
>> dn: cn=A,dc=my-domain,dc=com
>> objectClass: inetOrgPerson
>> objectClass: organizationalPerson
>> objectClass: person
>> objectClass: top
>> cn: A
>> sn: A
>> uid: A
>> mail: A(a)example.com
>> EOF
> $ wc -c /tmp/input.ldif
> 166 /tmp/input.ldif
> $ truncate -s 165 /tmp/input.ldif
> $ hexdump -c /tmp/input.ldif
> 0000000 d n : c n = A , d c = m y - d
> 0000010 o m a i n , d c = c o m \n o b j
> 0000020 e c t C l a s s : i n e t O r
> 0000030 g P e r s o n \n o b j e c t C l
> 0000040 a s s : o r g a n i z a t i o
> 0000050 n a l P e r s o n \n o b j e c t
> 0000060 C l a s s : p e r s o n \n o b
> 0000070 j e c t C l a s s : t o p \n c
> 0000080 n : A \n s n : A \n u i d :
> 0000090 A \n m a i l : A @ e x a m p l
> 00000a0 e . c o m
> 00000a5
> $ ldapadd -H ldap:// -D cn=Manager,dc=my-domain,dc=com -x -w password -f
> /tmp/input.ldif
> adding new entry "cn=A,dc=my-domain,dc=com"
>
> *** glibc detected *** ldapadd: free(): invalid pointer: 0x0000000001c435c8 ***
> ======= Backtrace: =========
> /lib64/libc.so.6[0x3626e76d63]
> ldapadd[0x404505]
> /lib64/libc.so.6(__libc_start_main+0xfd)[0x3626e1ee5d]
> ldapadd[0x4037e9]
> ======= Memory map: ========
> ...
>
> I am attaching proposed patch, which fixes this issue.
The patch uses a GNU-specific function. Since GLIBC is not supported on all of
the platforms OpenLDAP supports, the patch is not acceptable as-is.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
12 years, 6 months
Re: (ITS#6831) Proxycache database corruption
by hyc@symas.com
ryans(a)aweber.com wrote:
> Some more information: once I changed the search base from ou=Users,dc=example,dc=com to dc=example,dc=com to "fix" the
> problem for that particular user (after which the original query with the ou=Users,dc=example,dc=com search base began
> working again), the following entries popped up in the log:
> ftp://ftp.openldap.org/incoming/ryan-steele-110221.proxycache-log-fixing-...
>
> It gets stranger, though. If I start out by using the root entry as the search base (dc=example,dc=com) with a user who
> is not yet in the cache, not only will it say it is ANSWERABLE (which it clearly isn't) and then return nothing without
> even trying to reach out to the upstream host, but if I then change the search base to ou=Users,dc=example,dc=com, I get
> the following error on the CLI (and this is with a successful bind as the directory admin):
>
>
> ldapsearch -x -D cn=admin,dc=example,dc=com -y /etc/ldap.secret -H ldaps://localhost -LLL -b cn=admin,dc=example,dc=com
> '(&(|(objectClass=examplecomUtilityUser)(objectClass=examplecomEmployee))(uid=jdoe4))' uid
> No such object (32)
> Matched DN: dc=example,dc=com
>
> Debugging logs generated by that query can be found here:
> ftp://ftp.openldap.org/incoming/ryan-steele-110221.proxycache-log-attempt...
I'm not sure I reproduced all the behaviors you were seeing, but I've
reproduced at least one of them and fixed it in git. Please pull the latest
pcache.c and test, thanks.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
12 years, 6 months