openldap-technical

openldap-technical@openldap.org

9897 discussions

Re: Is there any easy way to decode openldap logs
by chandan jain 09 Mar '21

09 Mar '21

OK, but how to spread out read traffic. I mean how I can bifurcate read and write go to different nodes. I mean how application decide which node to write and which node to read from. Regards Chandan On Wed, Mar 10, 2021, 00:02 Quanah Gibson-Mount <quanah(a)symas.com> wrote: > > > --On Tuesday, March 9, 2021 3:28 PM +0530 chandan jain > <chandandevops(a)gmail.com> wrote: > > > > > > > Thanks, > > > > > > Mirror mode configuration cannot be horizontal scaled what I understood > > as writes are going to one of the node, and other act as an active > > standby. > > > > > > I want 2 or more nodes behind a load balancer which can share read/write > > load. A kind of active active setup. > > The point of mirror mode is that only one server in the pool gets writes. > You can horizontally scale that as much as you want, whether there are 2 > servers in the pool or 5000. I.e., as long as write traffic only goes to > one of those servers, you have mirror mode. > > Generally I would advise against distributing write traffic (i.e., do > exactly what mirror mode does, direct all write traffic to a single active > node unless it goes down and fail over is necessary). Spread out read > traffic as desired. > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

1 0

Re: Is there any easy way to decode openldap logs
by chandan jain 09 Mar '21

09 Mar '21

Thanks, Quanah Is it possible to direct upgrade from 2.4.32 to latest version. Also, can we horizontal scale a 2 node mirror mode setup? I am confused after seeing suggestions on different sites. Regards Chandan Jain On Fri, Mar 5, 2021, 00:28 Quanah Gibson-Mount <quanah(a)symas.com> wrote: > > > --On Thursday, March 4, 2021 11:49 PM +0530 chandan jain > <chandandevops(a)gmail.com> wrote: > > > > > It is openldap-2.4.32, i don't see any mdb support option while > > compiling . > > It is compiled with below options: > > > > > > tar -xzf db-5.3.21.tar.gz > > tar -zxf openldap-2.4.32.tgz > > cd db-5.3.21 > > cd build_unix/ > > ../dist/configure --enable-compat185 --enable-dbm --disable-static > > --enable-cxx && make && make install > > db_verify -V > > cd ../.. > > cd openldap-2.4.32 > > ./configure --prefix=/usr/local/OpenLDAP --with-tls=no > > --enable-modules=yes --enable-overlays=yes --enable-ppolicy=yes && make > > depend && make && make install > > 2.4.32 is over 8 years old. As I said, use a current release (2.4.57). > > --Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

3 3

opinions on schema-checking
by A. Schulze 08 Mar '21

08 Mar '21

Hello, I'm running a LDAP provider and multiple LDAP consumer and like to ask for your opinions to such a setup: While writing data to the LDAP provider, schema-checking is enforced. Currently also the LDAP consumer enforce schema checking. Q: does it make sense to enforce schema checking on a LDAP consumer, too? What pros and cons do you see? Thanks! Andreas

5 10

ldap_modify: Other (e.g., implementation specific) error (80)
by Stefan Bauer 06 Mar '21

06 Mar '21

Hi, the internet is full of "tips" to solve the above problem. I'm pulling my hairs and can not find the real issue since days. any help is greatly appreciated. --------- enable_ssl.ldiff --------------- dn: cn=config changetype: modify add: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/ldap/key.key dn: cn=config changetype: modify add: olcTLSCertificateFile olcTLSCertificateFile: /etc/ldap/cert.pem --------- enable_ssl.ldiff --------------- # ls -alh /etc/ldap/cert.pem /etc/ldap/key.key -rwxrwxrwx 1 root root 1,1K Mär 1 21:43 /etc/ldap/cert.pem -rwxrwxrwx 1 root root 1,7K Mär 1 21:21 /etc/ldap/key.key # openssl rsa -noout -modulus -in /etc/ldap/key.key | openssl md5 (stdin)= 45b4165df200817a20857fb453acd33e # openssl x509 -noout -modulus -in /etc/ldap/cert.pem | openssl md5 (stdin)= 45b4165df200817a20857fb453acd33e # head -n2 /etc/ldap/cert.pem -----BEGIN CERTIFICATE----- MIIFmDCCBICgAwIBAgIQBFMR6HMGTGjQIjSj4sQX+TANBgkqhkiG9w0BAQsFADBu # head -n2 /etc/ldap/key.key -----BEGIN RSA PRIVATE KEY----- MIIEowIBAAKCAQEAvrDddMwXoy10diqDpqd45jaC8HiGKz7KC5X3W0ZLvCshylu0 ldapmodify -Y EXTERNAL -H ldapi:/// -f enable_ssl.ldif -v # ldapmodify -Y EXTERNAL -H ldapi:/// -f enable_ssl.ldif -v ldap_initialize( ldapi:///??base ) SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 add olcTLSCertificateKeyFile: /etc/ldap/key.key modifying entry "cn=config" ldap_modify: Other (e.g., implementation specific) error (80) I can however modify other values like *olcLogLevel* without problems. Debian 10 latest: 2.4.47+dfsg-3+deb10u6 # slapd -VVV @(#) $OpenLDAP: slapd (Feb 14 2021 18:32:34) $ Debian OpenLDAP Maintainers <pkg-openldap-devel(a)lists.alioth.debian.org> Included static backends: config ldif Stefan.

2 2

ACL for sync reader
by Frédéric Goudal 06 Mar '21

06 Mar '21

Hello, I have a production ldap with some acl set. For historical reason the synchronizationn is done with the root dn which is bad. I want to add a user to perform synchronization it must have the right to read everytthing. is the acl : access to * by dn.exact=<somedn> break added in first position be enough to read everything (even attributs that have been limited on some other acl) AND not break the current configuration ? Thanks in advance. f.g.

3 6

Re: Is there any easy way to decode openldap logs
by chandan jain 04 Mar '21

04 Mar '21

It is openldap-2.4.32, i don't see any mdb support option while compiling . It is compiled with below options: tar -xzf db-5.3.21.tar.gz tar -zxf openldap-2.4.32.tgz cd db-5.3.21 cd build_unix/ ../dist/configure --enable-compat185 --enable-dbm --disable-static --enable-cxx && make && make install db_verify -V cd ../.. cd openldap-2.4.32 ./configure --prefix=/usr/local/OpenLDAP --with-tls=no --enable-modules=yes --enable-overlays=yes --enable-ppolicy=yes && make depend && make && make install Regards Chandan On Thu, 4 Mar 2021 at 22:48, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > > > --On Thursday, March 4, 2021 10:40 PM +0530 chandan jain > <chandandevops(a)gmail.com> wrote: > > > > > > > Thanks quanah, I will change log level to 256 to see the results. > > > > > > Also, is it possible to migrate from bdb to mdb, the ldap is mirror mode > > sync with 2 nodes and it is compiled version not a rpm one. > > Assuming it was built with back-mdb support, yes. I have no idea what > release you're running, but you'll want a current one. > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

2 1

Re: Is there any easy way to decode openldap logs
by chandan jain 04 Mar '21

04 Mar '21

Thanks quanah, I will change log level to 256 to see the results. Also, is it possible to migrate from bdb to mdb, the ldap is mirror mode sync with 2 nodes and it is compiled version not a rpm one. Regards Chandan On Thu, Mar 4, 2021, 21:49 Quanah Gibson-Mount <quanah(a)symas.com> wrote: > > > --On Thursday, March 4, 2021 12:00 PM +0530 chandan jain > <chandandevops(a)gmail.com> wrote: > > > > > Hi Techies, > > > > > > I am new to openLDAP, i am reading its log file. Is their any easy way to > > decode the logs to identify what is going on? > > I would suggest simply setting a loglevel of "stats". You're currently > going to suffer from information overload. > > I'd also note that the BDB backend is deprecated and is generally not > recommended for use. > > --Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

2 1

Is there any easy way to decode openldap logs
by chandan jain 04 Mar '21

04 Mar '21

Hi Techies, I am new to openLDAP, i am reading its log file. Is their any easy way to decode the logs to identify what is going on? Please see below logs: Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: activity on 1 descriptor Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: activity on: Mar 3 03:22:01 myserver OpenLDAP[53304]: Mar 3 03:22:01 myserver OpenLDAP[53304]: slap_listener_activate(7): Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: epoll: listen=7 busy Mar 3 03:22:01 myserver OpenLDAP[53304]: >>> slap_listener(ldap:// 0.0.0.0:389) Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: listen=7, new connection on 19 Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: activity on 1 descriptor Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: activity on: Mar 3 03:22:01 myserver OpenLDAP[53304]: Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: added 19r (active) listener=(nil) Mar 3 03:22:01 myserver OpenLDAP[53304]: conn=103380 fd=19 ACCEPT from IP= 10.101.21.156:60358 (IP=0.0.0.0:389) Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: epoll: listen=7 active_threads=0 tvp=zero Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: activity on 2 descriptors Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: activity on: Mar 3 03:22:01 myserver OpenLDAP[53304]: 19r Mar 3 03:22:01 myserver OpenLDAP[53304]: Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: read active on 19 Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: epoll: listen=7 active_threads=0 tvp=zero Mar 3 03:22:01 myserver OpenLDAP[53304]: connection_get(19) Mar 3 03:22:01 myserver OpenLDAP[53304]: connection_get(19): got connid=103380 Mar 3 03:22:01 myserver OpenLDAP[53304]: connection_read(19): checking for input on id=103380 Mar 3 03:22:01 myserver OpenLDAP[53304]: op tag 0x60, time 1614759721 Mar 3 03:22:01 myserver OpenLDAP[53304]: conn=103380 op=0 do_bind Mar 3 03:22:01 myserver OpenLDAP[53304]: >>> dnPrettyNormal: <cn=Manager,dc=icma-web,dc=com> Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: activity on 1 descriptor Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: activity on: Mar 3 03:22:01 myserver OpenLDAP[53304]: <<< dnPrettyNormal: <cn=Manager,dc=icma-web,dc=com>, <cn=manager,dc=icma-web,dc=com> Mar 3 03:22:01 myserver OpenLDAP[53304]: conn=103380 op=0 BIND dn="cn=Manager,dc=icma-web,dc=com" method=128 Mar 3 03:22:01 myserver OpenLDAP[53304]: do_bind: version=3 dn="cn=Manager,dc=icma-web,dc=com" method=128 Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: epoll: listen=7 active_threads=0 tvp=zero Mar 3 03:22:01 myserver OpenLDAP[53304]: ==> bdb_bind: dn: cn=Manager,dc=icma-web,dc=com Mar 3 03:22:01 myserver OpenLDAP[53304]: conn=103380 op=0 BIND dn="cn=Manager,dc=icma-web,dc=com" mech=SIMPLE ssf=0 Mar 3 03:22:01 myserver OpenLDAP[53304]: do_bind: v3 bind: "cn=Manager,dc=icma-web,dc=com" to "cn=Manager,dc=icma-web,dc=com" Mar 3 03:22:01 myserver OpenLDAP[53304]: send_ldap_result: conn=103380 op=0 p=3 Mar 3 03:22:01 myserver OpenLDAP[53304]: send_ldap_result: err=0 matched="" text="" Mar 3 03:22:01 myserver OpenLDAP[53304]: send_ldap_response: msgid=1 tag=97 err=0 Mar 3 03:22:01 myserver OpenLDAP[53304]: conn=103380 op=0 RESULT tag=97 err=0 text= Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: activity on 1 descriptor Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: activity on: Mar 3 03:22:01 myserver OpenLDAP[53304]: 19r Mar 3 03:22:01 myserver OpenLDAP[53304]: Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: read active on 19 Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: epoll: listen=7 active_threads=0 tvp=zero Mar 3 03:22:01 myserver OpenLDAP[53304]: connection_get(19) Mar 3 03:22:01 myserver OpenLDAP[53304]: connection_get(19): got connid=103380 Mar 3 03:22:01 myserver OpenLDAP[53304]: connection_read(19): checking for input on id=103380 Mar 3 03:22:01 myserver OpenLDAP[53304]: op tag 0x63, time 1614759721 Mar 3 03:22:01 myserver OpenLDAP[53304]: conn=103380 op=1 do_search Mar 3 03:22:01 myserver OpenLDAP[53304]: >>> dnPrettyNormal: <dc=icma-web,dc=com> Mar 3 03:22:01 myserver OpenLDAP[53304]: <<< dnPrettyNormal: <dc=icma-web,dc=com>, <dc=icma-web,dc=com> Mar 3 03:22:01 myserver OpenLDAP[53304]: SRCH "dc=icma-web,dc=com" 2 0 Mar 3 03:22:01 myserver OpenLDAP[53304]: 0 0 0 Mar 3 03:22:01 myserver OpenLDAP[53304]: begin get_filter Mar 3 03:22:01 myserver OpenLDAP[53304]: EQUALITY Mar 3 03:22:01 myserver OpenLDAP[53304]: end get_filter 0 Mar 3 03:22:01 myserver OpenLDAP[53304]: filter: (uid=icma_emp_1emp113) Mar 3 03:22:01 myserver OpenLDAP[53304]: attrs: Mar 3 03:22:01 myserver OpenLDAP[53304]: Mar 3 03:22:01 myserver OpenLDAP[53304]: conn=103380 op=1 SRCH base="dc=icma-web,dc=com" scope=2 deref=0 filter="(uid=icma_emp_1emp113)" Mar 3 03:22:01 myserver OpenLDAP[53304]: => bdb_search Mar 3 03:22:01 myserver OpenLDAP[53304]: bdb_dn2entry("dc=icma-web,dc=com") Mar 3 03:22:01 myserver OpenLDAP[53304]: => access_allowed: search access to "dc=icma-web,dc=com" "entry" requested Mar 3 03:22:01 myserver OpenLDAP[53304]: <= root access granted Mar 3 03:22:01 myserver OpenLDAP[53304]: => access_allowed: search access granted by manage(=mwrscxd) Mar 3 03:22:01 myserver OpenLDAP[53304]: search_candidates: base="dc=icma-web,dc=com" (0x00000001) scope=2 Mar 3 03:22:01 myserver OpenLDAP[53304]: => bdb_dn2idl("dc=icma-web,dc=com") Mar 3 03:22:01 myserver OpenLDAP[53304]: => bdb_filter_candidates Mar 3 03:22:01 myserver OpenLDAP[53304]: #011AND Mar 3 03:22:01 myserver OpenLDAP[53304]: => bdb_list_candidates 0xa0 Mar 3 03:22:01 myserver OpenLDAP[53304]: => bdb_filter_candidates Mar 3 03:22:01 myserver OpenLDAP[53304]: #011OR Mar 3 03:22:01 myserver OpenLDAP[53304]: => bdb_list_candidates 0xa1 Mar 3 03:22:01 myserver OpenLDAP[53304]: => bdb_filter_candidates Mar 3 03:22:01 myserver OpenLDAP[53304]: #011EQUALITY Mar 3 03:22:01 myserver OpenLDAP[53304]: => bdb_equality_candidates (objectClass) Mar 3 03:22:01 myserver OpenLDAP[53304]: => key_read Mar 3 03:22:01 myserver OpenLDAP[53304]: bdb_idl_fetch_key: [b49d1940] Mar 3 03:22:01 myserver OpenLDAP[53304]: <= bdb_index_read: failed (-30988) Mar 3 03:22:01 myserver OpenLDAP[53304]: <= bdb_equality_candidates: id=0, first=0, last=0 Mar 3 03:22:01 myserver OpenLDAP[53304]: <= bdb_filter_candidates: id=0 first=0 last=0 Mar 3 03:22:01 myserver OpenLDAP[53304]: => bdb_filter_candidates Mar 3 03:22:01 myserver OpenLDAP[53304]: #011EQUALITY Mar 3 03:22:01 myserver OpenLDAP[53304]: => bdb_equality_candidates (uid) Mar 3 03:22:01 myserver OpenLDAP[53304]: => key_read Mar 3 03:22:01 myserver OpenLDAP[53304]: bdb_idl_fetch_key: [9a14f458] Mar 3 03:22:01 myserver OpenLDAP[53304]: <= bdb_index_read: failed (-30988) Mar 3 03:22:01 myserver OpenLDAP[53304]: <= bdb_equality_candidates: id=0, first=0, last=0 Mar 3 03:22:01 myserver OpenLDAP[53304]: <= bdb_filter_candidates: id=0 first=0 last=0 Mar 3 03:22:01 myserver OpenLDAP[53304]: <= bdb_list_candidates: id=0 first=0 last=0 Mar 3 03:22:01 myserver OpenLDAP[53304]: <= bdb_filter_candidates: id=0 first=0 last=0 Mar 3 03:22:01 myserver OpenLDAP[53304]: <= bdb_list_candidates: id=0 first=1 last=0 Mar 3 03:22:01 myserver OpenLDAP[53304]: <= bdb_filter_candidates: id=0 first=1 last=0 Mar 3 03:22:01 myserver OpenLDAP[53304]: bdb_search_candidates: id=0 first=1 last=0 Mar 3 03:22:01 myserver OpenLDAP[53304]: bdb_search: no candidates Mar 3 03:22:01 myserver OpenLDAP[53304]: send_ldap_result: conn=103380 op=1 p=3 Mar 3 03:22:01 myserver OpenLDAP[53304]: send_ldap_result: err=0 matched="" text="" Mar 3 03:22:01 myserver OpenLDAP[53304]: send_ldap_response: msgid=2 tag=101 err=0 Mar 3 03:22:01 myserver OpenLDAP[53304]: conn=103380 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: activity on 1 descriptor Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: activity on:

2 1

openldap client library connection caching?
by Rallavagu Kon 04 Mar '21

04 Mar '21

All, Deployed OpenLDAP 2.4 in production (with replication) mainly serving saslauthd and sendmail on Linux with client library 2.4.49. We are experiencing sporadic errors "ldap_simple_bind() failed -1 (Can't contact LDAP server).”. This issue happens on both saslauthd and on openldap when replicating to other service. However, upon investigation we have found that this error is not disruptive as both services (saslauthd and openldap server) have “retry” options built-in and subsequent request (immediately after a failure) receives successful response. Also, noticed that this issue manifests when communication occurs via ELB (AWS) and no connect issues were manifested when clients are directly pointed to openldap server (all connections are TLS). This makes me infer (suspect) that openldap client library might be caching (or tcp alive etc.) the connection which is not working well with ELB (Elastic Load Balancer). Wondering if the connection is really cached and is there a configuration parameter that I can try and tune the behavior (tried to chase this down looking into the source code of client library but could not locate it, perhaps I need to look more but wondering if someone else in the community has any experience in this regard). Thank You.

3 3

difference in multi-master replication since 2.4.57
by Emmanuel Seyman 04 Mar '21

04 Mar '21

Hello, all. I have two OpenLDAP servers in production that were running 2.4.44 . Both of these servers host 5 directories, each with their own backends. This is a bog-standard 2-node RHEL7 multi-master configuration that has worked for years. The binaries are the LTB-Project rpms. I updated my OpenLDAP servers to 2.4.57 last week. A few minutes after the upgrade, I started to see syncrepl alerts in Nagios and I'm having a hard time convincing myself that the upgrade isn't responsible for the errors. The problem is that I don't see any messages in the log that stand out as being errors (granted, I'm not sure what I'm looking for). In fact, the alert flaps every once in a while as the two nodes come back in sync and drift away from each other again. Here's what the output of the syncrepl nagios plugin looks like: 2021-03-03 09:54:01: CRITICAL - directories are not in sync - 199 seconds late (W:10 - C:5) 2021-03-03 09:56:01: CRITICAL - directories are not in sync - 197 seconds late (W:10 - C:5) 2021-03-03 09:58:01: CRITICAL - directories are not in sync - 42 seconds late (W:10 - C:5) 2021-03-03 10:00:01: CRITICAL - directories are not in sync - 4200 seconds late (W:10 - C:5) 2021-03-03 10:02:01: CRITICAL - directories are not in sync - 81 seconds late (W:10 - C:5) 2021-03-03 10:04:01: CRITICAL - directories are not in sync - 201 seconds late (W:10 - C:5) 2021-03-03 10:06:01: CRITICAL - directories are not in sync - 196 seconds late (W:10 - C:5) 2021-03-03 10:08:01: CRITICAL - directories are not in sync - 42 seconds late (W:10 - C:5) 2021-03-03 10:10:01: CRITICAL - directories are not in sync - 200 seconds late (W:10 - C:5) 2021-03-03 10:12:01: CRITICAL - directories are not in sync - 81 seconds late (W:10 - C:5) I find these values surprising considering I've never seen a syncrepl error in the 2 years before the upgrade. Is there a known issue with replication in 2.4.57 that would explain these sync differences? Regards, Emmanuel

4 5

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical