- openldap-bugs - openldap.org

(ITS#8134) Error while starting an instance of openLDAP
by shailesh.bhirud＠omgeo.com 06 May '15

06 May '15

Full_Name: Shailesh Bhirud Version: OpenLDAP 2.4.40 OS: Windows 2008 R2 Enterprise URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (38.88.218.2) Hi I am getting the following error message and would like to know if anyone has any idea as to why I am getting it: 554a52b4 2.5.13.0 (objectIdentifierMatch): 554a52b4 matchingRuleUse: ( 2.5.13.0 NAME 'objectIdentifierMatch' APPLIES ( s edControl $ supportedExtension $ supportedFeatures $ supportedApplicationContext ) ) 554a52b4 slapd startup: initiated. 554a52b5 backend_startup_one: starting "cn=config" 554a52b5 config_back_db_open Backend ACL: access to * by * none 554a52b5 config_back_db_open: line 0: warning: cannot assess the validity of the ACL scope within backend naming context 554a52b5 config_back_db_open: No explicit ACL for back-config configured. Using hardcoded default 554a52b5 config_build_entry: "cn=config" 554a52b5 config_build_entry: "cn=schema" 554a52b5 >>> dnNormalize: <cn={0}core> 554a52b5 <<< dnNormalize: <cn={0}core> 554a52b5 config_build_entry: "cn={0}core" 554a52b5 >>> dnNormalize: <cn={1}cosine> 554a52b5 <<< dnNormalize: <cn={1}cosine> 554a52b5 config_build_entry: "cn={1}cosine" 554a52b5 >>> dnNormalize: <cn={2}nis> 554a52b5 <<< dnNormalize: <cn={2}nis> 554a52b5 config_build_entry: "cn={2}nis" 554a52b5 >>> dnNormalize: <cn={3}inetorgperson> 554a52b5 <<< dnNormalize: <cn={3}inetorgperson> 554a52b5 config_build_entry: "cn={3}inetorgperson" 554a52b5 >>> dnNormalize: <cn={4}openldap> 554a52b5 <<< dnNormalize: <cn={4}openldap> 554a52b5 config_build_entry: "cn={4}openldap" 554a52b5 >>> dnNormalize: <cn={5}dyngroup> 554a52b5 <<< dnNormalize: <cn={5}dyngroup> 554a52b5 config_build_entry: "cn={5}dyngroup" 554a52b5 config_build_entry: "olcDatabase={-1}frontend" 554a52b5 config_build_entry: "olcDatabase={0}config" 554a52b5 config_build_entry: "olcDatabase={1}bdb" 554a52b5 backend_startup_one: starting "dc=maxcrc,dc=com" 554a52b5 bdb_db_open: "dc=maxcrc,dc=com" 554a52b5 bdb_db_open: database "dc=maxcrc,dc=com": database already in use. 554a52b5 backend_startup_one (type=bdb, suffix="dc=maxcrc,dc=com"): bi_db_open failed! (-1) 554a52b5 slapd shutdown: initiated 554a52b5 ====> bdb_cache_release_all 554a52b5 slapd destroy: freeing system resources. 554a52b5 slapd stopped. C:\OpenLDAP> ------------------------ Thanks very much. I would really appreciate prompt reply. -Shailesh

1 0

(ITS#8133) segfault at startup with memberof+dds
by alexoz66＠gmail.com 06 May '15

06 May '15

Full_Name: John Alex. Version: 2.4.40 OS: FreeBSD 9.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (91.140.25.22) When those two overlays are configured in this order: {0}memberof, {1}dds, slapd will segfault at startup if dds finds a dynamicObject entry that is past its expiration time. This does not occur if an object expires while slapd is running, only during startup. Changing the order of those overlays to be {0}dds, {1}memberof avoids this issue. Sample config (without schema entries): dn: cn=config objectClass: olcGlobal cn: config olcConfigDir: slapd.d olcArgsFile:2F2Fvar/run/openldap/slapd.args olcAttributeOptions: lang- olcLogLevel: stats olcPidFile: /var/run/openldap/slapd.pid dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/local/libexec/openldap olcModuleLoad: {0}back_mdb dn: olcDababase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=extern al,cn=auth" manage by * break olcAccess: {1}to dn.base="" by * read olcAccess: {2}to dn.base="cn=subschema" by * read olcSchemaDN: cn=Subschema dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=extern lal,cn=auth" manage olcAddContentAcl: TRUE olcRootDN: cn=admin,cn=config dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /var/db/openldap-data/testing olcSuffix: dc=example,dc=com olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=extern al,cn=auth" manage by * break olcAccess: {1}to attrs=userPassword by anonymous auth olcAccess: {2}to dn.base="dc=example,dc=com"yby * read olcRootDN: cn=admin,dc=example,dc=com olcDbIndex: objectClass eq olcDbIndex: ou,uid eq olcDbIndex: entryExpireTimestamp eq olcDbMaxSize: 4294967296 dn: olcOverlay={0}memberof,olcDatabase={1}mdb,cn=config objectClass: olcMemberOf objectClass: olcOverlayConfig objectClass: olcConfig objectClass: top olcOverlay: {0}memberof dn: olcOverlay={1}dds,olcDatabase={1}mdb,cn=config objectClass: olcDDSConfig objectClass: olcOverlayConfig objectClass: olcConfig objectClass: top olcOverlay: {1}dds olcDDSinterval: 60 Steps to reproduce: 1. Create a dynamicObject entry, set a ttl of 60 seconds 2. Shut down the openldap server 3. Wait a couple minutes, then start the server

1 0

(ITS#8132) Slightly confusing documentation
by elecharny＠apache.org 06 May '15

06 May '15

Full_Name: Emmanuel Lecharny Version: 2.4.40 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2a01:e34:ec0b:b180:cd03:5409:b5fe:aa99) The slapd-config man page content on the olcServerID parameter is a bit confusing : 'Specify an integer ID from 0 to 4095 for this server (limited to 3 hexadecimal digits). The ID may also be specified as a hexa‐ decimal ID by prefixing the value with "0x".'... If it's an integer, like 4095, why is it limited to 3 hexadecimal digits, when 4 digits would be required ? If you have to enter FFF for 4095, then should we add the 0x prefix ? All in all, it's hard for me to know if those values are accepted : - 4095 - FFF also is : - 100 considered as 100 (decimal) or 256 (decimal) ?

1 0

Re: (ITS#8128) pwdFailureTime on client authentication
by ryan＠openldap.org 06 May '15

06 May '15

Hi, On Wed, May 06, 2015 at 04:46:05AM +0000, shashikanthbussa(a)gmail.com wrote: >Currently i configured openldap2.4 on RHEL6.5 with Syncrepl replication. Which 2.4 release? RHEL 6 ships a very old OpenLDAP version, and many bugs have been fixed since; so if you are using Red Hat's package, I would recommend trying again with a recent version built from source, or with packages such as those supplied by Symas or ltb-project.org. >When i use to lock the user with ldapwhoami am able to lock a and check the >pwdfailureTime it is enforced. But when i try to lock the user account using >ssh/Putty session. it is not locking the user account or PwdFailureTime not >enforcing. But, When i logged in to the ssh putty session the failure attributes >on the user is removed. > >Can anyone please advice me on the issue. Whether should i add any ACL >permissions or any configuration changes . The ITS is for bug reports only. Support requests should be directed to the openldap-technical mailing list. Please consult that list for assistance with making sure your setup is correct and not subject to any known or already-fixed bugs, and follow up here with more details if it turns out you are reporting an actual bug. Thanks!

1 0

Re: (ITS#8130) ldif export / import issue when memberURL used in groupOfURLs object class
by ryan＠openldap.org 06 May '15

06 May '15

Hi Awnish, On Wed, May 06, 2015 at 08:00:02AM +0000, awnish.kumar.singh(a)accenture.com wrote: >2>> But when I am exporting the ldif file, then dynamically populated attributes >in groupOfURLs objects and their values are also getting exported in the ldif >file, which should not happen because it is creating issue when I am trying to >import the same ldif in the destination environment. How are you doing that export? slapcat(8) is the tool that you should use to dump a slapd database. >3>> The reason is, these dynamically populated attributes in groupOfURLs object >is not the part of dyngroup.schema (because it is dynamically populated from >other object) thats why during ldif IMPORT in the target environment, ldap is >expecting these attributes should be part of dyngroup.schema and then will allow >the import, and because this not allowed to import the data. Normally those attributes should not be present in a slapcat(8) dump. If you are finding that they are, would you please provide an example configuration with clear and complete steps to reproduce it? >What is the solution for this? As per my understanding product should support to >migrate the ldif or other configuration from one environment to other without >any issue, this industry standard. I am looking for help on this issue from >community. Thanks Community support is handled on the openldap-technical mailing list; the ITS is for bug reports only. I would suggest that you consult that list for help, and follow up here again if the consensus is that you are doing things correctly and have encountered a bug. Thanks!

1 0

(ITS#8131) Improvibg back-meta logs
by elecharny＠apache.org 06 May '15

06 May '15

Full_Name: Version: 2.4.40 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2a01:e34:ec0b:b180:cd03:5409:b5fe:aa99) The back-meta backend does not log the error text when some LDAP_OTHER error. Here is a patch for that : diff --git a/servers/slapd/back-meta/conn.c b/servers/slapd/back-meta/conn.c index 44892a8..fb59be4 100644 --- a/servers/slapdFbFback-meta/conn.c +++ b/servers/slapd/back-meta/conn.c @@ -472,7 +472,8 @@ retry:; rc = ldap_result( msc->msc_ld, msgid, LDAP_MSG_ALL, &tv, &res ); switch ( rc ) { case -1: - rs->sr_err = LDAP_OTHER; + rs->sr_err = LDAP_UNAVAILABLE; + rs->sr_text = "Remote server down"; break; case 0: @@ -484,6 +485,7 @@ retry:; goto retry; } rs->sr_err = LDAP_OTHER; + rs->sr_text = "Timeout, no more retries"; break; default: @0 0 -534,6 +536,8 @@ retry:; } else { rs->sr_err = LDAP_OTHER; + rs->sr_text = "Unknown response to StartTLS request ," + " an ExtendedResponse is expected"; } if ( res != NULL ) { @@ -674,6 +678,12 @@ error_return:; } if ( rs-%srsr_err != LDAP_SUCCESS ) { + /* Get the error message and print it in TRACE mode */ + if ( LogTest( LDAP_DEBUG_TRACE ) ) { + Log4( LDAP_DEBUG_TRACE, ldap_syslog_level, "%s: meta_back_init_one_conn[%d] failed err=%d text=%s\n", +9%9 op->o_log_prefix, candidate, rs->sr_err, rs->sr_text ); + } + rs->sr_err = slap_map_api2result( rs ); if ( sendok & LDAP_BACK_SENDERR ) { send_ldap_result( op, rs ); @@ -1583,12 +1593,12 @@ retry_lock2:; err = lerr; if ( lerr == LDAP_UNAVAILAE E && mt->mt_isquarantined != LDAP_BACK_FQ_NO ) { - Debug( LDAP_DEBUG_TRACE, "%s: meta_back_getconn[%d] quarantined err=%d\n", - op->o_log_prefix, i, lerr ); + Log4( LDAP_DEBUG_TRACE, ldap_syslog_level, "%s: meta_back_getconn[%d] quarantined err=%d text=%s\n", + op->o_log_prefix, i, lerr, rs->sr_text ); } else { - Debug( LDAP_DEBUG_ANY, "%s: meta_back_getconn[%d] failed err=%d\n", - op->o_log_prefix, i, lerr ); + Log4( LDAP_DEBUG_ANY, ldap_syslog, "%s: meta_back_getconn[%d] failed err=%d text=%s\n", + op->o_log_prefix, i, lerr, rs->sr_text ); } if ( META_BACK_ONERR_STOP( mi ) ) { diff --git a/servers/slapd/back-meta/search.c b/servers/slapd/back-meta/search.c index 4604901..af5593f 100644 --- a/servers/slapd/back-meta/search.c +++ b/servers/slapd/back-meta/search.c @@ -1526,8 +1526,9 @@ really_bad:; Debug( LDAP_DEBUG_TRACE, "%s.\n", buf, 0, 0 ); } else { - Debug( LDAP_DEBUG_ANY, "%s (%s).\n", - buf, ldap_err2string( candidates[ i ].sr_err ), 0 ); + Debug( LDAP_DEBUG_ANY, "%s (%s) text=\"%s\".\n", + buf, ldap_err2string( candidates[ i ].sr_err ), + candidates[ i ].sr_text ? candidates[i].sr_text : "" ); } }

1 0

(ITS#8130) ldif export / import issue when memberURL used in groupOfURLs object class
by awnish.kumar.singh＠accenture.com 06 May '15

06 May '15

Full_Name: Awnish Kumar Singh Version: openldap-2.4.38 OS: Windows and Linux both URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (144.36.231.227) I am using OpenLDAP and facing issue during the ldif file IMPORT in the target environment, but successfully EXPORTED from source which is same in configuration. (Even I tested it with the same environment as a source as well as destination) ISSUE IN DETAIL: 1>> I have used memberURL attribute in groupOfURLs object class, and configured the memberURL values to populate the certain attributes & their values in groupOfURLs objects from other pointed source object. So due to this configuration required attributes and their values are getting populated dynamically from pointed source object to groupOfURLs target object properly. 2>> But when I am exporting the ldif file, then dynamically populated attributes in groupOfURLs objects and their values are also getting exported in the ldif file, which should not happen because it is creating issue when I am trying to import the same ldif in the destination environment. 3>> The reason is, these dynamically populated attributes in groupOfURLs object is not the part of dyngroup.schema (because it is dynamically populated from other object) thats why during ldif IMPORT in the target environment, ldap is expecting these attributes should be part of dyngroup.schema and then will allow the import, and because this not allowed to import the data. What is the solution for this? As per my understanding product should support to migrate the ldif or other configuration from one environment to other without any issue, this industry standard. I am looking for help on this issue from community. Thanks

1 0

(ITS#8129) ignored config variable autocommit for back-sql
by daniel.chobe＠dimensiondata.com 06 May '15

06 May '15

Full_Name: Daniel Chobe Version: 2.4.40 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.111.74.244) This bug is related to ITS#6613. In this bug a new configvariable named autocommit was introduced. But the flagmask in config.c was wrong, so setting this config variable has no influence to the behavior of the slapd. The Patch is very simply replace SQL_AUTOCOMMIT with BSQL_AUTOCOMMIT. diff -rupN 1/servers/slapd/back-sql/config.c 2/servers/slapd/back-sql/config.c --- 1/servers/slapd/back-sql/config.c 2013-11-15 04:31:27.000000000 +0100 +++ 2/servers/slapd/back-sql/config.c 2015-05-05 14:51:43.161310554 +0200 @@ -210,7 +210,7 @@ static ConfigTable sqlcfg[] = { "DESC 'Quoting char of the aliasing keyword' " "SYNTAX OMsDirectoryString SINGLE-VALUE )", NULL, NULL }, { "autocommit", "yes|no", 2, 2, 0, - ARG_ON_OFF|ARG_MAGIC|SQL_TOCOCOMMIT, (void *)sql_cf_gen, + ARG_ON_OFF|ARG_MAGIC|BSQL_AUTOCOMMIT, (void *)sql_cf_gen, "( OLcfgDbAt:6.45 NAME 'olcSqlAutocommit' " "SYNTAX OMsBoolean SINGLE-VALUE )", NULL, NULL }, { NULL, NULL, 0, 0, 0, ARG_IGNORED,

1 0

Re: Re: (ITS#8127) 32 bit windows build fails with mingw
by Frank.Offermanns＠caseris.de 06 May '15

06 May '15

Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 00233070C1257E3D_= Content-Type: text/plain; charset="US-ASCII" Hi, thanks for your patch. But since I am compilling 32 Bit, it doesn't work. I modified your patch to #define ftello ftell Then it works. But I still have the GetFileSizeEx problem. I use MinGW-5.1.6 and here is my installed.ini: [settings] mirror= installtype=current [components] runtime=mingwrt-3.17-mingw32-dev.tar.gz w32api=w32api-3.14-mingw32-dev.tar.gz binutils=binutils-2.20-1-mingw32-bin.tar.gz core=gcc-core-3.4.5-20060117-3.tar.gz gpp=gcc-g++-3.4.5-20060117-3.tar.gz g77= ada= java= objc=gcc-objc-3.4.5-20060117-3.tar.gz make=make-3.81-20090914-mingw32-bin.tar.gz runtimeDLL=mingwrt-3.17-mingw32-dll.tar.gz Regards, Frank Von: ebackes(a)symas.com An: openldap-its(a)OpenLDAP.org Datum: 05.05.2015 20:40 Betreff: Re: (ITS#8127) 32 bit windows build fails with mingw Gesendet von: "openldap-bugs" <openldap-bugs-bounces(a)openldap.org> This is a multi-part message in MIME format. --Multipart=_Tue__5_May_2015_11_37_19_-0700_mOvLt1ph20aiKu+q Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hello, Give this a try; it's a patch vs RE24 but should be broadly applicable. Still investigating your trouble with GetFileSizeEx from mdb.c. Which MinGW distribution are you using, exactly? -- Emily Backes Symas Corporation ebackes(a)symas.com --Multipart=_Tue__5_May_2015_11_37_19_-0700_mOvLt1ph20aiKu+q Content-Type: text/x-diff; name="0001-ftello-compat-for-windows-slapadd-meter.patch" Content-Disposition: attachment; filename="0001-ftello-compat-for-windows-slapadd-meter.patch" Content-Transfer-Encoding: 7bit >From 330ee6483c404d7e993df41f55a490c7b34ea2bf Mon Sep 17 00:00:00 2001 From: Emily Backes <ebackes(a)symas.com> Date: Thu, 5 Feb 2015 18:56:51 -0800 Subject: [PATCH] ftello compat for windows slapadd meter --- servers/slapd/slapadd.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/servers/slapd/slapadd.c b/servers/slapd/slapadd.c index 8cfdebd..29a3ff4 100644 --- a/servers/slapd/slapadd.c +++ b/servers/slapd/slapadd.c @@ -44,6 +44,10 @@ extern int slap_DN_strict; /* dn.c */ static char csnbuf[ LDAP_PVT_CSNSTR_BUFSIZE ]; +#ifdef _WIN32 +#define ftello _ftelli64 +#endif + typedef struct Erec { Entry *e; unsigned long lineno; -- Emily Backes Symas Corporation ebackes(a)symas.com --Multipart=_Tue__5_May_2015_11_37_19_-0700_mOvLt1ph20aiKu+q-- --=_alternative 00233070C1257E3D_= Content-Type: text/html; charset="US-ASCII" <font size=2 face="sans-serif">Hi,</font> <br> <br><font size=2 face="sans-serif">thanks for your patch. But since I am compilling 32 Bit, it doesn't work. </font> <br><font size=2 face="sans-serif">I modified your patch to </font> <br><font size=2 face="sans-serif">#define ftello ftell</font> <br><font size=2 face="sans-serif">Then it works. </font> <br> <br><font size=2 face="sans-serif">But I still have the GetFileSizeEx problem. </font> <br><font size=2 face="sans-serif">I use MinGW-5.1.6 and here is my installed.ini:</font> <br><font size=2 face="sans-serif">[settings]</font> <br><font size=2 face="sans-serif">mirror=</font> <br><font size=2 face="sans-serif">installtype=current</font> <br> <br><font size=2 face="sans-serif">[components]</font> <br><font size=2 face="sans-serif">runtime=mingwrt-3.17-mingw32-dev.tar.gz</font> <br><font size=2 face="sans-serif">w32api=w32api-3.14-mingw32-dev.tar.gz</font> <br><font size=2 face="sans-serif">binutils=binutils-2.20-1-mingw32-bin.tar.gz</font> <br><font size=2 face="sans-serif">core=gcc-core-3.4.5-20060117-3.tar.gz</font> <br><font size=2 face="sans-serif">gpp=gcc-g++-3.4.5-20060117-3.tar.gz</font> <br><font size=2 face="sans-serif">g77=</font> <br><font size=2 face="sans-serif">ada=</font> <br><font size=2 face="sans-serif">java=</font> <br><font size=2 face="sans-serif">objc=gcc-objc-3.4.5-20060117-3.tar.gz</font> <br><font size=2 face="sans-serif">make=make-3.81-20090914-mingw32-bin.tar.gz</font> <br><font size=2 face="sans-serif">runtimeDLL=mingwrt-3.17-mingw32-dll.tar.gz</font> <br> <br><font size=2 face="sans-serif">Regards,</font> <br><font size=2 face="sans-serif">Frank</font> <br> <br> <br> <br> <br><font size=1 color=#5f5f5f face="sans-serif">Von:        </font><font size=1 face="sans-serif">ebackes(a)symas.com</font> <br><font size=1 color=#5f5f5f face="sans-serif">An:        </font><font size=1 face="sans-serif">openldap-its(a)OpenLDAP.org</font> <br><font size=1 color=#5f5f5f face="sans-serif">Datum:        </font><font size=1 face="sans-serif">05.05.2015 20:40</font> <br><font size=1 color=#5f5f5f face="sans-serif">Betreff:        </font><font size=1 face="sans-serif">Re: (ITS#8127) 32 bit windows build fails with mingw</font> <br><font size=1 color=#5f5f5f face="sans-serif">Gesendet von:        </font><font size=1 face="sans-serif">"openldap-bugs" <openldap-bugs-bounces(a)openldap.org></font> <br> <hr noshade> <br> <br> <br><tt><font size=2>This is a multi-part message in MIME format.<br> <br> --Multipart=_Tue__5_May_2015_11_37_19_-0700_mOvLt1ph20aiKu+q<br> Content-Type: text/plain; charset=US-ASCII<br> Content-Transfer-Encoding: 7bit<br> <br> Hello,<br> <br> Give this a try; it's a patch vs RE24 but should be broadly<br> applicable.  Still investigating your trouble with GetFileSizeEx from<br> mdb.c.<br> <br> Which MinGW distribution are you using, exactly?<br> <br> -- <br> Emily Backes<br> Symas Corporation<br> ebackes(a)symas.com<br> <br> --Multipart=_Tue__5_May_2015_11_37_19_-0700_mOvLt1ph20aiKu+q<br> Content-Type: text/x-diff;<br> name="0001-ftello-compat-for-windows-slapadd-meter.patch"<br> Content-Disposition: attachment;<br> filename="0001-ftello-compat-for-windows-slapadd-meter.patch"<br> Content-Transfer-Encoding: 7bit<br> <br> >From 330ee6483c404d7e993df41f55a490c7b34ea2bf Mon Sep 17 00:00:00 2001<br> From: Emily Backes <ebackes(a)symas.com><br> Date: Thu, 5 Feb 2015 18:56:51 -0800<br> Subject: [PATCH] ftello compat for windows slapadd meter<br> <br> ---<br> servers/slapd/slapadd.c | 4 ++++<br> 1 file changed, 4 insertions(+)<br> <br> diff --git a/servers/slapd/slapadd.c b/servers/slapd/slapadd.c<br> index 8cfdebd..29a3ff4 100644<br> --- a/servers/slapd/slapadd.c<br> +++ b/servers/slapd/slapadd.c<br> @@ -44,6 +44,10 @@ extern int slap_DN_strict;                 /* dn.c */<br> <br> static char csnbuf[ LDAP_PVT_CSNSTR_BUFSIZE ];<br> <br> +#ifdef _WIN32<br> +#define ftello _ftelli64<br> +#endif <br> +<br> typedef struct Erec {<br>                  Entry *e;<br>                  unsigned long lineno;<br> -- <br> Emily Backes<br> Symas Corporation<br> ebackes(a)symas.com<br> <br> <br> --Multipart=_Tue__5_May_2015_11_37_19_-0700_mOvLt1ph20aiKu+q--<br> <br> <br> <br> </font></tt> <br> <br> --=_alternative 00233070C1257E3D_=--

1 0

Re: (ITS#8128) pwdFailureTime on client authentication
by shashikanthbussa＠gmail.com 06 May '15

06 May '15

--047d7b5d824dfd0784051563d8af Content-Type: text/plain; charset=UTF-8 slapd.conf file configuration and am using this configuration file to convert in to slapd.d/ include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/ppolicy.schema allow bind_v2 pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args modulepath /usr/lib64/openldap moduleload accesslog.la moduleload lastmod.la moduleload ppolicy.la moduleload syncprov.la moduleload unique.la access to attrs=userPassword by self =xw by anonymous auth by * none access to * by self write by * read database bdb suffix "dc=company,dc=com" rootdn "cn=Manager,dc=company,dc=com" rootpw {SSHA}k1FcYbzJYXKAPKbjO6g9bNy6+Hkaskla directory /var/lib/ldap index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub index nisMapName,nisMapEntry eq,pres,sub overlay ppolicy ppolicy_default "cn=default,ou=Policies,dc=company,dc=com" ppolicy_use_lockout overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 syncprov-checkpoint 10 1 syncprov-sessionlog 100 serverID 1 syncrepl rid=1 provider=ldap://server2 type=refreshAndPersist interval=00:00:00:10 retry="5 10 60 +" timeout=1 schemachecking=off searchbase="dc=company,dc=com" scope=sub bindmethod=simple binddn="cn=Manager,dc=company,dc=com" credentials="secret" mirrormode TRUE updateref ldap://server2 database monitor -- If you need any further information regarding me and my profile please call me on xxxxxxxxx or mail to shashikanthbussa(a)gmail.com *Thanks and Regards,* *Shashikanth.B* --047d7b5d824dfd0784051563d8af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">slapd.conf file configuration and am using this configurat= ion file to convert in to slapd.d/<div><br></div><div><br></div><div><div>i= nclude =C2=A0 =C2=A0 =C2=A0 =C2=A0 /etc/openldap/schema/core.schema</div><d= iv>include =C2=A0 =C2=A0 =C2=A0 =C2=A0 /etc/openldap/schema/cosine.schema</= div><div>include =C2=A0 =C2=A0 =C2=A0 =C2=A0 /etc/openldap/schema/inetorgpe= rson.schema</div><div>include =C2=A0 =C2=A0 =C2=A0 =C2=A0 /etc/openldap/sch= ema/nis.schema</div><div>include =C2=A0 =C2=A0 =C2=A0 =C2=A0 /etc/openldap/= schema/ppolicy.schema</div><div>allow bind_v2</div><div>pidfile =C2=A0 =C2= =A0 =C2=A0 =C2=A0 /var/run/openldap/slapd.pid</div><div>argsfile =C2=A0 =C2= =A0 =C2=A0 =C2=A0/var/run/openldap/slapd.args</div><div>modulepath =C2=A0 = =C2=A0 =C2=A0/usr/lib64/openldap</div><div>moduleload <a href=3D"http://acc= esslog.la">accesslog.la</a></div><div>moduleload <a href=3D"http://lastmod.= la">lastmod.la</a></div><div>moduleload <a href=3D"http://ppolicy.la">ppoli= cy.la</a></div><div>moduleload <a href=3D"http://syncprov.la">syncprov.la</= a></div><div>moduleload <a href=3D"http://unique.la">unique.la</a></div><di= v>access to attrs=3DuserPassword</div><div>=C2=A0 =C2=A0 =C2=A0 by self =3D= xw</div><div>=C2=A0 =C2=A0 =C2=A0 by anonymous auth</div><div>=C2=A0 =C2=A0= =C2=A0 by * none</div><div>access to *</div><div>=C2=A0 =C2=A0 =C2=A0 by s= elf write</div><div>=C2=A0 =C2=A0 =C2=A0 by * read</div><div>database =C2= =A0 =C2=A0 =C2=A0 =C2=A0bdb</div><div>suffix =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0"dc=3Dcompany,dc=3Dcom"</div><div>rootdn =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0"cn=3DManager,dc=3Dcompany,dc=3Dcom"</div><div>r= ootpw =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{SSHA}k1FcYbzJYXKAPKbjO6g9bNy6+Hkas= kla</div><div>directory =C2=A0 =C2=A0 =C2=A0 /var/lib/ldap</div><div>index = objectClass =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 eq,pres</div><div>index ou,cn,mail,surname,givenname =C2=A0 = =C2=A0 =C2=A0eq,pres,sub</div><div>index uidNumber,gidNumber,loginShell =C2= =A0 =C2=A0eq,pres</div><div>index uid,memberUid =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 eq,pres,sub</div><div>index nisM= apName,nisMapEntry =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0eq,pres,sub</di= v><div>overlay ppolicy</div><div>ppolicy_default "cn=3Ddefault,ou=3DPo= licies,dc=3Dcompany,dc=3Dcom"</div><div>ppolicy_use_lockout</div><div>= overlay =C2=A0 =C2=A0 =C2=A0 =C2=A0 syncprov</div><div>syncprov-checkpoint = 100 10</div><div>syncprov-sessionlog 100</div><div>syncprov-checkpoint =C2= =A0 =C2=A0 10 1</div><div>syncprov-sessionlog =C2=A0 =C2=A0 100</div><div>s= erverID =C2=A0 =C2=A0 =C2=A0 =C2=A01</div><div>syncrepl =C2=A0 =C2=A0 =C2= =A0 =C2=A0rid=3D1</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 provider=3Dldap://server2</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 type=3DrefreshAndPersist</div><div>=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 interval=3D00:00:00:10</div><= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 retry=3D"5= 10 60 +"</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 timeout=3D1</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 schemachecking=3Doff</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 searchbase=3D"dc=3Dcompany,dc=3Dcom"</di= v><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 scope=3Dsub<= /div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bindmetho= d=3Dsimple</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 binddn=3D"cn=3DManager,dc=3Dcompany,dc=3Dcom"</div><div>=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 credentials=3D"se= cret"</div><div>mirrormode =C2=A0 =C2=A0 =C2=A0TRUE</div><div>updatere= f ldap://server2</div><div>database =C2=A0 =C2=A0 =C2=A0 =C2=A0monitor</div= ><div><br></div><div><br></div>-- <br><div class=3D"gmail_signature"><div d= ir=3D"ltr"><div><div style=3D"font-family:arial;font-size:small"><font colo= r=3D"#000000" face=3D"Arial, Helvetica, sans-serif"><br>If you need any fur= ther information regarding me and my profile please call me on xxxxxxxxx or= mail to <a href=3D"mailto:shashikanthbussa@gmail.com" target=3D"_blank">sh= ashikanthbussa(a)gmail.com</a></font></div><div style=3D"font-family:arial;fo= nt-size:small"><br></div></div><b><font size=3D"2" face=3D"verdana, sans-se= rif">Thanks and Regards,</font></b><div><b><font size=3D"2" face=3D"verdana= , sans-serif"><br></font></b></div><div><b><font size=3D"2" face=3D"verdana= , sans-serif">Shashikanth.B</font></b></div><div><br></div></div></div> </div></div> --047d7b5d824dfd0784051563d8af--

1 0

(ITS#8128) pwdFailureTime on client authentication
by shashikanthbussa＠gmail.com 06 May '15

06 May '15

Full_Name: shashikanth.bussa Version: 2.4 OS: RHEL 6.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (115.160.252.10) Currently i configured openldap2.4 on RHEL6.5 with Syncrepl replication. When i use to lock the user with ldapwhoami am able to lock a and check the pwdfailureTime it is enforced. But when i try to lock the user account using ssh/Putty session. it is not locking the user account or PwdFailureTime not enforcing. But, When i logged in to the ssh putty session the failure attributes on the user is removed. Can anyone please advice me on the issue. Whether should i add any ACL permissions or any configuration changes .

1 0

Re: (ITS#8127) 32 bit windows build fails with mingw
by ebackes＠symas.com 05 May '15

05 May '15

This is a multi-part message in MIME format. --Multipart=_Tue__5_May_2015_11_37_19_-0700_mOvLt1ph20aiKu+q Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hello, Give this a try; it's a patch vs RE24 but should be broadly applicable. Still investigating your trouble with GetFileSizeEx from mdb.c. Which MinGW distribution are you using, exactly? -- Emily Backes Symas Corporation ebackes(a)symas.com --Multipart=_Tue__5_May_2015_11_37_19_-0700_mOvLt1ph20aiKu+q Content-Type: text/x-diff; name="0001-ftello-compat-for-windows-slapadd-meter.patch" Content-Disposition: attachment; filename="0001-ftello-compat-for-windows-slapadd-meter.patch" Content-Transfer-Encoding: 7bit >From 330ee6483c404d7e993df41f55a490c7b34ea2bf Mon Sep 17 00:00:00 2001 From: Emily Backes <ebackes(a)symas.com> Date: Thu, 5 Feb 2015 18:56:51 -0800 Subject: [PATCH] ftello compat for windows slapadd meter --- servers/slapd/slapadd.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/servers/slapd/slapadd.c b/servers/slapd/slapadd.c index 8cfdebd..29a3ff4 100644 --- a/servers/slapd/slapadd.c +++ b/servers/slapd/slapadd.c @@ -44,6 +44,10 @@ extern int slap_DN_strict; /* dn.c */ static char csnbuf[ LDAP_PVT_CSNSTR_BUFSIZE ]; +#ifdef _WIN32 +#define ftello _ftelli64 +#endif + typedef struct Erec { Entry *e; unsigned long lineno; -- Emily Backes Symas Corporation ebackes(a)symas.com --Multipart=_Tue__5_May_2015_11_37_19_-0700_mOvLt1ph20aiKu+q--

1 0

(ITS#8127) 32 bit windows build fails with mingw
by Frank.Offermanns＠caseris.de 05 May '15

05 May '15

Full_Name: Frank Offermanns Version: 2.4.40 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.7.149.50) Build fails for 32 bit msys/mingw (and config --prefix=/mingw --enable-accesslog --with-tls --enable-syncprov) Probably only 32 bit windows build has this error. slapadd.o: In function `getrec0': C:/msys/1.0/openldap-2.4.41Git/servers/slapd/slapadd.c:116: undefined reference to `ftello' slapadd.o: In function `slapadd': C:/msys/1.0/openldap-2.4.41Git/servers/slapd/slapadd.c:486: undefined reference to `ftello' libbackends.a(mdbmdb.o): In function `mdb_cursor_push': C:/msys/1.0/openldap-2.4.41Git/servers/slapd/back-mdb/./../../../libraries/liblm db/mdb.c:5001: undefined reference to `GetFileSizeEx' collect2: ld returned 1 exit status make[2]: *** [slapd.exp] Error 1 make[2]: Leaving directory `/openldap-2.4.41Git/servers/slapd' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/openldap-2.4.41Git/servers' make: *** [all-common] Error 1

1 0

(ITS#8126) pwdFailureTime on client authentication
by shashikanthbussa＠gmail.com 05 May '15

05 May '15

Full_Name: shashikanth.bussa Version: 2.4 OS: RHEL 6.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (115.160.252.10) Currently i configured openldap2.4 on RHEL6.5 with Syncrepl replication. When i use to lock the user with ldapwhoami am able to lock a and check the pwdfailureTime it is enforced. But when i try to lock the user account using ssh/Putty session. it is not locking the user account or PwdFailureTime not enforcing. But, When i logged in to the ssh putty session the failure attributes on the user is removed. Can anyone please advice me on the issue. Whether should i add any ACL permissions or any configuration changes .

1 0

(ITS#8125) MMR throws away valid changes causing drift
by quanah＠openldap.org 04 May '15

04 May '15

Full_Name: Quanah Gibson-Mount Version: RE24 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.52.177) On Friday May 1st, reloaded mmr00 from mmr01, so they had exactly the same dataset. Since Friday, significant drift has occurred between the two nodes. One example is the following MODRDN request that was made to mmr00. Note: Clocks are tightly in sync between both nodes. On MMR00, we see the modrdn occur: May 1 16:10:18 zm-mmr00 slapd[52931]: conn=13581 op=2 MODRDN dn="uid=xxxxxx,ou=people,dc=yyyy,dc=net" May 1 16:10:18 zm-mmr00 slapd[52931]: conn=1145 op=181451 SEARCH RESULT tag=101 err=0 nentries=1 text= May 1 16:10:18 zm-mmr00 slapd[52931]: slap_queue_csn: queueing 0x7f2b8c8931c0 20150501201018.574740Z#000000#002#000000 May 1 16:10:18 zm-mmr00 slapd[52931]: slap_queue_csn: queueing 0x14ebeb40 20150501201018.574740Z#000000#002#000000 May 1 16:10:18 zm-mmr00 slapd[52931]: slap_graduate_commit_csn: removing 0x1d53e480 20150501201018.574740Z#000000#002#000000 May 1 16:10:18 zm-mmr00 slapd[52931]: conn=13581 op=2 RESULT tag=109 err=0 text= May 1 16:10:18 zm-mmr00 slapd[52931]: slap_graduate_commit_csn: removing 0x10be8520 20150501201018.574740Z#000000#002#000000 Everything looks good on this host. Now on to MMR01... nearly 1.5 HOURS LATER WE SEE: May 1 17:27:36 zm-mmr01 slapd[43243]: syncrepl_message_to_op: rid=100 be_modify uid=someotherentry,ou=people,dc=differentdomain,dc=com (0) May 1 17:27:36 zm-mmr01 slapd[43243]: do_syncrep2: rid=100 cookie=rid=100,sid=002,csn=20150501201017.390034Z#000000#00b#000000 May 1 17:27:36 zm-mmr01 slapd[43243]: do_syncrep2: rid=100 CSN too old, ignoring 20150501201017.390034Z#000000#00b#000000 (reqStart=20150501201017.000302Z,cn=accesslog) May 1 17:27:36 zm-mmr01 slapd[43243]: do_syncrep2: rid=100 cookie=rid=100,sid=002,csn=20150501201017.528111Z#000000#00b#000000 May 1 17:27:36 zm-mmr01 slapdC43243]: do_syncrep2: rid=100 CSN too old, ignoring 20150501201017.528111Z#000000#00b#000000 (reqStart=20150501201017.000362Z,cn=accesslog) May 1 17:27:36 zm-mmr01 slapd[43243]: do_syncrep2: rid=100 cookie=rid=100,sid=002,csn=20150501201017.619314Z#000000#00b#000000 May 1 17:27:36 zm-mmr01 slapd[43243]: do_syncrep2: rid=100 CSN too old, ignoring 20150501201017.619314Z#000000#00b#000000 (reqStart=20150501201017.000406Z,cn=accesslog) May 1 17:27:36 zm-mmr01 slapd[43243]: do_syncrep2: rid=100 cookie=rid=100,sid=002,csn=20150501201018.502559Z#000000#002#000000 May 1 17:27:36 zm-mmr01 slapd[43243]: do_syncrep2: rid=100 CSN too old, ignoring 20150501201018.502559Z#000000#002#000000 (reqStart=20150501201018.000269Z,cn=cecesslog) May 1 17:27:36 zm-mmr01 slapd[43243]: do_syncrep2: rid=100 cookie=rid=100,sid=002,csn=20150501201018.519620Z#000000#002#000000 May 1 17:27:36 zm-mmr01 slapd[43243]: do_syncrep2: rid=100 CSN too old, ignoring 20150501201018.519620Z#000000#002#000000 (reqStart=20150501201018.000289Z,cn=accesslog) May 1 17:27:36 zm-mmr01 slapd[43243]: do_syncrep2: rid=100 cookie=rid=100,sid=002,csn=20150501201018.574740Z#000000#002#000000 May 1 17:27:36 zm-mmr01 slapd[43243]: do_syncrep2: rid=100 CSN too old,gignoring 20150501201018.574740Z#000000#002#000000 (reqStart=20150501201018.000336Z,cn=accesslog) May 1 17:27:36 zm-mmr01 slapd[43243]: do_syncrep2: rid=100 cookie=rid=100,sid=002,csn=20150501201018.611377Z#000000#002#000000 May 1 17:27:36 zm-mmr01 slapd[43243]: do_syncrep2: rid=100 CSN too old, ignoring 20150501201018.611377Z#000000#002#000000 (reqStart=20150501201018.000358Z,cn=accesslog) May 1 17:27:36 zm-mmr01 slapd[43243]: do_syncrep2: rid=100 cookie=rid=100,sid=002,csn=20150501201018.577381Z#000000#00b#000000 May 1 17:27:36 zm-mmr01 slapd[43243]: do_syncrep2: rid=100 CSN too old, ignoring 20150501201018.577381Z#000000#00b#000000 (reqStart=20150501201018.000366Z,cn=accesslog) May 1 17:27:36 zm-mmr01 slapd[43243]: do_syncrep2: rid=100 cookie=rid=100,sid=002,csn=20150501201018.628228Z#000000#002#000000 May 1 17:27:36 zm-mmr01 slapd[43243]: do_syncrep2: rid=100 CSN too old, ignoring 20150501201018.628228Z#000000#002#000000 (reqStart=20150501201018.000378Z,cn=accesslog) May 1 17:27:36 zm-mmr01 slapd[43243]: do_syncrep2: rid=100 cookie=rid=100,sid=002,csn=20150501201018.648496Z#000000#002#000000 May 1 17:27:36 zm-mmr01 slapd[43243]: do_syncrep2: rid=100 CSN too old, ignoring 20150501201018.648496Z#000000#002#000000 (reqStart=20150501201018.000398Z,cn=accesslog) May 1 17:27:36 zm-mmr01 slapd[43243]: do_syncrep2: rid=100 cookie=rid=100,sid=002,csn=20150501201018.747799Z#000000#00b#000000 May 1 17:27:36 zm-mmr01 slapd[43243]: do_syncrep2: rid=100 CSN too old, ignoring 20150501201018.747799Z#000000#00b#000000 (reqStart=20150501201018.000517Z,cn=accesslog) May 1 17:27:36 zm-mmr01 slapd[43243]: do_syncrep2: rid=100 cookie=rid=100,sid=002,csn=20150501201018.926821Z#000000#00b#000000 May 1 17:27:36 zm-mmr01 slapd[43243]: do_syncrep2: rid=100 CSN too old, ignoring 20150501201018.926821Z#000000#00b#000000 (reqStart=20150501201018.000639Z,cn=accesslog) May 1 17:27:36 zm-mmr01 slapd[43243]: do_syncrep2: rid=100 cookie=rid=100,sid=002,csn=20150501201019.051637Z#000000#00b#000000 May 1 17:27:36 zm-mmr01 slapd[43243]: do_syncrep2: rid=100 CSN too old, ignoring 20150501201019.051637Z#000000#00b#000000 (reqStart=20150501201019.000052Z,cn=accesslog) May 1 17:27:36 zm-mmr01 slapd[43243]: do_syncrep2: rid=100 cookie=rid=100,sid=002,csn=20150501201019.107217Z#000000#00b#000000 May 1 17:27:36 zm-mmr01 slapd[43243]: do_syncrep2: rid=100 CSN too old, ignoring 20150501201019.107217Z#000000#00b#000000 (reqStart=20150501201019.000092Z,cn=accesslog) May 1 17:27:36 zm-mmr01 slapd[43243]: do_syncrep2: rid=100 cookie=rid=100,sid=002,csn=20150501201019.165448Z#000000#00b#000000 May 1 17:27:36 zm-mmr01 slapd[43243]: do_syncrep2: rid=100 CSN too old, ignoring 20150501201019.165448Z#000000#00b#000000 (reqStart=20150501201019.000146Z,cn=accesslog) May 1 17:27:36 zm-mmr01 slapd[43243]: do_syncrep2: rid=100 cookie=rid=100,sid=002,csn=20150501201019.221163Z#000000#00b#000000 May 1 17:27:36 zm-mmr01 slapd[43243]: do_syncrep2: rid=100 CSN too old, ignoring 20150501201019.221163Z#000000#00b#000000 (reqStart=20150501201019.000190Z,cn=accesslog) May 1 17:27:36 zm-mmr01 slapd[43243]: do_syncrep2: rid=100 cookie=rid=100,sid=002 May 1 17:27:37 zm-mmr01 slapd[43243]: do_syncrep2: rid=102 cookie=rid=102,sid=00b,csn=20150501212737.068523Z#000000#00b#000000 May 1 17:27:37 zm-mmr01 slapd[43243]: syncrepl_message_to_op: rid=102 be_modify uid=anotherdifferententry,ou=people,dc=samedomain,dc=net (0)

1 0

Re: (ITS#8117) Bugs related to key-size in lmdb and backend
by h.b.furuseth＠usit.uio.no 04 May '15

04 May '15

On 03/05/15 09:09, Howard Chu wrote: > Hallvard Breien Furuseth wrote: >> test001 still crashes if you insert >> assert(a->mv_size == sizeof(int) && b->mv_size == sizeof(int)); >> in mdb_cmp_int(). >> Using RE24 commit 98f70f1841f85d93 "ITS#8120 Move final...". > > Not happening here, all tests pass with asserts enabled. You just fixed it. Turns out your older patches to this ITS introduced that one. >> Looking yet again at the doc, mdb_dbi_open():INTEGERKEY >> says "typically" sizeof(int/size_t), I can't see it >> requires these sizes. Maybe you copied that from a >> suggestion from me back when I asked for clarifications. > > Probably. The point was to show the expected sizes without enumerating > every possible C integer type that would work - e.g. unsigned int, > unsigned long, off_t, pid_t, whatever. At some point you have to say > "don't be an idiot." Don't be an idiot. (a) then we'd just say "the architecture's native unsigned integer types" or something, it's no need to be so vague nor to drag in every typedef under the sun. And (b) that's not what the code does anyway. If I understand correctly this time, the doc should simply say that the two types size_t and unsigned int are supported. The "typically" is plain misleading. That is, if mdb_node_search() shows the intent when it picks either int-sized or size_t-sized for IS_BRANCH. OTOH, another bug: default_cmp pick cmp_int for INTEGERDUP|DUPFIXED and some other replaces md_dcmp = cmp_int with cmp_long, which makes no sense unless cmp_int is just a placeholder. Yet at least mdb_dcmp() calls that placeholder directly without checking the data size. And if it's just a placeholder, how about instead setting dcmp to something which just abort()s, to make sure the bug of not replacing it is caught? >> "keys must all be of the same size" in the doc is unclear. >> I gather it should be "... in the DB's lifetime". But it >> can be read as "...at a given time": Write size_t-sized >> integers, empty the DB, then write int-sized integers. >> That does not work, since me_dbxs[].md_dcmp is updated. > > Don't be an idiot. If no time is stated, then it's For All Time. > Anything not called out specifically is, by definition, non-specific. I can't spot the idiocy of expecting a property which springs dynamically into life, to dynamically go away when the data which caused it is gone. In particular since that's how LMDB alignment works. Anyway, that seems to be what happens after latest commit, so maybe it doesn't matter anymore. Maybe the DB flags should include log2(integer sizes) in 2 2-bit fields.

1 0

Re: (ITS#8117) Bugs related to key-size in lmdb and backend
by hyc＠symas.com 03 May '15

03 May '15

Hallvard Breien Furuseth wrote: > test001 still crashes if you insert > assert(a->mv_size == sizeof(int) && b->mv_size == sizeof(int)); > in mdb_cmp_int(). > Using RE24 commit 98f70f1841f85d93 "ITS#8120 Move final...". Not happening here, all tests pass with asserts enabled. > I don't see "same size" in the INTEGERDUP doc, it's looser > than for INTEGERKEY integers. Or have I gone blind again? > Anyway, it would be clearer to cut some doc and say data > behave like INTEGERKEY keys. Ignoring that, though: > > Looking yet again at the doc, mdb_dbi_open():INTEGERKEY > says "typically" sizeof(int/size_t), I can't see it > requires these sizes. Maybe you copied that from a > suggestion from me back when I asked for clarifications. Probably. The point was to show the expected sizes without enumerating every possible C integer type that would work - e.g. unsigned int, unsigned long, off_t, pid_t, whatever. At some point you have to say "don't be an idiot." > "keys must all be of the same size" in the doc is unclear. > I gather it should be "... in the DB's lifetime". But it > can be read as "...at a given time": Write size_t-sized > integers, empty the DB, then write int-sized integers. > That does not work, since me_dbxs[].md_dcmp is updated. Don't be an idiot. If no time is stated, then it's For All Time. Anything not called out specifically is, by definition, non-specific. > "mc->mc_dbx->md_dcmp = mdb_cmp_clong;" looks wrong. > That updates env->me_dbxs[], I believe. But: > > If we mdb_txn_abort(), the txn has not been a no-op: > It will require next txn and even existing txns to use > size_t-sized INTEGERDUP data. Good point. I've committed a revised patch to leave the mc_dbx pointer alone. -- -- 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#8124) Patch "Context for compare functions"
by rouzier＠gmail.com 03 May '15

03 May '15

--f46d0418253ce774cd051521cc5a Content-Type: text/plain; charset=UTF-8 Howard thank you for taking the time to explain your reasoning. I am curious if I were remove the conditional compilation would the patch be more palatable. Because usually if you are using an interpreted language you are already taking a performance hit. Also it only slows your program down if you use the compare functions. If answer is still no I will just maintain the patch in my own branch. James Rouzier. On Sat, May 2, 2015 at 6:04 PM, Howard Chu <hyc(a)symas.com> wrote: > rouzier(a)gmail.com wrote: > >> Full_Name: James Rouzier >> Version: LMDB mdb.master >> OS: N/A >> URL: >> https://github.com/rouzier/openldap/commit/33f1dc8be4a8503e78930f130ff9c8e5… >> Submission from: (NULL) (70.81.32.80) >> >> >> New feature inclusion request: "Context for compare functions" >> >> I am finishing up a new perl module which is a very thin wrapper for LMDB. >> (The current perl LMDB module does not fit my needs as it does not support >> NO_TLS really support). >> >> When looking at mdb_set_compare and mdb_set_dupsort. >> >> There were three choices. >> >> * Not support mdb_set_compare, mdb_set_dupsort in the module. >> * Capture each mdb_*(del|put|get) function to figure which dbi I am using. >> * Add support for contexts in the compare functions. >> >> So I decided on the latter. >> >> I understand that passing a context for each compare can add some >> overhead. >> So I made this feature optional it is only enabled if the macro >> MDB_CMP_CTX is >> enabled. >> > > I don't see supporting compare functions in interpreted languages being a > realistic/worthwhile thing to do. The difference in performance is orders > of magnitude. > > I also don't believe such conditional compilation is a good idea. LMDB is > designed to be simple, to have very few options, and to Just Work the same > on every platform. Conditionally compiled features are horrible because you > can't guess which features will be present in a system-installed library. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > --f46d0418253ce774cd051521cc5a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">Howard thank y= ou for taking the time to explain your reasoning.<div><br></div><div>I am c= urious if I were remove the conditional compilation would the patch be more= palatable.</div><div>Because usually if you are using an=C2=A0<span style= =3D"font-size:12.8000001907349px">interpreted</span>=C2=A0language you are = already taking a performance hit.</div><div>Also it only slows your program= down if you use the=C2=A0<span style=3D"font-size:12.8000001907349px">comp= are functions.</span></div><div><br></div><div>If answer is still no I will= just maintain the patch in my own branch.<span class=3D"HOEnZb"><font colo= r=3D"#888888"><br></font></span></div><span class=3D"HOEnZb"><font color=3D= "#888888"><div><br></div><div>James Rouzier.</div><div><br><br></div><div><= br></div><div><br></div><div><br></div></font></span></div><div class=3D"HO= EnZb"><div class=3D"h5"><div class=3D"gmail_extra"><br><div class=3D"gmail_= quote">On Sat, May 2, 2015 at 6:04 PM, Howard Chu <span dir=3D"ltr"><<a = href=3D"mailto:hyc@symas.com" target=3D"_blank">hyc(a)symas.com</a>></span= > wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo= rder-left:1px #ccc solid;padding-left:1ex"><a href=3D"mailto:rouzier@gmail.= com" target=3D"_blank">rouzier(a)gmail.com</a> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Full_Name: James Rouzier<br> Version: LMDB mdb.master<br> OS: N/A<br> URL: <a href=3D"https://github.com/rouzier/openldap/commit/33f1dc8be4a8503e= 78930f130ff9c8e5aa9bfa7b" target=3D"_blank">https://github.com/rouzier/open= ldap/commit/33f1dc8be4a8503e78930f130ff9c8e5aa9bfa7b</a><br> Submission from: (NULL) (70.81.32.80)<br> <br> <br> New feature inclusion request: "Context for compare functions"<br= > <br> I am finishing up a new perl module which is a very thin wrapper for LMDB.<= br> (The current perl LMDB module does not fit my needs as it does not support<= br> NO_TLS really support).<br> <br> When looking at mdb_set_compare and mdb_set_dupsort.<br> <br> There were three choices.<br> <br> * Not support mdb_set_compare, mdb_set_dupsort in the module.<br> * Capture each mdb_*(del|put|get) function to figure which dbi I am using.<= br> * Add support for contexts in the compare functions.<br> <br> So I decided on the latter.<br> <br> I understand that passing a context for each compare can add some overhead.= <br> So I made this feature optional it is only enabled if the macro MDB_CMP_CTX= is<br> enabled.<br> </blockquote> <br> I don't see supporting compare functions in interpreted languages being= a realistic/worthwhile thing to do. The difference in performance is order= s of magnitude.<br> <br> I also don't believe such conditional compilation is a good idea. LMDB = is designed to be simple, to have very few options, and to Just Work the sa= me on every platform. Conditionally compiled features are horrible because = you can't guess which features will be present in a system-installed li= brary.<span><font color=3D"#888888"><br> <br> -- <br> =C2=A0 -- Howard Chu<br> =C2=A0 CTO, Symas Corp.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"= http://www.symas.com" target=3D"_blank">http://www.symas.com</a><br> =C2=A0 Director, Highland Sun=C2=A0 =C2=A0 =C2=A0<a href=3D"http://highland= sun.com/hyc/" target=3D"_blank">http://highlandsun.com/hyc/</a><br> =C2=A0 Chief Architect, OpenLDAP=C2=A0 <a href=3D"http://www.openldap.org/p= roject/" target=3D"_blank">http://www.openldap.org/project/</a><br> </font></span></blockquote></div><br></div> </div></div></div><br></div> --f46d0418253ce774cd051521cc5a--

1 0

Re: (ITS#8124) Patch "Context for compare functions"
by hyc＠symas.com 03 May '15

03 May '15

rouzier(a)gmail.com wrote: > Full_Name: James Rouzier > Version: LMDB mdb.master > OS: N/A > URL: https://github.com/rouzier/openldap/commit/33f1dc8be4a8503e78930f130ff9c8e5… > Submission from: (NULL) (70.81.32.80) > > > New feature inclusion request: "Context for compare functions" > > I am finishing up a new perl module which is a very thin wrapper for LMDB. > (The current perl LMDB module does not fit my needs as it does not support > NO_TLS really support). > > When looking at mdb_set_compare and mdb_set_dupsort. > > There were three choices. > > * Not support mdb_set_compare, mdb_set_dupsort in the module. > * Capture each mdb_*(del|put|get) function to figure which dbi I am using. > * Add support for contexts in the compare functions. > > So I decided on the latter. > > I understand that passing a context for each compare can add some overhead. > So I made this feature optional it is only enabled if the macro MDB_CMP_CTX is > enabled. I don't see supporting compare functions in interpreted languages being a realistic/worthwhile thing to do. The difference in performance is orders of magnitude. I also don't believe such conditional compilation is a good idea. LMDB is designed to be simple, to have very few options, and to Just Work the same on every platform. Conditionally compiled features are horrible because you can't guess which features will be present in a system-installed library. -- -- 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#8124) Patch "Context for compare functions"
by rouzier＠gmail.com 02 May '15

02 May '15

Full_Name: James Rouzier Version: LMDB mdb.master OS: N/A URL: https://github.com/rouzier/openldap/commit/33f1dc8be4a8503e78930f130ff9c8e5… Submission from: (NULL) (70.81.32.80) New feature inclusion request: "Context for compare functions" I am finishing up a new perl module which is a very thin wrapper for LMDB. (The current perl LMDB module does not fit my needs as it does not support NO_TLS really support). When looking at mdb_set_compare and mdb_set_dupsort. There were three choices. * Not support mdb_set_compare, mdb_set_dupsort in the module. * Capture each mdb_*(del|put|get) function to figure which dbi I am using. * Add support for contexts in the compare functions. So I decided on the latter. I understand that passing a context for each compare can add some overhead. So I made this feature optional it is only enabled if the macro MDB_CMP_CTX is enabled. This patch does the following. * Adds context to the MDB_cmp_func typedef int (MDB_cmp_func)(const MDB_val *a, const MDB_val *b ,void* ctx); * And two new data members to the MDB_dbx struct * void *md_cmpctx; /**< user-provided context for md_cmp */ * void *md_dcmpctx; /**< user-provided context for md_dcmp */ * Add functions for setting/getting the contexts * int mdb_set_cmpctx(MDB_txn *txn, MDB_dbi dbi, void *ctx); * int mdb_set_dcmpctx(MDB_txn *txn, MDB_dbi dbi, void *ctx); * int mdb_get_cmpctx(MDB_txn *txn, MDB_dbi dbi, void **ctx); * int mdb_get_dcmpctx(MDB_txn *txn, MDB_dbi dbi, void **ctx); I have no problem maintaining this as a separate patch if it does not fit in the vision of LMDB. I believe this can be useful for people who wants to add LMDB to a scripting language. New feature inclusion request: "Context for compare functions" I am finishing up a new perl module which is a very thin wrapper for LMDB. (The current perl LMDB module does not fit my needs as it does not support NO_TLS really well). When looking at mdb_set_compare and mdb_set_dupsort. There were three choices. * Not support mdb_set_compare, mdb_set_dupsort in the module. * Capture each mdb_*(del|put|get) function to figure which dbi I am using. * Add support for contexts in the compare functions. So I decided on the latter. I understand that passing a context for each compare can add some overhead. So I made this feature optional it is only enabled if the macro MDB_CMP_CTX is enabled. This patch does the following. * Adds context to the MDB_cmp_func typedef int (MDB_cmp_func)(const MDB_val *a, const MDB_val *b ,void* ctx); * And two new data members to the MDB_dbx struct * void *md_cmpctx; /**< user-provided context for md_cmp */ * void *md_dcmpctx; /**< user-provided context for md_dcmp */ * Add functions for setting/getting the contexts * int mdb_set_cmpctx(MDB_txn *txn, MDB_dbi dbi, void *ctx); * int mdb_set_dcmpctx(MDB_txn *txn, MDdbi i dbi, void *ctx); * int mdb_get_cmpctx(MDB_txn *txn, MDB_dbi dbi, void **ctx); * int mdb_get_dcmpctx(MDB_txn *txn, MDB_dbi dbi, void **ctx); I have no problem maintaining this as a separate patch if it does not fit in the vision of LMDB. I figured it might be very useful for others. Thank You for creating and releasing LMDB 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.

1 0

Re: (ITS#8117) Bugs related to key-size in lmdb and backend
by h.b.furuseth＠usit.uio.no 01 May '15

01 May '15

test001 still crashes if you insert assert(a->mv_size == sizeof(int) && b->mv_size == sizeof(int)); in mdb_cmp_int(). Using RE24 commit 98f70f1841f85d93 "ITS#8120 Move final...". I don't see "same size" in the INTEGERDUP doc, it's looser than for INTEGERKEY integers. Or have I gone blind again? Anyway, it would be clearer to cut some doc and say data behave like INTEGERKEY keys. Ignoring that, though: Looking yet again at the doc, mdb_dbi_open():INTEGERKEY says "typically" sizeof(int/size_t), I can't see it requires these sizes. Maybe you copied that from a suggestion from me back when I asked for clarifications. "keys must all be of the same size" in the doc is unclear. I gather it should be "... in the DB's lifetime". But it can be read as "...at a given time": Write size_t-sized integers, empty the DB, then write int-sized integers. That does not work, since me_dbxs[].md_dcmp is updated. "mc->mc_dbx->md_dcmp = mdb_cmp_clong;" looks wrong. That updates env->me_dbxs[], I believe. But: If we mdb_txn_abort(), the txn has not been a no-op: It will require next txn and even existing txns to use size_t-sized INTEGERDUP data. The assignment may be non-atomic. Another txn may be reading the pointer. I expect IL32P64 architectures are examples, and also function pointers can be quite large. (OpenLDAP expects void*-sized function pointers though.)

1 0

Re: (ITS#8123) Incorrect loglevel man page content
by hyc＠symas.com 01 May '15

01 May '15

elecharny(a)apache.org wrote: > Full_Name: Emmanuel L.charny > Version: 2.4.40 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (80.12.43.27) > > > The slapd-config man page contains a slightly incorrect explaination for the > olcLogLevel config element. One can read : > > olcLogLevel: <integer> [...] > ... > The desired log level can be input as ... or as a list of the names that > are shown between brackets... > > but the sample does not show any bracket being used : > > olcLogLevel: acl trace > > Actually, using brackets does not work (you can't inject the attribute using > [acl trace] or {acl trace}) "between brackets" refers to the manpage text itself, it does not mean to enter anything with literal brackets. It probably should be corrected to "between parentheses" since it is referring to e.g. 1 (0x1 trace) trace function calls -- -- 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#8122) Incorrect Schema content
by hyc＠symas.com 01 May '15

01 May '15

elecharny(a)apache.org wrote: > Full_Name: Emmanuel L.charny > Version: 2.4.40 > OS: Mac OSX > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (80.12.55.37) > > > There are a few elements in some schema which are incorrect (even if it does not > break anything) : This is a known issue. Will not be fixed. > > Core schema > ----------- > * The organizationalRole OC has the preferredDeliveryMethod AT declared twice > * The residentialPerson OC has the preferredDeliveryMethod AT declared twice These definitions are copied verbatim from RFC2256. We do not alter published schema from their published form. > Cosine schema > ------------- > * The domain OC has the streetAddress AT declared twice > * The RFC822localPart OC has the telephoneNumber AT declared twice Again, copied verbatim from RFC1274. -- -- 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#8123) Incorrect loglevel man page content
by elecharny＠apache.org 01 May '15

01 May '15

Full_Name: Emmanuel L.charny Version: 2.4.40 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.12.43.27) The slapd-config man page contains a slightly incorrect explaination for the olcLogLevel config element. One can read : olcLogLevel: <integer> [...] ... The desired log level can be input as ... or as a list of the names that are shown between brackets... but the sample does not show any bracket being used : olcLogLevel: acl trace Actually, using brackets does not work (you can't inject the attribute using [acl trace] or {acl trace})

1 0

(ITS#8122) Incorrect Schema content
by elecharny＠apache.org 01 May '15

01 May '15

Full_Name: Emmanuel L.charny Version: 2.4.40 OS: Mac OSX URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.12.55.37) There are a few elements in some schema which are incorrect (even if it does not break anything) : Core schema ----------- * The organizationalRole OC has the preferredDeliveryMethod AT declared twice * The residentialPerson OC has the preferredDeliveryMethod AT declared twice Cosine schema ------------- * The domain OC has the streetAddress AT declared twice * The RFC822localPart OC has the telephoneNumber AT declared twice

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs