openldap-technical

openldap-technical@openldap.org

9951 discussions

Limit which database is reachable on which port (slapd is listening on)?
by Karsten Heymann 19 Jun '17

19 Jun '17

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? Best regards Karsten

1 0

RE: SIGSEGV on mdb_txn_begin / __pthread_mutex_lock_full
by opensource＠gmx-topmail.de 18 Jun '17

18 Jun '17

> Are you running multiple Docker instances on the same database? AFAIK that won't work because of Docker's munging with POSIX namespaces. No, it is a Single Docker instance. Actually, I saw the same thing happening on a Ubuntu box, so it should not be related to Docker. I restructured the CI tests and divided one big test suite into two. Funny thing is that the problem did not occur anymore as of now. One difference between the now separated tests was that they were using a different version of our lib.so (including the same version of LMDB however). But I hardly see how that might cause problems. *Shrug.*

1 0

Re: SIGSEGV on mdb_txn_begin / __pthread_mutex_lock_full
by Howard Chu 18 Jun '17

18 Jun '17

opensource(a)gmx-topmail.de wrote: > We are using LMDB and are running a big number of tests on a CI server (Debian via Docker, Xenon CPU). Are you running multiple Docker instances on the same database? AFAIK that won't work because of Docker's munging with POSIX namespaces. > The crash happens during opening the database. This is done a lot in the tests without problems (and on Windows this problem does not exist). However, during the CI process we get the crash quite reproducible (~80% crash rate when running the full CI test suite). > > This is our basic code triggering the SIGSEGV (minus error checking for simplicity): > > mdb_env_create(&dbEnv_); > mdb_env_set_maxdbs(dbEnv_, 8); > mdb_env_set_mapsize(dbEnv_, maxDbSizeInKByte * 1024); > mdb_env_open(dbEnv_, directory, 0, fileMode); > MDB_txn* txn; > mdb_txn_begin(dbEnv_, NULL, 0, &txn); > > It crashes inside mdb_txn_begin with this: > SIGSEGV (0xb) at pc=0x00007fd2607e4b58, pid=23603, tid=0x00007fd228633700 > C [libpthread.so.0+0x5b58] __pthread_mutex_lock_full+0x1a8 > > I digged into it a bit, and could tracd it down to this LOCK_MUTEX call in mdb_txn_renew0: > > /* Not yet touching txn == env->me_txn0, it may be active */ > if (ti) { > if (LOCK_MUTEX(rc, env, env->me_wmutex)) > return rc; > > I also logged some data about the env and the mutex (which looks normal however): > PID: 23603 ENV: 0x7fd1e03e9ab0 > TXN: 0x7fd22811b000 COUNT: 0 KIND: 144 LOCK: 0 OWNER: 0 > > Any idea what could go wrong here? > > Thanks! > Markus > > > Some additional crash info: > > siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x00007fd22801a058 > > Registers: > RAX=0x00007fd22801a060, RBX=0x00007fd22811b040, RCX=0x0000000000000000, RDX=0x0000000000000000 > RSP=0x00007fd22862ff50, RBP=0x0000000000005c4f, RSI=0x0000000000000080, RDI=0x0000000000005c4f > R8 =0x0000000000000080, R9 =0x0000000000000000, R10=0x00007fd22811b060, R11=0x0000000000000000 > R12=0x0000000000000000, R13=0x00007fd22813b0f0, R14=0x00007fd2286309d0, R15=0x00007fd25848b000 > RIP=0x00007fd2607e4b58, EFLAGS=0x0000000000010206, CSGSFS=0x0000000000000033, ERR=0x0000000000000006 > TRAPNO=0x000000000000000e > > Top of Stack: (sp=0x00007fd22862ff50) > 0x00007fd22862ff50: 00007fd22813b0f0 00007fd228630040 > 0x00007fd22862ff60: 0000000000000000 00007fd22813b0f0 > 0x00007fd22862ff70: 00007fd2286309d0 00007fd20c2d05e4 > 0x00007fd22862ff80: 00007fd228630050 00007fd22862ff90 > 0x00007fd22862ff90: 0000000000001020 000000000000003c > 0x00007fd22862ffa0: 0000000a00000023 0000000a00000000 > 0x00007fd22862ffb0: 00007fd228633700 00007fd25fee1c29 > 0x00007fd22862ffc0: 0000000000000000 00007fd25fe7a423 > 0x00007fd22862ffd0: 00007fd2286309d0 0000000900000000 > 0x00007fd22862ffe0: 0000000000000008 00007fd244000000 > 0x00007fd22862fff0: 00007fd22813b0f0 00007fd25fe79ae3 > 0x00007fd228630000: 0000000000000000 00000000286300c0 > 0x00007fd228630010: 0000000000000000 00007fd25fe7b255 > 0x00007fd228630020: 00007fd22811b000 00007fd1e03e9ab0 > 0x00007fd228630030: 00007fd1e08f3260 00007fd25fe6fb22 > 0x00007fd228630040: 00007fd2286300c0 00007fd20c2d0e8a > 0x00007fd228630050: 00007fd2286300c0 00007fd2601ac2a0 > 0x00007fd228630060: 0000000000000020 00007fd244000000 > 0x00007fd228630070: 0000000800000000 00007fd25fe79ae3 > 0x00007fd228630080: 0000000000000020 00007fd228630660 > 0x00007fd228630090: 00007fd1e08f3260 00007fd2286301c8 > 0x00007fd2286300a0: 00000000601ac2a0 0000000000000000 > 0x00007fd2286300b0: 00007fd1e03e9ab0 00007fd25fe6fb22 > 0x00007fd2286300c0: 00007fd228630660 00007fd20c23a768 > 0x00007fd2286300d0: 0000000200f01b00 00007fd20000003b > 0x00007fd2286300e0: 00007fd20c2eb3fd 00007fd24921da4c > 0x00007fd2286300f0: 00000005cac01420 00007fd22814c210 > 0x00007fd228630100: 00007fd228630460 00007fd24921f99f > 0x00007fd228630110: 00007fd2286301c8 0000002000000000 > 0x00007fd228630120: 0000000000000000 0000000000000000 > 0x00007fd228630130: 0000000000000000 0000000000000020 > 0x00007fd228630140: 0000000000000000 0000000000000000 > > Instructions: (pc=0x00007fd2607e4b58) > 0x00007fd2607e4b38: 00 a9 00 00 00 40 0f 85 02 ff ff ff c7 43 04 01 > 0x00007fd2607e4b48: 00 00 00 64 48 8b 04 25 e0 02 00 00 48 83 e0 fe > 0x00007fd2607e4b58: 4c 89 50 f8 64 48 8b 04 25 e0 02 00 00 48 89 43 > 0x00007fd2607e4b68: 20 64 48 8b 04 25 10 00 00 00 48 05 e0 02 00 00 > > Register to memory mapping: > > RAX=0x00007fd22801a060 is an unknown value > RBX=0x00007fd22811b040 is an unknown value > RCX=0x0000000000000000 is an unknown value > RDX=0x0000000000000000 is an unknown value > RSP=0x00007fd22862ff50 is pointing into the stack for thread: 0x00007fd25848b000 > RBP=0x0000000000005c4f is an unknown value > RSI=0x0000000000000080 is an unknown value > RDI=0x0000000000005c4f is an unknown value > R8 =0x0000000000000080 is an unknown value > R9 =0x0000000000000000 is an unknown value > R10=0x00007fd22811b060 is an unknown value > R11=0x0000000000000000 is an unknown value > R12=0x0000000000000000 is an unknown value > R13={method} {0x00007fd22813b0f0} 'nativeCreate' '(Ljava/lang/String;J[B)J' in 'MyDb' > R14=0x00007fd2286309d0 is pointing into the stack for thread: 0x00007fd25848b000 > R15=0x00007fd25848b000 is a thread > > > > -- -- 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

Elliptic Curve support in 2.4 branch
by Abdelkader Chelouah 18 Jun '17

18 Jun '17

Elliptic Curve support for OpenSSL was added in master branch 4 years ago (ITS#7595). Is there any plan to backport EC support for OpenSSL in 2.4 branch ?

1 0

slap_global_control: unrecognized control: 1.3.6.1.4.1.4203.666.5.16
by Jelle de Jong 18 Jun '17

18 Jun '17

Hello everybody, I am getting a lot of these slap_global_control messages in my syslog. I searched online and tried adding the bellow to my /etc/ldap/slapd.conf but it did not help. Does somebody know how to resolve these messages? Kind regards, Jelle de Jong include /etc/ldap/schema/ppolicy.schema Jun 15 13:15:08 cassidy slapd[9071]: slap_global_control: unrecognized control: 1.3.6.1.4.1.4203.666.5.16 cassidy:~# slapd -V @(#) $OpenLDAP: slapd (May 30 2017 07:56:03) $ buildd@x86-ubc-01:/build/openldap-BLqnh8/openldap-2.4.40+dfsg/debian/build/servers/slapd cassidy:~# ldapsearch -x -b "" -s base supportedControl # extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectclass=*) # requesting: supportedControl # # dn: supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.2 supportedControl: 1.3.6.1.4.1.4203.1.10.1 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.2.826.0.1.3344810.2.3 supportedControl: 1.3.6.1.1.13.2 supportedControl: 1.3.6.1.1.13.1 supportedControl: 1.3.6.1.1.12 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1

2 1

Re: using -c with slapd to force full reload
by Quanah Gibson-Mount 15 Jun '17

15 Jun '17

--On Thursday, June 15, 2017 4:20 PM -0700 Daniel Jung <mimianddaniel(a)gmail.com> wrote: > > > > -c with RID of the consumer and using Syncrepl. > I see the ITSs are opened for the related issue. I am only seeing this > problem on some consumer and not on the master by the way. I will see if > the masters are not in synced in all the datas. Hi Daniel, Your answer still isn't clear to me. From what you wrote, I would interpret that as doing -c 100 (-c with the RID of the consumer). The man page clearly states it takes a value pair, like -c rid=100 Generally, you're always better off doing a slapcat of the master and a slapadd on the consumer as it takes less time to populate the DB, and you don't have to worry about clients getting results from a partial database. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: using -c with slapd to force full reload
by Daniel Jung 15 Jun '17

15 Jun '17

-c with RID of the consumer and using Syncrepl. I see the ITSs are opened for the related issue. I am only seeing this problem on some consumer and not on the master by the way. I will see if the masters are not in synced in all the datas. On Jun 14, 2017 12:56, "Quanah Gibson-Mount" <quanah(a)symas.com> wrote: --On Monday, June 12, 2017 5:19 PM -0700 Daniel Jung < mimianddaniel(a)gmail.com> wrote: Am I misreading the man page where providing rid only with -c forces > full reload? > Also, anyone seeing unsynced entries even though contextcsn is in > synced? > -c or -c 0? syncrepl or delta-syncrepl? There are known cases where replication can fail to properly sync: <http://www.openldap.org/its/index.cgi/?findid=8125> --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

SIGSEGV on mdb_txn_begin / __pthread_mutex_lock_full
by opensource＠gmx-topmail.de 15 Jun '17

15 Jun '17

We are using LMDB and are running a big number of tests on a CI server (Debian via Docker, Xenon CPU). The crash happens during opening the database. This is done a lot in the tests without problems (and on Windows this problem does not exist). However, during the CI process we get the crash quite reproducible (~80% crash rate when running the full CI test suite). This is our basic code triggering the SIGSEGV (minus error checking for simplicity): mdb_env_create(&dbEnv_); mdb_env_set_maxdbs(dbEnv_, 8); mdb_env_set_mapsize(dbEnv_, maxDbSizeInKByte * 1024); mdb_env_open(dbEnv_, directory, 0, fileMode); MDB_txn* txn; mdb_txn_begin(dbEnv_, NULL, 0, &txn); It crashes inside mdb_txn_begin with this: SIGSEGV (0xb) at pc=0x00007fd2607e4b58, pid=23603, tid=0x00007fd228633700 C [libpthread.so.0+0x5b58] __pthread_mutex_lock_full+0x1a8 I digged into it a bit, and could tracd it down to this LOCK_MUTEX call in mdb_txn_renew0: /* Not yet touching txn == env->me_txn0, it may be active */ if (ti) { if (LOCK_MUTEX(rc, env, env->me_wmutex)) return rc; I also logged some data about the env and the mutex (which looks normal however): PID: 23603 ENV: 0x7fd1e03e9ab0 TXN: 0x7fd22811b000 COUNT: 0 KIND: 144 LOCK: 0 OWNER: 0 Any idea what could go wrong here? Thanks! Markus Some additional crash info: siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x00007fd22801a058 Registers: RAX=0x00007fd22801a060, RBX=0x00007fd22811b040, RCX=0x0000000000000000, RDX=0x0000000000000000 RSP=0x00007fd22862ff50, RBP=0x0000000000005c4f, RSI=0x0000000000000080, RDI=0x0000000000005c4f R8 =0x0000000000000080, R9 =0x0000000000000000, R10=0x00007fd22811b060, R11=0x0000000000000000 R12=0x0000000000000000, R13=0x00007fd22813b0f0, R14=0x00007fd2286309d0, R15=0x00007fd25848b000 RIP=0x00007fd2607e4b58, EFLAGS=0x0000000000010206, CSGSFS=0x0000000000000033, ERR=0x0000000000000006 TRAPNO=0x000000000000000e Top of Stack: (sp=0x00007fd22862ff50) 0x00007fd22862ff50: 00007fd22813b0f0 00007fd228630040 0x00007fd22862ff60: 0000000000000000 00007fd22813b0f0 0x00007fd22862ff70: 00007fd2286309d0 00007fd20c2d05e4 0x00007fd22862ff80: 00007fd228630050 00007fd22862ff90 0x00007fd22862ff90: 0000000000001020 000000000000003c 0x00007fd22862ffa0: 0000000a00000023 0000000a00000000 0x00007fd22862ffb0: 00007fd228633700 00007fd25fee1c29 0x00007fd22862ffc0: 0000000000000000 00007fd25fe7a423 0x00007fd22862ffd0: 00007fd2286309d0 0000000900000000 0x00007fd22862ffe0: 0000000000000008 00007fd244000000 0x00007fd22862fff0: 00007fd22813b0f0 00007fd25fe79ae3 0x00007fd228630000: 0000000000000000 00000000286300c0 0x00007fd228630010: 0000000000000000 00007fd25fe7b255 0x00007fd228630020: 00007fd22811b000 00007fd1e03e9ab0 0x00007fd228630030: 00007fd1e08f3260 00007fd25fe6fb22 0x00007fd228630040: 00007fd2286300c0 00007fd20c2d0e8a 0x00007fd228630050: 00007fd2286300c0 00007fd2601ac2a0 0x00007fd228630060: 0000000000000020 00007fd244000000 0x00007fd228630070: 0000000800000000 00007fd25fe79ae3 0x00007fd228630080: 0000000000000020 00007fd228630660 0x00007fd228630090: 00007fd1e08f3260 00007fd2286301c8 0x00007fd2286300a0: 00000000601ac2a0 0000000000000000 0x00007fd2286300b0: 00007fd1e03e9ab0 00007fd25fe6fb22 0x00007fd2286300c0: 00007fd228630660 00007fd20c23a768 0x00007fd2286300d0: 0000000200f01b00 00007fd20000003b 0x00007fd2286300e0: 00007fd20c2eb3fd 00007fd24921da4c 0x00007fd2286300f0: 00000005cac01420 00007fd22814c210 0x00007fd228630100: 00007fd228630460 00007fd24921f99f 0x00007fd228630110: 00007fd2286301c8 0000002000000000 0x00007fd228630120: 0000000000000000 0000000000000000 0x00007fd228630130: 0000000000000000 0000000000000020 0x00007fd228630140: 0000000000000000 0000000000000000 Instructions: (pc=0x00007fd2607e4b58) 0x00007fd2607e4b38: 00 a9 00 00 00 40 0f 85 02 ff ff ff c7 43 04 01 0x00007fd2607e4b48: 00 00 00 64 48 8b 04 25 e0 02 00 00 48 83 e0 fe 0x00007fd2607e4b58: 4c 89 50 f8 64 48 8b 04 25 e0 02 00 00 48 89 43 0x00007fd2607e4b68: 20 64 48 8b 04 25 10 00 00 00 48 05 e0 02 00 00 Register to memory mapping: RAX=0x00007fd22801a060 is an unknown value RBX=0x00007fd22811b040 is an unknown value RCX=0x0000000000000000 is an unknown value RDX=0x0000000000000000 is an unknown value RSP=0x00007fd22862ff50 is pointing into the stack for thread: 0x00007fd25848b000 RBP=0x0000000000005c4f is an unknown value RSI=0x0000000000000080 is an unknown value RDI=0x0000000000005c4f is an unknown value R8 =0x0000000000000080 is an unknown value R9 =0x0000000000000000 is an unknown value R10=0x00007fd22811b060 is an unknown value R11=0x0000000000000000 is an unknown value R12=0x0000000000000000 is an unknown value R13={method} {0x00007fd22813b0f0} 'nativeCreate' '(Ljava/lang/String;J[B)J' in 'MyDb' R14=0x00007fd2286309d0 is pointing into the stack for thread: 0x00007fd25848b000 R15=0x00007fd25848b000 is a thread

1 0

Re: using -c with slapd to force full reload
by Quanah Gibson-Mount 14 Jun '17

14 Jun '17

--On Monday, June 12, 2017 5:19 PM -0700 Daniel Jung <mimianddaniel(a)gmail.com> wrote: > Am I misreading the man page where providing rid only with -c forces > full reload? > Also, anyone seeing unsynced entries even though contextcsn is in > synced? -c or -c 0? syncrepl or delta-syncrepl? There are known cases where replication can fail to properly sync: <http://www.openldap.org/its/index.cgi/?findid=8125> --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Attempting to set Access Control for auth to Perl Backend
by Quanah Gibson-Mount 13 Jun '17

13 Jun '17

--On Tuesday, June 06, 2017 5:32 PM +0000 Etan Weintraub <eweintra(a)jhmi.edu> wrote: > I now need to do the same type of thing for another branch, but for > authentication instead (i.e. only allow auth to occur if coming from an > approved IP). I've tried the following: > > access to dn.sub="dc=mfa" > > by peername.ip=127.0.0.1 auth > > by peername.ip=10.181.24.193 auth > > by * none > > > > But no luck. Any ideas/help? If I can't do this with an ACL, if I can > get the IP address of the request passed in to the bind function in the > Perl backend, I can handle the controls there. That's not really what "auth" access means. Are you using simple binds? If so, I'd try something like: access to dn.sub="dc=mfa" attrs=userPassword by peername.ip=127.0.0.1 anonymous auth by peername.ip=10.181.24.193 anonymous auth by <admin> write access to dn.sub="dc=mfa" by users read Now this makes some assumptions: a) Users auth against an entry in the dc=mfa tree, and b) that users only exist in that tree. Alternatively, you may wish to look at set based ACLs to set it so that only entries that exist /in/ the dc=mfa tree can read entries in the dc=mfa tree, combined with the IP restrictions. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

3 2

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical