March 2019 - openldap-technical

by dee heffem

Is there a way to obtain the username (CN or UID attribute?) being authenticated when a LUTIL_PASSWD_CHK_FUNC function is called? I'd like to call a 2FA provider from within a password plugin but not sure how to get the user tied to the sc, passwd, or cred bervals. Thanks

4 years, 1 month

4
7
0 / 0

Replication delay

by Ángel L. Mateo

Hello, I've been running a multi master configuration without any problem for years. This running servers are running in 5 ubuntu 14.04 servers with openldap 2.4.43. The configuration is: dn: olcDatabase={3}mdb,cn=config ... olcSyncrepl: {0}rid=31 provider=ldap://canis31.um.es binddn=<repl user dn> bindmethod=simple credentials=XXXXXXX searc hbase=dc=Telematica type=refreshAndPersist retry="300 +" timeout=1 olcSyncrepl: {1}rid=32 provider=ldap://canis32.um.es binddn=<repl user dn> bindmethod=simple credentials=XXXXXXX searc hbase=dc=Telematica type=refreshAndPersist retry="300 +" timeout=1 olcSyncrepl: {2}rid=33 provider=ldap://canis33.um.es binddn=<repl user dn> bindmethod=simple credentials=XXXXXXX searc hbase=dc=Telematica type=refreshAndPersist retry="300 +" timeout=1 olcSyncrepl: {3}rid=34 provider=ldap://canis34.um.es binddn=<repl user dn> bindmethod=simple credentials=XXXXXXX searc hbase=dc=Telematica type=refreshAndPersist retry="300 +" timeout=1 dn: olcOverlay={0}dynlist,olcDatabase={3}mdb,cn=config objectClass: olcDynamicList objectClass: olcOverlayConfig objectClass: olcConfig olcOverlay: {0}dynlist olcDlAttrSet: {0}labeledURIObject labeledURI dn: olcOverlay={1}ppolicy,olcDatabase={3}mdb,cn=config objectClass: olcPPolicyConfig objectClass: olcOverlayConfig objectClass: olcConfig olcOverlay: {1}ppolicy olcPPolicyDefault: cn=default,ou=policies,dc=Telematica dn: olcOverlay={2}syncprov,olcDatabase={3}mdb,cn=config objectClass: olcSyncProvConfig objectClass: olcOverlayConfig objectClass: olcConfig olcOverlay: {2}syncprov olcSpCheckpoint: 100 10 olcSpSessionlog: 100 where each server has 4 olcSyncrepl attributes pointing to the other servers. I had no problem with this configuration for years Now I'm deploying an update of these servers in a new ubuntu 18.04 server with openldap 2.4.47. In order to synchronize entries between them, I have linked this new server to one of the other (and this one to the new one). Configuration in the new one (named canis41) is: dn: olcDatabase={3}mdb,cn=config ... olcSyncrepl: {0}rid=39 provider=ldap://canis39.um.es binddn=<repl user dn> bindmethod=simple credentials=XXXXXXXX searc hbase=dc=Telematica type=refreshAndPersist retry="60 +" timeout=1 schemache cking=off scope=sub olcSyncrepl: {1}rid=42 provider=ldap://canis42.um.es binddn=<repl user dn> bindmethod=simple credentials=XXXXXXXX searc hbase=dc=Telematica type=refreshAndPersist retry="30 +" timeout=1 logbase=" cn=log" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemaCh ecking=on syncdata=accesslog exattrs="pwdFailureTime" dn: olcOverlay={0}syncprov,olcDatabase={3}mdb,cn=config objectClass: olcSyncProvConfig objectClass: olcOverlayConfig objectClass: olcConfig olcOverlay: {0}syncprov olcSpCheckpoint: 100 10 olcSpSessionlog: 100 dn: olcOverlay={1}ppolicy,olcDatabase={3}mdb,cn=config objectClass: olcPPolicyConfig objectClass: olcOverlayConfig objectClass: olcConfig olcOverlay: {1}ppolicy olcPPolicyDefault: cn=default,ou=policies,dc=Telematica dn: olcOverlay={2}dynlist,olcDatabase={3}mdb,cn=config objectClass: olcDynamicList objectClass: olcOverlayConfig objectClass: olcConfig olcOverlay: {2}dynlist olcDlAttrSet: {0}labeledURIObject labeledURI where canis39 is one the former servers and canis42 is a new server too synchronizing just with canis41. My problem is that synchronization is working, but sometimes modifications done in the canis3x farm are delayed a lot of time until they are replicated to the new one (sometimes in the order of 40-60 minutes). I'm logging sync logs, but I haven't found much information about these logs. Is there any way to debug it? How? -- Angel L. Mateo Martínez Sección de Telemática Área de Tecnologías de la Información y las Comunicaciones Aplicadas (ATICA) http://www.um.es/atica Tfo: 868889150 Fax: 868888337

4 years, 1 month

7
34
0 / 0

"Authentication failure" on Ubuntu 18.04...

by Robert Heller

I have a server running CentOS 6 on the bare metal, running the stock CentOS 6 OpenLDAP packages (openldap-2.4.40-16.el6.x86_64, openldap-clients-2.4.40-16.el6.x86_64, openldap-2.4.40-16.el6.i686, openldap-servers-2.4.40-16.el6.x86_64) [yes I know these are old, but they *work* -- "If it ain't broke, don't fix it."]. There are two VMs running on this server, one running Ubuntu 14.04 and the other Ubuntu 18.04. (These two VMs are/will be servers for DRBL.) The Ubuntu 14.04 VM (and all of its diskless clients) are perfectly happy to talk to the OpenLDAP server (slapd) running on the CentOS 6 machine. The Ubuntu 18.04 VM is not. ldapsearch works everywhere though, so it is NOT the server or the core ldap libraries on any of the machines (partitularly the Ubuntu 18.04 VM). I can only assume that there is something fishy with nslcd or the pam/ldap libraries or config on the Ubuntu 18.04 VM. I have checked everything, but I am coming up empty. I am thinking there might be some "trick" to getting LDAP Authentication to work under Ubuntu 18.04 that I am missing. -- Robert Heller -- 978-544-6933 Deepwoods Software -- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services heller(a)deepsoft.com -- Webhosting Services

4 years, 1 month

2
2
0 / 0

mdb_equality_candidates: (entryUUID) not indexed, with olcDbIndex=entryUUID pres, eq

by Marc Roos

First time I am installing the slapd with a mdb backend. Could this be because the syntax has changed? I am getting these messages: mdb_equality_candidates: (entryUUID) not indexed While I have in {2}mdb olcDbIndex entryUUID pres,eq CentOS Linux release 7.6.1810 (Core) openldap-clients-2.4.44-21.el7_6.x86_64 openldap-2.4.44-21.el7_6.x86_64 openldap-servers-2.4.44-21.el7_6.x86_64

4 years, 1 month

2
1
0 / 0

back_mdb: does rtxnsize affect slapcat live backups?

by Maxime Besson

Hi! I am running OpenLDAP 2.4.47 with significant write activity (in the hundreds of modify/add/del ops per second), and a large volume of data compared to available RAM (about 20G) For backups, I am trying to do a live slapcat dump to maintain availability, and encountered the growth in MDB database size described in those ITS: http://www.openldap.org/its/index.cgi/Software%20Bugs?id=7904 http://www.openldap.org/its/index.cgi/Software%20Bugs?id=8226 I am however a little puzzled over the rtxnsize option. My understanding is that this option splits large read transactions (such as backups) into smaller transactions, allowing freed pages to be reused before the end of the full operation. This is critical for me because backups take more than 10 minutes and a significant portion of my MDB file (100G) gets filled up during that time. However, setting rtxnsize to a smaller value from the default does not seem to have any effect on the growth of my MDB file. I have made several tries with different rtxnsizes from 1M to 100, starting from a freshly rebuilt MDB database every time. I saw that the rtxnsize option was added to handle an issue with replication, so perhaps it was never supposed to help in my particular case. For the whole duration of a slapcat backup, I see the same transaction ID from the slapcat process in mdb_stat -r. I noticed that using ldapsearch for backups behaves much better (MDB only grows by a few thousand pages in my workload), but takes a while longer, regardless of the rtxnsize setting Is it normal that rtxnsize does not affect slapcat dumps while slapd is running, or am I missing something? How would you handle live backups of a database with lots of write activity? -- Maxime Besson Systems Engineer - Worteks maxime.besson(a)worteks.com

4 years, 1 month

5
6
0 / 0

LMDB mdb_txn_begin parent in other thread

by Abilio Marques

Hello, I read the documentation for the mdb_txn_begin function, and the note reads "a transaction and its cursors must only be used by a single thread". Does this rule also apply to being a parent for another thread transaction? I gave it a quick shot, and it seems to work for me, but I'm not sure if I'm breaking the rules. Can anybody confirm this? Best, Abilio

4 years, 2 months

2
1
0 / 0

Tree versus group

by Olivier -

4 years, 2 months

3
3
0 / 0

Add module crashes slapd

by Gao

Hi all, I am relatively new to openldap and I am having an issue when I try to setup Master-Slave replication. I don't know how to solve this issue and need your help please. On the master I made a ldif file: [root@test-ldap ldif]# cat syncprov_mod.ldif dn: cn=module,cn=config objectClass: olcModuleList cn: module olcModulePath: /usr/lib64/openldap olcModuleLoad: syncprov.la Then I run command: [root@test-ldap ldif]# ldapadd -Y EXTERNAL -H ldapi:/// -f syncprov_mod.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "cn=module,cn=config" The output seems normal. But actually the slapd got messed up. So if I do slapcat I got: [root@test-ldap ldif]# slapcat -n 0 5c9d1323 config error processing cn={0}module,cn=config: slapcat: bad configuration file! And restart slapd failed. journalctl shows: Mar 28 11:40:39 test-ldap systemd[1]: Starting OpenLDAP Server Daemon... -- Subject: Unit slapd.service has begun start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit slapd.service has begun starting up. Mar 28 11:40:39 test-ldap runuser[3427]: pam_unix(runuser:session): session opened for user ldap by (uid=0) Mar 28 11:40:39 test-ldap runuser[3427]: pam_unix(runuser:session): session closed for user ldap Mar 28 11:40:39 test-ldap check-config.sh[3424]: Checking configuration file failed: Mar 28 11:40:39 test-ldap check-config.sh[3424]: 5c9d1527 config error processing cn={0}module,cn=config: Mar 28 11:40:39 test-ldap check-config.sh[3424]: slaptest: bad configuration file! Mar 28 11:40:39 test-ldap slapd[3438]: @(#) $OpenLDAP: slapd 2.4.40 (Nov 6 2016 01:21:28) $ mockbuild@worker1.bsys.centos.org:/builddir/build/BUILD/openldap-2.4.40/openldap-2.4.40 Mar 28 11:40:39 test-ldap slapd[3438]: config error processing cn={0}module,cn=config: Mar 28 11:40:39 test-ldap slapd[3438]: slapd stopped. Mar 28 11:40:39 test-ldap slapd[3438]: connections_destroy: nothing to destroy. Mar 28 11:40:39 test-ldap systemd[1]: slapd.service: control process exited, code=exited status=1 Mar 28 11:40:39 test-ldap systemd[1]: Failed to start OpenLDAP Server Daemon. -- Subject: Unit slapd.service has failed -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit slapd.service has failed. -- -- The result is failed. Mar 28 11:40:39 test-ldap systemd[1]: Unit slapd.service entered failed state. Mar 28 11:40:39 test-ldap systemd[1]: slapd.service failed. Thank you for your help. Gao

4 years, 2 months

3
2
0 / 0

LMDB crash after power failure

by Abilio Marques

Hello, I've successfully ported a particular piece of software from multiple plain files in disk to LMDB. There were multiple reasons to do so (i.e., performance and maintenance). The program is making individual calls to a storage API, that in turn creates files or reads them (through a cache). There is no concept of transaction. For performance and lifetime reasons, the original code avoids to perform a fsync every time it writes to a file by queuing renames (for atomic writes) and deletes, which in turn are executed by a background thread after 2 seconds idling (or a max of 15 sec after first write/delete). Replacing such a monster "files + cache" with LMDB was a breeze. I kept the API intact, and to deal with the price of fsyncs, I thought of opening with MDB_NOSYNC, and sync after 2 seconds of inactivity. I must mention that the software runs on an OpenWRT based board, with a MIPS (big endian 32-bit), using UBIFS as storage (with OverlayFS sitting on top of it). Flash memory is rather slow, peaking at ~350 KiB/sec on sequential writing. Kernel version is 3.18.29. This works perfect, except for power failures. With a USB relay board, I'm cutting the power to the CPU during the sync period. After restart, the test program I'm running with LMDB crashes with a sigbus error. Opening the environment seems to work, but the program crashes as soon as it tries to write to it. The file seems "ok" (no visible garbage or missing parts) when viewed with hexdump (but is a 5 Mb file). Any suggestions on where to start looking for issues? I wanted to congratulate Howard Chu for his work with LMDB, and the OpenLDAP team for a wonderful work during the years. Keep it up! Best, Abilio

4 years, 2 months

2
1
0 / 0

olcDbConnectionPoolMax documentation

by Jongeling, Eric C

I'm running into what appears to be an issue with my olcDatabase meta configuration that appears to be a bottleneck limiting me to 16 concurrent operations when working through the meta database. This seems suspiciously similar to the olcDbConnectionPoolMax setting I've seen in many examples and the value I usually encounter of 16. The schema definition doesn't clear it up entirely, either: olcAttributeTypes: ( OLcfgDbAt:3.23 NAME 'olcDbConnectionPoolMax' DESC 'Max size of privileged connections pool' SYNTAX OMsInteger SINGLE- VALUE ) While I assume that this sets the maximum size of the backend connection pool, I'm confused by the word "privileged" in this situation. Can someone explain what this setting controls or point me towards documentation? Thanks in advance! ~Eric C. J.

4 years, 2 months

2
1
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical March 2019