root-Server hängt sich auf - stundenlange Neuinstallation

[Kuckuck]

Prima, langsam bekomme ich schonmal einen Überlich über die Struktur der Logdateien.

Hier die messages:
http://pastebin.com/8FbQ6SCD

In der auth.log.1 sieht nichts verdächtig aus. Aber wie gesagt, die Einträge dort sind mit dem Monat September datiert.

Eine error.log sehe ich nicht, auch eine access.log ist zwischen den ganzen Dateien nicht zu finden.

 

[spoensche]

md: faulty personality registered for level -5

Da haben wir doch schon einen Verdächtigen und man sollte jetzt analysieren, was die Ursache ist. Mögliche Ursache kann ein Faulty RAID-Device sein.

EDIT:

Ich habe gerade noch Tante G bemüht. Im Kernel 2.6.30 bzw. mdadm existiert ein Bug. Ein Kernel bzw. mdadm Update hätte abhilfe geschaffen.

Welche Logfiles stehen dir den zur Verfügung?

 

[Kuckuck]

Im Kernel 2.6.30 bzw. mdadm existiert ein Bug. Ein Kernel bzw. mdadm Update hätte abhilfe geschaffen.

Ist das Update auch möglich, nachdem der Server wie beschrieben nicht mehr bootet? Oder ist das die Konsequenz dessen dass man sich lange nicht um Updates gekümmert hat?

Welche Logfiles stehen dir den zur Verfügung?

Hier die Dateiliste aus dem Logordner, welcher mir der Provider hochgeladen hat:

• 26.05.2011 13:51 <DIR> .
  26.05.2011 13:51 <DIR> ..
  23.05.2011 13:46 <DIR> apache2
  23.05.2011 13:46 <DIR> apt
  23.05.2011 13:46 <DIR> exim4
  23.05.2011 13:46 <DIR> fsck
  23.05.2011 13:46 <DIR> installer
  23.05.2011 13:46 <DIR> mysql
  23.05.2011 13:46 <DIR> news
  23.05.2011 13:46 <DIR> ntpstats
  23.05.2011 13:51 <DIR> proftpd
  21.08.2009 15:43 0 aptitude
  21.08.2009 15:17 31 boot
  01.04.2011 07:25 0 btmp
  03.10.2010 07:25 0 debug
  30.09.2010 18:02 50.738 dmesg
  25.08.2010 08:57 64.064 faillog
  21.04.2011 12:02 584.584 lastlog
  03.10.2010 07:25 0 messages
  01.10.2010 07:25 0 syslog
  21.04.2011 12:20 80.256 wtmp
  17.09.2010 05:24 50.765 dmesg.0
  30.09.2010 23:40 287.363 auth.log.1
  30.09.2010 23:44 13.913 daemon.log.1
  30.09.2010 18:03 17.684 debug.1
  19.03.2011 14:59 8.598 dpkg.log.1
  10.04.2011 07:25 0 fail2ban.log.1
  30.09.2010 18:03 75.639 kern.log.1
  17.09.2010 17:18 126 mail.err.1
  30.09.2010 18:02 24.053 mail.info.1
  30.09.2010 18:02 24.053 mail.log.1
  22.09.2010 17:18 52.865 mail.warn.1
  30.09.2010 18:03 58.715 messages.1
  30.09.2010 23:44 97.908 syslog.1
  30.09.2010 18:00 70 user.log.1
  18.09.2010 07:25 0 mail.err
  13.02.2011 20:57 0 mysql.err
  26.09.2010 07:25 23.118 auth.log.2.gz
  19.09.2010 07:25 23.185 auth.log.3.gz
  12.09.2010 07:25 16.295 auth.log.4.gz
  28.03.2011 07:25 20 btmp.1.gz
  26.09.2010 06:17 1.530 daemon.log.2.gz
  19.09.2010 06:40 2.505 daemon.log.3.gz
  12.09.2010 06:51 1.378 daemon.log.4.gz
  25.09.2010 00:47 1.438 debug.2.gz
  19.09.2010 02:09 3.471 debug.3.gz
  09.09.2010 19:30 218 debug.4.gz
  27.08.2010 03:26 13.914 dmesg.1.gz
  09.03.2010 00:30 12.391 dmesg.2.gz
  23.01.2010 01:53 12.411 dmesg.3.gz
  23.01.2010 01:14 12.345 dmesg.4.gz
  15.02.2010 21:59 750 dpkg.log.10.gz
  25.01.2010 12:04 5.894 dpkg.log.11.gz
  14.02.2011 01:49 6.972 dpkg.log.2.gz
  15.12.2010 15:25 515 dpkg.log.3.gz
  11.12.2010 12:39 1.625 dpkg.log.4.gz
  01.10.2010 00:16 1.691 dpkg.log.5.gz
  21.09.2010 21:21 195 dpkg.log.6.gz
  15.07.2010 21:20 3.555 dpkg.log.7.gz
  05.05.2010 10:41 164 dpkg.log.8.gz
  07.04.2010 19:13 220 dpkg.log.9.gz
  03.04.2011 07:25 20 fail2ban.log.2.gz
  28.03.2011 07:25 20 fail2ban.log.3.gz
  20.03.2011 07:25 20 fail2ban.log.4.gz
  26.09.2010 07:25 1.538 kern.log.2.gz
  19.09.2010 07:25 14.231 kern.log.3.gz
  12.09.2010 07:25 307 kern.log.4.gz
  26.09.2010 07:25 71.153 mail.info.2.gz
  19.09.2010 07:25 101.460 mail.info.3.gz
  12.09.2010 07:25 4.212 mail.info.4.gz
  26.09.2010 07:25 71.153 mail.log.2.gz
  19.09.2010 07:25 101.460 mail.log.3.gz
  12.09.2010 07:25 4.212 mail.log.4.gz
  19.09.2010 07:19 1.236 mail.warn.2.gz
  18.09.2010 07:18 878 mail.warn.3.gz
  17.08.2010 00:20 157 mail.warn.4.gz
  26.09.2010 07:25 246 messages.2.gz
  19.09.2010 07:25 11.275 messages.3.gz
  12.09.2010 07:25 251 messages.4.gz
  20.04.2011 07:25 20 mysql.log.1.gz
  19.04.2011 07:25 20 mysql.log.2.gz
  18.04.2011 07:25 20 mysql.log.3.gz
  17.04.2011 07:25 20 mysql.log.4.gz
  16.04.2011 07:25 20 mysql.log.5.gz
  15.04.2011 07:27 20 mysql.log.6.gz
  14.04.2011 07:25 20 mysql.log.7.gz
  30.09.2010 07:25 2.625 syslog.2.gz
  29.09.2010 07:25 3.042 syslog.3.gz
  28.09.2010 07:25 3.255 syslog.4.gz
  27.09.2010 07:25 2.868 syslog.5.gz
  26.09.2010 07:25 3.077 syslog.6.gz
  25.09.2010 07:25 2.766 syslog.7.gz
  17.09.2010 05:07 82 user.log.2.gz
  08.03.2010 23:12 81 user.log.3.gz
  23.01.2010 00:22 94 user.log.4.gz
  01.04.2011 03:15 838 wtmp.1.gz
  03.10.2010 07:25 0 mail.info
  03.10.2010 07:25 0 auth.log
  03.10.2010 07:25 0 daemon.log
  20.03.2011 07:25 0 dpkg.log
  17.04.2011 07:25 0 fail2ban.log
  13.02.2011 21:45 856 fontconfig.log
  03.10.2010 07:25 0 kern.log
  21.08.2009 15:23 0 lpr.log
  03.10.2010 07:25 0 mail.log
  21.04.2011 07:25 0 mysql.log
  21.08.2009 15:20 0 pycentral.log
  01.10.2010 07:25 0 user.log
  26.05.2011 13:52 0 dateien.txt
  26.09.2010 07:25 0 mail.warn

 

[nbkr]

Wenn du dich ins Rescuesystem einloggen kannst mittles "chroot" ins alte System wechseln kannst, sollte auch ein Update möglich sein. Ist mehr die Frage ob du noch zugriff auf die Platte hast, wenn es das Raid zerissen hat. Notfalls müsste man das Raid halt erst wieder flicken.

 

[spoensche]

Ist das Update auch möglich, nachdem der Server wie beschrieben nicht mehr bootet? Oder ist das die Konsequenz dessen dass man sich lange nicht um Updates gekümmert hat?

Zum Update wurde ja schon was geschrieben. Ein Bug ist nicht unbedingt die Konsequenz von nicht durchgeführten Updates. Aus sicherheitstechnischer Sicht sind nicht durchgeführte Updates allerdings an Fahrlässigkeit und Verantwortungslosigkeit nur noch durch ein total offenes System zu toppen.

Hier die Dateiliste aus dem Logordner, welcher mir der Provider hochgeladen hat:

Die Dateien daemon.log, mail.warn, kern.log, dmesg, syslog und sofern vorhanden die Logs von exim, proftpd, fsck interessant. In mysql sind vermutlich die binären Logs von MySQL, die als Backup verwendet werden können.

 

[Kuckuck]

Hmm, das ist interessant was ihr da schreibt.

Zu den weiteren Logs:
daemon.log.1 ist leider auch vom 30. Sept.: http://pastebin.com/kHz0iPbf

In mail.warn.1 steht viele Male die folgende Zeile mit anderer Nummer in den eckigen Klammern:

Sep 22 16:18:24 srv1 sm-mta[27122]: STARTTLS=client, error: connect failed=0, SSL_error=5, errno=0, retry=-1

kern.log.1: http://pastebin.com/2WRUU5Fg
dmesg: http://pastebin.com/07T3WJ7Q
syslog.1: http://pastebin.com/txGwQfNU
exim4/mainlog.1: http://pastebin.com/ikNfmMXu
fsck/checkroot: http://pastebin.com/Njz6kbbZ
Der Log-Ordner mysql ist leer. Die Datenbanken und sonstige Dateien sind soweit auch erhalten geblieben.

Wenn du dich ins Rescuesystem einloggen kannst mittles "chroot" ins alte System wechseln kannst, sollte auch ein Update möglich sein. Ist mehr die Frage ob du noch zugriff auf die Platte hast, wenn es das Raid zerissen hat. Notfalls müsste man das Raid halt erst wieder flicken.

Der Server steht zur Zeit noch im Rescue. Die Festplatten des Raidsystems sind gemountet.
Ich muss schauen ob ich mich heute etwas einlesen kann zu chroot & Co. Ich glaube schlauer ist eh eine Neuinstallation vom zukünftigen Administrator, sodass das Rumspielen auf dem alten System eher Lernzwecke hat und um zu prüfen ob der vorige Admin so fahrlässig war dass er auf einen Teil seines Honorares verzichten soll (was mir so scheint).

 

[spoensche]

Die restlichen Logfiles sehen in Ordnung aus. In der dmesg. log taucht die Meldung vom faulty RAID auch auf. dmesg ist ein Programm, dass den Inhalt des Kernelringbuffers ausgibt, also die Meldungen, die auch in der kern.log und der dmesg.log stehen.

Die Ursache der SSL Meldung, aus der mail.warn, ist ein e-Mail Client, der sich vermutlich über Port 465 (SMTP over TLS, smtps) verbinden will. STARTLS arbeitet aber mit Port 25.

Es besteht keine Fahrlässigkeit. Ein faulty RAID kündigt sich nicht zwangsläufig an, sondern tritt plötzlich auf. Man setzt dann das fehlerhafte Device auf fault bzw failed, sofern das nicht schon geschehen ist und wechselt es aus. Den Rest macht das RAID i.d.R. autom.

 

[Kuckuck]

Oki danke auch für diese Info

Aus sicherheitstechnischer Sicht sind nicht durchgeführte Updates allerdings an Fahrlässigkeit und Verantwortungslosigkeit nur noch durch ein total offenes System zu toppen.

Es besteht keine Fahrlässigkeit. Ein faulty RAID kündigt sich nicht zwangsläufig an, sondern tritt plötzlich auf. Man setzt dann das fehlerhafte Device auf fault bzw failed, sofern das nicht schon geschehen ist und wechselt es aus.

Wie viel Arbeitsaufwand ist so ungefähr nötig, wenn man u.a. das Device auswechselt und das System den Rest machen lässt? Rechtfertigt das eine stundenlange Neuinstallation?

 

[spoensche]

Wie viel Arbeitsaufwand ist so ungefähr nötig, wenn man u.a. das Device auswechselt und das System den Rest machen lässt? Rechtfertigt das eine stundenlange Neuinstallation?

Wie schon erwähnt, hatten schon mehrere Anwender, in einigen Foren, das selbe Problem, dass durch ein Kernelupdate behoben werden konnte. Das Kernelupdate sollte also der erste Schritt sein.

Durch eine Neuinstallation wird man den Bug nicht los, weil man dann i.d.R. den selben Kernel mit dem selben Bug weiter in Betrieb hat und es nur eine Frage der Zeit ist, bis der Fehler wieder auftritt.

Im Rescue System mountest du deine Rootpartition nach /mnt.

mount /dev/root-part /mnt

Für root-part musst du die Gerätedatei der Partition verwenden, z.B. /dev/sda1.

Danach gehst du wie folgt vor:

chroot /mnt
apt-get update
apt-get upgrade
exit

Bei "apt-get upgrade" darauf achten, dass ein Kernelupdate mit dabei ist. Wenn nicht, musst du danach

apt-get install kernel-image-server
exit

Danach mit

reboot

einen Neustart durchführen.