Your message dated Wed, 25 Mar 2020 19:12:47 -0700
with message-id <20200326021247.ga24...@t570.nardis.ca>
and subject line Re: Bug#905219: slapd: apt-get upgrade with Duplicate 
attributeType: "2.5.4.2"
has caused the Debian Bug report #905219,
regarding slapd: apt-get upgrade with Duplicate attributeType: "2.5.4.2"
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
905219: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905219
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: slapd
Version: 2.4.44+dfsg-5+deb9u1
Severity: important

Dear Maintainer,

   * What led up to the situation? I wanted to update my system
   * What exactly did you do (or not do) that was effective (or
     ineffective)? I ran "apt-get upgrade"
   * What was the outcome of this action? It bailed when it hit slapd
   * What outcome did you expect instead? apt-get upgrade usually just works

It upgraded most of the packages just fine, but failed when it hit slapd.
If I try it again, I get the same result. It complains about the schema, but
the schema here are the dist schema; I have not modified them. I found this
exact schema error in google going back over a decade, but the fix does not
apply to my system (and it has been working fine for quite some time, not
throwing this error until I tried to apt-get upgrade).

hamilton /home/jackmc [1] # apt-get upgrade
Reading package lists... Done
Building dependency tree       
Reading state information... Done
You might want to run 'apt --fix-broken install' to correct these.
The following packages have unmet dependencies:
 slapd : Depends: libldap-2.4-2 (= 2.4.44+dfsg-5+deb9u1) but 
2.4.44+dfsg-5+deb9u2 is installed
E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or 
specify a solution).
hamilton /home/jackmc [2] # apt --fix-broken install
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Correcting dependencies... Done
The following additional packages will be installed:
  slapd
Suggested packages:
  libsasl2-modules-gssapi-mit | libsasl2-modules-gssapi-heimdal
The following packages will be upgraded:
  slapd
1 upgraded, 0 newly installed, 0 to remove and 67 not upgraded.
44 not fully installed or removed.
Need to get 0 B/1,430 kB of archives.
After this operation, 1,024 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Reading changelogs... Done
Preconfiguring packages ...
(Reading database ... 199351 files and directories currently installed.)
Preparing to unpack .../slapd_2.4.44+dfsg-5+deb9u2_amd64.deb ...
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!
dpkg: error processing archive 
/var/cache/apt/archives/slapd_2.4.44+dfsg-5+deb9u2_amd64.deb (--unpack):
 subprocess new pre-installation script returned error exit status 1
  Backing up /etc/ldap/slapd.d in /var/backups/slapd-2.4.44+dfsg-5+deb9u2... 
done.
Errors were encountered while processing:
 /var/cache/apt/archives/slapd_2.4.44+dfsg-5+deb9u2_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
hamilton /home/jackmc [3] # 



-- System Information:
Debian Release: 9.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-4-amd64 (SMP w/12 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages slapd depends on:
ii  adduser                            3.115
ii  coreutils                          8.26-3
ii  debconf [debconf-2.0]              1.5.61
ii  libc6                              2.24-11+deb9u3
ii  libdb5.3                           5.3.28-12+deb9u1
ii  libgnutls30                        3.5.8-5+deb9u3
iu  libldap-2.4-2                      2.4.44+dfsg-5+deb9u2
ii  libltdl7                           2.4.6-2
ii  libodbc1                           2.3.4-1
iu  libperl5.24 [libmime-base64-perl]  5.24.1-3+deb9u4
ii  libsasl2-2                         2.1.27~101-g0780600+dfsg-3
ii  libwrap0                           7.6.q-26
ii  lsb-base                           9.20161125
iu  perl                               5.24.1-3+deb9u4
ii  psmisc                             22.21-2.1+b2

Versions of packages slapd recommends:
ii  libsasl2-modules  2.1.27~101-g0780600+dfsg-3

Versions of packages slapd suggests:
iu  ldap-utils                                             2.4.44+dfsg-5+deb9u2
pn  libsasl2-modules-gssapi-mit | libsasl2-modules-gssapi  <none>

-- 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"


-- debconf information excluded

--- End Message ---
--- Begin Message ---
Hello,

I understand why this problem triggered when it did. There was a broken slapd.d directory, which wasn't being used because SLAPD_OPTS specified slapd.conf instead. Then the upgrade of slapd detected the slapd.d directory, went to export a backup of it, and failed.

I still do not understand why a broken and unused slapd.d directory existed, or how it got into that broken state. The only way I've managed to reproduce the actual error mentioned here is by actually duplicating the attribute type definition inside /etc/ldap/slapd.d/cn=config/cn=schema/cn={0}core.ldif itself, which seems very unlikely to happen by accident.

I am closing this bug as I can't identify anything to be fixed based on the information supplied. Feel free to reopen if my conclusion is wrong and there is actually a bug in the package.

thanks,
Ryan

--- End Message ---

Reply via email to