openldap-technical June 2017

openldap-technical@openldap.org

34 participants
69 discussions

LDAP Issue: Logging region out of memory; you may need to increase its size
by Gurjot Kaur 27 Jun '17

27 Jun '17

Hello, On an already running setup of OpenLDAP 2.4 on Linux (Linux GURKES015 2.6.18-128.el5 #1 SMP Wed Dec 17 11:41:38 EST 2008 x86_64 x86_64 x86_64 GNU/Linux) platform, one day I start getting following error when I execute the slapcat command: bdb_db_open: warning - no DB_CONFIG file found in directory /opt/proxy/HostedDirectoryLDAPMultiMaster/instances/LdapServers_1/var/openldap-data: (2). Expect poor performance for suffix "dc=ORG,dc=COM".bdb(dc=ORG,dc=COM): Logging region out of memory; you may need to increase its size bdb_db_open: database "dc=ORG,dc=COM": db_open(/opt/proxy/HostedDirectoryLDAPMultiMaster/instances/LdapServers_1/var/openldap-data/id2entry.bdb) failed: Cannot allocate memory (12). backend_startup_one: bi_db_open failed! (12) slap_startup failed Following are the system RAM and disk space usage. Tasks: 192 total, 2 running, 190 sleeping, 0 stopped, 0 zombie Cpu(s): 0.1%us, 0.3%sy, 0.0%ni, 98.9%id, 0.7%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 8178840k total, 8145460k used, 33380k free, 329840k buffers Swap: 2031608k total, 220k used, 2031388k free, 6623032k cached Filesystem Size Used Avail Use% Mounted on /dev/mapper/rootvg-lv_root 1.9G 688M 1.2G 38% / tmpfs 3.9G 0 3.9G 0% /dev/shm /dev/sda1 289M 17M 258M 7% /boot /dev/mapper/rootvg-lv_users 1.9G 1.6G 218M 89% /users /dev/mapper/rootvg-lv_exec 124M 5.6M 113M 5% /exec /dev/mapper/rootvg-lv_images 1.9G 73M 1.8G 4% /images /dev/mapper/rootvg-lv_var 1.9G 140M 1.7G 8% /var /dev/mapper/rootvg-lv_tmp 961M 22M 890M 3% /tmp /dev/mapper/rootvg-lv_system 186M 7.9M 169M 5% /system /dev/mapper/rootvg-lv_usr 1.9G 663M 1.2G 37% /usr /dev/mapper/rootvg-lv_cft251 496M 430M 41M 92% /exec/products/cft /dev/mapper/rootvg-lv_bases 79G 19G 57G 25% /bases /dev/mapper/rootvg-lv_nbu 1008M 361M 597M 38% /exec/products/netbackup /dev/mapper/rootvg-lv_pat 1008M 194M 764M 21% /exec/products/patrol /dev/mapper/rootvg-lv_bladelogic 992M 187M 755M 20% /exec/products/bladelogic I have removed some log.xxxxx files from /opt/proxy/HostedDirectoryLDAPMultiMaster/instances/LdapServers_1/var/openldap-data which are not in use. But still the same error persist while executing slapcat command. Then I restarted the slapd process. After that I start facing ldaperror 80 with additional info "index generation failed" error while adding, deleting or modifying any entry along in ldap DB. Could somebody help us to understand: 1. Why there was "Logging region out of memory; you may need to increase its size" error. How to resolve it? 2. Why after slapd restart, I got "index generation failed" error. How to resolve it? PS: DB_CONFIG was not present in /var/openldap-data directory and slapcat was used to work properly before this issue. "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."

2 2

RE: Using TLS
by Quanah Gibson-Mount 26 Jun '17

26 Jun '17

--On Friday, June 23, 2017 10:31 PM +0000 Daniel Le <daniel.le(a)exfo.com> wrote: > Thanks Quanah. > > Using OpenLDAP API, is it correct to set client TLS option to -not- > validate server certificates as follows? > > int opt; > opt = LDAP_OPT_X_TLS_NEVER; > rc = ldap_set_option(NULL, LDAP_OPT_X_TLS_REQUIRE_CERT, &opt); You still have to reinitialize the global context, as in my commit, for the filehandle. So you'd want these two lines to be following: int new_ctx = 0; rc = ldap_set_option(ld, LDAP_OPT_X_TLS_NEWCTX, &new_ctx) etc. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

RE: syncrepl fails after upgrade to openldap 2.4.45
by Quanah Gibson-Mount 25 Jun '17

25 Jun '17

--On Friday, June 23, 2017 8:30 AM +0000 Juergen.Sprenger(a)swisscom.com wrote: > Have also added these entries to syncrepl now, but without any success: > > tls_cert=/etc/ssl/openldap/dannatu.ch.pem > tls_key=/etc/ssl/openldap/dannatu.ch.key > tls_cacert=/etc/ssl/certs/dannatuCA-cacert.pem This would indicate you want to do client cert authentication with the syncrepl client, which as far as I know, you are not using (based on your earlier configuration). You need to remove the tls_cert and tls_key lines. I've tested with OpenLDAP 2.4.45 and TLS works as expected with replication. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: ldapsearch on accesslog hangs in OpenLDAP 2.4.40 on RHEL 6.9 ( works ok w/ slapcat -b "cn=accesslog")
by Quanah Gibson-Mount 24 Jun '17

24 Jun '17

--On Thursday, June 22, 2017 9:19 PM +0000 Ron Lamarche <Ron.Lamarche(a)innovapost.com> wrote: > I've installed the RHEL 6.9 OpenLDAP bundled product and have a working > suffix based on cn=config vs. slapd.conf model but cannot get the > accesslog overlays/DB's to work properly (ldapsearch returns accesslog > records but never completes and instead hangs showing > "ldap_int_select" . Need to ctl –c to exit ) Hi Ron, The OpenLDAP build distributed by RedHat is known to have severe issues. It is strongly recommended to avoid their OpenLDAP builds because of this and their advanced age. If you are not able to build OpenLDAP yourself, the LTB project provides standard OpenLDAP builds for free: <http://ltb-project.org/wiki/download#openldap> If you require support, Symas (my employer) has such an offering. Our OpenLDAP builds also include features not yet available from the OpenLDAP project. You may be well facing any of a number of bugs that have been fixed in the 2.5 years since 2.4.40 was released, in particular: Fixed slapd cn=config when updating olcAttributeTypes (ITS#8199) Fixed slapo-accesslog to honor pauses during purge for cn=config update (ITS#8423) Finally, I would also note that the back-bdb backend has been deprecated since OpenLDAP 2.3, and as of OpenLDAP 2.4, back-hdb is also deprecated. The recommended backend is back-mdb, which is built on top of LMDB (<http://www.symas.com/lmdb/>, <https://en.wikipedia.org/wiki/Lightning_Memory-Mapped_Database>) In general, issues with RedHat's build will not be explored unless you can reproduce the same problem with a current build of OpenLDAP. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

RE: Using TLS
by Quanah Gibson-Mount 23 Jun '17

23 Jun '17

--On Friday, June 23, 2017 10:08 PM +0000 Daniel Le <daniel.le(a)exfo.com> wrote: > Hi Quanah, > > No, I'm fairly new to OpenLDAP and wasn't aware of such global context > requirement. > > Does that only apply to client TLS options? > > Is global option set by passing a NULL LDAP handle? > > I found ITS#8573 wrt your TLS patch, but the URL: > <http://www.openldap.org/lists/openldap-devel/attachments/20170608/2ae39d > 03/attachment.bin> is not found. Can you point me to where to download or > see the patch? Has it been integrated into 2.4.45? Hi Daniel, You can view it here: <https://github.com/quanah/openldap-scratch/commit/cff66313706c607d4df6f0742…> and no, it would be part of 2.5 once submitted, although it applies just fine for me to 2.4 --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

RE: Using TLS
by Quanah Gibson-Mount 23 Jun '17

23 Jun '17

Hi Daniel, You are aware that you must use the global context when changing the TLS options for a client, correct? It does not work on the specific filehandle. See my TLS patch for the command line client tools for an example (that is posted to the openldap-devel list). --Quanah --On Friday, June 23, 2017 9:20 PM +0000 Daniel Le <daniel.le(a)exfo.com> wrote: > Hello, > > Is there a unit tester where the client LDAP_OPT_X_TLS_REQUIRE_CERT > option is set to LDAP_OPT_X_TLS_NEVER that I can try? I was looking at > openldap-2.4.44/clients/tools/ldapsearch but it doesn't configure this > option. > > My application program sets LDAP_OPT_X_TLS_NEVER. Why does LDAP client > still check for server certificate which fails in the case of bad > certificate? > > int opt; > opt = LDAP_OPT_X_TLS_NEVER; > ldap_retcode = ldap_set_option(m_tLDAP, LDAP_OPT_X_TLS_REQUIRE_CERT, > &opt); ... > > Daniel > > -----Original Message----- > From: Daniel Le > Sent: Monday, June 19, 2017 3:58 PM > To: 'Paulm' <paulm(a)tetrardus.net> > Cc: openldap-technical(a)openldap.org > Subject: RE: Using TLS > > I rebuilt with libssl (an OpenSSL library which supports SSL and TLS) and > that worked. Thanks. > > However, I got into the connect error "14090086:SSL > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (self > signed certificate)", even though the LDAP_OPT_X_TLS_REQUIRE_CERT option > is set to LDAP_OPT_X_TLS_NEVER. Isn't LDAP client supposed to bypass > server certificate validation when LDAP_OPT_X_TLS_NEVER is configured? > > Daniel > > -----Original Message----- > From: Paulm [mailto:paulm@tetrardus.net] > Sent: Sunday, June 18, 2017 10:13 PM > > On Fri, Jun 16, 2017 at 03:26:20PM +0000, Daniel Le wrote: >> Hi, >> >> >> I'm seeing some critical error which causes the application program to >> exit/terminate when ldap_start_tls_s(LDAP-handle, NULL, NULL) is >> called. Tracing the code execution, ldap_start_tls_s => >> ldap_int_tls_start => tls_init, it appears the crash is at the >> statement "return impl->ti_tls_init()" in the tls_init function. >> >> >> Can someone give a pointer to help debugging this? And does OpenLDAP >> need to be linked to OpenSSL library for TLS to work? > > If your ldap libs are linked to gnutls, then it might be worthwhile to > rebuild and link to the openssl library; then test your code again. > > I don't use gnutls because it has given me problems. > >> I use LDAPv3, port 389 and the default LDAP_OPT_X_TLS_NEVER option. >> HAVE_TLS is defined but not LDAP_R_COMPILE. >> >> >> Thanks, >> >> Daniel > -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Using TLS
by Daniel Le 23 Jun '17

23 Jun '17

Hi, I'm seeing some critical error which causes the application program to exit/terminate when ldap_start_tls_s(LDAP-handle, NULL, NULL) is called. Tracing the code execution, ldap_start_tls_s => ldap_int_tls_start => tls_init, it appears the crash is at the statement "return impl->ti_tls_init()" in the tls_init function. Can someone give a pointer to help debugging this? And does OpenLDAP need to be linked to OpenSSL library for TLS to work? I use LDAPv3, port 389 and the default LDAP_OPT_X_TLS_NEVER option. HAVE_TLS is defined but not LDAP_R_COMPILE. Thanks, Daniel

2 3

Re: syncrepl fails after upgrade to openldap 2.4.45
by Quanah Gibson-Mount 23 Jun '17

23 Jun '17

--On Thursday, June 22, 2017 10:25 AM +0000 Juergen.Sprenger(a)swisscom.com wrote: > syncrepl rid=000 > provider=ldaps://ldap.dannatu.ch:636 > type=refreshAndPersist > retry="5 5 300 +" > searchbase="dc=dannatu,dc=ch" > attrs="*,+" > scope=sub > bindmethod=simple > binddn="cn=Manager,dc=dannatu,dc=ch" > credentials=************** I don't see anything here configuring for syncrepl to find the CA for your server cert. I.e., something like tls_cacertdir=<path> --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

ldapsearch on accesslog hangs in OpenLDAP 2.4.40 on RHEL 6.9 ( works ok w/ slapcat -b "cn=accesslog")
by Ron Lamarche 22 Jun '17

22 Jun '17

Hi. My company has decided to migrate from Oracle Directory Server 7.0 (ODSEE ) to OpenLDAP due to end of life supportability issues . I've installed the RHEL 6.9 OpenLDAP bundled product and have a working suffix based on cn=config vs. slapd.conf model but cannot get the accesslog overlays/DB's to work properly (ldapsearch returns accesslog records but never completes and instead hangs showing "ldap_int_select" . Need to ctl -c to exit ) Here's the details: - more /etc/redhat-release o Red Hat Enterprise Linux Server release 6.9 (Santiago) - yum list installed | grep openldap o compat-openldap.x86_64 1:2.3.43-2.el6 o openldap.x86_64 2.4.40-16.el6 o openldap-clients.x86_64 2.4.40-16.el6 o openldap-devel.x86_64 2.4.40-16.el6 o openldap-servers.x86_64 2.4.40-16.el6 - ldapsearch -Q -Y EXTERNAL -H ldapi:/// -LLL -b "olcDatabase={2}bdb,cn=config" | egrep "olcRo|olcSu" < - -------- main suffix DB o olcSuffix: dc=mydomain,dc=ca o olcRootDN: cn=dev13,dc=mydomain,dc=ca o olcRootPW: {SSHA}ZODaH7MZuRjuG+FTzIZvdPg5edL2WDjg - ldapsearch -Q -Y EXTERNAL -H ldapi:/// -LLL -b "olcDatabase={3}bdb,cn=config" < - ---accesslog DB and overlay o dn: olcDatabase={3}bdb,cn=config o objectClass: olcDatabaseConfig o objectClass: olcBdbConfig o olcDatabase: {3}bdb o olcDbDirectory: /var/lib/ldap/accesslog o olcSuffix: cn=accesslog o olcRootDN: cn=dev13,dc=mydomain,dc=ca o olcDbIndex: default eq o olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart - o dn: olcOverlay={0}accesslog,olcDatabase={3}bdb,cn=config o objectClass: olcOverlayConfig o objectClass: olcAccessLogConfig o olcOverlay: {0}accesslog o olcAccessLogDB: cn=accesslog o olcAccessLogOps: writes reads session o olcAccessLogPurge: 07+00:00 01+00:00 o olcAccessLogSuccess: TRUE - ldapsearch -Q -Y EXTERNAL -H ldapi:/// -LLL -b "cn=module{0},cn=config" |< - --------------loaded modules o dn: cn=module{0},cn=config o objectClass: olcModuleList o cn: module{0} o olcModulePath: /usr/lib64/openldap o olcModuleLoad: {0}syncprov.la o olcModuleLoad: {1}accesslog.la When I execute the ldapsearch on cn=accesslog I get the following ( ctl-c needed to exit from the hang ) : ldapsearch -d 1 -H ldap:// -v -x -LLL -D "cn=dev13,dc=mailposte,dc=ca" -b cn=accesslog -W ldap_url_parse_ext(ldap://) ldap_initialize( ldap://:389/??base ) ldap_create ldap_url_parse_ext(ldap://:389/??base) Enter LDAP Password: ... stuff omitted due to length ... reqDN: reqStart=20170620210816.000003Z,cn=accesslog ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: reqResult: 0 ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: reqMod: objectClass:+ auditSearch reqMod: structuralObjectClass:+ auditSearch reqMod: reqStart:+ 20170620210816.000003Z reqMod: reqEnd:+ 20170620210816.000004Z reqMod: reqType:+ search reqMod: reqSession:+ 18446744073709551615 reqMod: reqAuthzID:+ cn=dev13,dc=mailposte,dc=ca reqMod: reqDN:+ cn=accesslog reqMod: reqResult:+ 0 reqMod: reqScope:+ one reqMod: reqDerefAliases:+ never reqMod: reqAttrsOnly:+ TRUE reqMod: reqFilter:+ (reqStart<=20170613210816Z) reqMod: reqAttr:+ 1.1 reqMod: reqEntries:+ 0 reqMod: reqTimeLimit:+ -1 reqMod: reqSizeLimit:+ -1 reqMod: entryUUID:+ 52bef5ee-ea48-1036-9807-2fa6ad6fded4 reqMod: creatorsName:+ cn=dev13,dc=mailposte,dc=ca reqMod: createTimestamp:+ 20170620210816Z reqMod: entryCSN:+ 20170620210816.416676Z#000000#000#000000 reqMod: modifiersName:+ cn=dev13,dc=mailposte,dc=ca reqMod: modifyTimestamp:+ 20170620210816Z ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: reqEntryUUID: 52bef5ee-ea48-1036-9807-2fa6ad6fded4 ldap_get_attribute_ber ldap_msgfree ldap_result ld 0x14c91c0 msgid -1 wait4msg ld 0x14c91c0 msgid -1 (infinite timeout) wait4msg continue ld 0x14c91c0 msgid -1 all 0 ** ld 0x14c91c0 Connections: * host: (null) port: 389 (default) refcnt: 2 status: Connected last used: Wed Jun 21 13:46:58 2017 ** ld 0x14c91c0 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ld 0x14c91c0 request count 1 (abandoned 0) ** ld 0x14c91c0 Response Queue: Empty ld 0x14c91c0 response count 0 ldap_chkResponseList ld 0x14c91c0 msgid -1 all 0 ldap_chkResponseList returns ld 0x14c91c0 NULL ldap_int_select ^C When I do an strace of the working suffix ( dc=mydomain,dc=ca ) I get the following termination : - strace ldapsearch -d 1 -H ldap:// -v -x -LLL -D "cn=dev13,dc=mydomain,dc=ca" -b dc=mydomain,dc=ca -w my_passwd ..... stuff omitted due to length .... write(3, "0\5\2\1\3B\0", 7) = 7 shutdown(3, SHUT_RDWR) = 0 close(3) = 0 write(2, "ldap_free_connection: actually f"..., 37ldap_free_connection: actually freed ) = 37 exit_group(0) = ? +++ exited with 0 +++ When I do an strace of cn=accesslog I get the following termination : - strace ldapsearch -d 1 -H ldap:// -v -x -LLL -D "cn=dev13,dc=mydomain,dc=ca" -b cn=accesslog -w my_passwd ..... stuff omitted due to length .... write(1, "reqEntryUUID: 52bef5ee-ea48-1036"..., 51reqEntryUUID: 52bef5ee-ea48-1036-9807-2fa6ad6fded4) = 51 write(2, "ldap_get_attribute_ber\n", 23ldap_get_attribute_ber) = 23 write(2, "ldap_msgfree\n", 13ldap_msgfree) = 13 write(2, "ldap_result ld 0x24381e0 msgid -"..., 34ldap_result ld 0x24381e0 msgid -1) = 34 write(2, "wait4msg ld 0x24381e0 msgid -1 ("..., 50wait4msg ld 0x24381e0 msgid -1 (infinite timeout)) = 50 write(2, "wait4msg continue ld 0x24381e0 m"..., 46wait4msg continue ld 0x24381e0 msgid -1 all 0) = 46 write(2, "** ld 0x24381e0 Connections:\n", 29** ld 0x24381e0 Connections:) = 29 write(2, "* host: (null) port: 389 (defa"..., 37* host: (null) port: 389 (default)) = 37 write(2, " refcnt: 2 status: Connected\n", 31 refcnt: 2 status: Connected) = 31 stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3477, ...}) = 0 write(2, " last used: Wed Jun 21 14:07:30"..., 39 last used: Wed Jun 21 14:07:30 2017) = 39 write(2, "\n", 1) = 1 write(2, "** ld 0x24381e0 Outstanding Requ"..., 38** ld 0x24381e0 Outstanding Requests:) = 38 write(2, " * msgid 2, origid 2, status In"..., 41 * msgid 2, origid 2, status InProgress) = 41 write(2, " outstanding referrals 0, pare"..., 43 outstanding referrals 0, parent count 0) = 43 write(2, " ld 0x24381e0 request count 1 ("..., 45 ld 0x24381e0 request count 1 (abandoned 0)) = 45 write(2, "** ld 0x24381e0 Response Queue:\n", 32** ld 0x24381e0 Response Queue:) = 32 write(2, " Empty\n", 9 Empty) = 9 write(2, " ld 0x24381e0 response count 0\n", 32 ld 0x24381e0 response count 0) = 32 write(2, "ldap_chkResponseList ld 0x24381e"..., 49ldap_chkResponseList ld 0x24381e0 msgid -1 all 0) = 49 write(2, "ldap_chkResponseList returns ld "..., 47ldap_chkResponseList returns ld 0x24381e0 NULL) = 47 write(2, "ldap_int_select\n", 16ldap_int_select) = 16 poll([{fd=3, events=POLLIN|POLLPRI}], 1, -1 < - ------------------------------- This means poll is waiting for something on this File descriptor which never gets returned ^C Process 7844 detached <detached ...> Here is the ldif file used for moduleload by ldapadd : cat addModule.ldif dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib64/openldap #olcModuleLoad: {0}back_bdb olcModuleLoad: syncprov.la olcModuleLoad: accesslog.la Here is the ldif file to add the accesslog db and overlay by ldapadd: cat addAccesslog2DB # Accesslog database definitions dn: olcDatabase={3}bdb,cn=config objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: {3}bdb olcDbDirectory: /var/lib/ldap/accesslog olcSuffix: cn=accesslog olcRootDN: cn=dev13,dc=mydomain,dc=ca olcDbIndex: default eq olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart # accesslog overlay definitions for primary db dn: olcOverlay=accesslog,olcDatabase={3}bdb,cn=config objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: accesslog olcAccessLogDB: cn=accesslog olcAccessLogOps: writes reads session olcAccessLogSuccess: TRUE # scan the accesslog DB every day and purge entries older than 7 days olcAccessLogPurge: 07+00:00 01+00:00 I have also created /var/lib/ldap/accesslog owned by ldap:ldap : ls -l /var/lib/ldap/accesslog total 11232 -rw-r-----. 1 ldap ldap 4096 Jun 20 17:08 alock -rw-------. 1 ldap ldap 24576 Jun 20 17:08 __db.001 -rw-------. 1 ldap ldap 188416 Jun 21 14:07 __db.002 -rw-------. 1 ldap ldap 270336 Jun 21 13:46 __db.003 -rw-------. 1 ldap ldap 98304 Jun 21 13:46 __db.004 -rw-------. 1 ldap ldap 753664 Jun 21 14:07 __db.005 -rw-------. 1 ldap ldap 32768 Jun 21 14:07 __db.006 -rw-------. 1 ldap ldap 8192 Jun 20 17:08 dn2id.bdb -rw-------. 1 ldap ldap 8192 Jun 20 17:08 entryCSN.bdb -rw-------. 1 ldap ldap 32768 Jun 20 17:08 id2entry.bdb -rw-------. 1 ldap ldap 10485760 Jun 20 17:08 log.0000000001 -rw-------. 1 ldap ldap 8192 Jun 20 17:08 objectClass.bdb -rw-------. 1 ldap ldap 8192 Jun 20 17:08 reqEnd.bdb -rw-------. 1 ldap ldap 8192 Jun 20 17:08 reqResult.bdb -rw-------. 1 ldap ldap 8192 Jun 20 17:08 reqStart.bdb I am new to this forum so If I've missed something please let me know. Constructive comments and suggestions are greatly appreciated. regards RON LAMARCHE Technical Specialist, Online Channel Innovapost

1 0

Re: Limit which database is reachable on which port (slapd is listening on)?
by Howard Chu 22 Jun '17

22 Jun '17

Karsten Heymann wrote: > Hi, > > short question: If I configure slapd to listen to several ports and > have several databases configured, is there a way to limit which > database is visible on which port? I want to use a single slapd > instance to serve multiple databases (slapd-meta instances to be > exact) and for each database want to use a dedicated listening port, > somehow like port-based virtual hosts in the apache web server. The > reason is that I want to define different firewall rules for the > different databases. Is this possible with openldap? Read the slapd.access(5) manpage, use an ACL specifying sockname=xxx for the local port identifier. > Best regards > Karsten > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

3 7

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical June 2017