root-Server hängt sich auf - stundenlange Neuinstallation

Kuckuck · 26 Apr. 2011

Hallo Sportsfreunde,

ich bin Anwendungsentwickler, habe wenig Ahnung von root-Servern. Ich habe trotzdem einen, aber keine Angst, ich habe einen Serveradministrator. Nur eben das ist das Problem: Ich habe etwas das Gefühl, er will mich verarschen oder weiß nicht was er tut.
Deshalb habe ich zwei Fragen von euch:
Ist es prinzipiell möglich, dass der debian-Server sich ohne Ankündigung oder erkennbare Vorzeichen komplett aufhängt und man im Nachhinein nicht oder nur durch ca. 4-5-stündige (noch bevorstehende) Diagnose herausbekommt, woran es liegt?
Ist es normal oder zumindest möglich, dass man für Zugang zum Rescue-System bekommen, einen neuen VServer anlegen und die Daten drüber schieben und konfigurieren 3 Stunden braucht sowie 5 weitere um die Dienste (bei mir läuft ein normaler Webserver mit MySQL-DB) normal zum Laufen zu bekommen? Er schreibt zum Beispiel

ich habe versucht selber an den Server und die Daten zu kommen, das hat aufgrund fehlerhafter Daten nicht funktioniert. Zeitaufwand ca 1h

Der Server war dann inkl. Nacht knapp 36 Stunden offline. Das würde bei managed Servern bzw. bei professionellen Serverbetreuern doch schneller laufen, oder?

Danke für eure Anregungen im Voraus

spoensche · 26 Apr. 2011

Kuckuck schrieb:
Hallo Sportsfreunde,
Ist es prinzipiell möglich, dass der debian-Server sich ohne Ankündigung oder erkennbare Vorzeichen komplett aufhängt und man im Nachhinein nicht oder nur durch ca. 4-5-stündige (noch bevorstehende) Diagnose herausbekommt, woran es liegt?
[/code]

Es ist möglich, dass ein Server ohne Vorzeichen abschmiert. Wie lange es dauert, bis das wieso des Absturz und die genaue Ursache geklärt ist, ist von dem Problem abhängig. Wenn sich ein vServer (virtueller Server) ohne Gründe verabschiedet, ist der vServer entweder total Verkonfiguriert, die Ressourcen werden knapp oder beim Hoster stimmt was nicht.

Kuckuck schrieb:

Ist es normal oder zumindest möglich, dass man für Zugang zum Rescue-System bekommen, einen neuen VServer anlegen und die Daten drüber schieben und konfigurieren 3 Stunden braucht sowie 5 weitere um die Dienste (bei mir läuft ein normaler Webserver mit MySQL-DB) normal zum Laufen zu bekommen?

Zum Vergrößern anklicken....

Ein Server, egal ob vServer, root Server etc., ist nicht mal eben zu konfigurieren. Unter Beachtung der Systemsicherheit inkl. testen, ob der Server auch wirklich dicht ist und den Stellschrauben für eine performante Datenbank, einen performanten Webserver usw. können da schon einige Stunden und mehr vergehen, vor allem dann, wenn man kein Backup hat, wenn man eins hat die Rücksicherung vorher nicht getestet hat oder man an das Backup nicht mehr heran kommt.

Kuckuck schrieb:

Er schreibt zum Beispiel

ich habe versucht selber an den Server und die Daten zu kommen, das hat aufgrund fehlerhafter Daten nicht funktioniert. Zeitaufwand ca 1h

Zum Vergrößern anklicken....

Dann frag ihn doch mal, was für fehlerhafte Daten sein sollen, welche Fehlermeldungen auftraten etc.

Kuckuck schrieb:

Der Server war dann inkl. Nacht knapp 36 Stunden offline. Das würde bei managed Servern bzw. bei professionellen Serverbetreuern doch schneller laufen, oder?

Zum Vergrößern anklicken....

Zum Vergrößern anklicken....

Wenn sie kein aktuelles Backup haben sollten oder an dieses nicht herankommen, was aber sehr unwahrscheinlich ist, da i.d.R. immer noch ein Backup vom Backup existiert, schon.

Lass dir mal Logfiles etc. geben.

Kuckuck · 27 Apr. 2011

Danke für deine Antwort.
Also er antwortete auf die Fragen, welche Fehlermeldung und Logs er erhielt und um welche fehlerhaften Daten es sich handelt:

Für mich sah es zu dem Zeitpunkt eher nach einem Hardware-Defekt aus. Ich habe fehlermeldungen bekommen, habe dies jedoch an Hetz.ner zum Überprüfen der Hardware abgegeben.

Er schreibt diverse "Systemprogramme" wie z.B. "mv" liesen sich nicht mehr korrekt ausführen.
In den Logfiles konnte er beim Überprüfen nichts besonderes feststellen, hätte aber dort auch nicht intensiv gesucht.

Nachdem Hetz.ner die Systeme im Rescue booten konnte, waren ALLE Logfiles nur noch leere Dateien. Dort kann ich leider nichts mehr finden.

Jägerschlürfer · 27 Apr. 2011

also für mich sind die Aussagen schon sehr schwammig. Du schreibst dein Admin hat die Fehlermeldungen an Hetz.ner übergeben. Wie hat er das gemacht? Per Telefon? per Mail? Wenn per Mail, sollte er diese ja noch haben.
Auch die Sache mit den Logfiles kann ich nicht wirklich glauben. In den Logfiles sollte immer was stehen. Es kann zwar sein, dass nicht mehr alle Daten vorhanden sind (je nachdem was Hetz.ner gemacht hat) aber dass diese leer sind, denke ich nicht.
Ich würde mal hergehen und selbst mal bei Hetz.ner nachfragen, was diese gemacht haben bzw. welche Probleme vorlagen.

whois · 28 Apr. 2011

spoensche schrieb:
Wenn sie kein aktuelles Backup haben sollten oder an dieses nicht herankommen, was aber sehr unwahrscheinlich ist, da i.d.R. immer noch ein Backup vom Backup existiert, schon.
.

..und da fängt die Nachtigall zu trapsen an.

Wer macht den heute kein Backup mehr wenn es um sensible Server Daten geht und sei es nur um die logs im nachhinein zu interpretieren?

Ich kenne keinen Admin der was auf sich hält, und sei es nur aus technischer Neugierde, das klingt doch mehr nach gewollt und nicht gekonnt....

Kuckuck · 28 Apr. 2011

Die Daten wir Scripte und Datenbanken sind immerhin ohne Datenverluste erhalten geblieben. Ihr meint jetzt ein Backup zum Zeitpunkt vor dem Absturz, um aus dieser Zeit die Logs zu lesen?

Ich würde mal hergehen und selbst mal bei Hetz.ner nachfragen, was diese gemacht haben bzw. welche Probleme vorlagen.

Da ich meinen Vertrag wiederum mit einer anderen Firma habe, die den Server gemietet hat und ich nicht weiß, was ich fragen soll bzw. was ich mit den Antworten machen soll, frage ich am besten meinen Admin weiter aus. Ich habe ihn nun gefragt welche Fehlermeldungen denn kamen und was er an den Provider weitergegeben hat. Mal sehen was er schreibt.

spoensche · 28 Apr. 2011

Nein, ein Backup um den letzten aktuellen Stand wiederherstellen zu können. Das ist normalerweise das vom Vortag. Interessante Logs sind:

/var/log/messages, /var/log/auth.log, /var/log/apache2/error.log und access.log, /var/log/kern.log, die Lofiles des DB-Servers liegen unter/var/log/mysql

Frag selbst bei Hetzner nach.

Kuckuck · 3 Mai 2011

Hi

spoensche schrieb:
Frag selbst bei Hetzner nach.

Das werde ich morgen machen, auch wenn es leider etwas kompliziert wird.

Der Sysadmin hat sich heute das System nochmal angeschaut. Meine Seiten laufen ja seit dem Vorfall auf einem Ersatzserver.
Er bekäme den

Systemadministrator schrieb:
Möglich wäre ein Fehler bei der Raid-Syncronisierung. Leider kann ich mehr zu diesem Fehler nicht sagen

Die Hardware-Checks seien jedoch alle in Ordnung und im Prinzip könnten wir einfach das System neu installieren.

spoensche · 3 Mai 2011

Kuckuck schrieb:
Der Sysadmin hat sich heute das System nochmal angeschaut. Meine Seiten laufen ja seit dem Vorfall auf einem Ersatzserver.
Er bekäme den

Error 17 ist eine Fehlermeldung von Grub.

17 : "Invalid device requested"

This error is returned if a device string is recognizable but does not fall under the other device errors.

Systemadministrator schrieb:
Möglich wäre ein Fehler bei der Raid-Syncronisierung. Leider kann ich mehr zu diesem Fehler nicht sagen

:???: Was hat der Bootloader mit der RAID Synchronisation, die RAID- Controller, bzw. das Software-RAID durchführt zu tun? Nichts. Wenn Hardware- Probleme, sei es RAID- Controller, bzw. oder Festplatten, dann hätte der Kernel das gemeldet und es würden entsprechende Einträge in den Logfiles existieren. mdadm (Software-RAID) hätte sich auch bemerkbar gemacht, wenn etwas nicht "rund" läuft.

Was für ein RAID wird den im Server verwendet? Software-RAID, oder richtiges Hardware-RAID?

Kuckuck schrieb:
Die Hardware-Checks seien jedoch alle in Ordnung und im Prinzip könnten wir einfach das System neu installieren.

Frag mal nach, was er für Hardware-Checks gemacht und lass dir die Ausgaben geben. Tu dir vorallem selber den Gefallen und frag bei Hetzner nach.

Kuckuck · 4 Mai 2011

Danke

Ich habe ihm die Fragen in anderem Wortlaut gestellt.

Systemadministrator schrieb:
Der Bootloader hat Probleme auf die Configuration zuzugreifen. Ich habe diesen neu geschrieben und immernoch kann dieser nicht booten.

Logfiles würden nicht geschrieben, alle Logfiles seien leer.

Systemadministrator schrieb:
Bei einem Bootversuch (ich hatte gestern abend auch noch eine KVM dran) kommt der auch nur bis zu Grub und nicht weiter.

Im Server wird ein Hardware-Raid verwendet.
Die Hardware-Checks habe er gemacht, was in der Recovery-Console von Hetz.ner möglich ist/war. Dort habe er alles durchlaufen lassen, was es gab und nichts hätte Fehler erzeugt.

Also bei Hetz.ner frage ich heute am besten nach einem kompletten Backup oder was der Typ ihnen gemeldet hat oder nach den erwähnten Logdateien?

spoensche · 4 Mai 2011

Leere Logdateien sind bei dem Fehler eine ganz ganz schlechte Ausrede, weil die Logfiles nicht gelöscht werden und zumindest die Logdateien vom Vortag vorhanden sind. Wenn er den Syslog deaktiviert hat o.ä. dann ist es kein Wunder, wenn eine Fehlersuche lange dauert und eine Erkennung von Angriffen ist auch nicht mehr wirklich möglich.

Wenn es tatsächlich leere Logdateien gibt, dann sollte man mal prüfen, ob sich nicht jemand auf dem Server ausgetobt hat, der eigentlich keinen Zugriff hat.

Warum hat er nicht per Grub-Shell gebootet? Da stimmt bestimmt die Angabe der Root- Partition nicht.

Beispiel 1.Festplatte, 1. Partition:

Code:

root (hd0,0)
kernel /boot/vmlinuz root=/dev/sda1
initrd /boot/initrd
boot

und siehe da der Rechner bootet und eine Neuinstallation ist unnötig.

Kuckuck · 4 Mai 2011

Ich habe den Provider heute noch nicht erreicht.

Ich habe ihn jetzt so auf die leeren Logfiles angesprochen wie du geschrieben hast.
Er schreibt nun dazu:

Systemadministrator schrieb:
Das letzte Logfile, welches lesbar ist ist von September oder Oktober. Syslog war nicht deaktiviert, jedoch sind alle Logfiles weg. Ich weiß ehrlich gesagt nicht, warum. Ich weiß, dass ich definitiv im Februar mir ein paar Logs angesehen hatte wegen irgendetwas.

Zum Booten des Grub-Shell schreibt er, er habe es versucht, leider erfolglos.

Hm, bin mal gespannt wie es weitergeht. Er will ja bald den Server neu installieren und ich bin mir natürlich gar nicht sicher ob er das weiter managen soll.

spoensche · 5 Mai 2011

Die Logfiles das letzte mal im Februar überprüft und nicht gehandelt? :schockiert:

Das sollte man min. 1x am Tag machen, besser mehrmals oder autom. e-Mail Benachrichtigung, bei Fehlern etc.

Auf einmal keine Logfiles mehr bzw. leere Logfiles und die Alarmglocken fangen nicht an zu klingeln?? Da bin ich absolut fassungslos Sprachlos.

Kuckuck · 23 Mai 2011

Doch, Alarmglocken klingelten.
Adminzusammenarbeit ist beendet. Die Firma, die das Management übernimmt, hat vom alten System die Logs gesichert (waren nun doch da) und mir zugeschickt. Server ist im Rescue und wird dann von der neuen Firma bald neu installiert.
Der alte Serveradmin hat mir eine Rechnung für 12 Stunden über 190 Euro geschickt (vorher 240, aber 50 Euro "Abschiedsgeschenk").
Da lohnt es sich doch auch nochmal in den Logs zu schauen, ob ein Vorsatz oder Schlampigkeit vorliegt?

spoensche · 23 Mai 2011

Es ist schon verwunderlich, dass die Logfiles da waren und dies verneint worden ist. Möglicherweise waren die Dateien auf den ersten Blick nicht zu sehen. Allerdings sind gelöschte Dateien trotzdem noch auf der Platte vorhanden und können mit den passenden Tools wiederhergestellt werden.

Ich denke nicht, dass ein Vorsatz oder Schlamperei vorliegt.

Die Logs würde ich mir trotzdem genau ansehen, um die Ursache zu identifizieren.

Kuckuck · 23 Mai 2011

Ich verstehe.
Danke auf jeden Fall für die Hilfe.
Ich denke das Forum noch wegen Hilfe zur Ursachenforschung in den Logs zu beanspruchen sprengt den Rahmen und ist nicht Sinn der Sache. Weil ich alleine mit den Logs aber nichts anfangen kann, überweise ich dem Typen einfach das Geld und habe dann meine Ruhe. :igitt:

Jägerschlürfer · 24 Mai 2011

Kuckuck schrieb:
Ich denke das Forum noch wegen Hilfe zur Ursachenforschung in den Logs zu beanspruchen sprengt den Rahmen und ist nicht Sinn der Sache. Weil ich alleine mit den Logs aber nichts anfangen kann, ...

also mich würde es interessieren,...
und du lernst so sicher auch das ein oder andere dazu.

Kuckuck · 24 Mai 2011

Das auf jeden Fall.

Jetzt weiß ich nur nicht welche Logs ich bedenkenlos veröffentlichen kann (also keine Zugangsdaten o.ä. beinhalten).
Viele Dateien sind tatsächlich leer, wie die messages, aber dann gibt es immer eine .1 dahinter, in der etwas drinsteht.

Hier der Beginn der messages.1:

Sep 26 06:25:18 srv1 kernel: imklog 3.18.6, log source = /proc/kmsg started.
Sep 26 06:25:18 srv1 rsyslogd: [origin software="rsyslogd" swVersion="3.18.6" x-pid="2547" x-info="http://www.rsyslog.com"] restart
Sep 27 06:25:14 srv1 kernel: imklog 3.18.6, log source = /proc/kmsg started.
Sep 27 06:25:14 srv1 rsyslogd: [origin software="rsyslogd" swVersion="3.18.6" x-pid="2547" x-info="http://www.rsyslog.com"] restart
Sep 28 06:25:12 srv1 kernel: imklog 3.18.6, log source = /proc/kmsg started.
Sep 28 06:25:12 srv1 rsyslogd: [origin software="rsyslogd" swVersion="3.18.6" x-pid="2547" x-info="http://www.rsyslog.com"] restart
Sep 29 06:25:17 srv1 kernel: imklog 3.18.6, log source = /proc/kmsg started.
Sep 29 06:25:17 srv1 rsyslogd: [origin software="rsyslogd" swVersion="3.18.6" x-pid="2547" x-info="http://www.rsyslog.com"] restart
Sep 30 06:25:19 srv1 kernel: imklog 3.18.6, log source = /proc/kmsg started.
Sep 30 06:25:19 srv1 rsyslogd: [origin software="rsyslogd" swVersion="3.18.6" x-pid="2547" x-info="http://www.rsyslog.com"] restart
Sep 30 17:00:38 srv1 shutdown[31065]: shutting down for system reboot
Sep 30 17:00:47 srv1 kernel: Kernel logging (proc) stopped.
Sep 30 17:02:50 srv1 kernel: imklog 3.18.6, log source = /proc/kmsg started.
Sep 30 17:02:50 srv1 rsyslogd: [origin software="rsyslogd" swVersion="3.18.6" x-pid="2554" x-info="http://www.rsyslog.com"] restart
Sep 30 17:02:50 srv1 kernel: [ 0.000000] Initializing cgroup subsys cpuset
Sep 30 17:02:50 srv1 kernel: [ 0.000000] Initializing cgroup subsys cpu
Sep 30 17:02:50 srv1 kernel: [ 0.000000] Linux version 2.6.30 (root@linux-build) (gcc version 4.3.2 (Debian 4.3.2-1.1) ) #1 SMP Fri Sep 4 05:34:40 CDT 2009
Sep 30 17:02:50 srv1 kernel: [ 0.000000] Command line: root=/dev/sda1 ro
Sep 30 17:02:50 srv1 kernel: [ 0.000000] KERNEL supported cpus:
Sep 30 17:02:50 srv1 kernel: [ 0.000000] Intel GenuineIntel
Sep 30 17:02:50 srv1 kernel: [ 0.000000] AMD AuthenticAMD
Sep 30 17:02:50 srv1 kernel: [ 0.000000] Centaur CentaurHauls
Sep 30 17:02:50 srv1 kernel: [ 0.000000] BIOS-provided physical RAM map:

So geht es dann noch etwas weiter, zeitlich bewegt es sich aber aus dem 30. Sep nicht mehr in diesem Log heraus.

Ähnliche Zeitstempel gibt es auch in auth.log.1 und kern.log.1.
Im error.log geht es tatsächlich noch bis kurz vor dem Absturz, dort sehe ich aber nur gewöhnliche Meldungen wie File does not exist.

:???:

spoensche · 24 Mai 2011

Bedenklich wären Benutzernamen, Passwörter etc.

Die letzten Zeilen der "messages" sind die Kernelausgaben beim Systemstart. Wäre praktisch, wenn du den Inhalt der Datei mal bei http://pastebin.com reinstellen und den Link hier posten würdest.

In der auth.log werden die Anmeldungen und Anmeldeversuche protokolliert. Da in der Datei auch Usernamen enthalten sind postest du sie besser nicht. In der auth.log solltest du prüfen, ob die Benutzernamen auch auf dem System existieren. Benutzernamen, die häufig Anmeldeversuche im Minutentakt aufweisen kann ein Hinweis auf Brute-Force Angriffe sein.

Die kern.log enthält nur Ausgaben des Kernels.

Die error.log und die access.log kannst du posten.

nbkr · 24 Mai 2011

Kuckuck schrieb:
Der alte Serveradmin hat mir eine Rechnung für 12 Stunden über 190 Euro geschickt (vorher 240, aber 50 Euro "Abschiedsgeschenk").
Da lohnt es sich doch auch nochmal in den Logs zu schauen, ob ein Vorsatz oder Schlampigkeit vorliegt?

Unabhängig von der tatsächlichen Fehlerursache: 20 Euro / Stunde sind absolute Dumpingpreise - ist nicht unbedingt verwunderlich dass der Admin nicht konnte oder wollte.

root-Server hängt sich auf - stundenlange Neuinstallation

Newbie

Moderator

Newbie

Moderator

Ultimate Guru

Newbie

Moderator

Newbie

Moderator

Newbie

Moderator

Newbie

Moderator

Newbie

Moderator

Newbie

Moderator

Newbie

Moderator

Guru