I'm using the following config... Any path is adjusted according to the target OS on which is being used... for example in Freebsd openldap's modules are located in /usr/local/libexec/openldap Thanks in advance
# # See slapd-config(5) for details on configuration options. # This file should NOT be world readable. # dn: cn=config objectClass: olcGlobal cn: config # # # Define global ACLs to disable default read access. # olcPidFile: /run/openldap/slapd.pid olcArgsFile: /run/openldap/slapd.args # # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #olcReferral: ldap://root.openldap.org # # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 64-bit encryption for simple bind #olcSecurity: ssf=1 update_ssf=112 simple_bind=64
# # Load dynamic backend modules: # dn: cn=module,cn=config objectClass: olcModuleList cn: module olcModulepath: /usr/lib/openldap olcModuleload: back_mdb.la #olcModuleload: back_bdb.la #olcModuleload: back_hdb.la #olcModuleload: back_ldap.la #olcModuleload: back_passwd.la #olcModuleload: back_shell.la
dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema
include: file:///etc/openldap/schema/core.ldif include: file:///etc/openldap/schema/cosine.ldif include: file:///etc/openldap/schema/nis.ldif include: file:///etc/openldap/schema/inetorgperson.ldif
# Frontend settings # dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAccess: to * by * read # # Sample global access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # #olcAccess: to dn.base="" by * read #olcAccess: to dn.base="cn=Subschema" by * read #olcAccess: to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! #
dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: to * by * none olcRootPW: {SSHA}pCEOC687DNCkuFE+1owDG0QRHoioRqle
####################################################################### # LMDB database definitions ####################################################################### # dn: olcDatabase=mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: mdb olcDbMaxSize: 1073741824 olcSuffix: dc=hlab,dc=lan olcRootDN: cn=hlabadm,dc=hlab,dc=lan # Cleartext passwords, especially for the rootdn, should # be avoided. See slappasswd(8) and slapd-config(5) for details. # Use of strong authentication encouraged. olcRootPW: {SSHA}dZlyVv5cR432HIzRmnbTq3O6TNOVM6rx # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. olcDbDirectory: /var/lib/openldap/openldap-data # Indices to maintain olcDbIndex: objectClass eq
On Tue, May 5, 2020 at 11:16 AM Quanah Gibson-Mount quanah@symas.com wrote:
--On Tuesday, May 5, 2020 12:02 PM -0500 Beker fzfq3m@gmail.com wrote:
Yep, that was an error I made when I redacted the email and changed the the rootdn to not leak info about my environment (which might be stupid since this is just a home lab)
I would suggest you provide the full, unredacted slapd.ldif file you were loading.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
--On Tuesday, May 5, 2020 1:42 PM -0500 Beker fzfq3m@gmail.com wrote:
dn: cn=module,cn=config objectClass: olcModuleList cn: module olcModulepath: /usr/lib/openldap olcModuleload: back_mdb.la
I was able to load your slapd.ldif file w/o issue with the exception of a minor problem in the above, which has two spaces after the : instead of a single space. This made slapd try to load " back_mdb.la" instead of "back_mdb.la".
Once I fixed that problem, I was able to import it w/o issue:
root@anvil3:/tmp# slapadd -n 0 -F /usr/local/etc/openldap/slapd.d -l slapd.ldif _#################### 100.00% eta none elapsed none fast! Closing DB... root@anvil3:/tmp#
However, I get the same failure you report when doing a dry-run:
/opt/symas/bin/slapadd -u -n 0 -F /opt/symas/etc/openldap/slapd.d -l slapd.ldif 5eb1d54e <= str2entry: str2ad(olcDbMaxSize): attribute type undefined slapadd: could not parse entry (line=1066) _#################### 100.00% eta none elapsed none fast!
So this seems to be an bug with the dry run code vs an actual problem with the configuration.
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 Tuesday, May 5, 2020 1:42 PM -0500 Beker fzfq3m@gmail.com wrote:
dn: cn=module,cn=config objectClass: olcModuleList cn: module olcModulepath: /usr/lib/openldap olcModuleload: back_mdb.la
I was able to load your slapd.ldif file w/o issue with the exception of a minor problem in the above, which has two spaces after the : instead of a single space. This made slapd try to load " back_mdb.la" instead of "back_mdb.la".
Once I fixed that problem, I was able to import it w/o issue:
root@anvil3:/tmp# slapadd -n 0 -F /usr/local/etc/openldap/slapd.d -l slapd.ldif _#################### 100.00% eta none elapsed none fast! Closing DB... root@anvil3:/tmp#
However, I get the same failure you report when doing a dry-run:
/opt/symas/bin/slapadd -u -n 0 -F /opt/symas/etc/openldap/slapd.d -l slapd.ldif 5eb1d54e <= str2entry: str2ad(olcDbMaxSize): attribute type undefined slapadd: could not parse entry (line=1066) _#################### 100.00% eta none elapsed none fast!
So this seems to be an bug with the dry run code vs an actual problem with the configuration.
In a dry run none of the directives are actually executed. Since the moduleLoad doesn't happen, the back-mdb schema isn't present.
--On Tuesday, May 5, 2020 11:32 PM +0100 Howard Chu hyc@symas.com wrote:
In a dry run none of the directives are actually executed. Since the moduleLoad doesn't happen, the back-mdb schema isn't present.
And on the one system where it worked would indicate that back-mdb was compiled in vs being a shared object (just to note).
--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