openldap-bugs

openldap-bugs@openldap.org

1 participants
21184 discussions

(ITS#8106) Retry pwrite operations in case of EINTR
by milinevskyy＠gmail.com 17 Apr '15

17 Apr '15

Full_Name: Dmytro Milinevskyy Version: OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (92.132.131.166) On linux systems it's common to have system calls interrupted and restarted. LMDB should retry pwrites to avoid "false" failures.

1 0

Re: (ITS#8097) update nssov to nss-pam-ldapd 0.9.4
by hyc＠symas.com 15 Apr '15

15 Apr '15

ryan(a)nardis.ca wrote: > Full_Name: Ryan Tandy > Version: master, 2.4 > OS: Debian > URL: > Submission from: (NULL) (24.68.37.4) > Thanks, pushed to git master. > updating the copied nss-pam-ldapd files: > > ftp://ftp.openldap.org/incoming/20150405_rtandy_nssov-update-nss-pam-ldapd-… > > updating nssov for those changes, see commit msg for details: > > ftp://ftp.openldap.org/incoming/20150405_rtandy_nssov-update-to-protocol-ve… > > while I'm in the code anyway, cleaning up a few compiler warnings (that were > already there, I didn't introduce them :P). Cosmetic stuff: unused variables, > return-type (void/non-void) mismatches, a couple of undeclared prototypes. > > ftp://ftp.openldap.org/incoming/20150405_rtandy_nssov-clean-up-some-compile… > > Please note, the protocol change breaks backwards compat with older versions of > the client libraries (per nss-pam-ldapd/README). > > Tested on Linux. No idea about Solaris etc, sorry. > > The DN field was removed from the pam protocol, so uid lookup happens on every > connection now. I couldn't think of a safe way to avoid that; suggestions > welcome. > > -- > > (the following statements apply to patches 2 and 3 only; patch 1 is copied from > work by Arthur de Jong, licensed LGPLv2.1) > > The attached patch files are derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the preceding patches were > developed by Ryan Tandy <ryan(a)nardis.ca>. I have not assigned rights and/or > interest in this work to any party. > > I, Ryan Tandy, hereby place the preceding modifications to OpenLDAP Software > (and only these modifications) into the public domain. Hence, these > modifications may be freely used and/or redistributed for any purpose with or > without attribution and/or other notice. > > -- -- 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#8095) Patch
by hyc＠symas.com 15 Apr '15

15 Apr '15

rouzier(a)gmail.com wrote: > Full_Name: James Rouzier > Version: > OS: > URL: ftp://ftp.openldap.org/incoming/james-rouzier-150331.patch > Submission from: (NULL) (192.222.129.11) > > > I am working on a proof of concept of a simple key value store service using > lmdb as the back end. > I am using sendfile to avoid an extra copy. > I accomplished this by creating function to extract get the mmap ptr from the > env so I can calculate the offset of data. I'm quite reluctant to return the mmap pointer. In a WRITEMAP environment that invites all manner of undetectable/unpreventable corruptions. Have you actually measured the performance difference between using sendfile() here and plain write() or send()? The kernel doesn't physically copy the written data from user space to kernel space, it just maps in a particular page. Since LMDB data is already mmap'd, the kernel has very little work to do since the relevant pages are already present in the kernel's page tables. Ultimately sending data over TCP involves byte-by-byte iteration anyway, since TCP checksums must be computed on all outgoing data. Doesn't seem to me like sendfile can be a very significant optimization here. > > I figured that function might be useful to the bigger community. > > If it does not fit in the bigger vision of lmdb it is fine not to include it. > > > I, James Rouzier, hereby place the following modifications to OpenLDAP Software > (and only these modifications) into the public domain. Hence, these > modifications may be freely used and/or redistributed for any purpose with or > without attribution and/or other notice. > > > -- -- 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#8089) LMDB hangs on mdb_txn_renew0 if MDB_NOSYNC flag is used
by hyc＠symas.com 15 Apr '15

15 Apr '15

pk(a)dbic.pro wrote: > Full_Name: Pavel Kraynyukhov > Version: only LMDB from git and lmdb-0.9.14 > OS: Gentoo Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (37.99.47.171) > > > Hello there, I have ran into an issue with LMDB, which I can reproduce at will, > but it seems a specific one. The git commit is > 3368d1f5e243225cba4d730fba19ff600798ebe3 > And this commit and my issue seems to be related. > > 1. I use MDB_NOTLS flag on environment open. > 2. if I use MDB_NOSYNC flag for LMDB environment, the writer thread is stuck > after several transactions (writer thread backtrace): > P.S. tested against system provided lmdb version 0.9.14 and result is the same. > So this maybe not related to latest commit in git. If you're having this problem in 0.9.14 then it is certainly not related to 3368d1f5e243225cba4d730fba19ff600798ebe3. You confirm that the issue does not occur in 0.9.13? Can you upload a test case demonstrating the problem? -- -- 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#8105) [PATCH] slaptest doesn't convert perlModuleConfig lines
by hyc＠symas.com 15 Apr '15

15 Apr '15

jsynacek(a)redhat.com wrote: > Full_Name: Jan Synacek > Version: master > OS: GNU/Linux > URL: https://jsynacek.fedorapeople.org/openldap/jsynacek-20150415-back-perl-corr… > Submission from: (NULL) (213.175.37.10) > > > When using the perl backend, slaptest doesn't convert perlModuleConfig lines > from slapd.conf to slapd.d. > > A simple reproducer can be found at > https://jsynacek.fedorapeople.org/openldap/back-perl.sh > > Thanks, added to git master -- -- 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#8062) Assertion 'IS_LEAF(mp)' failed in mdb_cursor_next()
by hyc＠symas.com 15 Apr '15

15 Apr '15

This is a multi-part message in MIME format. --------------030305070307090003010905 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Gawen ARAB wrote: > Thanks for the report. Unfortunately, it appears the DB was > constructed incorrectly at some time in the past, so even updating > to later revisions of the code won't avoid the crash. It's more > important now to find the sequence of steps that recreates the > invalid DB in the first place, or verify that the same sequence > doesn't crash using the 0.9.15 release candidate. > > > OK. I'll try to reproduce the steps. I reproduced an occurrence of this assert using the attached test program. This particular bug is now fixed in git, but since we never had a test case for your original situation it's still unconfirmed whether this fix addresses your issue. Were you able to do any further testing? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --------------030305070307090003010905 Content-Type: text/x-csrc; name="its8062.c" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="its8062.c" /* mtest.c - memory-mapped database tester/toy */ /* * Copyright 2011-2015 Howard Chu, Symas Corp. * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted only as authorized by the OpenLDAP * Public License. * * A copy of this license is available in the file LICENSE in the * top-level directory of the distribution or, alternatively, at * <http://www.OpenLDAP.org/license.html>. */ #include <stdio.h> #include <stdlib.h> #include <string.h> #include "lmdb.h" #define E(expr) CHECK((rc = (expr)) == MDB_SUCCESS, #expr) #define RES(err, expr) ((rc = expr) == (err) || (CHECK(!rc, #expr), 0)) #define CHECK(test, msg) ((test) ? (void)0 : ((void)fprintf(stderr, \ "%s:%d: %s: %s\n", __FILE__, __LINE__, msg, mdb_strerror(rc)), abort())) /* Write an 8 byte integer in big-endian order */ void L2B(unsigned long l, char *c) { int i; for (i=7; i>=0; i--) { c[i] = l & 0xff; l >>= 8; } } int main(int argc,char * argv[]) { int i = 0, j = 0, rc; MDB_env *env; MDB_dbi dbi; MDB_val headkey1, headkey2, headkey3, TERMINATOR; MDB_val key, data; MDB_txn *txn; MDB_cursor *cursor; int count = 1024; char ck1[24], ck2[24], ck3[24], ckx[32], cterm[511]; char cvar[1024]; E(mdb_env_create(&env)); E(mdb_env_set_mapsize(env, 1024*1024*1024)); E(mdb_env_set_maxdbs(env, 2)); E(mdb_env_open(env, "./testdb", MDB_NOSYNC, 0664)); E(mdb_txn_begin(env, NULL, 0, &txn)); E(mdb_dbi_open(txn, "test", MDB_CREATE, &dbi)); E(mdb_txn_commit(txn)); /* set up 3 partitions of data */ headkey1.mv_size = 24; headkey1.mv_data = ck1; headkey2.mv_size = 24; headkey2.mv_data = ck2; headkey3.mv_size = 24; headkey3.mv_data = ck3; /* and a final record */ TERMINATOR.mv_size = sizeof(cterm); TERMINATOR.mv_data = cterm; memset(cterm, 255, sizeof(cterm)); memset(ck1, 0, 24); memset(ck2, 0, 24); memset(ck3, 0, 24); memset(ckx, 0, 24); /* Assign the 3 partition keys */ L2B(1, ck1); L2B(-1, ck2); L2B(0, ck3); E(mdb_txn_begin(env, NULL, 0, &txn)); /* Terminator data is a single NUL byte */ data.mv_size = 1; data.mv_data = cvar; cvar[0] = 0; E(mdb_put(txn, dbi, &TERMINATOR, &data, 0)); /* Partition data is 24 NUL bytes */ memset(cvar, 0, 24); data.mv_size = 24; E(mdb_put(txn, dbi, &headkey1, &data, 0)); E(mdb_put(txn, dbi, &headkey2, &data, 0)); E(mdb_put(txn, dbi, &headkey3, &data, 0)); /* Main data is 35 NUL bytes, keys are 32 bytes */ memset(cvar, 0, 35); data.mv_size = 35; key.mv_data = ckx; key.mv_size = 32; for (i=1; i<=count; i++) { L2B(i, ckx+24); memcpy(ckx, headkey1.mv_data, 24); E(mdb_put(txn, dbi, &key, &data, 0)); memcpy(ckx, headkey2.mv_data, 24); E(mdb_put(txn, dbi, &key, &data, 0)); memcpy(ckx, headkey3.mv_data, 24); E(mdb_put(txn, dbi, &key, &data, 0)); } /* Delete from 1st partition */ E(mdb_cursor_open(txn, dbi, &cursor)); E(mdb_cursor_get(cursor, &headkey1, &data, MDB_SET)); for (i=0; i<count; i++) { E(mdb_cursor_del(cursor, 0)); E(mdb_cursor_get(cursor, &key, &data, MDB_NEXT)); } mdb_cursor_close(cursor); /* Delete from 2nd partition - assert happens here */ E(mdb_cursor_open(txn, dbi, &cursor)); E(mdb_cursor_get(cursor, &headkey2, &data, MDB_SET)); for (i=0; i<count; i++) { E(mdb_cursor_del(cursor, 0)); E(mdb_cursor_get(cursor, &key, &data, MDB_NEXT)); } mdb_cursor_close(cursor); /* Delete from 3rd partition - not reached */ E(mdb_cursor_open(txn, dbi, &cursor)); E(mdb_cursor_get(cursor, &headkey3, &data, MDB_SET)); for (i=0; i<count; i++) { E(mdb_cursor_del(cursor, 0)); E(mdb_cursor_get(cursor, &key, &data, MDB_NEXT)); } mdb_cursor_close(cursor); E(mdb_txn_commit(txn)); mdb_dbi_close(env, dbi); mdb_env_close(env); return 0; } --------------030305070307090003010905--

1 0

(ITS#8105) [PATCH] slaptest doesn't convert perlModuleConfig lines
by jsynacek＠redhat.com 15 Apr '15

15 Apr '15

Full_Name: Jan Synacek Version: master OS: GNU/Linux URL: https://jsynacek.fedorapeople.org/openldap/jsynacek-20150415-back-perl-corr… Submission from: (NULL) (213.175.37.10) When using the perl backend, slaptest doesn't convert perlModuleConfig lines from slapd.conf to slapd.d. A simple reproducer can be found at https://jsynacek.fedorapeople.org/openldap/back-perl.sh

1 0

(ITS#8104) Admin Guide 2.4 pdf
by it＠kotoc.cat 14 Apr '15

14 Apr '15

Full_Name: Ricard Valero Version: 2.4 OS: Debian/Ubuntu URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.35.55.43) Hi, Admins Guide 2.4 PDF lacks images, i know it's a minor issue but I like to have it on pdf, i'm new to LDAP and I would like to print it so i can write notes on it. Thanks

1 0

Re: (ITS#6077) Spurious uniqueness errors with filters in unique overlays
by quanah＠zimbra.com 12 Apr '15

12 Apr '15

I would suggest testing current RE24, somes fixes to slapo-unique went in last week. --Quanah --On Sunday, April 12, 2015 10:19 PM +0000 sbin(a)informatik.uni-leipzig.de wrote: > Should I be having this issue on OpenLDAP 2.4.40? I have the filter > > ldap:///?gidNumber?sub?(objectClass=posixGroup) > > and cannot use gidNumber in posixAccount's. This was working in 2.4.31 > if I recall correctly. > > #!RESULT ERROR > #!ERROR [LDAP: error code 19 - some attributes not unique] > dn: cn=User Name,ou=People,dc=... > changetype: modify > replace: gidNumber > gidNumber: 10000 > - > > > > > > -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6077) Spurious uniqueness errors with filters in unique overlays
by sbin＠informatik.uni-leipzig.de 12 Apr '15

12 Apr '15

Should I be having this issue on OpenLDAP 2.4.40? I have the filter ldap:///?gidNumber?sub?(objectClass=posixGroup) and cannot use gidNumber in posixAccount's. This was working in 2.4.31 if I recall correctly. #!RESULT ERROR #!ERROR [LDAP: error code 19 - some attributes not unique] dn: cn=User Name,ou=People,dc=... changetype: modify replace: gidNumber gidNumber: 10000 -

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs