Slapd startet nicht mehr bei upgrade auf 2.4-2

german

#1

Hallo, versuche ein Upgrade auf 4.1 durchzuführen und scheitere schon beim upgrade auf 2.4-2

Richte slapd ein (2.4.23-1.47.201102221221) ... Installiere neue Version der Konfigurationsdatei /etc/ldap/schema/core.schema ... Backing up /etc/ldap/slapd.conf in /var/backups/slapd-2.4.23-1.44.201007281521... done. File: /etc/init.d/slapd Check database: /var/lib/univention-ldap/ldap BDB Version does not seem to match the one back-bdb uses. Skipping /usr/bin/db4.7_recover to avoid damage. done Starting ldap server(s): slapd. invoke-rc.d: initscript slapd, action "start" failed. dpkg: Fehler beim Bearbeiten von slapd (--configure): Unterprozess post-installation script gab den Fehlerwert 1 zurück Fehler traten auf beim Bearbeiten von: slapd

ich konnte nicht wirklich rausfinden warum slapd den Fehlerwert 1 meldet.
Auf dem Rechner war noch opsi4ucs installiert, das habe ich vorher deinstalliert, auch das opsi ldap schema package ist entfernt worden, slapd neu gestartet vor dem upgrade, alles lief noch problemlos.


#2

Moin,

können Sie bitte mal die folgenden Informationen hier posten (sinnvollerweise als Dateianhänge, da die Ausgaben vermutlich nicht ganz klein sein werden):

[ol][li]Modifizieren Sie die Datei /etc/init.d/slapd und fügen Sie dort direkt hinter dem großen Kommentarblock am Anfang eine Zeile mit »set -x« ein. Dann versuchen Sie, den slapd zu starten, und speichern Sie die Ausgabe: »/etc/init.d/slapd start > ~/init-script.txt«. Diese Ausgabe brauche ich.[/li]
[li]Schauen Sie anschließend mal ins Syslog. Dort sollten Meldungen vom slapd erscheinen, die sagen, warum er nicht starten wollte.[/li][/ol]

Danke sehr.

Gruß,
mosu


#3

danke, hilft mir aber auch noch nicht weiter.
im Syslog:

slapd[6029]: @(#) $OpenLDAP: slapd 2.4.23 (Feb 25 2011 05:46:16) $ ^Iroot@norrebo:/tmp/buildd/openldap-2.4.23/debian/build/servers/slapd

debug output vom slapd start:

  • start-stop-daemon --start --quiet --pidfile /var/run/slapd/slapd.pid --exec /usr/sbin/slapd – -h ‘ldap:/// ldapi:/// ldaps:///’
  • test -e /var/run/slapd/ldapi
  • ln -sf /var/run/slapd/ldapi /var/run/ldapi
  • check_subschema

#4

Moin,

das kann nicht alles sein, was da ausgegeben wurde. Mich interessiert eigentlich viel eher, was mit dem db_recover etc. passiert und warum dort gesagt wird.

Starten Sie doch bitte mal den slapd manuell mit hohem Debuglevel und hängen Sie die Ausgabe hier an:

/usr/sbin/slapd -h 'ldapi:/// ldap://:7389/ ldaps://:7636/' -d 255 &> output.txt

Gruß,
mosu


#5

die letzten Zeilen der Ausgabe vom debug scheinen interessant.
Selbiges bekomme ich als ergebniss wenn ich slapcat aufrufe:

OVER: Loading Translog Overlay
OVER: db_init
OVER: Configuring Translog Overlay
OVER: Configured Translog Overlay to use file "/var/lib/univention-ldap/listener/listener"
bdb(dc=foobar,dc=at): Build signature doesn't match environment
bdb_db_open: database "dc=foobar,dc=at" cannot be opened, err -30971. Restore from backup!
backend_startup_one (type=bdb, suffix="dc=foobar,dc=at"): bi_db_open failed! (-30971)
slap_startup failed

#6

sodala, versuche grad ein restore vom LDAP durchzufuehren und scheitere anscheinend am OPSI wobei ich mir nicht so 100% sicher bin ob es nun gescheitert ist oder nicht.
Slapd kann ich danach jedenfalls wieder starten.

slapadd -l ldap-backup_20160203.ldif
OVER: Loading Translog Overlay
OVER: db_init
OVER: Configuring Translog Overlay
OVER: Configured Translog Overlay to use file "/var/lib/univention-ldap/listener/listener"
_#########             46.23% eta        elapsed            none spd   1.3 M/s Entry (cn=7zip,cn=smb.foobar.at,cn=products,cn=opsi,dc=foobar,dc=at): object class 'opsiLocalBootProduct' requires attribute 'opsiProductId'
slapadd: dn="cn=7zip,cn=ifsmb.foobar.at,cn=products,cn=opsi,dc=foobar,dc=at" (line=14781): (65) object class 'opsiLocalBootProduct' requires attribute 'opsiProductId'
.##########            52.90% eta        elapsed            none spd 239.9 k/s
Closing DB...
OVER: db_close
OVER: db_destroy
root@ifsmbtest:~# echo $?
1

#7

Moin,

ja, das schlug fehl, da slapadd per default bei einem Fehler nicht weitermacht.

Sie können versuchen, slapadd zu sagen, dass eben keine Schema-Prüfung durchgeführt werden soll. Dazu ergänzen Sie bei slapadd die Parameter »-o schema-check=no«. Ist sicherlich nicht die sauberste Variante, aber ein Versuch ist’s wert.

Vorher natürlich noch mal die halb importierten Datenbankdateien entfernen.

Gruß,
mosu