openldap-technical

openldap-technical@openldap.org

20 participants
9802 discussions

2 way SSL configuration in OpenLDAP 2.4
by vidya bharadwaj 11 Dec '13

11 Dec '13

Hi, We have to implement a 2 way SSL mechanism on a LDAP connector in our product. In order to test the implementation, we have chosen openLDAP2.4 as the data source. Currently we have done the following steps: On the OpenLDAP end: 1. Installed OpenLDAP with TLS feature 2.Created a CA using OpenSSL /etc/pki/tls/misc/CA –newca 3.Created a certificate using OpenSSL openssl req -newkey rsa:1024 -nodes -keyout newreq.pem -out newreq.pem 4.Signed the certificate using the CA created /etc/pki/tls/misc/CA –sign 5. Finally stored the cacert.pem, newreq.pem and newcert.pem under /opt/openldap/certificate folder 6. Following changes were made in sldap.conf TLSCipherSuite MEDIUM:+SSLv2:+SSLv3:RSA TLSCACertificatePath /opt/openldap/certificate/ TLSCACertificateFile /opt/openldap/certificate/cacert.pem TLSCertificateFile /opt/openldap/certificate/servercrt.pem TLSCertificateKeyFile /opt/openldap/certificate/serverkey.pem # Use the following if client authentication is required TLSVerifyClient demand 7.Similarly a new certificate for client was created using client’s details such as host name etc 8.Signed by the previously created CA On the client side: 1. Following changes were made in ldap.conf HOST spsdel192 PORT 636 TLS_CACERTDIR/etc/openldap/certs TLS_REQCERT demand TLS_CACERT /etc/openldap/certs/cacert.pem Finally when executing [root@spsdel193 ~]# ldapsearch -v -Z -D cn=root,o=ShawEnterprise -w secret -b o=accounts,o=shawEnterprise ldap_initialize( <DEFAULT> ) ldap_start_tls: Connect error (-11) additional info: TLS error -12227:SSL peer was unable to negotiate an acceptable set of security parameters. ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) [root@spsdel193 ~]# Any solution to resolve this issue would be of great help. Thanks in advance. Regards Vidya

2 1

Re: Recovering from a Single-Node downtime in a Multi-Master Setup
by Marco Nett 11 Dec '13

11 Dec '13

2013/12/10 Quanah Gibson-Mount <quanah(a)zimbra.com> > --On Tuesday, December 10, 2013 11:08 AM -0600 espeake(a)oreillyauto.comwrote: > > Do the slapcat on ldap2 and then delete the db files on ldap1 and then run >> the slapadd. you will not get duplicates because all of the CSN's will be >> the same. This is what I have done my migrations to the most recent >> versions and doing my own builds. Works great that way. >> > So by "delete the db files" you mean deleting the contents of the slapd home-dir (usually /var/lib/ldap)? Here's what I read out of your answer: (ldap2) slapcat -bcn=config -l config.ldiff (ldap2) slapcat -l actual-data.ldiff (ldap1) rm -rf /var/lib/ldap/* (ldap1) /etc/init.d/slapd start (ldap1) slapadd -bcn=config -l config.ldiff (ldap1) slapcat -l actual-data.ldiff Like this? Any traps or common problems I should be aware of? > > Huh? > > The CSNs contain the server IDs. Servers ignore their own changes. > You're saying I shouldn't delete the files before doing the cat/add business, right? If I'd do it like this, wouldn't stuff that got deleted on ldap2 (while ldap1 was down) still end up being on ldap1?

3 2

Custom attribute values created prior to an index are not getting indexed by slapindex
by Jon C Kidder 11 Dec '13

11 Dec '13

I am running 2.4.36 with mdb and have discovered an interesting behavior that may be a bug but wanted some input before I opened an ITS. I can upgrade to .38 and verify the behavior if needed. I have a third party application that defines the following custom attribute: olcAttributeTypes: ( 1.3.6.1.4.1.8241.1.15 NAME 'ctscPropertyKeywords' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) I have recently added the following index to the database for this application: olcDbIndex: ctscPropertyKeywords pres,eq When I run a search using objectclass as a filter I see 17 records that contain the value "Exportable" for ctscPropertyKeywords. When I repeat the search using (ctscPropertyKeywords=Exportable) as the filter I only get back 9 records even though the value is present in 17 records. I have included examples of my searches and the results below. I have run slapindex on this database several times since the new index was added using: /appl/openldap/sbin/slapindex -v -F /appl/openldap/etc/openldap/slapd.d -b "dc=global,dc=aep,dc=com" I have also restarted slapd several times just for grins. The behavior has not changed. I have discovered that the 9 records I see have been modified since the index was created and the missing 8 records existed before the index was created. Modifying a record causes the index to get updated and adds the record to the results of my second search but re-indexing the database using slapindex does not. Any thoughts? Here are my sample searches and their output. /appl/openldap/bin/ldapsearch -H "ldap://localhost:389" -x -D {removed} -y {removed} -s sub -b 'dc=Global,dc=aep,dc=com' '(objectClass=ctscPropertyDefinition)' objectClass ctscPropertyKeywords # extended LDIF # # LDAPv3 # base <dc=Global,dc=aep,dc=com> with scope subtree # filter: (objectClass=ctscPropertyDefinition) # requesting: objectClass ctscPropertyKeywords # # 1102, ctscApplicationDataRepository, ctsc, ApplicationData, Global.aep.com dn: cn=1102,ou=ctscApplicationDataRepository,ou=ctsc,ou=ApplicationData,dc=Glo bal,dc=aep,dc=com objectClass: top objectClass: dlm1ManagedElement objectClass: ctscPropertyDefinition objectClass: ctscManagedObjectAuxClass ctscPropertyKeywords: Exportable # 1103, ctscApplicationDataRepository, ctsc, ApplicationData, Global.aep.com dn: cn=1103,ou=ctscApplicationDataRepository,ou=ctsc,ou=ApplicationData,dc=Glo bal,dc=aep,dc=com objectClass: top objectClass: dlm1ManagedElement objectClass: ctscPropertyDefinition objectClass: ctscManagedObjectAuxClass ctscPropertyKeywords: Exportable # 1104, ctscApplicationDataRepository, ctsc, ApplicationData, Global.aep.com dn: cn=1104,ou=ctscApplicationDataRepository,ou=ctsc,ou=ApplicationData,dc=Glo bal,dc=aep,dc=com objectClass: top objectClass: dlm1ManagedElement objectClass: ctscPropertyDefinition objectClass: ctscManagedObjectAuxClass ctscPropertyKeywords: Exportable # 4305, ctscApplicationDataRepository, ctsc, ApplicationData, Global.aep.com dn: cn=4305,ou=ctscApplicationDataRepository,ou=ctsc,ou=ApplicationData,dc=Glo bal,dc=aep,dc=com objectClass: top objectClass: dlm1ManagedElement objectClass: ctscPropertyDefinition objectClass: ctscManagedObjectAuxClass ctscPropertyKeywords: Exportable ctscPropertyKeywords: HelpDeskAccessible # 16802, ctscApplicationDataRepository, ctsc, ApplicationData, Global.aep.com dn: cn=16802,ou=ctscApplicationDataRepository,ou=ctsc,ou=ApplicationData,dc=Gl obal,dc=aep,dc=com objectClass: top objectClass: dlm1ManagedElement objectClass: ctscPropertyDefinition objectClass: ctscManagedObjectAuxClass ctscPropertyKeywords: Exportable ctscPropertyKeywords: HelpDeskAccessible # 16803, ctscApplicationDataRepository, ctsc, ApplicationData, Global.aep.com dn: cn=16803,ou=ctscApplicationDataRepository,ou=ctsc,ou=ApplicationData,dc=Gl obal,dc=aep,dc=com objectClass: top objectClass: dlm1ManagedElement objectClass: ctscPropertyDefinition objectClass: ctscManagedObjectAuxClass ctscPropertyKeywords: Exportable ctscPropertyKeywords: HelpDeskAccessible # 16804, ctscApplicationDataRepository, ctsc, ApplicationData, Global.aep.com dn: cn=16804,ou=ctscApplicationDataRepository,ou=ctsc,ou=ApplicationData,dc=Gl obal,dc=aep,dc=com objectClass: top objectClass: dlm1ManagedElement objectClass: ctscPropertyDefinition objectClass: ctscManagedObjectAuxClass ctscPropertyKeywords: Exportable ctscPropertyKeywords: HelpDeskAccessible # 16805, ctscApplicationDataRepository, ctsc, ApplicationData, Global.aep.com dn: cn=16805,ou=ctscApplicationDataRepository,ou=ctsc,ou=ApplicationData,dc=Gl obal,dc=aep,dc=com objectClass: top objectClass: dlm1ManagedElement objectClass: ctscPropertyDefinition objectClass: ctscManagedObjectAuxClass ctscPropertyKeywords: Exportable ctscPropertyKeywords: HelpDeskAccessible # 16806, ctscApplicationDataRepository, ctsc, ApplicationData, Global.aep.com dn: cn=16806,ou=ctscApplicationDataRepository,ou=ctsc,ou=ApplicationData,dc=Gl obal,dc=aep,dc=com objectClass: top objectClass: dlm1ManagedElement objectClass: ctscPropertyDefinition objectClass: ctscManagedObjectAuxClass ctscPropertyKeywords: Exportable ctscPropertyKeywords: HelpDeskAccessible # 16808, ctscApplicationDataRepository, ctsc, ApplicationData, Global.aep.com dn: cn=16808,ou=ctscApplicationDataRepository,ou=ctsc,ou=ApplicationData,dc=Gl obal,dc=aep,dc=com objectClass: top objectClass: dlm1ManagedElement objectClass: ctscPropertyDefinition objectClass: ctscManagedObjectAuxClass ctscPropertyKeywords: Exportable ctscPropertyKeywords: HelpDeskAccessible # 16810, ctscApplicationDataRepository, ctsc, ApplicationData, Global.aep.com dn: cn=16810,ou=ctscApplicationDataRepository,ou=ctsc,ou=ApplicationData,dc=Gl obal,dc=aep,dc=com objectClass: top objectClass: dlm1ManagedElement objectClass: ctscPropertyDefinition objectClass: ctscManagedObjectAuxClass ctscPropertyKeywords: Exportable ctscPropertyKeywords: HelpDeskAccessible # 16813, ctscApplicationDataRepository, ctsc, ApplicationData, Global.aep.com dn: cn=16813,ou=ctscApplicationDataRepository,ou=ctsc,ou=ApplicationData,dc=Gl obal,dc=aep,dc=com objectClass: top objectClass: dlm1ManagedElement objectClass: ctscPropertyDefinition objectClass: ctscManagedObjectAuxClass ctscPropertyKeywords: Exportable ctscPropertyKeywords: HelpDeskAccessible # 16814, ctscApplicationDataRepository, ctsc, ApplicationData, Global.aep.com dn: cn=16814,ou=ctscApplicationDataRepository,ou=ctsc,ou=ApplicationData,dc=Gl obal,dc=aep,dc=com objectClass: top objectClass: dlm1ManagedElement objectClass: ctscPropertyDefinition objectClass: ctscManagedObjectAuxClass ctscPropertyKeywords: Exportable ctscPropertyKeywords: HelpDeskAccessible # 17702, ctscApplicationDataRepository, ctsc, ApplicationData, Global.aep.com dn: cn=17702,ou=ctscApplicationDataRepository,ou=ctsc,ou=ApplicationData,dc=Gl obal,dc=aep,dc=com objectClass: top objectClass: dlm1ManagedElement objectClass: ctscPropertyDefinition objectClass: ctscManagedObjectAuxClass ctscPropertyKeywords: Exportable # 17703, ctscApplicationDataRepository, ctsc, ApplicationData, Global.aep.com dn: cn=17703,ou=ctscApplicationDataRepository,ou=ctsc,ou=ApplicationData,dc=Gl obal,dc=aep,dc=com objectClass: top objectClass: dlm1ManagedElement objectClass: ctscPropertyDefinition objectClass: ctscManagedObjectAuxClass ctscPropertyKeywords: Exportable # 17803, ctscApplicationDataRepository, ctsc, ApplicationData, Global.aep.com dn: cn=17803,ou=ctscApplicationDataRepository,ou=ctsc,ou=ApplicationData,dc=Gl obal,dc=aep,dc=com objectClass: top objectClass: dlm1ManagedElement objectClass: ctscPropertyDefinition objectClass: ctscManagedObjectAuxClass ctscPropertyKeywords: Exportable # 18902, ctscApplicationDataRepository, ctsc, ApplicationData, Global.aep.com dn: cn=18902,ou=ctscApplicationDataRepository,ou=ctsc,ou=ApplicationData,dc=Gl obal,dc=aep,dc=com objectClass: top objectClass: dlm1ManagedElement objectClass: ctscPropertyDefinition objectClass: ctscManagedObjectAuxClass ctscPropertyKeywords: Exportable ctscPropertyKeywords: HelpDeskAccessible ctscPropertyKeywords: MultiValued # search result search: 2 result: 0 Success # numResponses: 18 # numEntries: 17 /appl/openldap/bin/ldapsearch -H "ldap://localhost:389" -x -D {removed} -y {removed} -s sub -b 'dc=Global,dc=aep,dc=com' '(ctscPropertyKeywords=Exportable)' objectClass ctscPropertyKeywords # extended LDIF # # LDAPv3 # base <dc=Global,dc=aep,dc=com> with scope subtree # filter: (ctscPropertyKeywords=Exportable) # requesting: objectClass ctscPropertyKeywords # # 1103, ctscApplicationDataRepository, ctsc, ApplicationData, Global.aep.com dn: cn=1103,ou=ctscApplicationDataRepository,ou=ctsc,ou=ApplicationData,dc=Glo bal,dc=aep,dc=com objectClass: top objectClass: dlm1ManagedElement objectClass: ctscPropertyDefinition objectClass: ctscManagedObjectAuxClass ctscPropertyKeywords: Exportable # 1104, ctscApplicationDataRepository, ctsc, ApplicationData, Global.aep.com dn: cn=1104,ou=ctscApplicationDataRepository,ou=ctsc,ou=ApplicationData,dc=Glo bal,dc=aep,dc=com objectClass: top objectClass: dlm1ManagedElement objectClass: ctscPropertyDefinition objectClass: ctscManagedObjectAuxClass ctscPropertyKeywords: Exportable # 4305, ctscApplicationDataRepository, ctsc, ApplicationData, Global.aep.com dn: cn=4305,ou=ctscApplicationDataRepository,ou=ctsc,ou=ApplicationData,dc=Glo bal,dc=aep,dc=com objectClass: top objectClass: dlm1ManagedElement objectClass: ctscPropertyDefinition objectClass: ctscManagedObjectAuxClass ctscPropertyKeywords: Exportable ctscPropertyKeywords: HelpDeskAccessible # 16808, ctscApplicationDataRepository, ctsc, ApplicationData, Global.aep.com dn: cn=16808,ou=ctscApplicationDataRepository,ou=ctsc,ou=ApplicationData,dc=Gl obal,dc=aep,dc=com objectClass: top objectClass: dlm1ManagedElement objectClass: ctscPropertyDefinition objectClass: ctscManagedObjectAuxClass ctscPropertyKeywords: Exportable ctscPropertyKeywords: HelpDeskAccessible # 16810, ctscApplicationDataRepository, ctsc, ApplicationData, Global.aep.com dn: cn=16810,ou=ctscApplicationDataRepository,ou=ctsc,ou=ApplicationData,dc=Gl obal,dc=aep,dc=com objectClass: top objectClass: dlm1ManagedElement objectClass: ctscPropertyDefinition objectClass: ctscManagedObjectAuxClass ctscPropertyKeywords: Exportable ctscPropertyKeywords: HelpDeskAccessible # 17702, ctscApplicationDataRepository, ctsc, ApplicationData, Global.aep.com dn: cn=17702,ou=ctscApplicationDataRepository,ou=ctsc,ou=ApplicationData,dc=Gl obal,dc=aep,dc=com objectClass: top objectClass: dlm1ManagedElement objectClass: ctscPropertyDefinition objectClass: ctscManagedObjectAuxClass ctscPropertyKeywords: Exportable # 17703, ctscApplicationDataRepository, ctsc, ApplicationData, Global.aep.com dn: cn=17703,ou=ctscApplicationDataRepository,ou=ctsc,ou=ApplicationData,dc=Gl obal,dc=aep,dc=com objectClass: top objectClass: dlm1ManagedElement objectClass: ctscPropertyDefinition objectClass: ctscManagedObjectAuxClass ctscPropertyKeywords: Exportable # 17803, ctscApplicationDataRepository, ctsc, ApplicationData, Global.aep.com dn: cn=17803,ou=ctscApplicationDataRepository,ou=ctsc,ou=ApplicationData,dc=Gl obal,dc=aep,dc=com objectClass: top objectClass: dlm1ManagedElement objectClass: ctscPropertyDefinition objectClass: ctscManagedObjectAuxClass ctscPropertyKeywords: Exportable # 18902, ctscApplicationDataRepository, ctsc, ApplicationData, Global.aep.com dn: cn=18902,ou=ctscApplicationDataRepository,ou=ctsc,ou=ApplicationData,dc=Gl obal,dc=aep,dc=com objectClass: top objectClass: dlm1ManagedElement objectClass: ctscPropertyDefinition objectClass: ctscManagedObjectAuxClass ctscPropertyKeywords: Exportable ctscPropertyKeywords: HelpDeskAccessible ctscPropertyKeywords: MultiValued # search result search: 2 result: 0 Success # numResponses: 10 # numEntries: 9 -Jon C. Kidder American Electric Power Middleware Services Email: jckidder(a)aep.com<mailto:jckidder@aep.com> Phone: 614-716-4970

1 0

Replicating cn=config in configuration tool
by Daniel J 10 Dec '13

10 Dec '13

Hi Openldap gents/ladies, For those who migrated over to cn=config and are replicating cn=config as well as other DIT using configuration tools like cfengine, puppet, chef etc... I have currently have set up to not replicate cn=config for the following reasons: - flexibility to run different cn=config if needed for testing/for a specific purpose - able to reduce the scope of changes that may be disastrous Curious to know how others have implemented and theirs reasoning behind his/hers implementation. Your comments and advise are very welcome. Thanks

1 0

LTB DOWNLOAD
by Borresen, John - 0442 - MITLL 10 Dec '13

10 Dec '13

Sorry, if this is not the forum to post this issue...but...received the following error when downloading the LTB Packages: Is this ok [y/N]: y Downloading Packages: openldap-ltb-2.4.38-1.el5.x86_64.rpm | 3.9 MB 00:01 Running rpm_check_debug Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction Error in PREIN scriptlet in rpm package openldap-ltb-2.4.38-1.el5.x86_64 error: %pre(openldap-ltb-2.4.38-1.el5.x86_64) scriptlet failed, exit status 1 error: install: %pre scriptlet failed (2), skipping openldap-ltb-2.4.38-1.el5 Failed: openldap-ltb.x86_64 0:2.4.38-1.el5 Complete! John D. Borresen (Dave) Linux/Unix Systems Administrator MIT Lincoln Laboratory

2 1

Recovering from a Single-Node downtime in a Multi-Master Setup
by Marco Nett 10 Dec '13

10 Dec '13

Quick question: State 1: - I have two OpenLDAP slapd servers (ldap1 and ldap2) configured as Multi-master. - The both have the exact same data between the mirrored directories. - If I create a new directory entry on one server, it immediately gets mirrored to the second server. - I'm happy. State 2: - One LDAP-Master (ldap1) is down because of whatever. - Changes to the directory are made on the LDAP-Master which is still up (ldap2). - Changes are not mirrored to ldap1 because it's down. - I'm a little worried but still happy. State 3: - ldap1 is back up and running, but it's directory is not up to date. - The changes made to ldap2 in state 2 are not on ldap1 and aren't getting replicated automatically. - Mirroring again works fine, but ldap1 still doens't know about changes made in state 2. - I'm confused because I can't seem to find any information on how to recover from this. I couldn't just delete the directory on ldap1 and import the one from ldap2 because the importing would also be mirrored to ldap2. right? how would i go about recoverying from a downtime in a multi-master setup?

4 6

Q: empty groups (groupOfNames, member)
by Ulrich Windl 09 Dec '13

09 Dec '13

Hi! I had a problem with "empty groups": object class groupOfNames has a MUST member attribute, so you cannot create an empty group. I consider this to be a bug in the object class definition, specifically as groupOfNames is structural, and not auxillary. So in SLES empty (POSIX) groups are created with a namedObject structural class. Unfortunately because of "structural object class modification from 'namedObject' to 'groupOfNames' not allowed", the entry has to be recreated whenever the first member is added or the last member is removed to/from a group. While examining the problem,. I found out that the namedObject (rfc2307bis.schema) has ist "cn" attribute optional: ## namedObject is needed for groups without members objectclass ( 1.3.6.1.4.1.5322.13.1.1 NAME 'namedObject' SUP top STRUCTURAL MAY cn ) I'd consider this workaround as a bug also. Two questions remaining: 1) is there a technical reason against empty groups? I'd consider them as valid as empty arrays. 2) Is it an LDAP requirement to forbid structural changes in object classes, or is it an implementation restriction? In my experience the ID of an entry is (if not the entry's UUID) more the value of DN rather than the structural objectClass... Insights? Regards, Ulrich

4 6

OPENLDAP HANGS DAILY
by Borresen, John - 0442 - MITLL 06 Dec '13

06 Dec '13

All, I just restarted with the group, and the OpenLDAP software has not been upgraded - currently 2.4.23 (that will be coming...hopefully). Anyway, an issue that was brought to my attention upon starting was that slapd needs to be restarted daily. It is still running, it just stops responding (no one can log in). Nothing has, previously, been found in the logs. The other day, during my initial search through the slapd logs I found: conn=1144 op=1 SRCH attr=automountKey automountInformation <= bdb_equality_candidates: (automountKey) not indexed <= bdb_equality_candidates: (automountKey) not indexed <= bdb_equality_candidates: (automountKey) not indexed Which I added "olcDbIndex: automountKey eq" to the cn=config/olcDatabase={1}bdb.ldif. Took care of that one. But, under further investigation I am finding this, repeatedly (for slapcat, slapd, and others): Dec 5 00:00:02 server_name slapcat: unable to dlopen /usr/lib/sasl2/libanonymous.so.2: /usr/lib/sasl2/libanonymous.so.2: wrong ELF class: ELFCLASS32 Dec 5 00:00:02 server_name slapcat: unable to dlopen /usr/lib/sasl2/libplain.so.2: /usr/lib/sasl2/libplain.so.2: wrong ELF class: ELFCLASS32 Dec 5 00:00:02 server_name slapcat: unable to dlopen /usr/lib/sasl2/libsasldb.so.2: /usr/lib/sasl2/libsasldb.so.2: wrong ELF class: ELFCLASS32 Dec 5 00:00:02 server_name slapcat: unable to dlopen /usr/lib/sasl2/liblogin.so.2: /usr/lib/sasl2/liblogin.so.2: wrong ELF class: ELFCLASS32 Dec 5 02:00:02 server_name setroubleshoot: SELinux is preventing sendmail (system_mail_t) "read" to libsasl2.so.2 (usr_t). For complete SELinux messages. run sealert -l c4516acc-2dde-4dca-973e-86cd6686ee9f Dec 5 02:30:02 server_name setroubleshoot: SELinux is preventing sendmail (system_mail_t) "read" to libsasl2.so.2 (usr_t). For complete SELinux messages. run sealert -l c4516acc-2dde-4dca-973e-86cd6686ee9f Dec 5 02:31:08 server_name tar: nss-ldap: do_open: do_start_tls failed:stat=-1 Not sure why it should even been trying to use the these lib files, as one, we are not using SASL. Looking at "ldd slapd" it is seeing only 64-bit libraries. Anyone have any suggestions? John D. Borresen (Dave) Linux/Unix Systems Administrator MIT Lincoln Laboratory Surveillance Systems Group 244 Wood St Lexington, MA 02420 Ph: (781) 981-1609 Email: john.borresen(a)ll.mit.edu<mailto:john.borresen@ll.mit.edu>

5 7

Mysql to Ldap
by Burk Al 05 Dec '13

05 Dec '13

Hi, I am using mysql to store my users and mailbox information on my email server (postfix & dovecot). And I am using Postfix Admin as my front end to manage domains, users and such. I want to replace mysql with ldap server. Somehow, I need to find a way to create the same or similar structure of mysql schema on ldap server. I am not expecting a tool, magic wand to make that conversion but what is the easiest and right approach to do this? Any sample, documentation etc etc would help greatly. Thanks...

1 0

[LMDB] Problem with extending size on Windows
by Alain 05 Dec '13

05 Dec '13

I encountered a problem trying to change the mapsize of an existing store. It turned out to be that the newsize argument to mdb_env_map wasn't set correctly when coming from mdb_env_open2. So I had to change the call to be: rc = mdb_env_map(env, meta.mm_address, newenv || env->me_mapsize != meta.mm_mapsize); (adding the || != test) Also I had some issues with large files (4GB) and I made some small changes which better match documentation and reported issues, but not sure if the original code was flawed or not. It is in mdb_env_map when we set the file pointer and EOF: if (newsize) { if ((SetFilePointer(env->me_fd, sizelo, &sizehi, 0) == INVALID_SET_FILE_POINTER && GetLastError() != ERROR_SUCCESS) || !SetEndOfFile(env->me_fd) || (SetFilePointer(env->me_fd, 0, NULL, 0) == INVALID_SET_FILE_POINTER && GetLastError() != ERROR_SUCCESS)) return ErrCode(); } Again, I made those changes according to what I noticed and this might not be the perfect final solution. Cheers, Alain

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical