Hi Jack,
Just wondering whether you'd seen my previous response on this bug
(included below).
I was looking at this again, though, and noticed the debconf information
on your original post:
-- Configuration Files:
/etc/default/slapd changed:
SLAPD_CONF=
SLAPD_USER="openldap"
SLAPD_GROUP="openldap"
SLAPD_PIDFILE=
SLAPD_SERVICES=""
SLAPD_SENTINEL_FILE=/etc/ldap/noslapd
SLAPD_OPTIONS="-f /etc/ldap/slapd.conf"
Setting the config file location this way is probably confusing the
maintainer scripts and might even be the root cause of your problem. An
empty SLAPD_CONF setting is equivalent to "-F /etc/ldap/slapd.d", i.e.,
using the new cn=config style. The config location (and type!) isn't
parsed out of SLAPD_OPTIONS at all.
If you really want to use slapd.conf, I recommend reverting
SLAPD_OPTIONS to the default SLAPD_OPTIONS="" and setting
SLAPD_CONF="/etc/ldap/slapd.conf".
The package should probably be detecting this situation and warning you
about it...
On Wed, Aug 01, 2018 at 08:22:36AM -0700, Ryan Tandy wrote:
Hi Jack,
Thanks for the report.
On Wed, Aug 01, 2018 at 10:35:00AM -0400, Jack McKinney wrote:
Saving current slapd configuration to /var/backups/slapd-2.4.44+dfsg-5+deb9u1...
5b61c485 olcAttributeTypes: value #0 olcAttributeTypes: Duplicate attributeType:
"2.5.4.2"
5b61c485 config error processing cn={0}core,cn=schema,cn=config: olcAttributeTypes:
Duplicate attributeType: "2.5.4.2"
slapcat: bad configuration directory!
Interesting. I wonder how it got that way?
Can you confirm by pasting the output of:
grep -Frw 2.5.4.2 /etc/ldap/slapd.d
that it actually occurs twice in your config?
You might have some older config backups in /var/backups/slapd-*; can
you also check those and see if you can determine in which version it
was introduced?
What is your upgrade history like for slapd? Were you running
2.4.44+dfsg-5 and then upgraded to +deb9u1 before this upgrade to
+deb9u2?
If there is a bug in the package, I would be most suspicious of the
upgrade path from jessie to stretch...
thanks,
Ryan
