Hi there
Sorry for the long post however I aim to provide as much information as possible to help pinpoint the issue. Also sorry for any wrong wording as I am still a bit overwhelmed with OpenLDAP and struggle to understand everything I need.
From my predecessor I inherited an OpenLDAP 2.4.x cluster running on RHEL 7. My job is to migrate this cluster to OpenLDAP 2.6.x on RHEL 8. The cluster consists of two provider and four consumer servers. The old cluster was based on self-compiled original OpenLDAP binaries. For the new cluster I am using the LTB version of OpenLDAP, currently with version 2.6.8. I also switched from HDB to MDB with the new cluster and am using Let's Encrypt instead of DigiCert certificates and upped the TLS version from 1.0 to 1.2. And for the default password hashing algorhythm I switched from SSHA to ARGON2. So there are lots of changes that might potentially influence the meta databases though I did not see anything that suggests this.
The synchronisation of the normal databases between the provider servers and to the consumer servers is working fine. My problem is with the meta databases I try to build using slapd-meta. They are only needed on the consumer servers. Unfortunately the meta databases do not seem to be created or are not working as expected. On the old cluster I can ldapsearch in the meta databases and they show up as trees when connecting with Apache Directory Studio. On the new cluster I am setting up I don't see those meta trees in Apache Directory Studio and ldapsearches don't return any results. Furthermore slapcat on those databases returns the message "slapcat: database doesn't support necessary operations."
The meta trees don't query external servers but suffixmassage locally present sub-trees. From what I've read this could also be accomplished with slapd-relay but the man page states that it is experimental. That is why I am trying the same way my predecessor did using slapd-meta.
I temporarily set the loglevel to 4094 but even then did not see any hint on what goes wrong with those meta databases. By the way, when I do set the loglevel so high I can no longer connect using Apache Directory Studio, but that is not the issue I'm concerned about.
Neither the documentation, nor the slapd-meta man page, nor the very few tutorials/stackexchange-posts/mailinglist-posts I found online about meta-back helped me in solving this issue. That is why I hope someone on this mailinglist can spot an issue in my configuration. Or point me to other resources/tutorials or share some debugging advice. For the purpose of sharing the configuration I omitted all the schemata and some of the ACLs. Also I removed the linebreaks so what belongs together is all on one line. Lastly I redacted any sensitive information. It is attached as a text/ldif file.
Thanks a lot in advance and let me know if I need to share further information such as log entries etc.
Best regards, Cyril
--On Friday, November 29, 2024 12:37 PM +0100 cyril@stoll.info wrote:
Hi there
Sorry for the long post however I aim to provide as much information as possible to help pinpoint the issue. Also sorry for any wrong wording as I am still a bit overwhelmed with OpenLDAP and struggle to understand everything I need.
From my predecessor I inherited an OpenLDAP 2.4.x cluster running on RHEL 7. My job is to migrate this cluster to OpenLDAP 2.6.x on RHEL 8. The cluster consists of two provider and four consumer servers. The old cluster was based on self-compiled original OpenLDAP binaries. For the new cluster I am using the LTB version of OpenLDAP, currently with version 2.6.8. I also switched from HDB to MDB with the new cluster and am using Let's Encrypt instead of DigiCert certificates and upped the TLS version from 1.0 to 1.2. And for the default password hashing algorhythm I switched from SSHA to ARGON2. So there are lots of changes that might potentially influence the meta databases though I did not see anything that suggests this.
I would remove the shell loglevel from your config since you don't use any shell backends.
Sometimes I'll use slapd in debug mode (-d -1) to get a full dump of everything to dig through.
I noted that you have a duplicate entry for one of the meta backends:
dn: olcMetaSub={0}uri,olcDatabase={2}meta,cn=config
dn: olcMetaSub={1}uri,olcDatabase={2}meta,cn=config
These appear to have identical configurations, which may be a problem? The other URIs on a same meta db have different rewrite options, but on the above, they are the same.
--Quanah
Thanks a lot for the reply Quanah.
Definitely makes sense to not use loglevels that don’t even apply. I was just kinda desperate and tried lots of things.
However I made progress lately and actually got it to work (was an ACL issue after all). So there is currently no need for further assistance. Though I will check if I still have that duplicate entry in the config. Thanks for pointing that out.
Unfortunately I didn’t get to write to the list as I wanted to write up something more comprehensive because the documentation on the meta backend is kinda sparse aside from the man page. Hopefully I will get to that in the next days to have something more recent than posts from 10 years ago for people who search for the same issue as I did.
Best regards and thanks again, Cyril
On 18 Dec 2024, at 22:59, Quanah Gibson-Mount quanah@fast-mail.org wrote:
--On Friday, November 29, 2024 12:37 PM +0100 cyril@stoll.info mailto:cyril@stoll.info wrote:
Hi there
Sorry for the long post however I aim to provide as much information as possible to help pinpoint the issue. Also sorry for any wrong wording as I am still a bit overwhelmed with OpenLDAP and struggle to understand everything I need.
From my predecessor I inherited an OpenLDAP 2.4.x cluster running on RHEL 7. My job is to migrate this cluster to OpenLDAP 2.6.x on RHEL 8. The cluster consists of two provider and four consumer servers. The old cluster was based on self-compiled original OpenLDAP binaries. For the new cluster I am using the LTB version of OpenLDAP, currently with version 2.6.8. I also switched from HDB to MDB with the new cluster and am using Let's Encrypt instead of DigiCert certificates and upped the TLS version from 1.0 to 1.2. And for the default password hashing algorhythm I switched from SSHA to ARGON2. So there are lots of changes that might potentially influence the meta databases though I did not see anything that suggests this.
I would remove the shell loglevel from your config since you don't use any shell backends.
Sometimes I'll use slapd in debug mode (-d -1) to get a full dump of everything to dig through.
I noted that you have a duplicate entry for one of the meta backends:
dn: olcMetaSub={0}uri,olcDatabase={2}meta,cn=config
dn: olcMetaSub={1}uri,olcDatabase={2}meta,cn=config
These appear to have identical configurations, which may be a problem? The other URIs on a same meta db have different rewrite options, but on the above, they are the same.
--Quanah
openldap-technical@openldap.org