Update auf 4.0 schlägt fehl

Hallo,

Server mit Stand UCS 3.2-4 errata277 (c’t Edition) soll auf 4.0 upgraded werden.

Als erstes wurde eine falsche gcc Version beanstandet. Also gcc deinstalliert und Update (per Webconsole) neugestartet. Jetzt bleibt das Update mit dem Fehler:
Die folgenden Pakete haben unerfüllte Abhängigkeiten:
libc6-dev : Beschädigt: cmake (< 2.8.4+dfsg.1-5) aber 2.8.2+dfsg.1-0.17.201105181302 soll installiert werden
mysql-server : Hängt ab von: mysql-server-5.5 soll aber nicht installiert werden
E: Beschädigte Pakete
failed.
ERROR: Failed to upgrade mysql-server.
Error: Update aborted by pre-update script of release 4.0-0
exitcode of univention-updater: 1
stehen.
Ein apt-get install mysql-server bringt die Meldung “mysql-server ist schon die neueste Version”. Wenn über die Software-Verwaltung mysql-server-5.1 deinstalliert werden soll, zeigt das System auch die Deinstallierung von zarafa4ucs an. Kann man das System ohne Deinstallierung von Zarafa upgraden?

Bin für alle Tipps/Infos dankbar.
Gruß, Uwe

Hallo,

was ist eine “falsche” gcc-Version? Mir ist dahingehend nichts bekannt. Was haben Sie daraufhin konkret getan? - sind Sie wie in Update UCS c’t edition to UCS 4.0 vorgegangen?
Nach Ihren Schilderungen würde ich vermuten, dass der Paketstatus inkonsistent ist und von Hand repariert werden muss. Haben Sie den aktuellen Paketstatus bereits geprüft?

dpkg -C

Mit freundlichen Grüßen,
Tim Petersen

Hallo Herr Petersen,

das Vorgehen war wie im SDB Artikel beschrieben.
Gestern hat ein dpkg -C keine Meldung gebracht.
Nach einem reboot waren die Netzwerkeinstellungen weg (eth0 wurde nicht geladen). Nachdem ich das gefixt habe und den Rechner neugestartet wurde sieht das nun so aus:

root@server ~ # cat /var/log/syslog|grep "Jan 26 13:4"|grep nagios
Jan 26 13:43:07 server nagios3: SERVICE ALERT: server.domain.private;UNIVENTION_DISK_ROOT;OK;HARD;10;DISK OK - free space: / 505194 MB (58% inode=96%):
Jan 26 13:45:07 server nagios3: SERVICE ALERT: server.domain.private;UNIVENTION_DNS;OK;HARD;10;DNS OK: 0.056 seconds response time. www.univention.de returns 78.47.199.152
Jan 26 13:47:07 server nagios3: SERVICE NOTIFICATION: root@localhost;server.domain.private;UNIVENTION_JOINSTATUS;CRITICAL;notify-service-by-email;CRITICAL: auth failed: ldapsearch -x -h server.domain.private -p 7389 -D ldap_hostdn
Jan 26 13:49:17 server nagios3: SERVICE NOTIFICATION: root@localhost;server.domain.private;UNIVENTION_LDAP_AUTH;CRITICAL;notify-service-by-email;CHECK_NRPE: Socket timeout after 10 seconds.

root@server ~ # dpkg -C
Die folgenden Pakete sind nur halb konfiguriert, wahrscheinlich durch
Probleme während der ersten Konfiguration. Die Konfiguration sollte mit
dpkg --configure <Paket> oder mit dem Konfigurations-Menüeintrag in
dselect erneut versucht werden:
 univention-config    UCS - configuration manager

Die folgenden Pakete sind wegen Problemen während der Installation nur halb
installiert. Die Installation kann wahrscheinlich durch erneuten Versuch
beendet werden; die Pakete können mit dselect oder mit dpkg --remove entfernt
werden:
 univention-pkgdb     UCS - PkgDB

root@server ~ # dpkg --configure univention-config
univention-config (10.0.1-6.476.201409011607) wird eingerichtet ...

root@server ~ # dpkg --remove univention-pkgdb
(Lese Datenbank ... 287654 Dateien und Verzeichnisse sind derzeit installiert.)
Entfernen von univention-pkgdb ...
/usr/share/univention-directory-manager-tools/univention-dnsedit: timeout while trying to contact LDAP server server.boris-nbg.private
/usr/share/univention-directory-manager-tools/univention-dnsedit: timeout while trying to contact LDAP server server.boris-nbg.private
/usr/share/univention-directory-manager-tools/univention-dnsedit: timeout while trying to contact LDAP server server.boris-nbg.private
/usr/share/univention-directory-manager-tools/univention-dnsedit: timeout while trying to contact LDAP server server.boris-nbg.private
^CTraceback (most recent call last):
  File "/usr/share/univention-directory-manager-tools/univention-dnsedit", line 400, in <module>
    main()
  File "/usr/share/univention-directory-manager-tools/univention-dnsedit", line 351, in main
    lo, position = bind()
  File "/usr/share/univention-directory-manager-tools/univention-dnsedit", line 155, in bind
    return bind()  # recursion
  File "/usr/share/univention-directory-manager-tools/univention-dnsedit", line 155, in bind
    return bind()  # recursion
  File "/usr/share/univention-directory-manager-tools/univention-dnsedit", line 155, in bind
    return bind()  # recursion
  File "/usr/share/univention-directory-manager-tools/univention-dnsedit", line 154, in bind
    time.sleep(10)
KeyboardInterrupt
dpkg: Fehler beim Bearbeiten von univention-pkgdb (--remove):
 Unterprozess installiertes post-removal-Skript mit Signal (Unterbrechung) getötet
Trigger für univention-config werden verarbeitet ...
Kein Paket gefunden, das auf ldapacl_66univention-appcenter_app.acl passt.
Fehler traten auf beim Bearbeiten von:
 univention-pkgdb

Login jetzt nur noch als root möglich.

Eine Idee wie man das ohne Neuinstallation fixen kann? (Backup einspielen schlug fehl da anscheinend das Backup-Medium defekt ist)

Danke+Gruß,
Uwe

Hallo,

schwer zu beurteilen - erfahrungsgemäß lassen sich derartige Situationen aber auflösen.
Grob gesagt würde ich versuchen, den inkonsisten Paketstatus aufzulösen und anschließend den Updater erneut auf der Kommandozeile starten, um das Update auf UCS 4.0 fortzusetzen.

Gut wäre es noch, wenn Sie uns die komplette updater.log anhängen könnten (gern als attachment).

Mit freundlichen Grüßen,
Tim Petersen

Hallo Herr Petersen,

anbei das Logfile.

Danke+Gruß,
Uwe
updater.log (287 KB)

Hallo,

das momentane Problem ist dann tatsächlich doch weniger ein Problem mit dem Update und/oder dem Paketstatus (das Update auf 4.0 wurde “zum Glück” noch nicht richtig gestartet), sondern viel mehr dass der LDAP-Server aufgrund fehlender Schemata nicht mehr startet:

(65) Object class violation: unrecognized objectClass 'agorumcore'

Ich vermute, dass dies durch ein fehlendes Agorum Schema-Paket zustande kommt - haben Sie die Agorum App ggf. getestet und anschließend entfernt?
Sofern Sie die App nicht verwenden möchten, müssten die Daten im LDAP bereinigt werden, sprich: die fehlenden Objektklassen und entsprechenden Attribute entfernt werden.
Das konkret über diesen Kanal zu prüfen wird aber vermutlich sehr schwierig.

Mit freundlichen Grüßen,
Tim Petersen

Hallo,

noch ein kurzer Nachtrag - der folgende Artikel hilft vermutlich: Remove LDAP schema extensions

Mit freundlichen Grüßen,
Tim Petersen

Hallo Herr Petersen,

werde das mal probieren. Vielen Dank.

mfG
Uwe

Hallo Herr Petersen,

ich komm da nicht weiter.
Die Ausgabe von dpkg-query -W ‘*-schema’ zeigt mir an dass<das Paket nicht installiert ist:

agorumcore-ucs-schema
univention-fetchmail-schema     7.0.0-3.42.201310251717
univention-virtual-machine-manager-schema       4.0.2-3.57.201307262059
zarafa4ucs-schema       7.1.2001-7.68.201310070934

Nehme ich udm settings/ldapschema list | grep filename: erhalte ich keine Ausgabe.

Eine Suche im System nach der ldif Datei bleibt - erwartungsgemäß - erfolglos.

Die Ausgabe von slapschema bringt nachstehende Ausgabe:

54c7c756 OVER: Loading Translog Overlay
54c7c756 OVER: db_init
54c7c756 OVER: Configuring Translog Overlay
54c7c756 OVER: Configured Translog Overlay to use file "/var/lib/univention-ldap/listener/listener"
54c7c756 /etc/ldap/slapd.conf: line 137: rootdn is always granted unlimited privileges.
54c7c756 /etc/ldap/slapd.conf: line 161: rootdn is always granted unlimited privileges.
54c7c756 UNKNOWN attributeDescription "AGORUMCOREACCOUNT" inserted.
# (65) Object class violation: unrecognized objectClass 'agorumcore'
dn: uid=user1,cn=users,dc=domain,dc=private

# (65) Object class violation: unrecognized objectClass 'agorumcore'
dn: uid=user2,cn=users,dc=domain,dc=private

# (65) Object class violation: unrecognized objectClass 'agorumcore'
dn: uid=user3,cn=users,dc=domain,dc=private

# (65) Object class violation: unrecognized objectClass 'agorumcore'
dn: uid=user4,cn=users,dc=domain,dc=private

54c7c756 OVER: db_close
54c7c756 OVER: db_destroy

Noch eine Idee?

mfG
Uwe

Hallo,

ich habe das eben in einem Testsystem mit Agorum-LDAP-Schema für Sie nachvollzogen - die fehlende Objektklasse lautet agorumcore und das einzige Attribut lautet agorumcoreAccount.
Das bedeutet, dass Sie die vier Objekte vermutlich schon folgendermaßen bereinigen können (analog zum SDB-Artikel, step 5.2):

ldapmodify -D "cn=admin,$(ucr get ldap/base)" -y /etc/ldap.secret <<__LDIF__
dn: uid=user1,cn=users,dc=domain,dc=private
changetype: modify
delete: agorumcoreAccount
-
__LDIF__
ldapmodify -D "cn=admin,$(ucr get ldap/base)" -y /etc/ldap.secret <<__LDIF__
dn: uid=user2,cn=users,dc=domain,dc=private
changetype: modify
delete: agorumcoreAccount
-
__LDIF__
ldapmodify -D "cn=admin,$(ucr get ldap/base)" -y /etc/ldap.secret <<__LDIF__
dn: uid=user3,cn=users,dc=domain,dc=private
changetype: modify
delete: agorumcoreAccount
-
__LDIF__
ldapmodify -D "cn=admin,$(ucr get ldap/base)" -y /etc/ldap.secret <<__LDIF__
dn: uid=user4,cn=users,dc=domain,dc=private
changetype: modify
delete: agorumcoreAccount
-
__LDIF__

Anschließend bitte mit slapschema prüfen und ggfs. den LDAP-Server neustarten.

Mit freundlichen Grüßen,
Tim Petersen

Hallo Herr Petersen,

ldapmodify

wird mit:

ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

quitiert.
Die Ausgabe von slapschema:

54c8d85a OVER: Loading Translog Overlay
54c8d85a OVER: db_init
54c8d85a OVER: Configuring Translog Overlay
54c8d85a OVER: Configured Translog Overlay to use file "/var/lib/univention-ldap/listener/listener"
54c8d85a /etc/ldap/slapd.conf: line 140: rootdn is always granted unlimited privileges.
54c8d85a /etc/ldap/slapd.conf: line 164: rootdn is always granted unlimited privileges.
54c8d85a OVER: db_close
54c8d85a OVER: db_destroy

Die Ausgabe von slaptest bringt:

54c8d84e OVER: Loading Translog Overlay
54c8d84e OVER: db_init
54c8d84e OVER: Configuring Translog Overlay
54c8d84e OVER: Configured Translog Overlay to use file "/var/lib/univention-ldap/listener/listener"
54c8d84e /etc/ldap/slapd.conf: line 140: rootdn is always granted unlimited privileges.
54c8d84e /etc/ldap/slapd.conf: line 164: rootdn is always granted unlimited privileges.
54c8d84e WARNING: No dynamic config support for overlay translog.
config file testing succeeded
54c8d84e OVER: db_close
54c8d84e OVER: db_destroy

mfG, Uwe

Hallo,

wie ich gerade sehe sind die Logs nicht angehängt. Komme wahrscheinlich aber erst morgen wieder an den Rechner und hänge sie dann nachträglich an.

mfg, Uwe

Hallo,

anbei das Log. Nicht wundern wegen den Zeiten, das Ursprungs-Log war in /tmp und der Rechner wurde zwischenzeitlich runtergefahren.

Gruß, Uwe
log_ldap.log (303 KB)

Wenn ich es richtig sehe, dann fehlt in den ldapmodify Befehlen nur ein -x, also so:

[code]ldapmodify -x -D “cn=admin,$(ucr get ldap/base)” -y /etc/ldap.secret <<LDIF
dn: uid=user1,cn=users,dc=domain,dc=private
changetype: modify
delete: agorumcoreAccount

LDIF

ldapmodify -D “cn=admin,$(ucr get ldap/base)” -y /etc/ldap.secret <<LDIF
dn: uid=user2,cn=users,dc=domain,dc=private
changetype: modify
delete: agorumcoreAccount

LDIF

ldapmodify -x -D “cn=admin,$(ucr get ldap/base)” -y /etc/ldap.secret <<LDIF
dn: uid=user3,cn=users,dc=domain,dc=private
changetype: modify
delete: agorumcoreAccount

LDIF
ldapmodify -x -D “cn=admin,$(ucr get ldap/base)” -y /etc/ldap.secret <<LDIF
dn: uid=user4,cn=users,dc=domain,dc=private
changetype: modify
delete: agorumcoreAccount

LDIF

[/code]

Funktioniert es damit?

Hallo,

Hilft leider auch nicht.
Anscheinend liegt das Problem eher an der Hardware. Bekomme Fehler von fsck und memtest.

Danke bis dahin.

MfG,
Uwe