[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ssh-login auf einen Server ohne logind



On Wed, 24 Feb 2016 00:48:54 +0100, Martin Steigerwald
<martin@lichtvoll.de> wrote:
>Am Mittwoch, 24. Februar 2016, 00:06:54 CET schrieb Michael Biebl:
>> Das ist nicht weiters verwunderlich. Der ssh.service hat (indirekt) eine
>> dependency auf local-fs.target. Wenn dieses target nicht aktiv ist,
>> triggered ein start von ssh.service natürlich auch diese Abhängigkeiten.
>> Könnte ja auch sein, dass /var nicht eingehängt ist und ssh möchte in
>> /var schreiben. Dann möchte man nicht, dass sshd gestarted wird.
>
>Möchte man nicht? Mir wäre das für einen Rettungsversuch ziemlich egal, 
>solange der Daemon ohne /var hochstartet – was ich im Falle von sshd nicht 
>weiß, ob er das tun würde. Ich möchte zuallerst mal, das systemd *genau* das 
>macht, was ich ihm sage, anstatt sich so zu verhalten, als würden die 
>Entwickler besser wissen als ich, was gut für mich ist. Genau mit dieser 
>Haltung, die für mich etwas von Arroganz hat, komme ich bis heute nicht klar.

Genau, dieses "you're doing it wrong" ist einer der größten Turn-Offs
an systemd.

>Bei einem Server, auf den ich üblicherweise über SSH zugreife, möchte ich 
>zuallerst mal, dass der SSH-Daemon läuft, selbst dann, wenn ansonsten die 
>Hälfte kaputt ist.

Genau. Einloggen können, um die Dinge fixen zu können.

>> Wenn man weiss, was man tut, kann man die Abhängigkeiten ignorieren,
>> indem man die systemctl option --job-mode=ignore-dependencies verwendet.
>
>Jup, ich denke, das hast Du oder jemand anderes auf der Debconf auch erwähnt. 
>Mir wäre da allerdings ein "-f" als "Tue was ich sage" lieber, anstatt mir für 
>einen solchen Fall eine dermaßen ausführlich zu schreibende Option zu merken.

Genau. In so einer Situation sich an so ein Kommandozeilenmonster
erinnern zu müssen ist einfach bäh.

>Was für mich einfach ungewohnt ist:
>
>Die Systemd-Entwickler scheinen die Korrektheit des Bootvorgangs mehr zu 
>gewichten, als dass die Kiste überhaupt hochkommt – und das ist halt mal ein 
>deutlich anderes Verhalten als das von Sysvinit.

Zustimmung.

>Ich sehe das anders: Bei Problemen möchte ich, dass der Server solange es 
>irgendwie geht, in ein SSH hinein bootet, damit ich das Problem beheben kann. 
>Für mich ist ein solches Fehler-tolerantes Verhalten ein wichtiger Beitrag für 
>Robustheit – Fehler-tolerante Systeme steigen bei einem Fehler eben nicht 
>gleich ganz aus und funktionieren dann gar nicht mehr. Das ist für mich in 
>vielen Fällen wichtiger als Korrektheit. Anders wäre das für mich nur, bei 
>einer Gefahr des Verlustes wichtiger Daten durch inkorrektes Verhalten.

Zustimmung.

>Ich glaube nach wie vor daran, dass ich als Admin auf dem Server Chef bin und 
>der Computer meine Befehle empfangen und auszuführen hat. Daher toleriere ich 
>nicht, wenn irgendein Programm mir vorzuschreiben versucht, wie ich zu 
>arbeiten habe.

Zustimmung.

Solche Dinge machen auf mich den Eindruck, als hätten die
systemd-Entwickler noch nie außerhalb ihres Heimnetzes gearbeitet,
oder gar irgendwo, wo es auf Verfügbarkeit und schnelle
Wiederanlaufzeit ankommt. Die Welt ist nicht immer "schön", manchmal
muss es einfach nur funktionieren. systemd verändert dies, und zwar in
die falsche Richtung.

>Nun, ich setze einfach für alles, was nicht zum Booten gebraucht wird, 
>mittlerweile überall "nofail", um zumindest in Bezug auf Dateisysteme diesen 
>Effekt zu erreichen, der für mich gesundem Menschenverstand entspricht.

Obacht, das darf man KEINESFALLS auf Dateisystemen tun, die schon im
initramfs eingehängt werden. Denn mount kennt kein "nofail" und
springt dann aus dem Fenster.

Es gibt also in ein und derselben /etc/fstab Zeilen, in denen
KEINESFALLS nofail stehen darf, und Zeilen, in denen nofail stehen
MUSS, damit das system nicht beim kleinsten Problem ohne Netz stehen
bleibt.

Ich bekomme echt den Eindruck, als wollte systemd den Umsatz der
Anbieter von OoB-Zugängen steigern.

>Aber nach meinen Erfahrungen auf systemd-devel halte ich es für vollkommen 
>sinnlos und für eine Verschwendung von Zeit, das Thema bei den Upstream-
>Entwicklern zur Sprache zu bringen.

Ja, auch das ist richtig, da bekommt man höchstens lang und breit
erkläret warum der systemd-Weg der einzige richtige Weg ist und dass
sich der Rest der Welt bitte anpassen möge. Dem lokalen Admin auch nur
die Möglichkeit zu bieten, in einer halbwegs wenig häßlichen Art und
Weise um Macken existierender Software herumzunavigigieren, macht dem
Upstream das Leben schwer und deswegen tut er es nicht. "You're doing
it wrong". "Have your software fixed". Recht schönen Dank.

Grüße
Marc
-- 
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber         |   " Questions are the         | Mailadresse im Header
Mannheim, Germany  |     Beginning of Wisdom "     | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


Reply to: