openldap-bugs

openldap-bugs@openldap.org

20960 discussions

Re: (ITS#7682) LMDB: [PATCH] mdb_env_copy should retry open() if O_DIRECT fails
by h.b.furuseth＠usit.uio.no 14 Sep '13

14 Sep '13

I wrote: > Also on RHEL 6.4 (2.6.32-358.18.1.el6.x86_64) with > /dev/shm/nosuch. I'll report it to RedHat and see what they say. https://bugzilla.redhat.com/show_bug.cgi?id=1008073 Simpler fix, at least on Linux: #ifdef O_DIRECT if ((rc = fcntl(fd, F_GETFL)) != -1) (void) fcntl(fd, F_SETFL, rc | O_DIRECT); #endif But that could fail elsewhere, if some OS only accepts O_DIRECT to open() and not to fcntl(). BTW, does the nearby Apple code need to fail if fcntl(newfd, F_NOCACHE, 1) fails? Could ignore errors. -- Hallvard

1 0

Re: (ITS#7682) LMDB: [PATCH] mdb_env_copy should retry open() if O_DIRECT fails
by h.b.furuseth＠usit.uio.no 14 Sep '13

14 Sep '13

On 2013-09-13 23:09, sog(a)msg.com.mx wrote: > If the call fails because O_DIRECT, in a "tmpfs" in my Fedora 19 > '/tmp', > the file is left created anyway! so the retry fails because > O_EXCL|O_CREAT. Also on RHEL 6.4 (2.6.32-358.18.1.el6.x86_64) with /dev/shm/nosuch. I'll report it to RedHat and see what they say. > I propose the following: > (...) > + * Fortunately seems that other errors are reported before EINVAL > + * So, we need to remove it before retry open. > */ > if (newfd == INVALID_HANDLE_VALUE && ErrCode() == EINVAL) > + (void)unlink(lpath) , No unlink(). EINVAL does not say whether the file existed before the call. Not on another OS, nor on another Linux version or filesystem where Linux may work differently. Somewhat better: #ifdef <buggy Linux>, replace O_EXCL with O_TRUNC in the 2nd call. Or add paranoia like taking an exclusive lock, but ignore "locking not supported" errors. > #endif > newfd = open(lpath, O_WRONLY|O_CREAT|O_EXCL, 0666); > #endif -- Hallvard

1 0

Re: (ITS#7682) LMDB: [PATCH] mdb_env_copy should retry open() if O_DIRECT fails
by sog＠msg.com.mx 13 Sep '13

13 Sep '13

On 09/05/2013 06:33 PM, Howard Chu wrote: > sog(a)msg.com.mx wrote: >> Full_Name: Salvador Ortiz >> Version: 24 >> OS: Linux >> URL: >> ftp://ftp.msg.com.mx/pub/varios/0001-In-mdb_env_copy-retry-open-if-O_DIRECT-fails.patch >> Submission from: (NULL) (187.162.45.111) >> >> >> If the OS defines O_DIRECT mdb_env_copy unconditionally uses it, but >> according >> to open(2): "Some file systems may not implement the flag and >> open() will >> fail with EINVAL if it is used." >> >> In this cases mdb_env_copy should retry without the flag. >> >> The attached patch implements that. >> >> > Thanks, applied. > Thank you Howard, but I found an unexpected problem with the patch as commited. If the call fails because O_DIRECT, in a "tmpfs" in my Fedora 19 '/tmp', the file is left created anyway! so the retry fails because O_EXCL|O_CREAT. I consider this undocumented behavior for "open", buggy or at least ugly. (A simple test program in ftp://ftp.msg.com.mx/pub/varios/o_direct.c) I propose the following: ======== --- a/liblmdb/mdb.c 2013-09-05 17:31:01.498090281 -0500 +++ b/liblmdb/mdb.c 2013-09-13 14:45:00.918717292 -0500 @@ -4250,9 +4250,16 @@ /* The OS supports O_DIRECT, try with it */ newfd = open(lpath, O_WRONLY|O_CREAT|O_EXCL|O_DIRECT, 0666); /* But open can fail if O_DIRECT isn't supported by the file system - * so retry without the flag + * so retry without the flag. + * + * Sept 13 2013. + * On a tmpfs, at least, an open with O_DIRECT fails, + * BUT the file is created anyway!! + * Fortunately seems that other errors are reported before EINVAL + * So, we need to remove it before retry open. */ if (newfd == INVALID_HANDLE_VALUE && ErrCode() == EINVAL) + (void)unlink(lpath) , #endif newfd = open(lpath, O_WRONLY|O_CREAT|O_EXCL, 0666); #endif ========= What do you think? Regards.

1 0

Re: (ITS#7693) ProxyCache Problems
by quanah＠zimbra.com 13 Sep '13

13 Sep '13

--On Friday, September 13, 2013 9:19 AM +0000 teichler(a)message-mobile.de wrote: > That's not so easy how you think because this is a running producive > Server and i don't have the time to build OpenLDAP 2.4 for CentOS 5.9, > thats why i try to use an ProxyCache. This is why, again, you could use the LTB packages I pointed you at. They don't replace the existing ldap libraries, etc, on the server. They install into their own location (/usr/local I believe). Then you don't have to build it yourself, and you can actually be on something current. --Quanah -- Quanah Gibson-Mount Lead Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7693) ProxyCache Problems
by teichler＠message-mobile.de 13 Sep '13

13 Sep '13

That's not so easy how you think because this is a running producive Server and i don't have the time to build OpenLDAP 2.4 for CentOS 5.9, thats why i try to use an ProxyCache. Best Regards Mike Teichler -- _____________________________________________________ Message Mobile GmbH Stresemannstr. 6, D-21335 Lüneburg teichler(a)message-mobile.de tel.: +49 (0)4131 24444-234, fax: +49 (0)4131 24444-2349 www.message-mobile.de GF: Dr. Martin Hecker, AG Lüneburg, HRB: 2414 _____________________________________________________

1 0

Re: (ITS#7693) ProxyCache Problems
by ck＠cksoft.de 13 Sep '13

13 Sep '13

Hi, On Fri, 13 Sep 2013, teichler(a)message-mobile.de wrote: > My Problem is, that this LDAP Server running on CentOS 5.9 Server, and > there are more Services then LDAP so I can't Updatet the Server and LDAP > 2.4. ... doesn't Supports CentOS 5.9. it should be perfectly possible to update to a current openldap server and leave the dependencies of your system to the old libraries. Just use one of the freely available source rpm and build from that. Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck(a)cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer

1 0

Re: (ITS#7693) ProxyCache Problems
by teichler＠message-mobile.de 13 Sep '13

13 Sep '13

And my Destination LDAP where the ProxyCache works in on LDAP 2.4.23. My Questions is: Is it generelly possible to do a ProxyCache query from a LDAP 2.4 server to a LDAP 2.3 server? -- _____________________________________________________ Message Mobile GmbH Stresemannstr. 6, D-21335 Lüneburg teichler(a)message-mobile.de tel.: +49 (0)4131 24444-234, fax: +49 (0)4131 24444-2349 www.message-mobile.de GF: Dr. Martin Hecker, AG Lüneburg, HRB: 2414 _____________________________________________________

1 0

Re: (ITS#7693) ProxyCache Problems
by teichler＠message-mobile.de 13 Sep '13

13 Sep '13

My Problem is, that this LDAP Server running on CentOS 5.9 Server, and there are more Services then LDAP so I can't Updatet the Server and LDAP 2.4. ... doesn't Supports CentOS 5.9. -- _____________________________________________________ Message Mobile GmbH Stresemannstr. 6, D-21335 Lüneburg teichler(a)message-mobile.de tel.: +49 (0)4131 24444-234, fax: +49 (0)4131 24444-2349 www.message-mobile.de GF: Dr. Martin Hecker, AG Lüneburg, HRB: 2414 _____________________________________________________

1 0

(ITS#7695) Fix regression using ldapsearch with cldap
by stefw＠redhat.com 12 Sep '13

12 Sep '13

Full_Name: Stef walter Version: git master OS: Fedora 19 URL: ftp://ftp.openldap.org/incoming/stef-walter-cldap-regression-130912.patch Submission from: (NULL) (46.5.2.70) I get an assertion with today's git master when using ldapsearch with a cldap URL. openldap has been compiled with -DLDAP_CONNECTIONLESS $ ldapsearch -d -1 -LL -H 'cldap://10.34.37.22' -b '' -s base '(&(DnsDomain=ad.baseos.qe)(NtVer=\06\00\00\00))' NetLogon ldap_url_parse_ext(cldap://10.34.37.22) ldap_create ldap_url_parse_ext(cldap://10.34.37.22:389/??base) ldap_simple_bind ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: UDP 10.34.37.22:389 ldap_new_socket: 7 ldap_prepare_socket: 7 ldap_connect_to_host: Trying 10.34.37.22:389 ldap_open_defconn: successful ldap_parse_result ldapsearch: error.c:255: ldap_parse_result: Assertion `r != ((void *)0)' failed. Program received signal SIGABRT, Aborted. 0x000000322e835a19 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 56 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig); (gdb) bt #0 0x000000322e835a19 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x000000322e837128 in __GI_abort () at abort.c:90 #2 0x000000322e82e986 in __assert_fail_base ( fmt=0x322e97dda8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x489ded "r != ((void *)0)", file=file@entry=0x489d2c "error.c", line=line@entry=255, function=function@entry=0x489e20 <__PRETTY_FUNCTION__.7860> "ldap_parse_result") at assert.c:92 #3 0x000000322e82ea32 in __GI___assert_fail ( assertion=0x489ded "r != ((void *)0)", file=0x489d2c "error.c", line=255, function=0x489e20 <__PRETTY_FUNCTION__.7860> "ldap_parse_result") at assert.c:101 #4 0x0000000000421a96 in ldap_parse_result (ld=0x6c7c90, r=0x0, errcodep=0x7fffffff914c, matcheddnp=0x7fffffff9140, errmsgp=0x7fffffff9138, referralsp=0x7fffffff9130, serverctrls=0x7fffffff9128, freeit=1) at error.c:255 #5 0x0000000000412093 in tool_bind (ld=0x6c7c90) at common.c:1623 #6 0x0000000000407f01 in main (argc=12, argv=0x7fffffffd3f8) at ldapsearch.c:903

1 0

Re: (ITS#7694) cldap fails with IPv6 due to wrong size sockaddr
by quanah＠zimbra.com 12 Sep '13

12 Sep '13

--On Thursday, September 12, 2013 4:04 PM +0000 stefw(a)redhat.com wrote: >> 2.4.35 is not the current version of OpenLDAP, 2.4.36 is. There were >> fixes to CLDAP made in 2.4.36. Please test against 2.4.36 and report >> back, thanks. > > This patch is against master. > > However master cldap support is broken in additional ways, and I'll be > filing further bugs/patches. Hi Stef, Thanks! In the future then, if it is an issue with the current 2.4 release series still, you can just put RE24 as the version. ;) Then I won't spend time trying to see if it's a known issue already fixed via the changes log. --Quanah -- Quanah Gibson-Mount Lead Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

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