Re: (ITS#7682) LMDB: [PATCH] mdb_env_copy should retry open() if O_DIRECT fails
by sog＠msg.com.mx
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.
10 years, 2 months
Re: (ITS#7693) ProxyCache Problems
by quanah＠zimbra.com
--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
10 years, 2 months
Re: (ITS#7693) ProxyCache Problems
by teichler＠message-mobile.de
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
_____________________________________________________
10 years, 2 months
Re: (ITS#7693) ProxyCache Problems
by ck＠cksoft.de
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
10 years, 2 months
Re: (ITS#7693) ProxyCache Problems
by teichler＠message-mobile.de
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
_____________________________________________________
10 years, 2 months
Re: (ITS#7693) ProxyCache Problems
by teichler＠message-mobile.de
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
_____________________________________________________
10 years, 2 months
(ITS#7695) Fix regression using ldapsearch with cldap
by stefw＠redhat.com
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
10 years, 2 months
Re: (ITS#7694) cldap fails with IPv6 due to wrong size sockaddr
by quanah＠zimbra.com
--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
10 years, 2 months
Re: (ITS#7694) cldap fails with IPv6 due to wrong size sockaddr
by stefw＠redhat.com
On 12.09.2013 18:00, Quanah Gibson-Mount wrote:
> --On Thursday, September 12, 2013 3:56 PM +0000 stefw(a)redhat.com wrote:
>
>> Full_Name: Stef Walter
>> Version: 2.4.35
>> OS: Fedora 19
>> URL: ftp://ftp.openldap.org/incoming/stef-walter-130912.patch
>> Submission from: (NULL) (46.5.2.70)
>>
>>
>> Connectionless LDAP (ie: cldap enabled with -DLDAP_CONNECTIONLESS) is
>> broken for IPv6 for current versions of openldap. Tested with version
>> 2.4.35
>
>
> 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.
Cheers,
Stef
10 years, 2 months
Re: (ITS#7694) cldap fails with IPv6 due to wrong size sockaddr
by quanah＠zimbra.com
--On Thursday, September 12, 2013 3:56 PM +0000 stefw(a)redhat.com wrote:
> Full_Name: Stef Walter
> Version: 2.4.35
> OS: Fedora 19
> URL: ftp://ftp.openldap.org/incoming/stef-walter-130912.patch
> Submission from: (NULL) (46.5.2.70)
>
>
> Connectionless LDAP (ie: cldap enabled with -DLDAP_CONNECTIONLESS) is
> broken for IPv6 for current versions of openldap. Tested with version
> 2.4.35
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.
--Quanah
--
Quanah Gibson-Mount
Lead Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
10 years, 2 months
