Boycott Systemd

Status
Für weitere Antworten geschlossen.
Und Gründe warum irgend ein Dienst wegsterben kann sind halt so vielfältig, da ist es einfach billiger und einfacher das System redundant und selbstheilend aufzubauen.

Es ist nicht nur einfacher und billiger, es ist auch zuverlässiger und flexibler.

Das hilft Dir alles nichts, wenn Du für SAP, Hybris, Oracle und was es sonst da noch alles gibt Support benötigts und halt nur ein zertifizierter Stand unterstützt wird. Da kannste Du wie das Rumpelstielzchen umherhüpfen, die werden Dir was husten :-)

Auch wenn ich persönlich ein Freund von aktuell gehaltener Software bin, in manchen Industrien dauert schon der Prüfungsprozess der Compliance-Konformität länger als die Supportzeiträume so mancher Distribution.

Entweder läuft dein System relativ still, rebootet aber oft neu(man kann ihm aber uU. nicht 100% vertrauen) oder man nimmt Auszeiten in Kauf dafür hat man stets definiertes Verhalten und dann aussteigert wenn assert = false ist.

Für definiertes Verhalten sind (zumindest) Reboots nach jeder Änderung am System Pflicht. Die will man auch nicht sammeln und dann nach dem Reboot raten, welche der Änderungen das etwaige Fehlverhalten verursacht.

Wenn man es richtig machen möchte, sollte man gleich zu Infrastructure as Code übergehen. Serverinstanzen und die darauf laufende Software sind Wegwerfware (vgl. Pets vs. Cattle) und werden bei Änderungen gleich komplett neu gebaut. In Produktion kann man dann via Blue-Green Deployment recht gefahrlos testen, ob die Tester auch alle kritischen Fehler gefunden haben. ;)

Ich möchte der Software vertrauen, das sie ihren Job tut.

Vertraue keiner Software und spekuliere immer darauf, dass sie dich im Stich lässt; bereite dich aber genau darauf vor.
 
Wegwerf-Hosts funktionieren doch paradoxerweise nur, wenn gerade das "Wegwerfen" maximal robust funktioniert, was hier ja nicht der Fall ist. Nicht mal rebooten kann das Scheißteil problemlos. Was ist denn daran selbstheilend? Da ist doch das ganze Gefasel um Wegwerf-Hosts total sinnlos, wenn man dem Host beim Abkacken erst noch abwischen muss, bevor er wieder frisch hochkommt.
 
Und das systemd nicht in der Lage ist einen Neustart durchzuführen entnimmst du jetzt einem einzelnen Tweet, ohne nähere Informationen? ;)

Ich mag ja FreeBSD sehr, meine Erfahrungen sind halt genau das Gegenteil... ich hab mit den FreeBSD Servern deutlich mehr Alltagsprobleme als mit den Linux-Kisten. Das hat zwar nichts mit dem Init-System zu tun, aber zeigt mir auch, dass bei mir auf zig Systemen systemd so gut wie keine Probleme bereitet.

systemd hat seine Macken, einige Entscheidungen sind fragwürdig, aber so gut wie keine davon ist ohne Ausweg, wenn es einem nicht gefällt
 
Ich mag inzwischen systemd, läuft und zwar komplett ereignisfrei. Nix mit dem hier im Thread erwähntes; hättehätte Fahrradkette. Was alles passieren hätte und noch wird Könnte. Einfach nix. SORGENFREI.
Polemik.
 
Ja, systemd löst Probleme von sysvinit. Das ist nicht wirklich die Frage. Genau deshalb gab und gibt es unter Linux zig Alternativen. Die Frage ist eher, wie gut systemd die Probleme löst.

Das mit dem "zeitgemäß" halte ich für ein sehr schwammiges und schwaches Argument. Dann könnte man genau so Sachen, dass wir weite Teile des Systems in JavaScript neu schreiben sollten. Das würde ja auch gehen, nachdem heute sehr viele Leute mit JavaScript entwickeln und es diverse Schwächen von C und C++ nicht hat würde das ja genau so Sinn machen. Auch ist es kein Ding der Unmöglichkeit und es gibt auch bereits Implementierungen diverser Tools in JavaScript. Da ist dann C der Stein und JavaScript der Hammer.

Ich würde mich eher auf die Realität konzentrieren und ja, man muss einsehen, das sysvinit gewisse Limitierungen hat. Ich glaube das sehen auch viele Kritiker ein, denn meist wird nicht gesagt, dass man das behalten soll, sondern, dass systemd eine schlechte Lösung ist. Ist ja auch nicht das erste Mal, dass eine schlechte Lösung sich durchsetzt und man drauf kommt, dass das in vielen Bereichen einfach Humbug war. Zum Beispiel gab es eine Zeit, wo man meinte alles in möglich komplexe XML-Formate zu packen und dann XML aufzubohren. Für die einen oder anderen Dinge mag das ja auf den ersten Blick und vor allem in der Realität plausibel erscheinen. In der Realität stellt sich dann heraus, dass es eher toll aussieht, aber allen Seiten nur Probleme bereitet. Es ist zu groß, zu komplex zu parsen für Menschen für Computer - siehe unzählige (security) Bugs, zu verbos, etc. Da hat man dann irgendwann mal eingesehen, dass es auch einfacher geht und mittlerweile stellen sich die einfacheren Alternativen als problembehaftet raus und man arbeitet am nächsten Schritt.

Was beim Umsteigen von SysV-Init zu SystemD nicht gemacht wurde oder nicht genug und worauf auch viel Kritik abzielt ist ein längeres Evaluieren. Zu dem Zeitpunkt, als viele Distributionen sich entschieden haben auf SystemD umzusteigen war es noch fehlerhafter, deutlich ärmer an Features, was dazu führt, dass mittlerweile häufig eine Reevaluierung anstehen sollte. Probleme die es gab wurden tatsächlich behoben und andere Probleme sind neu aufgekommen.

Ich weiß, ich bin da ein wenig biased (war vor langer Zeit mal Genoo-Nutzer und jetzt eben BSD), aber die Behauptung, dass es keine sinnvollen Alternativen zu SystemD gab halte ich für eine Falschaussage. OpenRC zum Beispiel ist ein (im Vergleich zu SystemD) altes Projekt. Es löst ein relativ ähnliches Set an Problem, läuft auf vielen Plattformen, ist trotzdem recht simpel behalten und vor allem sehr erprobt. Es löst Probleme wie Dependency Management, Parallelismus, Linux-Themen, wie cgroups, etc. Es gibt Unterschiede, aber man muss einfach zugeben, dass es die großen immer wieder angesprochenen Probleme mit SysV-Init löst. Der Weg ist nur ein komplett anderer. Es gab andere Design-Entscheidung und viele Dinge, die an philosophischen Standpunkten grenzen (also vor allem die Dinge, die an einem grundsätzlich funktionierendem SystemD-System immer noch kritisiert werden) sind einfach auf eine andere Art realisiert worden.

Das heißt es gab Alternativen. OpenRC ist aber kaum evaluiert worden. Ich weiß, da gibt es das Argument, dass man das ja hätte tun können. Allerdings, und das ist jetzt eine Kritik, die an die Community geht und für die SystemD nichts kann (je nachdem, welcher Ansicht man ist, vielleicht aber die Macher von SystemD). OpenRC und auch andere Alternativen wurden nicht evaluiert, weil niemand wirklich Zeit aufgewendet hat. Das ist durchaus ein Argument und man sollte da auch nicht den Supportern von SystemD groß Schuld geben, auch wenn es cool wäre, wenn sie das selbst gemacht hätten, wenn ihr System so viel besser ist, aber man muss da auch einfach in die Realität blicken und sich fragen, ob man wirklich Software verwenden möchte, wo Leute nur dann mitentscheiden können, wenn sie in ihrer Freizeit (oder tatsächlich bezahlt vom Arbeitgeber) die selbe Arbeit aufwendet, wie das Unternehmen, das hinter einer Software steht. Genau das scheint passiert zu sein. Bei Fedora und RedHat ist das ja okay, aber wie es aussieht ist das zumindest noch bei Debian passiert, das in der Vergangenheit genau so etwas mit diversen institutionellen Mechanismen und Guidelines vorbeugen wollte. Dabei muss ich sagen, dass ich überhaupt kein Fan von Debian oder Debianbasierten Systemen bin, es aber trotzdem manch anderen Systemen vorziehe und wie wohl jeder viel Kontakt damit habe. Zumindest in Form von Ubuntu.

Mich hat es ziemlich verblüfft, das viele einfach so schnell umgestiegen sind. Da hat man sich entweder Jahre nicht drum gekümmert, teilweise eigene Systeme entwickelt und dann sind viele Distributionen sehr rasch umgesattelt. SystemD muss ich gestehen, hat viele Zustände, die es anfangs hatte verbessert. Ich hoffe man verzeiht mir den Seitenhieb, aber gerade wo Lennart Teilprojekte und Tools abgegeben hat dürfte das geschehen sein.

Derzeit scheint es eine gewisse Ernüchterung auf beiden Seiten zu geben, den SystemD-Supportern und -Kritikern. Ich glaube es traut sich gerade niemand das Problem erneut aufzugreifen. Man viel ja keinen neuen Fehlgriff warten und schaut eher was die anderen so treiben, wartet, dass die den ersten Schritt machen.

Natürlich greift SystemD viel mehr ins System ein. sd-notify ist da noch das Kleinste. So schnell wird das nicht weggehen, aber andererseits ist es auch so, dass quasi jede Software, die auch auf anderen Betriebssystemen, als Linux läuft ja nicht drauf angewiesen ist. Und Linux-only ist schon unter Linux eher was, wo man sich fern halten will. Ist meist kein gutes Zeichen.

Ja, SystemD wird viel gebasht, aber hinter vielen Dingen, wie --force ..force, aber auch anderen Dingen verbergen sich eben jene Design-Schwächen, die man bei Abhandlungen, die tiefer gehen, als ein typischer Tweet auch detaillierter haben kann.

Es gibt gebashe und es fehlt oft an Inhalt. Das kann man ebenfalls kritisieren oder ich denke mal am Besten nehmen als was es ist. Jemand lässt einen frustrieren Tweet raus, den kann man beschmunzeln oder auch nicht. Es hängt aber vielleicht damit zusammen, dass die Zeit der ausführlichen Kritik die Zeit der Umstellung auf Systemd war. Relativ prompt gab es Kritik, verbale, die Schwächen aufzeigen, Alternativen, wie OpenRC aufzeigen, oder auch in rein technischer Form, sei es uselessd, das Behauptungen bloßgestellt hat, alternativen die gebaut wurden (vor allem Minimalisten), Froks, neue Distributionen, etc.

Wenn man heute als Admin (oder DevOp/Platform Engineer/Site Reliability Engineer, ...) oder Programmierer ein Problem damit hat, dann ist es wohl relativ gesund darüber zu Lachen oder andere zum Lachen zu bringen. Derzeit ist systemd einfach mal Realität. Das kann man erst mal(!) nicht ändern. Was anderes gibt's frühestens beim nächsten Release oder wenn eben eine Umstellung anfällt, bzw. wenn man sich auf eine Alternative geeinigt hat und man muss solche Themen einfach im Zusammenhang mit Communities sehen. Das ist nicht nur bei Open Source so. Auch wenn ich komplett auf Closed Source, proprietäre Systeme setze will ich Produkte verwenden, wo der Anbieter auch auf die Community hört und bin bis zu einem gewissen Grad fesgefahren. Auch wenn ich der beste Entwickler mit den besten Argumenten bin und alles an Freizeit darauf verwende das beste Init-System der Welt zu schaffen bin ich in dem Augenblick wo ich meine Software oder mein System zu laufen bekommen will oder Support leiste einfach mal festgefahren und da basht man dann eben. Tut auch niemanden weh, und auf einen Tweet den man da raus lässt wird höchstwahrscheinlich niemand große Entscheidungen treffen.

Dann linkt man das halt irgendwo, wo man weiß, dass andere vielleicht auch mit sowas zu kämpfen haben, damit dem sozialem Leben des IT-Menschen genug getan wurde und so landet das dann hier. Wie geschrieben, sowas kann zugrundeliegende, valide Probleme aufzeigen, aber ich denke, dass eigentlich jeder hier über genug kritisches Denkvermögen hat das jetzt auch nicht als so viel mehr aufnimmt, als was es ist, ein Tweet von jemanden, der gerade über eine Software frustriert ist. Wenn dem nicht so wäre, würden wir uns hier schon lange an die Gurgel gehen. ;)

EDIT: Zwei Klarstellungen:

Ja, ich weiß, jeder Vergleich hinkt irgendwo. Mir ging's nur darum, dass "zeitgemäß" ein äußerst subjektiver und nicht sehr aussagekräftiger Begriff ist. Bzw. einfach, das man das am Besten präzisieren sollte.

Und mit philosophisch meine ich Themen, wo beide Seiten Argumente haben, nicht so Dinge wo sich ohnehin alle einig sind (es ist ziemlich blöd, wenn PID 1 nicht stabil läuft, egal was PID1 jetzt ist).
 
Man braucht aber auch nicht mehr auf Problemen rumreiten, die systemd vor 2 Jahren gehabt hat. Ich stand der damaligen Hype-Umstellung bei ArchLinux auch kritisch gegenüber und es gab auch Probleme... aber die wurden auch gefixt und gut ist. Ebenso die jetzt laufende Wayland Umstellung geht nicht ohne Kanten.

Wenn man jahrelang nur evaluiert besteht die Gefahr, dass nichts passiert. Aus realistischen Anforderungen werden dann irgendwann Luftschlösser und man diskutiert Details. Man muss halt ab einem Punkt anfangen es zu benutzen. Man kriegt mehr Testergebnisse, man kriegt mehr Empfehlungen, man kriegt allgemein Input.

Und die Umstellung auf systemd erfolge doch überhaupt nicht schnell. Wer die Diskussion bei Debian mitverfolgt hat wurde so ziemlich alles evaluiert. Und auch wenn Gentoo jetzt OpenRC hochlobt, stand bei Debian gegen Ende eher Upstart vs systemd auf dem Plan.

Mir geht es dabei jetzt auch nicht darum hier systemd intensiv zu verteidigen. Wem es nicht gefällt... alles ist OpenSource. Es gibt genügend Distributionen oder Systeme ohne systemd.

Was mich stört ist eher diese "es funktioniert, wir müssen nichts ändern" Mentalität. Diese arg Konservative Ansicht führt halt eben dazu, dass sich FreeBSD relativ wenig und langsam bewegt. OK, sagen wir mal nicht wenig, aber eben sehr langsam. Auch FreeBSD hat sich damals entschieden kein erprobtes Paketmanagement von Linux oder anderen BSDs zu benutzen, sondern lieber von Grund auf alles neu zu schreiben. Auch Jahre später hinkt man noch sehr gewaltig hinterher. Auch Port Optionen sind immer noch schlecht gesetzt und wenn man diese dann ändert geht mir auch ziemlich oft was kaputt. Auch in Sachen Sicherheitsfeatures wie ASLR und Sandboxing hinkt man hinterher. Zumindest letzteres wird gerade angegangen (Capsicum).

Und wie man sieht, wenn man es anspricht trifft man eben häufig nur auf Beißreflexe.
 
Ja, ich weiß, jeder Vergleich hinkt irgendwo. Mir ging's nur darum, dass "zeitgemäß" ein äußerst subjektiver und nicht sehr aussagekräftiger Begriff ist. Bzw. einfach, das man das am Besten präzisieren sollt

Joahr, Diskussionen um Begrifflichkeiten... ermüdend. Wenn ich mir eben ansehe wie überaus komplex die meisten FreeBSD Beschreibungssysteme oder Skripte sind, dann ist die Frage nach "ist das wirklich nötig?" doch nichts falsches. Es wird immer und überall um Mithilfe gebeten. Sogar wenn man nur pkg nutzen will, kriegt man "fehlender Maintainer" um die Ohren gehauen. Aber ich hab alleine beim Versuch genau das zu tun schon das Gefühl, ich könnte in kürzerer Zeit ein komplett neues System entwickeln... ganz ehrlich... ich hab einfach keine Lust mich in diesen großen Haufen SH-Magie einzuarbeiten wo Variablen über 20 Dateien verteilt sind, damit die Skripte nicht noch länger werden.
 
Sorry, ja. Ich wollte da keine große Diskussion zu Begrifflichkeiten machen. Nur sehe ich das Argument "das ist besser, weil es neuer ist" viel zu oft. Und dann hat man irgendwelche Designfehler aus deren Einsichten der vermeintlich überholte Vorgänger entstanden ist.

ich hab einfach keine Lust mich in diesen großen Haufen SH-Magie einzuarbeiten wo Variablen über 20 Dateien verteilt sind, damit die Skripte nicht noch länger werden.
Schau und ich habe den Frust mit systemd. Da will ich sowas simples machen wir für mein dnscrypt-proxy meinen Port ändern. Unter RC habe für solche und ähnliche Dinge simple Variablen und wenn ich was komplexeres machen will ein schönes Shelll-Skript. Alles was ich brauche landet in rc.conf.

Unter systemd:
  • Ich schaue zunächst in /usr/lib/systemd/system/dnscrypt-proxy.service (persönlich ein Graus mit /usr/lib)
    Dann will ich den Port dadrin ändern indem ich ein Flag ändere. In den meisten Guides steht dann "editiere die Datei". Da ich mittlerweile ein wenig Erfahrung habe weiß ich, dass es besser ist die Datei nach /etc/systemd/system/dnscrypt-proxy.service kopiere, damit der Package Manager nicht reinfunkt (ist ein bisschen wie /etc/default unter FreeBSD.
  • Dann ändere ich das Port. Ich skripte also quasi.
  • Dann mache ich ein systemctl daemon-reload (nichts schlimmes, aber man ärgert sich, wenn man drauf vergisst und sich wunder warum's nicht funktionier)
  • Dann funktioniert das ganze nicht. Warum nicht? Weil es ja noch eine andere Datei gibt, dnscrypt-proxy.socket. Das kann ja keinesfalls Teil des Unit-Files sein. Das ist eindeutig nicht zentral.
  • Das kopiere ich auch, nach etc und dann geht's hoffentlich.
  • Womöglich brauche ich noch Anpassungen unter unbound, die ähnlich sind und natürlich mit socket files.
Während dem Debuggen spiele ich mich mit journalctl rum und nein, das ist nicht einfacher als mit Datein zu arbeiten. Solange es Dateien gibt unter Unix werde ich mir einfacher tun mit Files zu arbeiten und kann mir da auch was zusammenstöpseln als Sysadmin. Das ist ja eine große Stärke von Unix. In journalctl sind alle tools nochmal neu mit leichten Unterschieden und teilweise mit Bugs (-n1, -n0 hatten Bugs unter manchen Systemen, aber gut, ist gefixed).

Im Endeffekt war das was einfaches. Allerdings ist das mit Shell etwas einfacher. Außerdem ist das Ergebnis, nämlich sowas wie eine Config-Variable dnscrypt_port deutlich deskriptiver, als nachforschen zu müssen. Und der Port-Maintainer oder gar der Autor kennt sich mit solchen Dingen wohl am Besten aus. Unter systemd ist das komplett unmöglich und das obwohl das die Leute sind, die von Dingen wie Systeme, die man nicht modifiziert reden kann. Hier muss ich in Systemd eingreifen, ein File unter /usr/lib um eine Konfiguration zu ändern. Das halte ich für ziemliche Frickelei.

Wenn ich schon bei sowas quasi an Systemd anstehe dann ist das bei komplexeren Dingen noch schlimmer. Und in der tat sehe ich immer häufiger Dinge, wie die hier:
Code:
[Unit]
Description=he.net IPv6 tunnel
After=network.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/ip tunnel add he-ipv6 mode sit remote Server_IPv4_Address local Client_IPv4_Address ttl 255
ExecStart=/usr/bin/ip link set he-ipv6 up mtu 1480
ExecStart=/usr/bin/ip addr add Client_IPv6_Address dev he-ipv6
ExecStart=/usr/bin/ip -6 route add ::/0 dev he-ipv6
ExecStop=/usr/bin/ip -6 route del ::/0 dev he-ipv6
ExecStop=/usr/bin/ip link set he-ipv6 down
ExecStop=/usr/bin/ip tunnel del he-ipv6

[Install]
WantedBy=multi-user.target

Ein Shell-Skript eingebettet in einem Config-File. Sowas wäre mit einem simplen, leicht lesbaren RC-Script schnell erledigt und hätte ein sauberers und wahrscheinlich flexibleren Interface (ein paar Config-Variablen für rc.conf), als ein paar Dinge in einem Unit-File zu ändern. Ist wieder Frickelei und ein schöner Platz für Fehler.

Ich finde die Idee dass man das ganze strikter behandelt grundsätzlich für keine schlechte Idee. Wenn ich mich recht erinnere habe ich in einer OpenBSD-Changelog mal gelesen, dass die da jetzt strikter machen. Ich halte die Umsetzung allerdings für ein Beispiel einer Verschlimmbesserung. Es ist doch nichts modern dran, dass man um solche Dinge derart herumhacken muss. Da halte ich Flexibilität von Skripts in Kombination mit strikten Konventionen für die bessere Variante. Vielleicht sollten strikte Konventionen stärker erzwungen werden. Selbst deutlich komplexere Sprachen, mit denen man deutlich einfacher Humbug treiben kann haben Möglichkeiten Konventionen zu erzwingen. Auch sysrc und ähnliches sind Möglichkeiten auf denen man meines Erachtens aufbauen sollte.

Der Kritikpunkt hier ist einfach ein wenig die Praxisferne. Ja, ein simples Format ist eine gute Idee, aber wenn das dann Leute zu Hacks bewegt, dann hat man was falsch gemacht. Und einfache, brave, schöne Daemons die mit Systemd-Unit schön und einfach zu lösen sind sind auch schöne und simple RC-Skripte. Du wirst in beiden Systemen unschöne Sachen sehen. Ich halte den SystemD-Ansatz da ein wenig für unerfahren, weil er zu sehr von Idealzuständen ausgeht, was in der IT meist kein sehr guter Ratgeber ist. Vielleicht übersehe ich nur etwas ganz grobes und verstehe mich nicht falsch. Ich meine nicht, dass die Leute generell Unerfahren sind, was C-Code oder so betrifft, sondern dass manche Annahmen ziemlich naiv sind und nur auf einen relativen schmalen Grad und Nutzung ausgelegt ist. Ja, das Ganze ist flexibel genug um mit Hacks alles mögliche zu erreichen, aber dann fehlt ziemlich schnell der Mehrwert.

Wir brauchen Konventionen und vielleicht auch Tooling. Ich denke aber auch, dass wir die durchaus haben (und teilweise dran arbeiten). Das ist jetzt der ein wenig philosophische Teil (weiß, dass es da unterschiedliche Ansichten gibt. Das sieht man teilweise auch bei der Anzahl von Programmier- und Beschreibungssprachen), aber ich denke, dass es besser ist flexibel zu sein und dann einzuschränken. In Richtung Linter, -Wall, etc.

Achja, hat du ein konkretes Beispiel, warum du durch vier Files schauen musstest und wie du das unter SystemD gelöst hast? Wäre echt neugierig.

EDIT: Und zum fehlenden Maintainer und so. Ja, stimme ich dir zu. Gerade wenn was komplexer ist, ist das Mühsam. Ist bei vielen solchen Dingen so. Ist ja auch bei Configure-Scripts/Makefiles, SELinux-Regeln, etc. oft der Fall. Ich glaube aber ehrlich gesagt nicht, dass sich da groß was ändert mit SystemD. Wieder, wenn es komplexer ist. SystemD vereinheitlicht ja nicht so sehr wie anfangs erhofft. Da gibt's für verschiedene Software recht häufig große Unterschiede. Schon beim Namen (ssh.service vs sshd.service zum Beispiel). Solche Dinge werden und leider fürs Erste nicht erspart bleiben. Ist auch ein Beispiel wo das Verbreiten von Konventionen helfen könnte.
 
Sorry, ja. Ich wollte da keine große Diskussion zu Begrifflichkeiten machen. Nur sehe ich das Argument "das ist besser, weil es neuer ist" viel zu oft. Und dann hat man irgendwelche Designfehler aus deren Einsichten der vermeintlich überholte Vorgänger entstanden ist.

Ebenso ist "das haben wir schon immer so gemacht" ebenso schädlich. Immerhin brauche ich eine Jail (!!!) um PostgreSQL unter FreeBSD korrekt upgraden zu können.

Unter systemd:
  • Ich schaue zunächst in /usr/lib/systemd/system/dnscrypt-proxy.service (persönlich ein Graus mit /usr/lib)
    Dann will ich den Port dadrin ändern indem ich ein Flag ändere. In den meisten Guides steht dann "editiere die Datei". Da ich mittlerweile ein wenig Erfahrung habe weiß ich, dass es besser ist die Datei nach /etc/systemd/system/dnscrypt-proxy.service kopiere, damit der Package Manager nicht reinfunkt (ist ein bisschen wie /etc/default unter FreeBSD.
  • Dann ändere ich das Port. Ich skripte also quasi.
  • Dann mache ich ein systemctl daemon-reload (nichts schlimmes, aber man ärgert sich, wenn man drauf vergisst und sich wunder warum's nicht funktionier)
  • Dann funktioniert das ganze nicht. Warum nicht? Weil es ja noch eine andere Datei gibt, dnscrypt-proxy.socket. Das kann ja keinesfalls Teil des Unit-Files sein. Das ist eindeutig nicht zentral.
  • Das kopiere ich auch, nach etc und dann geht's hoffentlich.
  • Womöglich brauche ich noch Anpassungen unter unbound, die ähnlich sind und natürlich mit socket files
Wenn man systemctl daemon-reload braucht, sagt einem systemctl das auch. Das Hauptproblem bei dir dürfte jetzt eher sein, dass du die Datei genau gleich benannt hast, statt ihm einfach einem anderen Namen zu geben. FreeBSD steigt dir da auch aus, wenn du gleichnamige Init-Skripte in unterschiedlichen Ordnern hast. Darum heißt der Base SSHD auch sshd und der aus den Ports opensshd. Und das es .socket Dateien gibt als Kritikpunkt zu sehen... wie gesagt. Es ist ein Feature von systemd und kein Muss. Dein Problem war vermutlich einfach der Name.

Während dem Debuggen spiele ich mich mit journalctl rum und nein, das ist nicht einfacher als mit Datein zu arbeiten. Solange es Dateien gibt unter Unix werde ich mir einfacher tun mit Files zu arbeiten und kann mir da auch was zusammenstöpseln als Sysadmin. Das ist ja eine große Stärke von Unix. In journalctl sind alle tools nochmal neu mit leichten Unterschieden und teilweise mit Bugs (-n1, -n0 hatten Bugs unter manchen Systemen, aber gut, ist gefixed).

Wenn dir journald nicht gefällt installiere einfach wieder syslogd... das ist wieder so ein Punkt. Du musst die systemd Tools nicht benutzen wenn sie dir nicht passen.

Wenn ich schon bei sowas quasi an Systemd anstehe dann ist das bei komplexeren Dingen noch schlimmer. Und in der tat sehe ich immer häufiger Dinge, wie die hier:
Code:
[Unit]
Description=he.net IPv6 tunnel
After=network.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/ip tunnel add he-ipv6 mode sit remote Server_IPv4_Address local Client_IPv4_Address ttl 255
ExecStart=/usr/bin/ip link set he-ipv6 up mtu 1480
ExecStart=/usr/bin/ip addr add Client_IPv6_Address dev he-ipv6
ExecStart=/usr/bin/ip -6 route add ::/0 dev he-ipv6
ExecStop=/usr/bin/ip -6 route del ::/0 dev he-ipv6
ExecStop=/usr/bin/ip link set he-ipv6 down
ExecStop=/usr/bin/ip tunnel del he-ipv6

[Install]
WantedBy=multi-user.target

Sorry, aber diese Datei ist vollkommen einfach lesbar und für jeden verständlich.

Ein Shell-Skript eingebettet in einem Config-File. Sowas wäre mit einem simplen, leicht lesbaren RC-Script schnell erledigt und hätte ein sauberers und wahrscheinlich flexibleren Interface (ein paar Config-Variablen für rc.conf), als ein paar Dinge in einem Unit-File zu ändern. Ist wieder Frickelei und ein schöner Platz für Fehler.

Die rc-Skripte in FreeBSD sind aber alle andere als einfach und leserlich. Ein nicht unerheblicher Teil sieht so aus (Auszug):
Code:
        for ifn in $_cooked_list; do
        case ${ifn#epair} in
        [0-9]*[ab])     ;;      # Skip epair[0-9]*[ab].
        [0-9]*)
                for _str in $_cooked_list; do
                case $_str in
                $ifn)   _tmp_list="$_tmp_list ${ifn}a ${ifn}b" ;;
                *)      _tmp_list="$_tmp_list ${ifn}" ;;
                esac
                done
                _cooked_list=${_tmp_list# }
        ;;
        esac
        done

Ist jetzt natürlich ein extremes Beispiel.

Der Kritikpunkt hier ist einfach ein wenig die Praxisferne. Ja, ein simples Format ist eine gute Idee, aber wenn das dann Leute zu Hacks bewegt, dann hat man was falsch gemacht. Und einfache, brave, schöne Daemons die mit Systemd-Unit schön und einfach zu lösen sind sind auch schöne und simple RC-Skripte. Du wirst in beiden Systemen unschöne Sachen sehen. Ich halte den SystemD-Ansatz da ein wenig für unerfahren, weil er zu sehr von Idealzuständen ausgeht, was in der IT meist kein sehr guter Ratgeber ist. Vielleicht übersehe ich nur etwas ganz grobes und verstehe mich nicht falsch. Ich meine nicht, dass die Leute generell Unerfahren sind, was C-Code oder so betrifft, sondern dass manche Annahmen ziemlich naiv sind und nur auf einen relativen schmalen Grad und Nutzung ausgelegt ist. Ja, das Ganze ist flexibel genug um mit Hacks alles mögliche zu erreichen, aber dann fehlt ziemlich schnell der Mehrwert.

Aber genau ein Großteil der ganzen Dienste braucht eben genau nicht viel außer ein Start, Stop und ein paar Status Dienste. Warum soll ich ein System überaus komplex definieren nur damit Randfälle "ein bisschen hübscher sind", aber jeder simple Fall einfach umständlich ist?

Achja, hat du ein konkretes Beispiel, warum du durch vier Files schauen musstest und wie du das unter SystemD gelöst hast? Wäre echt neugierig.

So gut wie jedes Init-Skript lädt im Vorfeld /etc/rc.subr und hat dann selbst keine einfach verständliche Syntax sondern auf den ersten Blick mMn vollig unverständliche Deklarationen. Und die die es nicht tun... oh weh... Ebenso die Ports-Sammlung die erst mal aus /ports/Mk zig Sachen lädt, Variablen aus Make.conf verarbeitet und selbst noch aus eigenen basierten Variablen besteht, die "irgendwo" her kommen. Und dann gibt es auch noch Port-Makefiles welche selbst noch Meta-Kram oben drauf kriegen, damit sie nicht so lang werden.

edit, nehmen wir mal als Beispiel mdnsd. Ein schön kurzes Skript....

Code:
# PROVIDE: mdnsd
# REQUIRE: DAEMON
# KEYWORD: shutdown

. /etc/rc.subr

name=mdnsd
rcvar=mdnsd_enable

load_rc_config $name

: ${mdnsd_enable="NO"}
: ${mdnsd_pidfile="/var/run/${name}.pid"}

command="/usr/local/sbin/${name}"
pidfile="${mdnsd_pidfile}"

run_rc_command $*

Fragen die einem Noob da kommen:
- Wie, warum ist das PROVIDE da wichtig, da ist doch ein Kommentarzeichen davor?
- uff... etc/rc.subr hat ja ÜBER 2000 Zeilen
- load_rc_config... hmm, brauche ich das? Was tut das?
- Doppelpunkt, leerzeichen Dollar?
- run_rc_command Dollar Sternchen? Huh?

So ein simples systemd service File ist dort auf den ersten Blick wesentlich selbsterklärender, meiner Meinung nach.

Mir ist übrigens auch klar, dass jetzt Beiträge wieder dieser nur wieder ein "das Haar in der Suppe suchen" Flamewar triggern könnte. Dann sind wir wieder am Anfang: "Wir haben das immer schon so gemacht" oder "es funktoniert" -> "Man sollte nichts ändern".
 
Ich will hier übrigens auch keinen überzeugen dass systemd total geil ist, wie gesagt. Ich will nur anmerken, dass die Sachen in FreeBSD eben nicht so toll sind, wenn man schon dabei ist an mMn besseren Sachen rumzukritisieren. Man trifft hier eben nunmal hauptsächlich auf "das war schon immer so!".

Und dann stehe ich da, will vielleicht einen Port erstellen, den es noch nicht gibt und wird einfach nur erschlagen... von dem Ports-System und vom Init-System. Und dann gucke ich z.B. in Richtung ArchLinux... total einfache Paketbeschreibung und total simple Init-Dateien.

Und da denke ich mir auch: Wenn es mir schon so geht, geht es sicherlich diversen anderen Leuten auch so. Und dann taucht die PKG-Meldung auf "No Maintainer"...
 
Also wenigstens Shell sollte man schon draufhaben, sonst hat man eigtl. überhaupt nichts bei UNIX verloren.

Sorry, aber... nein. Diese altertümlichen Sprüche kann man sich auch einfach sparen. Ist genauso aktuell und haltbar wie "Um Programmieren zu können, musst du Assembler beherrschen" oder "Du musst C können bevor du C++ lernst".

Shell-Skripting auf dem Level sehe ich gerade echt nur bei FreeBSD (kenne die anderen BSDs nicht) und ist auch nur dort nötig, wenn man versuchen will dort mitzumachen. Und nur mal so... bei systemd muss ich keine antike Skriptsprache lernen, um einen Dienst vom Init-System verwalten zu lassen und auch noch zu verstehen was dort dann im Hintergrund passiert. Und ich sehe auch so gar kein Argument, warum das jetzt bei FreeBSD nötig sein sollte.

FreeBSD muss echt nicht das Betriebssystem für Opas sein, die sich mit neuem Kram nicht mehr befassen wollen.
 
Wenn du Shell nicht kannst, solltest du keinen Server betreiben dürfen. Das ist eine Gefahr für dich und alle Besucher.
 
Wenn du Shell nicht kannst, solltest du keinen Server betreiben dürfen. Das ist eine Gefahr für dich und alle Besucher.

Was ist denn "Shell"? Wenn ich solche pauschalen Äusserungen lese rollen sich meine Fussnägel hoch ...
Auch wenn du alle Scriptsprachen beherrscht macht es deinen Server für dich und deine Nutzer nicht sicherer.
 
Du willst jemanden Unix-Server verwalten lassen ohne das er Grundkenntnisse der Shell hat?
Sorry, den würde ich hochkant rausschmeißen.
Mal abgesehen davon verrät dir ein Shellskript so viel mehr, wie man an bestimmte Informationen herankommt oder Jobs automatisiert erledigt.
Und Kenntnisse in Skripting sind für den Beruf ohnehin sehr angeraten wenn man mehr als zwei Rechner betreibt.
 
Grundkenntnisse in der Shell ist nunmal nicht das was FreeBSD in seinen Init-Skripten und Port-Tools da benutzt. Meiner Meinung nach braucht man teilweise schon gehobene Kenntnisse in Shell-Programmierung um die Sachen von FreeBSD zu verstehen und zu verwalten. Da ist nichts intuitiv und die scheiß Syntax von sh macht's nicht besser.

Es ist Quatsch was ihr da schreibt. Die Sicherheit eines Servers hat mit Shell-Programmierung so überhaupt nichts zu tun. Sorry, aber jemandem wegen einer kleineren Sache mal eben pauschal sämtliche Leistungen abzuerkennen ist armselig. Einfach mal vom hohen Ross runter kommen und über den Tellerrand gucken...
 
Sorry, aber jemandem wegen einer kleineren Sache mal eben pauschal sämtliche Leistungen abzuerkennen ist armselig.

Nicht kleinere Sache, grundlegende Sache. Das ist ein Unterschied.

Nicht nur, dass du nicht weißt, was diese Konstrukte in Shell machen, du bist auch anscheinend nicht in der Lage, dir das anzueignen. Darum geht's. Ich stimme zu, dass gerade FreeBSD es massiv übertreibt mit der Komplexität in seinen rc-Skripten, aber mit diesen zwei kleinen Details entlarvst du dich selbst und nicht FreeBSD.
 
Nicht nur, dass du nicht weißt, was diese Konstrukte in Shell machen, du bist auch anscheinend nicht in der Lage, dir das anzueignen. Darum geht's. Ich stimme zu, dass gerade FreeBSD es massiv übertreibt mit der Komplexität in seinen rc-Skripten, aber mit diesen zwei kleinen Details entlarvst du dich selbst und nicht FreeBSD.

Sorry, aber Blödsinn und plumpe Beleidigung... Ich hab schon vorher gesagt, dass ich mir den Kram nicht aneignen _will_. Ich lerne doch auch kein x86-64 Assembler mehr um ein Programm zu schreiben.

Klar könnte ich nachschauen was diese Konstrukte da sollen. Aber warum? In weiteren Skripten wird es noch viel ekliger und komplexer. Sorry, aber dann muss FreeBSD halt auf meine Mitarbeit verzichten.
 
Es geht doch nicht darum die Skripte bis ins Detail zu verstehen sondern bei Problemen zeitnah Lösungen zu präsentieren.
Kenntnisse in C würde ich nicht von Admins verlangen aber wenn man 1 Tag braucht um die Logs von 20 Rechnern auszuwerten ob selbiges Problem dort ebenfalls vorliegt, ist es üblich sich ein Skript zu basteln.
 
Dann schreibste halt keine Initscripts. Und?

Darum ging es doch die ganze Zeit :rolleyes:

Sich hier über moderne Init-Systeme auslassen ist wohl alles ganz lustig, aber wenn man hier den antiken BSD-Kram kritisiert wird man direkt als unfähig und unqualifiziert hingestellt... ist natürlich eine tolle Diskussionsgrundlage. Ebenso ernsthaft und begründet kann ich dann ebenso die Kritik hier an systemd sehen. Pauschale und uninformierte Kritik, Hauptsache man halt in die Richtung geschossen...

systemd zwingt mich nicht eine Skriptsprache aus den 80ern im Detail, mit all seinen Facetten zu lernen.
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben