openldap-technical July 2023

openldap-technical@openldap.org

29 participants
33 discussions

-Y external and SUSE
by Stefan Kania 06 Jul '23

06 Jul '23

Hi to all, I just installed openSUSE 15.5 and the actual symas packages. After installing OpenLDAP I could start slapd but "ldapsearch -Y external -H ldapi:///" is giving me a "can't connect to ldapserver" I found out that the ldap-socket on SUSE is (the same a on Debian systems) in /var/symas/run/ldapi and I can see: ss -lp | grep slapd u_str LISTEN 0 2048 /var/symas/run/ldapi 15214 * 0 users:(("slapd",pid=1431,fd=9)) but doing a ldapsearch: provider01:~ # ldapmodify -Y EXTERNAL -H ldapi:/// -d 5 ldap_url_parse_ext(ldapi:///) ldap_create ldap_url_parse_ext(ldapi:///??base) ldap_sasl_interactive_bind: user selected: EXTERNAL ldap_int_sasl_bind: EXTERNAL ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_path ldap_new_socket: 3 ldap_connect_to_path: Trying /run/slapd/ldapi ldap_connect_timeout: fd: 3 tm: -1 async: 0 ldap_ndelay_on: 3 ldap_close_socket: 3 ldap_msgfree ldap_err2string ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) You can see, that ldapsearch is looking in /run/slapd/ for the socket. How can I change this? I tested with setting a link: ln -s /var/symas/run/ldapi /run/slapd/ and ldapseach wit "external" is working. But this was only a test. After rebooting the system the link is gone. So how can I either change the behavior of the ldap-commands or changing the path where the socket will be stored? Thank's for any help

5 5

trying to understand SID portion in contextCSN
by cYuSeDfZfb cYuSeDfZfb 05 Jul '23

05 Jul '23

Hi! Trying to better understand the contextCSN attribute. ContextCSN is formatted like: TIMESTAMP#COUNT#SID#MOD My question is on the SID part: ServerID. I have the following serverID configuration in our 4-server Multi-Master PoC setup: serverID 222 ldaps://ldapm01.company.com serverID 221 ldaps://ldapm02.company.com serverID 212 ldaps://ldapm03.company.com serverID 211 ldaps://ldapm04.company.com And when I (quick and dirty) check contextCSN using slapcat (I know that ldapsearch is the better way) I get: [root@ldapm04 ~]# slapcat | grep contextcsn -i contextCSN: 20180917142109.765066Z#000000#000#000000 contextCSN: 20230622151102.137085Z#000000#001#000000 contextCSN: 20230622151105.174343Z#000000#002#000000 contextCSN: 20230627112536.529432Z#000000#0dd#000000 contextCSN: 20230627112536.529512Z#000000#0de#000000 The first 2018 contextCSN is irrelevant (it has alwas been there, and I should probably try to get rid of it) but the last four seem to be the "actual" configured replication 'lines' on each node to the other three, like this: syncrepl rid=2?4 provider=ldaps://ldapm0?.company.com:636 bindmethod=simple binddn="cn=replication,ou=Directory Access,o=company,c=com" credentials=very_secret searchbase="o=company,c=com" filter="(objectClass=*)" scope=sub schemachecking=on type=refreshAndPersist retry="60 +" attrs="*,+" tls_reqcert=demand syncrepl rid=2?4 provider=ldaps://ldapm0?.company.com:636 bindmethod=simple binddn="cn=replication,ou=Directory Access,o=company,c=com" credentials=very_secret searchbase="o=company,c=com" filter="(objectClass=*)" scope=sub schemachecking=on type=refreshAndPersist retry="60 +" attrs="*,+" tls_reqcert=demand syncrepl rid=2?4 provider=ldaps://ldapm0?.company.com:636 bindmethod=simple binddn="cn=replication,ou=Directory Access,o=company,c=com" credentials=very_secret searchbase="o=company,c=com" filter="(objectClass=*)" scope=sub schemachecking=on type=refreshAndPersist retry="60 +" attrs="*,+" tls_reqcert=demand Now the actual question: contextCSN displays these SID's: 001, 002, 0dd, 0de. None of which I have configured *anywhere*. Not as a SID, not as a RID, as can be seen above. Yet: all info I can find tells me that the third field of contextCSN is "the SID". Can anyone explain? Are they perhaps HEX? If why the large gap between to consequtive pairs..? Curious :-) Thanks!

2 1

RE: [EXT] Re: What drives CPU usage spikes?
by Quanah Gibson-Mount 03 Jul '23

03 Jul '23

--On Monday, July 3, 2023 2:25 PM +0000 "Windl, Ulrich" <u.windl(a)ukr.de> wrote: > Hi! > > I'm wondering: Did you examine whether some indices might help? Those don't help with the issue being addressed in regards to accesslog databases. --Quanah

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical July 2023