Apologies Quanah,
Yes - the first thing I did was to load the ppolicy schema.
Here is the full cn=module{0} from ldapsearch:
# module{0}, config dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib64/openldap olcModuleLoad: {0}back_bdb olcModuleLoad: {1}syncprov olcModuleLoad: {2}ppolicy
Here is the contents of cn=module{0}.ldif
dn: cn=module{0} objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib64/openldap olcModuleLoad: {0}back_bdb olcModuleLoad: {1}syncprov
I don't have the initial error that I got when attempting to load the ppolicy module, but subsequent attempts yield this error: add olcModuleLoad: ppolicy modifying entry "cn=module{0},cn=config" ldap_modify: Type or value exists (20) additional info: modify/add: olcModuleLoad: value #0 already exists
Then after (ill-advisedly) applying the ppolicy overlay, slapcat -n 0 yields the following:
5ede54b5 UNKNOWN attributeDescription "OLCPPOLICYDEFAULT" inserted. 5ede54b5 config error processing olcOverlay={1}ppolicy,olcDatabase={2}hdb,cn=config: slapcat: bad configuration file!
Thank you,
John Alexander
On Mon, Jun 8, 2020 at 9:12 AM Quanah Gibson-Mount quanah@symas.com wrote:
--On Monday, June 8, 2020 9:55 AM -0700 John Alexander jalexander@concentricsky.com wrote:
Hi Quanah,
I figured that was the problem, but after I ran the module load:
dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: ppolicy
I received errors. slapcat -n 0 | grep olcModuleLoad did not indicate that ppolicy was loaded. However ldapsearch indicated that it was loaded.
If you receive errors, you need to show what those errors are. You also need to show what your *full* cn=module{0} entry looks like, and you've never stated whether or not you've loaded the mandatory ppolicy schema.
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
--On Monday, June 8, 2020 10:27 AM -0700 John Alexander jalexander@concentricsky.com wrote:
Here is the contents of cn=module{0}.ldif
Given that the results differ between ldapsearch and the actual cn=module{0} LDIF file, it would appear you've managed to thoroughly break cn=config such that it's failing to properly update the files on disk.
You've never provided full output of your cn=config db from slapcat, so it's difficult to determine how you've ended up in that state (if the config db even fully captures what went wrong).
You'll likely need to export what you have via slapcat, fix the module load section and any other problems, and rebuild your cn=config db with that fixed export.
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Quanah Gibson-Mount wrote:
--On Monday, June 8, 2020 10:27 AM -0700 John Alexander jalexander@concentricsky.com wrote:
Here is the contents of cn=module{0}.ldif
Given that the results differ between ldapsearch and the actual cn=module{0} LDIF file, it would appear you've managed to thoroughly break cn=config such that it's failing to properly update the files on disk.
You've never provided full output of your cn=config db from slapcat, so it's difficult to determine how you've ended up in that state (if the config db even fully captures what went wrong).
You'll likely need to export what you have via slapcat, fix the module load section and any other problems, and rebuild your cn=config db with that fixed export.
There's no indication that the config that slapcat displayed is the same one that slapd is running with.
--On Monday, June 8, 2020 7:21 PM +0100 Howard Chu hyc@symas.com wrote:
There's no indication that the config that slapcat displayed is the same one that slapd is running with.
What he reported was the on-disk contents of cn=module{0}.ldif, vs slapcat output (which he also reported later). Although that too may not be the actual cn=module{0}.ldif file being used by slapd, it's true.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
openldap-technical@openldap.org