Re: ssh-login auf einen Server ohne logind
Hallo Michael,
Am Mittwoch, 24. Februar 2016, 00:06:54 CET schrieb Michael Biebl:
> Am 23.02.2016 um 21:58 schrieb Martin Steigerwald:
> > Das zusammen damit, dass systemd im Rettungs-Modus nicht mal erlaubt, via
> > systemctl oder service den SSH-Daemon zu starten finde ich schon ziemlich
> > heftig. So war das zumindest bei CentOS 7, wo systemd in den RettungsModus
> > wechselte, nachdem ich für /boot als Gerät LABEL=boot in die /etc/fstab
> > eintrug, vergaß das Label zu setzen und dann neu startete. Ich hab den SSH
> > dann allen ernstes mit /usr/bin/sshd manuell gestartet.
>
> 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.
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.
Daher ließ ich systemd dann auch einfach systemd sein und startete den Daemon
direkt.
> 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.
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.
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.
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.
Für alles andere habe ich ein Monitoring oder ich merke das schon selbst,
falls /boot beim Installieren eines Kernels nicht gemountet ist – spätestens
beim Neustart danach :) –, da habe ich auch in den letzten 10 Jahren keinen
Systemd gebraucht, der auf mich aufpasst. Ich brauch einfach keinen Babysitter
auf den Servern, die ich betreue.
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. Und
für NFS auch noch "_netdev".
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. Von einem Bugreport bei Debian habe ich
bislang auch abgesehen, nachdem aus meine Berichte bei CentOS und RedHat
bislang auch keine Ergebnisse brachten.
Ciao,
--
Martin
Reply to: