Rechner mit Debian10 immer Online/Laufend halten, welche Möglichkeiten gäbe es?

[ren22]

Hallo,

was für Möglichkeiten gibt es den, wenn man ein frisch aufgesetztes Debian10(stable) amd64 installiert hat und man dann anfängt den Rechner zu konfigurieren,
gerade ebend habe ich an der Netzwerkkonfiguration gefummelt, via ssh, und nach dem Befehl "sudo systemctl restart networking" war der Rechner nicht mehr zu erreichen, ein Neustart per physischen druck auf den reset Schalter brachte aber dann das System wieder zu Tage.
So, nun frage ich mich was man machen könnte, dass der Rechner "quasi" selber merkt, ah da ist eine Fehlkonfiguration, bin nicht mehr erreichbar oder so ännlich, ich starte mich mal neu, allerdings würde mir ein cronjob der alle 1 Stunde den Rechner neustartet auch nicht so viel bringen da ich auf dem System auch noch den Kernel backen möchte, und das dauert auf einem Q6600@2.40Ghz (4cores) schon ein wenig länger als eine Stunde. Was macht ihr den so wenn ihr eine Büchse per ssh einrichten müsst um euch abzusichern das der Rechner auch immer erreichbar ist, auch wenn mal ein Fehler passiert sollte beim konfigurieren... weil, manchmal steht der Rechner ja auch mal in einer anderen Stadt oder so ...

Vielen Dank

[MSfree]

auch wenn mal ein Fehler passiert sollte beim konfigurieren...

Öhm, keine Fehler beim Konfigurieren machen?

Aber mal ernsthaft, wie soll das gehen? Wenn du die Konfiguration vermurkst hast, kommt man nur noch mit Maus und Tastatur ran, da hilft auch ein Reboot nicht.

Wenn Murphy zuschlägt, bist du auf Maus und Tastatur angewiesen. Oder auf einen Bekannten, der telefonisch instruiert in die Tasten haut, wenn die Kiste in einer anderen Stadt steht.

Internethoster bieten in der Regel Rettungskonsolen an, über die man die Kisten erreichen kann, aber sowas bedingt ebenfalls Konfigurationaufwand der schief gehen kann.

[Roonix]

Für den Fall benötigst du z.B. iKVM Zugang wie es bei Supermicro Boards über das IPMI Interface möglich ist, oder bei IBM Server über das Integrated Management Module (IMM). VNC ist bei virtuellen Maschinen auch ein probates Mittel.
Ansonsten bleibt dir nur der rein physische Zugang zum Server. Konfigurationen am Netzwerk, das schließt iptables/iptables-persistent mit ein, und SSH sollten generell nicht über SSH vorgenommen werden. Egal wie gut man sich auskennt, jeder kann mal einen Tippfehler o.ä. unterbringen und schon ist man weg!

[ThorstenS]

Eine Konfigurationsmanagement Software, die sich updates im pull Verfahren selbst zieht/aktualisiert, kann dich retten¹.
Ich habe das lange mit cfengine und seit ein paar Jahren mit ansible umgesetzt. Die meisten Menschen nutzen ansible im push Verfahren, aber das scheitert, wenn der Horst nicht mehr erreichbar ist…
Wenn du festlegst welche Pakete mit welchen Konfigurationsdateien im System vorhanden sein sollen (und die Netzwerkkonfiguration ist auch scriptbar), dann bist du schon auf der sicheren Seite.
Ein watchdog, der bei Nichterreichbarkeit eines hosts per ping eine Aktion (Script oder reboot) auslöst, kann dir auch helfen auf bestimmte Fehler angemessen zu reagieren.

Generell aber solltest du bei deinen Systeme nicht am offenen Herzen operieren. vagrant kann ansible scripte triggern. Gewöhn dir an alle Änderungen mit ansible/puppet/salt/youNameIt zu automatisieren und dann an einer VM mit z.B. vagrant auszuprobieren, bevor die live gehst.

[uname]

Schau dir mal tmux bzw. screen an. Das löst dein Remote-Netzwerk-Problem über SSH.

[TRex]

Es ist beispielsweise bei manuellen Änderungen an iptables üblich, mit cron oder so iptables -F auszuführen, um die Regeln zurückzusetzen (oder ein Script, das den vorigen Zustand gleich mit wiederherstellt). Universell anwendbar ist das Konzept, aber so wie bei iptables kann dir niemand sagen, was der gewünschte Zustand sein soll, nachdem du ihn verändert hast. Mir fällt da noch etckeeper ein, was man dafür verwenden könnte... aber wenn du z. B. irgendwas dummes tust, was die Platte zumüllt, was soll dann passieren? mkfs auf die volle Partition?

Die Spur ansible/salt/puppet/...${configmanagementtool} ist toll, aber sehr aufwändig, und kann nur abdecken, was du explizit dort einträgst. Für Spielereien zuhause größtenteils überdimensioniert. Nicht, dass mich das bisher davon abgehalten hätte... aber dadurch weiß ich eben, dass es quasi nicht wartbar ist.