I'm starting a new thread on a different topic, as my current issue is veering way off topic from my original thread (c/f https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/t... and c/f https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/t...).
Thanks to Ulrich's suggestion to run slapcat -n0 with debug (-d -1). That did indeed get me some more information, but I still cannot pinpoint why slapcat keeps telling me that it "could not open database".
To recap: I'm currently running the Symas-provided openldap package v2.6, and my ultimate goal is to build a push-based proxy with syncrepl. But this thread is about the cn=config database.
As part of my troubleshooting, I found this quite old thread about the different ways to start slapd: https://openldap-technical.openldap.narkive.com/Y1yq9Qd1/can-not-modify-cn-c... I stopped slapd with:
systemctl stop slapd
I then manually started it like so, in order to force it to use the ldif directory instead of the slapd.conf file: /opt/symas/lib/slapd -F /var/symas/openldap-data/slapd.d/
This started right up, and I can confirm slapd is running.
I'm able to run a ldapsearch against: -b "cn=config" like so, where we see all of the various databases, frontend, and Overlays configured. I have redacted the password, and changed the domain to "example" in the following stdout. Given this information, I'm still very confused why slapcat can't open the cn=config database for its own processing. Any help on this would be appreciated.
root@ldap-provider:~# ldapsearch -x -LLL -D cn=config -W -s sub -b "cn=config" "(olcDatabase=*)" '*' '+' -v ldap_initialize( <DEFAULT> ) Enter LDAP Password: filter: (olcDatabase=*) requesting: * + dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAddContentAcl: FALSE olcLastMod: TRUE olcLastBind: TRUE olcLastBindPrecision: 0 olcMaxDerefDepth: 0 olcReadOnly: FALSE olcSchemaDN: cn=Subschema olcSyncUseSubentry: FALSE olcMonitoring: FALSE structuralObjectClass: olcDatabaseConfig entryUUID: 047a4d82-01dd-103c-8345-d3830b8ac76f creatorsName: cn=config createTimestamp: 20220104190525Z entryCSN: 20220104190525.214003Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20220104190525Z entryDN: olcDatabase={-1}frontend,cn=config subschemaSubentry: cn=Subschema
dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by * none olcAddContentAcl: TRUE olcLastMod: TRUE olcLastBind: TRUE olcLastBindPrecision: 0 olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=config olcRootPW: secret olcSyncUseSubentry: FALSE olcMonitoring: FALSE structuralObjectClass: olcDatabaseConfig entryUUID: 047a4fda-01dd-103c-8346-d3830b8ac76f creatorsName: cn=config createTimestamp: 20220104190525Z entryCSN: 20220104190525.214003Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20220104190525Z entryDN: olcDatabase={0}config,cn=config subschemaSubentry: cn=Subschema
dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /var/symas/openldap-data olcSuffix: dc=example,dc=com olcAddContentAcl: FALSE olcLastMod: TRUE olcLastBind: TRUE olcLastBindPrecision: 0 olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=admin,dc=example,dc=com olcRootPW: secret olcSyncUseSubentry: FALSE olcMonitoring: TRUE olcDbNoSync: FALSE olcDbIndex: objectClass eq olcDbIndex: entryUUID eq olcDbIndex: entryCSN eq olcDbMaxReaders: 0 olcDbMaxSize: 10485760 olcDbMode: 0600 olcDbSearchStack: 16 olcDbMaxEntrySize: 0 olcDbRtxnSize: 10000 structuralObjectClass: olcMdbConfig entryUUID: 047a52be-01dd-103c-8347-d3830b8ac76f creatorsName: cn=config createTimestamp: 20220104190525Z entryCSN: 20220104190525.214003Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20220104190525Z entryDN: olcDatabase={1}mdb,cn=config subschemaSubentry: cn=Subschema
dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpCheckpoint: 100 10 olcSpSessionlog: 100 structuralObjectClass: olcSyncProvConfig entryUUID: 047a54da-01dd-103c-8348-d3830b8ac76f creatorsName: cn=config createTimestamp: 20220104190525Z entryCSN: 20220104190525.214003Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20220104190525Z entryDN: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config subschemaSubentry: cn=Subschema
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, January 5th, 2022 at 9:40 AM, Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de wrote:
Hi!
I meant: The debug output is useless when you leave out "-n0" (the case that
doesn't work for you).
David White dmwhite823@protonmail.com schrieb am 05.01.2022 um 15:14 in
Nachricht
qn5VCvnElSb0fkpWltSUlY7hWAU=@protonmail.com>:
That's the thing.
-n0 always returns "unknown database".
Only -n1 returns data.
Thanks for the suggestion, though. :)
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, January 5th, 2022 at 8:11 AM, Ulrich Windl
Ulrich.Windl@rz.uni-regensburg.de wrote:
It seems you missed "-n0" for slapcat.
And of course if I had read (and understood) the man page correctly before now, I would have realized I could easily run slapcat with the -F flag like so:
slapcat -F /var/symas/openldap-data/slapd.d/ -n0
... which works like a charm.
Not sure why it's not picking that directory up by default, but problem (mostly) solved.
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, January 5th, 2022 at 10:57 AM, David White dmwhite823@protonmail.com wrote:
I'm starting a new thread on a different topic, as my current issue is veering way off topic from my original thread (c/f https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/t... and c/f https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/t...).
Thanks to Ulrich's suggestion to run slapcat -n0 with debug (-d -1). That did indeed get me some more information, but I still cannot pinpoint why slapcat keeps telling me that it "could not open database".
To recap: I'm currently running the Symas-provided openldap package v2.6, and my ultimate goal is to build a push-based proxy with syncrepl. But this thread is about the cn=config database.
As part of my troubleshooting, I found this quite old thread about the different ways to start slapd: https://openldap-technical.openldap.narkive.com/Y1yq9Qd1/can-not-modify-cn-c...
I stopped slapd with:
systemctl stop slapd
I then manually started it like so, in order to force it to use the ldif directory instead of the slapd.conf file:
/opt/symas/lib/slapd -F /var/symas/openldap-data/slapd.d/
This started right up, and I can confirm slapd is running.
I'm able to run a ldapsearch against: -b "cn=config" like so, where we see all of the various databases, frontend, and Overlays configured. I have redacted the password, and changed the domain to "example" in the following stdout. Given this information, I'm still very confused why slapcat can't open the cn=config database for its own processing. Any help on this would be appreciated.
root@ldap-provider:~# ldapsearch -x -LLL -D cn=config -W -s sub -b "cn=config" "(olcDatabase=)" '' '+' -v
ldap_initialize( <DEFAULT> )
Enter LDAP Password:
filter: (olcDatabase=*)
requesting: * +
dn: olcDatabase={-1}frontend,cn=config
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: {-1}frontend
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcLastBind: TRUE
olcLastBindPrecision: 0
olcMaxDerefDepth: 0
olcReadOnly: FALSE
olcSchemaDN: cn=Subschema
olcSyncUseSubentry: FALSE
olcMonitoring: FALSE
structuralObjectClass: olcDatabaseConfig
entryUUID: 047a4d82-01dd-103c-8345-d3830b8ac76f
creatorsName: cn=config
createTimestamp: 20220104190525Z
entryCSN: 20220104190525.214003Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20220104190525Z
entryDN: olcDatabase={-1}frontend,cn=config
subschemaSubentry: cn=Subschema
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcAccess: {0}to * by * none
olcAddContentAcl: TRUE
olcLastMod: TRUE
olcLastBind: TRUE
olcLastBindPrecision: 0
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=config
olcRootPW: secret
olcSyncUseSubentry: FALSE
olcMonitoring: FALSE
structuralObjectClass: olcDatabaseConfig
entryUUID: 047a4fda-01dd-103c-8346-d3830b8ac76f
creatorsName: cn=config
createTimestamp: 20220104190525Z
entryCSN: 20220104190525.214003Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20220104190525Z
entryDN: olcDatabase={0}config,cn=config
subschemaSubentry: cn=Subschema
dn: olcDatabase={1}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {1}mdb
olcDbDirectory: /var/symas/openldap-data
olcSuffix: dc=example,dc=com
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcLastBind: TRUE
olcLastBindPrecision: 0
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=admin,dc=example,dc=com
olcRootPW: secret
olcSyncUseSubentry: FALSE
olcMonitoring: TRUE
olcDbNoSync: FALSE
olcDbIndex: objectClass eq
olcDbIndex: entryUUID eq
olcDbIndex: entryCSN eq
olcDbMaxReaders: 0
olcDbMaxSize: 10485760
olcDbMode: 0600
olcDbSearchStack: 16
olcDbMaxEntrySize: 0
olcDbRtxnSize: 10000
structuralObjectClass: olcMdbConfig
entryUUID: 047a52be-01dd-103c-8347-d3830b8ac76f
creatorsName: cn=config
createTimestamp: 20220104190525Z
entryCSN: 20220104190525.214003Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20220104190525Z
entryDN: olcDatabase={1}mdb,cn=config
subschemaSubentry: cn=Subschema
dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
olcSpCheckpoint: 100 10
olcSpSessionlog: 100
structuralObjectClass: olcSyncProvConfig
entryUUID: 047a54da-01dd-103c-8348-d3830b8ac76f
creatorsName: cn=config
createTimestamp: 20220104190525Z
entryCSN: 20220104190525.214003Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20220104190525Z
entryDN: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config
subschemaSubentry: cn=Subschema
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, January 5th, 2022 at 9:40 AM, Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de wrote:
Hi!
I meant: The debug output is useless when you leave out "-n0" (the case that
doesn't work for you).
David White dmwhite823@protonmail.com schrieb am 05.01.2022 um 15:14 in
Nachricht
qn5VCvnElSb0fkpWltSUlY7hWAU=@protonmail.com>:
That's the thing.
-n0 always returns "unknown database".
Only -n1 returns data.
Thanks for the suggestion, though. :)
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, January 5th, 2022 at 8:11 AM, Ulrich Windl
Ulrich.Windl@rz.uni-regensburg.de wrote:
It seems you missed "-n0" for slapcat.
--On Wednesday, January 5, 2022 4:16 PM +0000 David White dmwhite823@protonmail.com wrote:
And of course if I had read (and understood) the man page correctly before now, I would have realized I could easily run slapcat with the -F flag like so:
slapcat -F /var/symas/openldap-data/slapd.d/ -n0
... which works like a charm.
Not sure why it's not picking that directory up by default, but problem (mostly) solved.
Because you created your cn=config directory outside of the expected default path, which would be /opt/symas/etc/openldap/slapd.d. Not clear to me why you chose /var.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
--On Thursday, January 6, 2022 9:14 AM +1100 Dewayne Geraghty dewayne@heuristicsystems.com.au wrote:
On 6/01/2022 4:35 am, Quanah Gibson-Mount wrote:
Because you created your cn=config directory outside of the expected default path, which would be /opt/symas/etc/openldap/slapd.d. Not clear to me why you chose /var.
--Quanah
Perhaps David has a BSD system, which do not have /opt in their heir
He noted that he's using the Symas OpenLDAP builds for Linux. We do not offer FreeBSD builds for 2.5 or 2.6. Thus he specifically chose to use a non-standard path for the builds he's using.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
He noted that he's using the Symas OpenLDAP builds for Linux. We >do not offer FreeBSD builds for 2.5 or 2.6. Thus he specifically >chose to use a non-standard path for the builds he's using.
Quanah is correct. I'm on a Ubuntu 20.04 test machine.
I stopped slapd, moved the directory from /var/symas/openldap-data/slapd.d/ over to the standard location of /opt/symas/etc/openldap/slapd.d/ and started slapd again, and that resolved the issue.
I thought I had tried the 'standard' location previously, but I obviously did not -- or if I did, I didn't set it up correctly. I can't remember how or why I found the /var/symas/openldap-data directory, but when I did, I guessed (incorrectly) that this was where it needed to reside. Obviously I was mistaken. I'm learning things every day. Thank you, Quanah.
I intentionally tore down all of my config, and am starting over as of yesterday afternoon to try to build this, from scratch, correctly now.
My issue in this thread is resolved.
openldap-technical@openldap.org
-
David White -
Dewayne Geraghty -
Quanah Gibson-Mount