UCS-Fehler nach Dateisystemreparatur

cheppo · October 1, 2013, 11:46am

Hallo Community

Mein UCS (3.1-1) mit Zarafa läuft in einer VM und gestern ist mein Host-System abgestützt. Beim Neustarten wollte UCS nicht mehr booten und verlangte nach einer Dateisystemreparatur, die ich komplett durchlaufen lassen habe. Der UCS bootet jetzt wieder gibt aber Fehler bzgl. …

-ClamAV
-Univention Directory Policy
-Zarafa-Gateway

aus

-ich kann mich an der Konsole nicht mehr mit meinem UCS=Zarafa-Nutzer und auch nicht mehr als Administrator anmelden, nur noch als root.

-Am Web-Interface kann ich mich als Administrator anmelden, aber klicke ich auf das Modul “Benutzer” gibt es einen Fehler “Die Anfrage konnte nicht bearbeitet werden”.

(Detail-Info

[code]Die Ausführung des Kommandos udm/superordinates ist fehlgeschlagen:

Traceback (most recent call last):
File “/usr/lib/pymodules/python2.6/univention/management/console/modules/init.py”, line 204, in execute
func( request )
File “/usr/lib/pymodules/python2.6/univention/management/console/modules/udm/init.py”, line 633, in superordinates
module = self._get_module_by_request( request )
File “/usr/lib/pymodules/python2.6/univention/management/console/modules/udm/init.py”, line 107, in _get_module_by_request
return self._get_module(object_type, request.flavor)
File “/usr/lib/pymodules/python2.6/univention/management/console/modules/udm/init.py”, line 96, in _get_module
return UDM_Module( module_name )
File “/usr/lib/pymodules/python2.6/univention/management/console/modules/udm/udm_ldap.py”, line 221, in init
self.load( force_reload=force_reload )
File “/usr/lib/pymodules/python2.6/univention/management/console/modules/udm/udm_ldap.py”, line 233, in load
self.module = _module_cache.get( module, force_reload=force_reload )
File “/usr/lib/pymodules/python2.6/univention/management/console/modules/udm/udm_ldap.py”, line 150, in wrapper_func
raise LDAP_ConnectionError( ‘Opening LDAP connection failed: %s’ % str( e ) )
LDAP_ConnectionError: Opening LDAP connection failed: {‘desc’: “Can’t contact LDAP server”}[/code]
-Zarafa läuft nicht mehr und lässt sich auch nicht neu starten (von der Konsole)

Hattet das schon Mal jemand?

ahrnke · October 1, 2013, 3:27pm

Hallo,

als erstes solltes Sie sehen, ob sich der LDAP-Server (slapd) starten lässt. Wenn nicht, wären detaillierte Informationen zu dessen Fehler nötig.

Welche Fehler gibt es beim Start von Zarafa von der Kommandozeile?

Viele Grüße,
Dirk Ahrnke

cheppo · October 1, 2013, 5:16pm

slapd lässt sich starten (allerdings nicht via upstart (service start …)

Trotzdem kommt es zu folgenden FehlernCheck Database ... Segmention fault Could not determine BOB version of /var/lib/univention-ldap/ldap Skipping /usr/bin/db4.8_recover to avoid damage Starting ldap server(s):slapd ... done Checking Schema ID: ...
Am oben beschriebenen Verhalten des UCS hat sich nichts geändert.

Korrektur zur obrigen Aussage:

“zarafa-server” lässt sich starten, aber beim Login an WebApp kommt “cannot connect to Zarafa-Server”, was aber einleuchtet, wenn er den Benutzer nicht mehr hat.

Danke schon Mal für die Mühe.

ahrnke · October 1, 2013, 8:23pm

Hallo,
der Segfault könnte bedeuten, dass die Backend-DB des slapd durch den Crash beschädigt ist. Aber ich würde mich an dieser Stelle bei dieser Informationslage nicht 100% darauf festlegen.
Sinnvoll wären begeleitende Logs aus /var/log, ggf. bei erhöhtem Log-Level.

Je nach Lage wäre dann entweder ein db_recover oder zur Not ein Neuaufbau auf Basis der LDAP-Dumps in var/univention-backup nötig.

Leider hab ich im Moment nicht alle Auszeichnungen parat und derartige Situationen nicht allzuoft durchgespielt und kann Ihnen auf die Schnelle keine sichere Anleitung zum Fix geben.

Wichtig wäre auf jeden Fall die genaue Prüfung der Ursache für den Segfault.

Viele Grüße,
Dirk Ahrnke

cheppo · October 2, 2013, 11:07am

Hallo Dirk,

welche Logs brauchst Du? in “messages” steht in Bezug auf slapd nicht viel drin ausser diversen ldap-auth-fails, z.B. Nagion weil keine Verbindung zur Datenbank hergestellt werden kann.

Thomas

ahrnke · October 2, 2013, 11:52am

Hallo,

wenn ich mir - wie auch hier - nicht sicher bin, versuche ich eine gezielte Reproduktion (hier: slapd durchstarten) und schau mit “ls -ltr” wer sich gerade bewegt hat.

Viele Grüße,
Dirk

cheppo · October 2, 2013, 1:00pm

Hi,

also in syslog scheint sich Einiges zu tun: Nützt Dir das was?Oct 2 14:46:01 mail /USR/SBIN/CRON[9975]: (root) CMD ( /usr/lib/univention-virtual-machine-manager-daemon/uvmmd-check.sh) Oct 2 14:48:02 mail /USR/SBIN/CRON[10182]: (root) CMD ( /usr/lib/univention-virtual-machine-manager-daemon/uvmmd-check.sh) Oct 2 14:49:59 mail kernel: [53281.814048] db4.8_stat[10444]: segfault at 7f86f9ac01a8 ip 00007efefa7e7726 sp 00007fff1fb8f748 error 4 in libdb-4.8.so[7efefa724000+176000] Oct 2 14:49:59 mail slapd[10445]: @(#) $OpenLDAP: slapd (Aug 13 2013 08:04:08) $#012#011root@ladda:/var/build/temp/tmp.epWZfjp7Mx/pbuilder/openldap-2.4.31/debian/build/servers/slapd Oct 2 14:50:03 mail /USR/SBIN/CRON[10602]: (root) CMD ( if [ -x /usr/sbin/univention-umount-homedirs ]; then /usr/sbin/univention-umount-homedirs; fi) Oct 2 14:50:03 mail /USR/SBIN/CRON[10604]: (root) CMD (if [ -x /usr/bin/mrtg ] && [ -r /etc/mrtg.cfg ]; then mkdir -p /var/log/mrtg ; env LANG=C /usr/bin/mrtg /etc/mrtg.cfg 2>&1 | tee -a /var/log/mrtg/mrtg.log ; fi) Oct 2 14:50:03 mail /USR/SBIN/CRON[10608]: (root) CMD (/usr/sbin/jitter 60 /usr/share/univention-samba4/scripts/sysvol-sync.sh >>/var/log/univention/sysvol-sync.log 2>&1) Oct 2 14:50:03 mail /USR/SBIN/CRON[10611]: (root) CMD ( /usr/lib/univention-virtual-machine-manager-daemon/uvmmd-check.sh) Oct 2 14:50:26 mail slapd[10648]: @(#) $OpenLDAP: slapd (Aug 13 2013 08:04:08) $#012#011root@ladda:/var/build/temp/tmp.epWZfjp7Mx/pbuilder/openldap-2.4.31/debian/build/servers/slapd Oct 2 14:50:26 mail kernel: [53308.592465] db4.8_stat[10647] general protection ip:7fc70bb55726 sp:7fff52376998 error:0 in libdb-4.8.so[7fc70ba92000+176000] Oct 2 14:52:01 mail /USR/SBIN/CRON[10853]: (root) CMD ( /usr/lib/univention-virtual-machine-manager-daemon/uvmmd-check.sh) Oct 2 14:54:02 mail /USR/SBIN/CRON[11167]: (root) CMD ( /usr/lib/univention-virtual-machine-manager-daemon/uvmmd-check.sh) Oct 2 14:55:02 mail /USR/SBIN/CRON[11319]: (root) CMD (if [ -x /usr/bin/mrtg ] && [ -r /etc/mrtg.cfg ]; then mkdir -p /var/log/mrtg ; env LANG=C /usr/bin/mrtg /etc/mrtg.cfg 2>&1 | tee -a /var/log/mrtg/mrtg.log ; fi) Oct 2 14:55:02 mail /USR/SBIN/CRON[11323]: (root) CMD (/usr/sbin/jitter 60 /usr/share/univention-samba4/scripts/sysvol-sync.sh >>/var/log/univention/sysvol-sync.log 2>&1)
und natürlich dann auch in mail.log, was dann aber mehr oder wneiger logisch ist.Oct 2 14:46:01 mail /USR/SBIN/CRON[9975]: (root) CMD ( /usr/lib/univention-virtual-machine-manager-daemon/uvmmd-check.sh) Oct 2 14:48:02 mail /USR/SBIN/CRON[10182]: (root) CMD ( /usr/lib/univention-virtual-machine-manager-daemon/uvmmd-check.sh) Oct 2 14:49:59 mail kernel: [53281.814048] db4.8_stat[10444]: segfault at 7f86f9ac01a8 ip 00007efefa7e7726 sp 00007fff1fb8f748 error 4 in libdb-4.8.so[7efefa724000+176000] Oct 2 14:49:59 mail slapd[10445]: @(#) $OpenLDAP: slapd (Aug 13 2013 08:04:08) $#012#011root@ladda:/var/build/temp/tmp.epWZfjp7Mx/pbuilder/openldap-2.4.31/debian/build/servers/slapd Oct 2 14:50:03 mail /USR/SBIN/CRON[10602]: (root) CMD ( if [ -x /usr/sbin/univention-umount-homedirs ]; then /usr/sbin/univention-umount-homedirs; fi) Oct 2 14:50:03 mail /USR/SBIN/CRON[10604]: (root) CMD (if [ -x /usr/bin/mrtg ] && [ -r /etc/mrtg.cfg ]; then mkdir -p /var/log/mrtg ; env LANG=C /usr/bin/mrtg /etc/mrtg.cfg 2>&1 | tee -a /var/log/mrtg/mrtg.log ; fi) Oct 2 14:50:03 mail /USR/SBIN/CRON[10608]: (root) CMD (/usr/sbin/jitter 60 /usr/share/univention-samba4/scripts/sysvol-sync.sh >>/var/log/univention/sysvol-sync.log 2>&1) Oct 2 14:50:03 mail /USR/SBIN/CRON[10611]: (root) CMD ( /usr/lib/univention-virtual-machine-manager-daemon/uvmmd-check.sh) Oct 2 14:50:26 mail slapd[10648]: @(#) $OpenLDAP: slapd (Aug 13 2013 08:04:08) $#012#011root@ladda:/var/build/temp/tmp.epWZfjp7Mx/pbuilder/openldap-2.4.31/debian/build/servers/slapd Oct 2 14:50:26 mail kernel: [53308.592465] db4.8_stat[10647] general protection ip:7fc70bb55726 sp:7fff52376998 error:0 in libdb-4.8.so[7fc70ba92000+176000] Oct 2 14:52:01 mail /USR/SBIN/CRON[10853]: (root) CMD ( /usr/lib/univention-virtual-machine-manager-daemon/uvmmd-check.sh) Oct 2 14:54:02 mail /USR/SBIN/CRON[11167]: (root) CMD ( /usr/lib/univention-virtual-machine-manager-daemon/uvmmd-check.sh) Oct 2 14:55:02 mail /USR/SBIN/CRON[11319]: (root) CMD (if [ -x /usr/bin/mrtg ] && [ -r /etc/mrtg.cfg ]; then mkdir -p /var/log/mrtg ; env LANG=C /usr/bin/mrtg /etc/mrtg.cfg 2>&1 | tee -a /var/log/mrtg/mrtg.log ; fi) Oct 2 14:55:02 mail /USR/SBIN/CRON[11323]: (root) CMD (/usr/sbin/jitter 60 /usr/share/univention-samba4/scripts/sysvol-sync.sh >>/var/log/univention/sysvol-sync.log 2>&1)

DBGTMaster · October 2, 2013, 2:22pm

Hallo,

Ausgabe von “slaptest” wäre auch noch interessant.

cheppo · October 2, 2013, 6:28pm

524c657b OVER: Loading Translog Overlay 524c657b OVER: db_init 524c657b OVER: Configuring Translog Overlay 524c657b OVER: Configured Translog Overlay to use file "/var/lib/univention-ldap/listener/listener" 524c657b WARNING: No dynamic config support for overlay translog. 524c657b bdb(dc=thomas-drilling,dc=local): unable to allocate memory for mutex; resize mutex region 524c657b bdb_db_open: database "dc=thomas-drilling,dc=local" cannot be opened, err 12. Restore from backup! 524c657b backend_startup_one (type=bdb, suffix="dc=thomas-drilling,dc=local"): bi_db_open failed! (12) slap_startup failed (test would succeed using the -u switch)

DBGTMaster · October 3, 2013, 8:03am

Klingt so, als wäre die LDAP- Datenbank kaputt.

Du könntest das letzte LDAP Backup zurückspielen:

cp /var/lib/univention-ldap/ldap/ /var/lib/univention-ldap/ldap.bak -R /etc/init.d/slapd stop rm /var/lib/univention-ldap/ldap/* cp /var/lib/univention-ldap/ldap.bak/DB_CONFIG /var/lib/univention-ldap/ldap/DB_CONFIG gunzip ldap-backup_20130930.ldif.gz (den letzten Tag vor der Dateisystemreperatur wählen!) slapadd -vl ldap-backup_20130930.ldif /etc/init.d/slapd start

Gibt es noch weitere backups / slaves, so würde ich diese neu joinen, um einen gleichen LDAP Stand zu erziehlen.

Viel Glück!

lG

cheppo · October 4, 2013, 9:04am

Führt zu …root@mail:/var/univention-backup# slapadd -vl ldap-backup_20130927.ldif 524e8353 OVER: Loading Translog Overlay 524e8353 OVER: db_init 524e8353 OVER: Configuring Translog Overlay 524e8353 OVER: Configured Translog Overlay to use file "/var/lib/univention-ldap/listener/listener" 524e8353 bdb_db_open: warning - no DB_CONFIG file found in directory /var/lib/univention-ldap/ldap: (2). Expect poor performance for suffix "dc=xxxxx-xxxxxx,dc=local". 524e8353 <= str2entry: str2ad(5244ae6f OVER): AttributeDescription contains inappropriate characters slapadd: could not parse entry (line=1) _ 0.65% eta none elapsed none spd 12.2 M/s Closing DB... 524e8353 OVER: db_close 524e8353 OVER: db_destroy
Noch jemand eine Idee? Auf jeden Fall schon Mal trotzdem Danke. Ich habe ja Backups von meinen Daten.

ahrnke · October 7, 2013, 8:43am

Was steht denn in Zeile 1 von “ldap-backup_20130927.ldif”?
Vielleicht trifft [bug]31997[/bug] hier zu.

ahrnke · October 7, 2013, 9:24am

Nachtrag:

[quote=“cheppo”]524e8353 bdb_db_open: warning - no DB_CONFIG file found in directory /var/lib/univention-ldap/ldap: (2).[/quote]
Hier sollte

ucr commit /var/lib/univention-ldap/ldap/DB_CONFIG

helfen.

cheppo · October 7, 2013, 8:14pm

Hallo Dirk,

Also auf

ucr commit /var/lib/univention-ldap/ldap/DB_CONFIG

war ich selbst schon gekommen; hier im Forum gefunden.

In Zeile 1 von /var/univention-backip/xxxxx.ldif

steht

5244ae6f OVER: Loading Translog Overlay

Das sieht mir erstmal vernünftig aus. Mit der Beschreibung des erwähnten Bug #31997 kann ich nichts anfangen, ebensowenig mit der Lösung. Brauche nähere Erläuterung.

ahrnke · October 8, 2013, 6:59am

Das mag sinnvoll aussehen, hat aber in einem LDIF nichts zu suchen und ist genau das im Bug beschriebene Problem, dass auch die Ausgaben von STDERR im Backup landen.
In der Bugbeschreibung ist kein direkter Workaround. Man muß demzufolge das LDIF manuell bearbeiten.

Ein bearbeitetes Beispiel aus einem aktuellen Backup:

52532ee5 OVER: Loading Translog Overlay
52532ee5 OVER: db_init
52532ee5 OVER: Configuring Translog Overlay
52532ee5 OVER: Configured Translog Overlay to use file "/var/lib/univention-ldap/listener/listener"
dn: dc=domain,dc=de
univentionPolicyReference: cn=default-settings,cn=thinclient,cn=policies,
 dc=domain,dc=de
...
structuralObjectClass: dNSZone
entryUUID: 52532ee5 OVER: db_close
52532ee5 OVER: db_destroy
009d13ae-bd56-1032-8a99-6f4ced1b780e
creatorsName: uid=Administrator,cn=users,dc=domain,dc=de
createTimestamp: 20130929132258Z

Das eigentliche LDIF fängt in Zeile 5 an. Am Ende sieht man beim Attribut entryUUID noch eine STDERR-Ausgabe dazwischen.
Korrekt wäre

entryUUID: 009d13ae-bd56-1032-8a99-6f4ced1b780e

Am besten also nach “OVER” suchen.

Viele Grüße,
Dirk Ahrnke

cheppo · October 8, 2013, 9:16am

Danke für den Tipp. Dass die Ausgaben von STDERR in Backup landen habe ich schon verstanden, habe nur ehrlich gesagt keine Ahnung, wie ein LDIF korrekt aussehen muss. Aber mit dem Tipp sollte ich weiterkommen.

ahrnke · October 8, 2013, 9:25am

In der Wikipedia LDAP_Data_Interchange_Format gibts gute Beispiele.
Hier bitte insbesondere auf die Form der Zeilenumbrüche achten.

cheppo · October 8, 2013, 9:47am

Danke für den Tipp. Nach dem LDAP-Restore habe ich jetzt einen Teilerfolg. Kann wieder den Benutzer-Manager aufrufen und Zarafa läuft auch wieder, sodass ich erstmal die Groupware-Daten der wichtigsten Nutzer via PST-Backup sichern kann.

Richtig rund läuft das System allerdings noch nicht wieder.

1)In der Portalseite fehlt der Link auf Zarafa Webaccess (OK, brauche ich niccht wirklich)
2)Beim Link auf Zarafa WebAPp fehlt das Icon
3)In der Benutzerverwaltung fehlt der Zarafa-Reiter, was vermutlich am beschädigten Zarafa-Schema liegt. Ist vielleicht mit einer Neuinstallation von Zarafa behoben
4)Gleiche Ursache hat vermutlich, dass beim Anlegen eines neuen Benutzers die Vorlage “Zarafa-Nutzer” fehlt, “Zarafa-Shared-Store” gibt es aber.
5)Weitere Auswirkungen konnte ich noch nicht prüfen.

Nachdem ich jetzt diverse Daten sichern kann, scheint das alles nicht mehr schlimm. Frage ist noch, lohnt eine Reparatur 1 bis 4 oder ist eher eine Neuinstallation angesagt?.

Und “By-the-Way”, letztendlich wurde mein System ja ursprünglich “nur” im laufenden Betrieb ausgeschaltet. Auf System/Linux-Seite war mit den Reperaturfähigkeiten des Dateisystems ja auch alles behoben. Bleibt die Frage, ob das LDAP-basierte Konzept beim UCS wirklich robust genug ist, oder bin ich ein Einzelfall?.

cheppo · October 8, 2013, 10:16am

Danke für den Tipp. Nach dem LDAP-Restore habe ich jetzt einen Teilerfolg. Kann wieder den Benutzer-Manager aufrufen und Zarafa läuft auch wieder, sodass ich erstmal die Groupware-Daten der wichtigsten Nutzer via PST-Backup sichern kann.

Richtig rund läuft das System allerdings noch nicht wieder.

1)In der Portalseite fehlt der Link auf Zarafa Webaccess (OK, brauche ich niccht wirklich)
2)Beim Link auf Zarafa WebAPp fehlt das Icon
3)In der Benutzerverwaltung fehlt der Zarafa-Reiter, was vermutlich am beschädigten Zarafa-Schema liegt. Ist vielleicht mit einer Neuinstallation von Zarafa behoben
4)Gleiche Ursache hat vermutlich, dass beim Anlegen eines neuen Benutzers die Vorlage “Zarafa-Nutzer” fehlt, “Zarafa-Shared-Store” gibt es aber.
5)Weitere Auswirkungen konnte ich noch nicht prüfen.

Nachdem ich jetzt diverse Daten sichern kann, scheint das alles nicht mehr schlimm. Frage ist noch, lohnt eine Reparatur 1 bis 4 oder ist eher eine Neuinstallation angesagt?.

Und “By-the-Way”, letztendlich wurde mein System ja ursprünglich “nur” im laufenden Betrieb ausgeschaltet. Auf System/Linux-Seite war mit den Reperaturfähigkeiten des Dateisystems ja auch alles behoben. Bleibt die Frage, ob das LDAP-basierte Konzept beim UCS wirklich robust genug ist, oder bin ich ein Einzelfall?.

ahrnke · October 8, 2013, 11:44am

/var/www/ucs-overview/de.html und ucs-overview/en.html werden aus Templates generiert. ucr commit usw.
Es gibt auch eine UCR-Variable zarafa/webaccess
zarafa4ucs.png müsste in /var/www/icon liegen, wenn nicht, hat es ggf. der fsck nach dem Absturz beräumt.

Das sind extended Attributes die normalerweise im LDAP im Container cn=zarafa,cn=custom attributes,cn=univention,dc=domain,dc=de liegen.

Auch Templates liegen im LDAP, cn=Zarafa Account,cn=templates,cn=univention…
Es wäre sinnvoll, zu prüfen, ob die Daten im Backup waren und ob sie jetzt nach dem Restore wiederhergestellt wurden.

[quote=“cheppo”]
Und “By-the-Way”, letztendlich wurde mein System ja ursprünglich “nur” im laufenden Betrieb ausgeschaltet. Auf System/Linux-Seite war mit den Reperaturfähigkeiten des Dateisystems ja auch alles behoben. Bleibt die Frage, ob das LDAP-basierte Konzept beim UCS wirklich robust genug ist, oder bin ich ein Einzelfall?.[/quote]
Naja, wenn fsck repariert, heißt es nicht automatisch, dass alles gut ist. In diesem Fall wäre ich aus der Ferne noch nicht mal sicher, ob das Plattenimage selbst ok ist.
Was die Robustheit betrifft, würde ich doch behaupten, dass wir nach dem aktuellen Status doch recht weit gekommen sind.

Viele Grüße,
Dirk Ahrnke