openldap-technical

openldap-technical@openldap.org

13 participants
9795 discussions

slapo-rwm documentation
by Ralf Mattes 17 Oct '16

17 Oct '16

Dear collected list wisdom, I have successfully set up a relay database with Rwm suffix massaging. Now, for a client app I need to transform gorupOfNames into posixGroups and member attributes into memberUID. I was able to do the objectclass/attribute transformation with olcRwmMaps but now I need to transform the attribute _values_ (i.e. I need to strip the DN-valued member values to get uids). From the existing documentation I can't find out how to restrict a rwm-RewriteRule to (certain) attributes. Any help? TIA Ralf Mattes

1 0

Public LDAP server, what do I need to know?
by John Lewis 16 Oct '16

16 Oct '16

I want to host a LDAP server that contains a directory that contains the offices of local Representatives and Public Servants, the issues they are responsible for, and their names. I would like anyone who wants to to browse it or put up front ends. Is there anything in particular that I should keep in mind?

1 0

openldap 2.4.40 on RHEL7
by Real, Elizabeth (392K) 15 Oct '16

15 Oct '16

Hello, Quick question about replication, I’m setting up an ldapclient to talk to my two LDAP servers which are replicating fine. To be able to talk to both LDAP servers, do I need to scp the server certificate (cert.pem) from both servers into the ldapclient /etc/openldap/cacerts directory? I’m looking at this documentation to configure the ldap client using sssd: https://www.certdepot.net/ldap-client-configuration-authconfig/ Thank you, Liz

2 1

Re: group membership search performance
by Quanah Gibson-Mount 14 Oct '16

14 Oct '16

--On Friday, October 14, 2016 1:13 PM +0200 Rébeli-Szabó Tamás <tamas.rebeli.szabo(a)webvalto.hu> wrote: > Hi Quanah, > > yes, it takes 5–7 seconds for each search. I believe that's a general known issue with very large groups. I personally moved to using dynamic groups via slapo-dynlist for a variety of reasons, performance being one. You may want to test in a dev environment if your issues go away if you move to dynamic groups instead. --Quanah -- Quanah Gibson-Mount Product Engineer Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: group membership search performance
by Quanah Gibson-Mount 14 Oct '16

14 Oct '16

--On Wednesday, October 12, 2016 10:11 PM +0200 Rébeli-Szabó Tamás <tamas.rebeli.szabo(a)webvalto.hu> wrote: > Hi, > > we are on OpenLDAP 2.4.41 + MDB, Oracle Linux 6 (2.6 x86_64). > > In our DIT we have around 300 groups, with tens of thousands of members > in each group. When we want to know which groups a certain user belongs > to, it takes OpenLDAP several seconds to perform such a search. > > Here is a log excerpt showing that it took 6 seconds for the server to > answer: > > Oct 10 15:39:38 ldap-srv1 slapd[14776]: conn=1062 op=1 SRCH > base="ou=groups,dc=tt,dc=hu" scope=1 deref=0 > filter="(&(uniqueMember=uid=o10011,ou=users,dc=tt,dc=hu)(objectClass=grou > pOfUniqueNames))" > Oct 10 15:39:44 ldap-srv1 slapd[14776]: conn=1062 op=1 SEARCH RESULT > tag=101 err=0 nentries=127 text= > > We have eq indices on objectClass and uniqueMember, and the latter is > also listed after sortvals. > > The machine running OpenLDAP has 2 virtual cores of Intel Xeon E5 2637 v2 > (3.5GHz). During such searches, one of the CPU cores is almost fully > loaded, but the system is not overloaded (the average load is around > 0.8). Our whole dataset is under 1 GB, and there are several gigabytes > of free RAM with no swapping. > > Our expectation would be for OpenLDAP to give an answer to a group > membership question under 1 second. Is that a realistic expectation, and > if so, how should we tune OpenLDAP or what do you suggest we change? > Version 2.4.41 is more than a year old, so the question is if there is > any significant performance enhancement (an order of magnitude) possible > with this setup described above, or that's about all we can get from > OpenLDAP+MDB (or perhaps any in-memory LDAP)? Does it always take 6 seconds to return the 127 group entries that match, or is that only on the first search? --Quanah -- Quanah Gibson-Mount Product Engineer Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

OpenLDAP server attack surface analysis shows UDP port 63515 in unknown state
by Sreekanth Sukumaran 14 Oct '16

14 Oct '16

Sorry, I missed to add subject in the last mail. Resending with subject. sorry about spamming the group Hi All, OpenLDAP version : 2.4.39 on windows Tool used : Microsoft Attack surface analyzer We have been doing attack surface analysis on OpenLDAP server, and we have found that there is an UDP port 63515 associated with OpenLDAP server. (state shows "Unknown", not listening or established) [image: Inline image 1] We have not connected any clients to OpenLDAP server, so we cannot think of it as an ephemeral port at server end as well. Has anyone an idea on what this port could be for. Inputs are much appreciated. -- Regards, Sreekanth -- Regards, Sreekanth 09036794524

5 5

syncrepl not working: "no serverID / URL match found"
by Daniel Spannbauer 14 Oct '16

14 Oct '16

Hello, at the moment we have an server running openSuSE 11.4 (lets call in server2), running openldap 2.4.23. Configured is a replication to/from out mainoffice (running openldap 2.4.17, server1). Replication works fine. I wan't to replace server2 with a newer one, running openldap 2.4.33 atm. ---------------------------------------------- Configuration for replication on server2: moduleload syncprov.la serverID 1 "ldap://server1.mainoffice.xxx.de" serverID 2 "ldap://server2.branch.xxx.de" overlay syncprov syncrepl rid=001 provider=ldap://server1.mainoffice.xxx.de:389 binddn="cn=Administrator,dc=xxx,dc=de" bindmethod=simple credentials=somepassowrd searchbase=" dc=marco,dc=de" type=refreshAndPersist interval=00:00:00:10 retry="5 5 300 +" timeout=1 mirrormode TRUE overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE syncprov-checkpoint 1000 60 ---------------------------------------------- This config works fine with the "old" 2.4.23, but on 2.4.33 I get the following error when I start it on the commandline with /usr/lib/openldap/slapd -h ldap:/// -f /etc/openldap/slapd.conf -u ldap -g ldap -o slp=off -d 1 57ff35cc read_config: no serverID / URL match found. Check slapd -h arguments. Any hints about this? regards Daniel -- Daniel Spannbauer Systemadministration marco Systemanalyse und Entwicklung GmbH Tel +49 8333 9233-27 Fax -11 Rechbergstr. 4-6, D 87727 Babenhausen Mobil +49 171 4033220 http://www.marco.de/ Email ds(a)marco.de Geschäftsführer Martin Reuter HRB 171775 Amtsgericht München

2 1

Re: syncrepl not working: "no serverID / URL match found"
by Quanah Gibson-Mount 14 Oct '16

14 Oct '16

--On Thursday, October 13, 2016 10:22 AM +0200 Daniel Spannbauer <ds(a)marco.de> wrote: > serverID 1 "ldap://server1.mainoffice.xxx.de" > serverID 2 "ldap://server2.branch.xxx.de" > This config works fine with the "old" 2.4.23, but on 2.4.33 I get the > following error when I start it on the commandline with > /usr/lib/openldap/slapd -h ldap:/// -f /etc/openldap/slapd.conf -u > ldap -g ldap -o slp=off -d 1 > > 57ff35cc read_config: no serverID / URL match found. Check slapd -h > arguments. Hi Daniel, As the error message notes, there is no match between what you are passing to -h when slapd starts (ldap:///) and a URI in your serverID config (ldap://server1... ldap://server2...). Adjust your -h option to slapd so that it can be matched against a server ID. Hope that helps! --Quanah -- Quanah Gibson-Mount Product Engineer Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: LMDB: Ignore SIGPIPE in mdb_env_copythr
by Howard Chu 13 Oct '16

13 Oct '16

Lorenz Bauer wrote: > Hello Hallvard, List, > > I'd like to propose explicitly ignoring SIGPIPE in the copy thread via > pthread_sigmask, and returning EPIPE to the caller instead. Feel free to submit a patch to the ITS, according to http://www.openldap.org/devel/contributing.html Since it seems this is a pretty small change, I suggest your IPR notice should place your changes into the public domain. > > This is a change that makes little sense in the C world, since the > caller can simply adjust the sigmask before calling the function > (which is indeed what the utilities do). However, this amount of > control is not always given, e.g. when using LMDB from Go (which is > what I am doing). > > Due to the way the Go runtime works, using mdb_env_copyfd2 with > CP_COMPACT on a pipe or a network connection will abort the whole > process with SIGPIPE if the reading end of the fd is closed > prematurely. The details why this happens are in [1]. Go has some > additional trickery when dealing with stdin and stdout, so ignoring > SIGPIPE for the whole process is undesirable (details in [2]). > > I understand that you might be reluctant to change the behaviour due > to the constraints of a different runtime. However, I think that even > in the C world it is surprising that calling a library function can > abort your process. > > What are your thoughts regarding this? I think the code changes would > be small, and the API would not change for consumers of the library. > > 1: https://golang.org/pkg/os/signal/#hdr-Go_programs_that_use_cgo_or_SWIG > 2: https://golang.org/pkg/os/signal/#hdr-SIGPIPE > > Best, > Lorenz > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

group membership search performance
by Rébeli-Szabó Tamás 12 Oct '16

12 Oct '16

Hi, we are on OpenLDAP 2.4.41 + MDB, Oracle Linux 6 (2.6 x86_64). In our DIT we have around 300 groups, with tens of thousands of members in each group. When we want to know which groups a certain user belongs to, it takes OpenLDAP several seconds to perform such a search. Here is a log excerpt showing that it took 6 seconds for the server to answer: Oct 10 15:39:38 ldap-srv1 slapd[14776]: conn=1062 op=1 SRCH base="ou=groups,dc=tt,dc=hu" scope=1 deref=0 filter="(&(uniqueMember=uid=o10011,ou=users,dc=tt,dc=hu)(objectClass=groupOfUniqueNames))" Oct 10 15:39:44 ldap-srv1 slapd[14776]: conn=1062 op=1 SEARCH RESULT tag=101 err=0 nentries=127 text= We have eq indices on objectClass and uniqueMember, and the latter is also listed after sortvals. The machine running OpenLDAP has 2 virtual cores of Intel Xeon E5 2637 v2 (3.5GHz). During such searches, one of the CPU cores is almost fully loaded, but the system is not overloaded (the average load is around 0.8). Our whole dataset is under 1 GB, and there are several gigabytes of free RAM with no swapping. Our expectation would be for OpenLDAP to give an answer to a group membership question under 1 second. Is that a realistic expectation, and if so, how should we tune OpenLDAP or what do you suggest we change? Version 2.4.41 is more than a year old, so the question is if there is any significant performance enhancement (an order of magnitude) possible with this setup described above, or that's about all we can get from OpenLDAP+MDB (or perhaps any in-memory LDAP)? Regards, tamas

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical