openldap-technical

openldap-technical@openldap.org

9 participants
9868 discussions

Start a nNew thread

Help with LDAP Notifications
by Manojkiran Eda 08 Aug '19

08 Aug '19

1 0

How to change BaseDN? (OpenLDAP/slapd)
by Dominique Fuchs 08 Aug '19

08 Aug '19

Hi everyone, I'm actually stuck trying to set up an OpenLDAP implementation on my server running debian/slapd. Based on the hostname of the server (server.foo.bar) slapd automatically sets up the base config with dc=foo,dc=bar as BaseDN. This runs fine and I can connect successfully. However, I actually want the BaseDN for the LDAP structure to rely on the subdomain ldap.foo.bar (dc=ldap,dc=foo,dc=bar). How can I accomplish this? I already tried to fiddle around with ldapmodify/ldif-files, but the only thing I found online where descriptions of how to add a node, not how to change the root node. This post on SO: https://stackoverflow.com/questions/19537319/change-basedn-in-openldap only explains how to rename an existing setup (and even there I can't imagine there isn't a more native way of changing the BaseDN). Thanks in advance!

5 6

Fwd: Clarification regarding global ldapoptions structure in ldap
by sachidananda sahu 07 Aug '19

07 Aug '19

Hi All, I recently upgraded to openldap 2.4.47, it's working with single threaded connection but with multi threaded getting problem due to global structure of ldapoptions in init.c ------------------------- init.c ------------------------- *struct* ldapoptions <http://opengrok-prd.eng.netapp.com/source/s?defs=ldapoptions&project=dev> ldap_int_global_options <http://opengrok-prd.eng.netapp.com/source/s?refs=ldap_int_global_options&pr…> = { LDAP_UNINITIALIZED <http://opengrok-prd.eng.netapp.com/source/s?defs=LDAP_UNINITIALIZED&project…>, LDAP_DEBUG_NONE <http://opengrok-prd.eng.netapp.com/source/s?defs=LDAP_DEBUG_NONE&project=dev> LDAP_LDO_NULLARG <http://opengrok-prd.eng.netapp.com/source/s?defs=LDAP_LDO_NULLARG&project=d…> LDAP_LDO_CONNECTIONLESS_NULLARG <http://opengrok-prd.eng.netapp.com/source/s?defs=LDAP_LDO_CONNECTIONLESS_NU…> LDAP_LDO_TLS_NULLARG <http://opengrok-prd.eng.netapp.com/source/s?defs=LDAP_LDO_TLS_NULLARG&proje…> LDAP_LDO_SASL_NULLARG <http://opengrok-prd.eng.netapp.com/source/s?defs=LDAP_LDO_SASL_NULLARG&proj…> LDAP_LDO_GSSAPI_NULLARG <http://opengrok-prd.eng.netapp.com/source/s?defs=LDAP_LDO_GSSAPI_NULLARG&pr…> LDAP_LDO_MUTEX_NULLARG <http://opengrok-prd.eng.netapp.com/source/s?defs=LDAP_LDO_MUTEX_NULLARG&pro…> }; This global structure is accessed at multiple places (such as ldap_pvt_tls_init_def_ctx <http://opengrok-prd.eng.netapp.com/source/s?refs=ldap_pvt_tls_init_def_ctx&…>, alloc_handle <http://opengrok-prd.eng.netapp.com/source/s?refs=alloc_handle&project=dev>, ldap_int_tls_connect <http://opengrok-prd.eng.netapp.com/source/s?refs=ldap_int_tls_connect&proje…>, *ldap_pvt_tls_destroy <http://opengrok-prd.eng.netapp.com/source/xref/R9.6x/third_party/open_sourc…>, ldap_ld_free*) in tls2.c using the macro lo <http://opengrok-prd.eng.netapp.com/source/s?defs=lo&project=dev> = LDAP_INT_GLOBAL_OPT <http://opengrok-prd.eng.netapp.com/source/s?defs=LDAP_INT_GLOBAL_OPT&projec…> (); So in case of multi threaded application multiple ldap connection will be using this global structure, for example ldo_tls_ctx of lapoptions will be used. In one thread it can be creating a tls connection and in one it can be destroying the connection. As it's global so it is getting corrupted. Is openldap library thread safe completely ? Because this variable seems to be not for this tls context variable, is there any other way of using this context . As i can see a local variable ldo_tls_ctx exist in dap ld->ldc->ldap_options->ldo_tls_ctx structure, but it's just got assigned with the same address of global structure in ldap_int_tls_connect <http://opengrok-prd.eng.netapp.com/source/s?refs=ldap_int_tls_connect&proje…> . So can someone share some thoughts on it ? -- Regards, Sachidananda Sahu

2 8

Re: Trouble with “Connection Refused” errors and timeouts on server with high Thread Backload
by erich_2323 06 Aug '19

06 Aug '19

Hi OpenLdap folks, I ran into an issue with OpenLdap 2.4.44 that I am having trouble finding the root cause of. I run Openldap in syncrepl mode. I have one machine which serves as a write endpoint (let’s call it the master node), and many machines which sync from it, and serve as read-replicas. To ensure that they are in-sync with the Master, each read-replica runs ldapsearch against the Master node every minute. It looks at the entryCSN values for a bunch of objects on the Master, and compares against its own entryCSNs for its copy of these objects. It searches a bunch of different objects, and in total takes about 3 seconds for a read replica to do this search (I have duration logging on LDAP operations enabled by merging in this patch (http://www.openldap.org/its/index.cgi/Software%20Enhancements?id=8054;page=9). About 20 MB are transferred to each read-replica when they run this script. NOTE: I prefer not to use the contextCSN for this sync because I only care about certain objects of the database being in-sync, and I need to know specifically which objects are in-sync vs out-of-sync. I doubled the amount of times this script runs per read-replica. Therefore instead of each read-replica running this script once per minute, it was running it twice per minute. Shortly thereafter, I started getting reports from someone who writes to the LDAP Master regularly that they are seeing a high amount of write operations failing with timeouts and “Connection Refused” errors. I reduced the frequency of the script back to once per minute, and the writer reported that they were no longer seeing these errors. I assumed that this Connection Refused error was due to the fact that Openldap 2.4 uses a single thread for incoming connections (sources: https://lwn.net/Articles/755207/, https://www.openldap.org/pub/slim/OpenLDAP_Conn_Mgmt.pdf (section 3)), and the pending connection backlog on the socket was too high. Therefore the syscall is returning Connection Refused. This may be similar to the frontend contention issue described in this post: (http://www.openldap.org/lists/openldap-devel/201308/msg00003.html). I noticed that the values for cn=Backload,cn=Threads,cn=Monitor as well as cn=Pending,cn=Threads,cn=Monitor got very high when the read-replicas were running the script twice as much. For example, Pending is usually sitting around 5-6, but during the time of high read traffic, I saw Pending count increase by over 1000 times (my graph looks very spiky, with pending threads shooting up to 1000x, then down to 10x or 100x the next minute, then back up, etc.). I understand that cn=Backload is simply Active + Pending Threads, and interestingly Active threads stayed at normal levels. I am wondering what Pending threads means exactly, and how is Pending Threads different from Read/Write Waiters? (Interestingly, Read/Write Waiters stayed at normal levels.) I attempted to reproduce this issue by running the script concurrently from a few different clients, hoIver, I was unable to get the Pending/Backload Threads up to similar levels (this value hovered around 16, which seems healthy. I did not see it spike up to similarly high levels). I observed that the latency of the Master from the read-replica’s perspective increased quite a bit during this test, but was unable to observe Connection Refused issues. Is my assumption about the cause of this issue (single thread for incoming connections) down the right track? Is this behavior (high Pending/Backload Threads, Connection Refused errors) a known occurrence? Are there any other metrics that I can observe which would indicate what is the cause of the Connection Refused errors? Is there a reliable way to repro this issue (without doubling the frequency of the read-replica script)? NOTE: I have the following settings configured, which I suspect may be relevant: olcConcurrency: 0 olcConnMaxPending: 100 olcConnMaxPendingAuth: 1000 olcGentleHUP: FALSE olcIdleTimeout: 60 olcIndexSubstrIfMaxLen: 4 olcIndexSubstrIfMinLen: 2 olcIndexSubstrAnyLen: 4 olcIndexSubstrAnyStep: 2 olcIndexIntLen: 4 olcListenerThreads: 1 olcLocalSSF: 71 olcLogLevel: Stats olcLogLevel: Sync olcSizeLimit: unlimited olcSockbufMaxIncoming: 262143 olcSockbufMaxIncomingAuth: 16777215 olcThreads: 16 olcToolThreads: 1 olcWriteTimeout: 0 Thanks, Sent with [ProtonMail](https://protonmail.com) Secure Email.

2 3

Re: Openldap Acl
by Quanah Gibson-Mount 29 Jul '19

29 Jul '19

--On Sunday, July 28, 2019 11:47 PM +0100 Meryem Fahim <meryem.f97(a)gmail.com> wrote: Hello, Please keep replies on the list. > Hello > Thank you for taking the time to respond.You have asked me to provide you > with my set of ACLs so here it is: > dn: olcDAtabase={0}config,cn=config You're changing the ACLs on the wrong database. That DN is clearly for the cn=config datbase, and so would not apply to the DB that contains your users, etc. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Openldap Access Control
by Meryem Fahim 26 Jul '19

26 Jul '19

HELLO; i'm working on an Openldap project where im supposed to create groups and users and be able to work with phpldapadmin,I've done all of that. Now I want to modify access whereas ensaUser and estUser when logging in will be able to see only the branch they are in(and give that privilege to admin only) I tried so many ACLs (using ldapmodify) but nothing seems to work,when I log in with one of the users I still can see the whole dataBase,I would appreciate some help.thank you

2 1

slapd-sock v2.4.47 not returning LDIF
by Giuseppe De Marco 26 Jul '19

26 Jul '19

Hello everyone, I made a configuration to get slapd-sock to work with a python3 server (gevent). The slapd configuration can be reproduced less then a minute using this ansible playbook: https://github.com/peppelinux/ansible-slapd-eduperson2016 the python3 server is available at the following resource, slapd-sock backend configuration can be found in the README file: https://github.com/peppelinux/pyMultiLDAP It is the following: ldapadd -Y EXTERNAL -H ldapi:/// <<EOF dn: cn=module,cn=config objectClass: olcModuleList cn: module olcModuleLoad: back_sock.la EOF ldapadd -Y EXTERNAL -H ldapi:/// <<EOF dn: olcDatabase={4}sock,cn=config objectClass: olcDbSocketConfig olcDatabase: {4}sock olcDbSocketPath: /var/run/multildap.sock olcSuffix: dc=proxy,dc=unical,dc=it olcDbSocketExtensions: binddn peername ssf EOF I tested that this configuration doesn't have any problems in a Debian 9 installation (slapd 2.4.44) but in a Debian10 (2.4.47) does. Even if I use "servers/slapd/back-sock/searchexample.pl" [1] I get the same faulty result, described as follow: ```` # extended LDIF # # LDAPv3 # base <dc=proxy,dc=unical,dc=it> with scope subtree # filter: uid=mario # requesting: ALL # # search result search: 2 result: 0 Success text: OK ```` As we can see RESULT was found but with any preceeding ldif. Looking into /var/log/slapd.log I found the same behaviour of Debian9 installation: ```` [25-07-2019 10:33:57] slapd debug conn=1036 fd=20 ACCEPT from IP= 127.0.0.1:54674 (IP=0.0.0.0:389) [25-07-2019 10:33:57] slapd debug conn=1036 op=0 BIND dn="cn=admin,dc=testunical,dc=it" method=128 [25-07-2019 10:33:57] slapd debug conn=1036 op=0 BIND dn="cn=admin,dc=testunical,dc=it" mech=SIMPLE ssf=0 [25-07-2019 10:33:57] slapd debug conn=1036 op=0 RESULT tag=97 err=0 text= [25-07-2019 10:33:57] slapd debug conn=1036 op=1 SRCH base="dc=proxy,dc=unical,dc=it" scope=2 deref=0 filter="(objectClass=*)" [25-07-2019 10:33:57] slapd debug conn=1034 op=5 SRCH base="ou=people,dc=testunical,dc=it" scope=2 deref=3 filter="(objectClass=*)" [25-07-2019 10:33:57] slapd debug conn=1034 op=5 SRCH attr=eduPersonPrincipalName schacHomeOrganization mail uid givenName sn eduPersonScopedAffiliation schacPersonalUniqueId schacPersonalUniqueCode userPassword [25-07-2019 10:33:57] slapd debug conn=1034 op=5 SEARCH RESULT tag=101 err=0 nentries=4 text= [25-07-2019 10:33:57] slapd debug sock: fgets failed: Success (0) [25-07-2019 10:33:57] slapd debug conn=1036 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= OK [25-07-2019 10:33:57] slapd debug conn=1036 op=2 UNBIND [25-07-2019 10:33:57] slapd debug conn=1036 fd=20 closed ```` I also tried to use admin credentials, as shown in the slapd log. I also tried to do a fresh slapd installation by hands, on Debian9 slapd-sock works (searchexample.pl <https://github.com/openldap/openldap/blob/master/servers/slapd/back-sock/se…> and pyMultiLdap) but not Debian10. I read that there are two additional features regarding slapd-sock in openldap 2.4.47. These are: - Added slapd-sock DN qualifier for subtrees to be processed (ITS#8051) - Added slapd-sock ability to send extended operations to external listeners (ITS#8714) My doubts: Is there any need to change configuration, following ITS#8714 and ITS#8051, to get it to work in Debian10 ? or Am I facing a bug present in openldap 2.4.47 ? Thank you in advance for everything you would tell me, Cheers [1] https://github.com/openldap/openldap/blob/master/servers/slapd/back-sock/se… -- ____________________ Dott. Giuseppe De Marco CENTRO ICT DI ATENEO University of Calabria 87036 Rende (CS) - Italy Phone: +39 0984 496961 e-mail: giuseppe.demarco(a)unical.it

3 5

Mapping gid numbers
by JC 24 Jul '19

24 Jul '19

My question is not strictly an LDAP one, but perhaps somebody here with experience in the LDAP and Linux worlds can throw some light on it. I understand how to map attributes, as defined in an LDAP server, to other attributes in a Linux when the NSS framework is used in the latter. Is it possible to map values of attributes? Let's say I have an OpenLDAP server that defines a certain group with a gid number 10000. Would it be possible to map that 10000 to (say) 5000 in the Linux system? That is, every time an operation is executed in the Linux system that uses the group information, the gid would be retrieved from the OpenLDAP server as 10000, and automatically be converted to 5000. Can this be done?

4 4

Re: where is debuglevel documented ?
by danielle lampert 23 Jul '19

23 Jul '19

Hello, yes I was asking for the log levels of the command-line tools like ldapsearch. Thanks for your answers. This doc helps ( https://www.openldap.org/doc/admin24/runningslapd.html ) but is not completely right, as levels 4 and 8 don't do anything special. I will rely on the this doc for my tests, thanks again. D.L. Le lun. 22 juil. 2019 à 16:14, Quanah Gibson-Mount <quanah(a)symas.com> a écrit : > --On Monday, July 22, 2019 10:56 AM -0400 Brian Reichert > <reichert(a)numachi.com> wrote: > > > I think that the OpenLDAP server and client share debug flags. I may be > > wrong on this. > > > > https://www.openldap.org/doc/admin24/runningslapd.html > > This is correct. It's trivial to grep the source and confirm this as well. > > --Quanah > > > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > > >

2 1

Re: Intensive disk write after long-running LDAP activity terminated
by Tamás Rébeli-Szabó 23 Jul '19

23 Jul '19

Quanah, thank you for your warning. We are aware that it is a very old release and a version upgrade is already being planned. But for the moment, that is the currently installed version and that is what produced the strange phenomenon. Regards, tamas Quanah Gibson-Mount <quanah(a)symas.com> ezt írta (időpont: 2019. júl. 22., H, 15:25): > --On Monday, July 22, 2019 2:20 PM +0200 Tamás Rébeli-Szabó > <tamas.rebeli.szabo(a)webvalto.hu> wrote: > > > > > > > > > Hello, > > > > we had a long-running (several days) process doing add and modify > > operations in OpenLDAP 2.4.41 + LMDB backend + SLES 11.3. > > I would note you're talking about OpenLDAP and LMDB releases that are over > 4 years old, past which point numerous issues have been fixed for both. > > LMDB 0.9.15 Release (2015/06/19) > OpenLDAP 2.4.41 Release (2015/06/21) > > --Quanah > > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

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