Re: (ITS#7065) changeType: modify "replace/delete" trick causes segmentation fault in cn=config
by h.b.furuseth@usit.uio.no
Reproduced in master by trying to change olcSaslHost:
config_modify_internal() does this with a == NULL:
5827 a->a_flags |= SLAP_ATTR_IXADD;
jeffreyc(a)ucsc.edu writes:
> To guarantee the removal of an attribute when I don't know if the attribute
> exists already or not I often employ the following LDIF:
>
> ==============
> dn: cn=config
> changeType: modify
> replace: attrToDelete
> attrToDelete: dummy
> -
> delete: attrToDelete
> ==============
You can use this instead:
dn: cn=config
changeType: modify
replace: attrToDelete
-
--
Hallvard
11 years, 11 months
Re: (ITS#6763) slapd does not clear sr_entry/ctrls on sizelimit/busy
by h.b.furuseth@usit.uio.no
I wrote:
> slap_send_search_entry() does not always free/release the entry and
> call slap_cleanup_play() on error.
>
> slap_send_search_reference() calls slap_cleanup_play(), but does not
> always free/release the entry.
>
> I expect both functions always should do both, but don't know enough
> myself to be sure.
>
> Resolution needed for ITS#6758 (SlapReply) - who should be responsible
> for clearing out the entry?
Nobody else were picking this up, and it was making back-monitor
hang in ITS#7053. So I've made result.c always clean up.
The code is still inconsistent: slap_send_search_entry() may
flush the entry either before or after slap_cleanup_play(),
while slap_send_search_reference() always flushes first.
If anyone feels that should be regularized, feel free. I'm
leaving it alone for now.
--
Hallvard
11 years, 11 months
Re: (ITS#7053) back-monitor blocks
by h.b.furuseth@usit.uio.no
Fixed in master, dup of ITS#6763.
Thank you for the simple test case. The '-z 10' identified the
problem. slap_send_search_entry() did not call rs_flush_entry()
when sizeLimitExceeded. I have not traced exactly what happened,
but I expect this means some back-monitor entry kept its locks.
--
Hallvard
11 years, 11 months
Re: (ITS#7053) back-monitor blocks
by michael@stroeder.com
But just for the records...
Finally I managed to reproduce this with OpenLDAP's ldapsearch command-line
tool. The bound entity needs read access to cn=monitor.
Try this more than one time:
ldapsearch -x -H ldapi://%2Ftmp%2Fopenldap-socket -b "cn=monitor" -z 10 -s one
"(objectClass=*)" cn objectclass
Do this as many times as you have threads configured and slapd becomes
completely unresponsive and has to be stopped by kill -9.
This was tested on my local install under openSUSE 11.4 but also on an
installation running on HP-UX (64 bit build). Both running 2.4.26.
Ciao, Michael.
11 years, 11 months
Re: (ITS#7070) test058-syncrepl-asymmetric failed for hdb
by quanah@zimbra.com
--On Friday, October 21, 2011 6:34 PM +0000 michael(a)stroeder.com wrote:
> hyc(a)symas.com wrote:
>> There's no evidence of an OpenLDAP bug here. All we can see from the
>> testrun/slapd.1.log is that it took 15 seconds for slap_sasl_init to
>> complete, which was long enough for the initial startup check to time
>> out. You need to check your system to see why SASL took so long to
>> initialize, most likely a DNS failure or some other transient issue.
>
> Hmm, this was with a local build of cyrus-sasl 2.1.25 which seg faulted on
> GSSAPI in another test. I will retry with cyrus-sasl package shipped with
> openSUSE 11.4.
There was a patch posted to the cyrus-sasl list the other day for issues
with the gssapi plugin in 2.1.25. It's working fine for me once it is
fixed up.
quanah@zre-ldap001:~/p4/main/ThirdParty/cyrus-sasl/patches$ cat gssapi.patch
--- cyrus-sasl-2.1.25/plugins/gssapi.c.orig 2011-10-07
14:47:07.461866240 -0700
+++ cyrus-sasl-2.1.25/plugins/gssapi.c 2011-10-07 14:47:45.891872589 -0700
@@ -370,7 +370,7 @@
}
if (output_token->value && output) {
- unsigned char * p = (unsigned char *) text->encode_buf;
+ unsigned char * p;
ret = _plug_buf_alloc(text->utils,
&(text->encode_buf),
@@ -384,6 +384,8 @@
return ret;
}
+ p = (unsigned char *) text->encode_buf;
+
p[0] = (output_token->length>>24) & 0xFF;
p[1] = (output_token->length>>16) & 0xFF;
p[2] = (output_token->length>>8) & 0xFF;
--Quanah
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
11 years, 11 months
Re: (ITS#7070) test058-syncrepl-asymmetric failed for hdb
by michael@stroeder.com
hyc(a)symas.com wrote:
> There's no evidence of an OpenLDAP bug here. All we can see from the
> testrun/slapd.1.log is that it took 15 seconds for slap_sasl_init to complete,
> which was long enough for the initial startup check to time out. You need to
> check your system to see why SASL took so long to initialize, most likely a
> DNS failure or some other transient issue.
Hmm, this was with a local build of cyrus-sasl 2.1.25 which seg faulted on
GSSAPI in another test. I will retry with cyrus-sasl package shipped with
openSUSE 11.4.
Ciao, Michael.
11 years, 11 months
Re: (ITS#7069) test061-syncreplication-initiation failed for hdb
by hyc@symas.com
michael(a)stroeder.com wrote:
> Full_Name: Michael Ströder
> Version: HEAD (from git)
> OS: openSUSE 11.4
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (84.163.45.214)
>
>
>>>>>> test061-syncreplication-initiation failed for hdb
> (exit 255)
> make[2]: *** [hdb-mod] Error 255
> make[2]: Leaving directory `/usr/src/michael/openldap/tests'
> make[1]: *** [test] Error 2
> make[1]: Leaving directory `/usr/src/michael/openldap/tests'
> make: *** [test] Error 2
Not enough info in your testrun directory, what was the output from the script
up this point?
From reading the slapd.?.log files, it also looks like something in your
environment is slowing down the SASL init here, enough to make the script timeout.
On all of my tests here the timestamp for slap_sasl_init is always identical
to the preceding timestamp, i.e., slap_sasl_init should never even take as
long as 1 second. Fix your environment before submitting any more bug reports.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
11 years, 11 months
Re: (ITS#7070) test058-syncrepl-asymmetric failed for hdb
by hyc@symas.com
michael(a)stroeder.com wrote:
> Full_Name: Michael Ströder
> Version: HEAD (from git master)
> OS: openSUSE 11.4
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (84.163.51.243)
>
>
>>>>>> Starting test058-syncrepl-asymmetric for hdb...
> running defines.sh
> Initializing master configurations...
> Initializing search configurations...
> Starting central master slapd on TCP/IP port 9011...
> Using ldapsearch to check that central master slapd is running...
> Waiting 1 seconds for slapd to start...
> Waiting 2 seconds for slapd to start...
> Waiting 3 seconds for slapd to start...
> Waiting 4 seconds for slapd to start...
> Waiting 5 seconds for slapd to start...
> ldapsearch failed (255)!
>>>>>> test058-syncrepl-asymmetric failed for hdb
> (exit 255)
> make[2]: *** [hdb-mod] Error 255
> make[2]: Leaving directory `/usr/src/michael/openldap/tests'
> make[1]: *** [test] Error 2
> make[1]: Leaving directory `/usr/src/michael/openldap/tests'
> make: *** [test] Error 2
There's no evidence of an OpenLDAP bug here. All we can see from the
testrun/slapd.1.log is that it took 15 seconds for slap_sasl_init to complete,
which was long enough for the initial startup check to time out. You need to
check your system to see why SASL took so long to initialize, most likely a
DNS failure or some other transient issue.
Closing this ITS.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
11 years, 11 months