openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

Re: (ITS#6152) proxycache enhancements
by hyc＠symas.com 29 May '09

29 May '09

Pierangelo Masarati wrote: > hyc(a)OpenLDAP.org wrote: > >> Some ideas that came out of discussions at the Ubuntu Developer Summit this >> week... >> >> It would be nice for pcache to detect when connectivity to the remote server has >> been lost. In that case, cache expiration should be stopped, and the cache >> contents should remain intact until connectivity is restored. > > Sounds fair. > >> Also, when connectivity is restored, pcache should explicitly refresh all the >> entries it currently holds, rather than allowing them to be immediately expired. > > Sounds an overkill? Perhaps. It is certainly likely that any entries in the cache will be stale; when connectivity is restored and expiration is re-enabled the cached entries will probably be immediately removed. While it will be no problem to retrieve the entries again since the network is available, the concern is that only a subset of the originally cached entries will be retrieved through normal user activity, but the entire set needs to be preserved in anticipation of the next disconnect event. -- -- 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

Re: (ITS#6152) proxycache enhancements
by masarati＠aero.polimi.it 29 May '09

29 May '09

hyc(a)OpenLDAP.org wrote: > Some ideas that came out of discussions at the Ubuntu Developer Summit this > week... > > It would be nice for pcache to detect when connectivity to the remote server has > been lost. In that case, cache expiration should be stopped, and the cache > contents should remain intact until connectivity is restored. Sounds fair. > Also, when connectivity is restored, pcache should explicitly refresh all the > entries it currently holds, rather than allowing them to be immediately expired. Sounds an overkill? Cheers, p.

1 0

Re: (ITS#6152) proxycache enhancements
by rhafer＠suse.de 29 May '09

29 May '09

Am Donnerstag 28 Mai 2009 18:29:55 schrieb hyc(a)openldap.org: > Full_Name: Howard Chu > Version: 2.4.16 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (80.67.104.102) > Submitted by: hyc > > > Some ideas that came out of discussions at the Ubuntu Developer Summit this > week... > > It would be nice for pcache to detect when connectivity to the remote > server has been lost. In that case, cache expiration should be stopped, and > the cache contents should remain intact until connectivity is restored. Yes that sound reasonable. It's probably also worth to think about a mechanism to explicitly set pcache to "offline" mode. That way on a client machine a hook could be provided for e.g. NetworkManager to bring pcache to offline mode immediately when the network goes offline. That mechanism could either be offered through back-config (back-monitor as for readonly?) and/or through the nssov Socket as that would most probably be the main user of this disconnected pcache mode. > Also, when connectivity is restored, pcache should explicitly refresh all > the entries it currently holds, rather than allowing them to be immediately > expired. -- Ralf

1 0

(ITS#6153) Segfault during Heimdal's kadmin -l init Realm
by dewayne_freebsd＠yahoo.com 29 May '09

29 May '09

Full_Name: Dewayne Geraghty Version: 2.4.16 OS: FreeBSD 7.2R URL: http://www.consciuminternational.com.au/ldap Submission from: (NULL) (58.172.112.108) FreeBSD version 7.2; Heimdal V1.2.1; OpenLDAP 2.4.16 Heimdal and OpenLDAP are built for heimdal to use OpenLDAP as backend. Segmentation fault during kadmin -l init HS slapd and heimdal work correctly, independently. slapd is running at debug 1019, logs are at enclosed URL along with the full gdb trace, and configuration files. If I can assist please advise. This is a single Pentium CPU, and gcc flags CFLAGS= -pipe -g3 -ggdb3 -O0 -march=pentium4 -mtune=pentium4 -DDO_KRB5 -DDO_SAMBA -DHAVE_OPENSSL #0 0x286447b6 in memmove () from /lib/libc.so.7 #1 0x282a10e8 in ber_write () from /usr/local/lib/liblber-2.4.so.6 #2 0x2829ebf7 in ber_put_ostring () from /usr/local/lib/liblber-2.4.so.6 #3 0x2829ed14 in ber_put_berval () from /usr/local/lib/liblber-2.4.so.6 #4 0x2829faca in ber_printf () from /usr/local/lib/liblber-2.4.so.6 #5 0x2821a0ee in ldap_add_ext () from /usr/local/lib/libldap-2.4.so.6 #6 0x2821a378 in ldap_add_ext_s () from /usr/local/lib/libldap-2.4.so.6 #7 0x280ad493 in LDAP_store (context=0x287050b0, db=0x2870e040, flags=0, entry=0xbfbfe790) at hdb-ldap.c:1600 #8 0x2809875b in kadm5_s_create_principal (server_handle=0x2871b0c0, princ=0xbfbfea3c, mask=17, password=0xbfbfe830 "bQdxg9drKf") at create_s.c:182 #9 0x2808da1c in kadm5_create_principal (server_handle=0x2871b0c0, princ=0xbfbfea3c, mask=17, password=0xbfbfe830 "bQdxg9drKf") at common_glue.c:64 #10 0x0804e496 in ?? () #11 0x2871b0c0 in ?? () #12 0xbfbfea3c in ?? () #13 0x00000011 in ?? () #14 0xbfbfe830 in ?? () #15 0x28084000 in ?? () #16 0x28084200 in ?? () #17 0x28084400 in ?? () #18 0x285b3c8d in _pthread_mutex_init_calloc_cb () from /lib/libc.so.7 #19 0x0804e8c9 in ?? () #20 0x2870c0e0 in ?? () #21 0x00000000 in ?? () #22 0x00000000 in ?? () #23 0x00000000 in ?? () #24 0x2870c085 in ?? () #25 0x00000000 in ?? () #26 0x28650030 in ?? () from /lib/libc.so.7 I have spent weeks trying to get this to work. (Because I'm using and modifing the FreeBSD ports system to build and use the latest version of LDAP and Heimdal.)

1 0

(ITS#6152) proxycache enhancements
by hyc＠OpenLDAP.org 28 May '09

28 May '09

Full_Name: Howard Chu Version: 2.4.16 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.67.104.102) Submitted by: hyc Some ideas that came out of discussions at the Ubuntu Developer Summit this week... It would be nice for pcache to detect when connectivity to the remote server has been lost. In that case, cache expiration should be stopped, and the cache contents should remain intact until connectivity is restored. Also, when connectivity is restored, pcache should explicitly refresh all the entries it currently holds, rather than allowing them to be immediately expired.

1 0

Re: (ITS#6056) Samba4 breaks OpenLDAP over ldapi
by hyc＠symas.com 28 May '09

28 May '09

Andrew Bartlett wrote: > On Tue, 2009-05-26 at 04:26 -0700, Howard Chu wrote: >> abartlet(a)samba.org wrote: >>> Full_Name: Andrew Bartlett >>> Version: CVS HEAD >>> OS: Fedora 10 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (59.167.251.137) >>> >>> >>> Samba4's provision and 'make test' seems to create some internal situation in >>> OpenLDAP slapd where it will not accept any more connections over ldapi:/// >>> >>> This is best seen by building Samba4, and running >>> >>> TEST_LDAP=yes OPENLDAP_ROOT=/usr/local make test >>> >>> The slapd does not crash, but simply stops accepting new connections. Samba4 >>> currently then crashes due to some other bug (the LDAP backend not responding is >>> clearly untested code in Samba4). >>> >>> It isn't a Samba4 client bug, as ldapsearch also fails to respond. >>> >>> This seems very, very similar to ITS#5261 >> >> Further testing with Andrew's kvm image shows the hang only occurs when Cyrus >> SASL's libsasldb2.so plugin is present. I always remove that plugin from my >> installs, since I only use in-directory SASL secrets. That's probably why I >> wasn't seeing the reported behavior before. >> >> Also a note - it's still not clear we've been talking about the same thing up >> to this point. Even when the samba test suite hangs, I see that ldapsearch >> still works fine against slapd. At any rate, currently all of the samba4 tests >> pass for me. > > Hmm. Using that KVM image, with the libsasldb moved aside (and with it > left in place), I still get errors. > > However, there is an important difference: Where previously, once it > locked up nothing proceeded, now it proceeds - as if the failure is > temporary now. The error has changed too - instead of a failure to > connect, it is an inability to successfully read the rootDSE. > > I agree, we might be jumping at different shadows here, but your patches > did fix something... I see what you're describing now, with the kvm set with 2 CPUs. It appears to be a bug caused by the recent patch for connection_hangup() processing. Running slapd with -d15 in your test shows that a connection is closed shortly after being established and becoming readable. The bug is (probably) that we queued the reader but processed the hangup immediately, thus closing the connection before the reader executes. I'm not exactly sure why this is causing the problem on your test, since it looks like your client is closing the socket before waiting for the reply. But certainly this is the right area. -- -- 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#6151) Update cosine.schema to RFC 4524
by michael＠stroeder.com 28 May '09

28 May '09

Full_Name: Michael Ströder Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.80.206) cosine.schema is still based on obsoleted RFC 1274. It should be updated to RFC 4524.

1 0

Re: (ITS#6150) schema compliance checking tool
by michael＠stroeder.com 28 May '09

28 May '09

Pierangelo Masarati wrote: > Added to HEAD. Please test. Wow! This was fast! It simply works. I want it in 2.4.17. ;-) Ciao, Michael.

1 0

Re: (ITS#6150) schema compliance checking tool
by masarati＠aero.polimi.it 28 May '09

28 May '09

Added to HEAD. Please test. p.

1 0

(ITS#6150) schema compliance checking tool
by michael＠stroeder.com 28 May '09

28 May '09

Full_Name: Michael Ströder Version: HEAD OS: URL: Submission from: (NULL) (84.163.68.118) masarati(a)aero.polimi.it wrote: > Comes to mind that something like a schema compliance checking tool, > either off- or on-line could be useful. Sort of a "slapschema" that > checks the schema compliance of each entry (matching a filter or > within a subtree specification) in a given database. The result could contain the DNs of non-compliant entries each with the diagnostic message which would have been returned to a client adding such a non-compliant entry.

1 0

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