News Systemd 214 greift tief in die Linux-Verzeichnishierarchie ein

Ist das für den Heimanwender von Bedeutung? Bringt es Linux sicherheitstechnisch weiter nach vorn?

Ich gehe mal davon aus, daß die Übergangsphase die schwierigste sein wird, sofern sich diese Idee wirklich durchsetzt und von anderen Distributionen übernommen wird.
 
Gerade den Factory Reset finde ich sehr toll. Benutzereinstellungen wird man ganz einfach los, indem man sie löscht, um dasselbe für Systemeinstellungen zu erreichen, muss ich derzeit alle Pakete neuinstallieren. Geht so einigermaßen, ist aber nicht unbedingt der Weg, wie man sich das so vorstellen würde.
 
Wolfsrabe schrieb:
Ist das für den Heimanwender von Bedeutung? Bringt es Linux sicherheitstechnisch weiter nach vorn?
Ich gehe mal davon aus, daß die Übergangsphase die schwierigste sein wird, sofern sich diese Idee wirklich durchsetzt und von anderen Distributionen übernommen wird.
Unter Umständen ist es auch für Desktop-Anwender von Belang, wie mein Vorredner bereits erläutert hat.
Ansonsten siehst Du das völlig richtig. Es ist verdammt viel Arbeit. Einige Distributionen haben den Schritt zu /sys für solche Aufgaben bereits länger vollzogen, die Mehrheit aber nicht. Denkbar ist auch, dass Distributionen Systemd in dieser Hinsicht forken werden um die Änderugnen nicht mitzugehen.
 
Zuletzt bearbeitet:
Für Heimanwender hat es nur in soweit Relevanz, dass Programme radikal umgeschrieben werden müssen. Leichtgewichtige aber nützliche Software, die aber schon etwas älter ist, kann der Paket-Maintainer dann nicht einfach kompilieren und ins Repository werfen. Die einzige Konsequenz ist also: Alles, was bisher wunderbar funktioniert, funktioniert dann nicht mehr. Die Menge an vertrauten und nützlichen Anwendungen wird, zumindest zeitweilig, radikal schrumpfen.
Sicherheitstechnisch bringt es genau GAR NICHTS.

Ich kann zu der Nachricht eigentlich nur sagen: Der blanke Hohn, der totale Schwachsinn und genau das, wieso sich systemd einfach nicht ins System gehört. Upstart wäre eben DOCH die bessere Wahl gewesen. Der größte Vorteil von Unix'oiden gegenüber Windows ist doch, dass man eine absolut verlässliche Ordnerstruktur hat, und zwar schon seit einigen Jahrzehnten.

Ist den Typen eigentlich klar, was da alles für ein Rattenschwanz dran hängt? Ist ja nicht so, dass in /var nur Logdateien liegen würden. Waren die mal kürzlich in /var/lib/? Da lagert MySQL z.B. seine Datenbanken. Im Endeffekt wird hier nur was vollkommen funktionstüchtiges durch hirnloses Gefrickel ersetzt.
Gegenüber dem Schnitt, den systemd hier durchführen soll, ist der Übergang von Win9x auf 2k/XP quasi nicht-existent.
 
Warum heißt das Verzeichnis lib wohl lib? Für ein Zurücksetzen auf den Auslieferungszustand braucht man den Zirkus eigentlich nicht, das geht auch mit einem internen Ursprungsbackup von etc und var. Sichergestellt ist das Zurücksetzen auch so nicht, weil erstens in anderen Ordnern auch Dateien geändert, gelöscht oder hinzugefügt worden sein können und zweitens das System im Auslieferungszustand evtl. gar nicht bootbar ist, es durch fehlerbehaftete Auslieferungskonfiguration mglw. nie war oder aber durch z.B. HW-Änderung nicht mehr ist. Die Vorschläge sind ok für ein Android-Handy, da gibt es bisher kam jemand sein Handy umlötet. Bei sonstig eingesetzter HW sehe ich aber große Probleme bei diesen Vorschlägen, bei den wieder einmal ein paar Einzelne glauben alle use-cases bedacht und abgedeckt zu haben. Willkommen in einer einfachen Welt à la Pippi Langstrumpf!
 
Irgendwie weiß ich auch nicht was ich davon halten soll. Von der prinzipiellen Idee war ich von SystemD immer überzeugt (und habe mit arch auch immer eine Distri verwendet die bald SystemD erzwungen hat - und ich fand die Veränderungen positiv).
Bei diesem jetzt geplanten Schritt graut mir fast schon ein bisschen. /etc und /var bilden das Rückgrat für soviele Pakete (seit Jahrzehnten) - die Umstellung kann da nicht gut verlaufen (ganz abgesehen, dass immer zwei Versionen existieren SystemD und nicht SystemD - Eingriff ist ja doch sehr tief).
 
Factory Reset hin oder her, das hätte man doch bestimmt auch schöner lösen können. Und gerade die Option hinstellen, /etc und /var weg zu lassen finde ich persönlich eher kontra-produktiv. Man darf hinterher jede Beschreibung und Anleitung neu schreiben, alle schon vorhandenen Anleitungen funktionieren oder taugen nichts, weil die Pfade dann nämlich ganz anders sind :freak:

Und das sind nur kleine Eckpunkte die mir so einfallen.
Ich sehe es schon wieder vor mir in den Unix, Linux und Server Foren, wenn die Leute rufen "Hilfe, mein Dienst XY läuft nicht und die Anleitungen im Netz helfen mir nicht weiter", und das nur weil man jetzt solche Veränderungen plant. Und dann kommen wieder alle quacksalber raus mit solchen schlauen Sätzen wie "google hilft Dir w?" :freak:
 
fethomm schrieb:
Das Init- und Systemmanagement-System Systemd greift ab der neuen Version 214 noch tiefer ins System ein als bisher.

Ich hoffe nur, dass wenigstens eine bedeutende Distribution übrigbleibt, die nicht von der systemd-Krankheit befallen wird. Die Kunst am old-school-Linux bestand ja gerade darin, schwach verwobene Komponenten zusammenzuschmeissen und ein lauffähiges, fehlertolerantes und im Ernstfall leicht reparables System zu bekommen. Die Komplexität von systemd erfordert eine fortgesetzte Verkomplizierung von systemd. Ich verstehe nicht, wie Leute, die seit Jahren die Unix-Philosophie aufgebaut haben, das Problem nicht mit Feuer und Schwert bekämpfen bevor es zu spät ist.
/RANT OFF

Was sagt Linus?
 
@blöderidiot ( :D ):
Das hab ich mich allerdings auch gefragt. Ich bin ja erst seit zwei oder drei Jahren Linux-Nutzer. Von der Historie habe ich auch einiges mitbekommen, und was ich hier lese, ist ja echt ein tiefer Einschnitt.

Diese Änderungen sind wirklich extrem tiefgreifend. Änderungen in der Verzeichnisstruktur gab es ja in der Vergangenheit auch, aber die waren überschaubar und nach meinem Gefühl vernünftig.

Ich bin ja wirklich kein Linux-Profi (auch wenn ich das gern wäre), aber was Systemd vorhat, erzeugt einfach ein "ungutes" Gefühl... keine Ahnung... :(


Was sagt denn nun Linus eigentlich dazu?
EDIT: Google listet bei den Suchbegriffen "Torvalds systemd" sofort einen Artikel auf
"Linus Torvalds kritisiert Systemd-Entwickler scharf..."
 
Ich muss sagen dass mir das Konzept ganz gut gefällt. Und gerade Snapshots ohne grossen aufwand und oder ein Factory Reset klingen für mich echt super. Werde mich aber erst noch weiter in die Materie einlesen müssen
 
Wolfsrabe schrieb:
Was sagt denn nun Linus eigentlich dazu?
EDIT: Google listet bei den Suchbegriffen "Torvalds systemd" sofort einen Artikel auf
"Linus Torvalds kritisiert Systemd-Entwickler scharf..."

Dabei ist gemeint, dass Linus im April 2014 einen Entwickler (Kay Sievers?) kritisierte, der wesentliche Patches für einen von ihm verursachten Fehler nicht eingepflegt hat.

Das hier ist interessant.
 
Selbstverständlich ist das ein großer Eingriff ins die Verzeichnisstruktur. Aber warum sollte gerade die Verzeichnisstruktur von der Evolution ausgenommen werden? Die grundsätzliche Idee finde ich erstmal gut, auch wenn der Übergang schwierig wird.
Aber wenn sich das Konzept funktioniert und eine gewisse Abwärtskompatibilität für einen Übergang gewährt wird, dann haben beide Varianten, Traditionell und Modern, die Möglichkeit, sich durchzusetzen:

Ist es der Factory Reset, werden sich die Entwickler anpassen und ich denke, dass geht schneller als hier manche denken. Ist es die traditionelle Variante: Dann gibt es halt die Forks und man muss den Factory Reset als einen von vielen Sackgassen in der Linux-Evolution abschreiben.
 
ich finde es erschreckend wie es immer wieder eintwicklungen, die alles nur unnötig verkomplizieren und vieles einfach kaputt machen, schaffen zum standard erklärt zu werden.

das alte init system war dermassen einfach zu handhaben, nein man muss es ersetzen mit systemd. zusätzlich haut man das logging so um, dass man anstatt mit einfachen tools wie less oder ähnlichem eine eigene applikation benötigt um logfiles zu lesen.

sorry wer sich bei windows über eventviewer, registry und ähnlichem aufregt, der hat scheinbar den knall bei systemd noch nicht gehört.
 
Hat eigentlich irgendjemand von euch den Original-Artikel gelesen? Ihr dreht ja schon wieder voll am Rad und malt hier Horrorszenarien aus, dass Linux bald total kaputt ist und dass /var und /etc gelöscht werden.

Lest euch mal das hier durch:
http://0pointer.de/blog/projects/stateless.html schrieb:
We decided to focus on three kinds of systems:

  1. The stateful system, the traditional system as we know it with machine-specific /etc, /usr and /var, all properly populated.
  2. Startup without a populated /var, but with configured /etc. (We will call these volatile systems.)
  3. Startup without either /etc or /var (We will call these stateless systems.).

Wenn man also ein "traditionelles" System hat, dann kann man /var und /etc immer noch schön weiter verwenden. Mit dem zusätzlichen Bonus, dass man eben den "Factory Reset" durchführen kann.

Wenn man aber jetzt z.B. Rechner in einem Kiosk hat, die nach jedem Rebooten wieder auf dem Anfangszustand sein sollen, dann nimt man Option 2. Alle spezifische Konfiguration ist vorhanden ("with configured /etc"), aber der "State" wird jedesmal gelöscht ("without a populated /var").

Man kann natürlich jetzt auch /etc und /var löschen, dann hat man ein "stateless system". Das ist z.B. ganz interessant, wenn das Gerät im Netzwerk bootet und sich seine Konfigurationsdaten eh im Netzwerk besorgt.


Wie man also sieht, ist das eine ERWEITERUNG zum normalen Betriebsmodus, es macht euch eure Linux-Distributionen nicht kaputt. Das Neue an diesem Release sind halt verschiedene Tools, um den Betrieb im "stateless mode" zu erlauben, z.B. ein Tool welches beim Booten die benötigten User automatisch erstellt. Als Beispiel braucht z.B. ntp einen eigenen User. Wenn man kein /etc hat, hat man antürlich auch kein /etc/passwd. Das systemd-sysusers-Tool erstellt dann den User beim Booten automatisch.

Ich finde, ihr regt euch mal wieder zu Unrecht auf, obwohl wahrscheinlich 95% von euch noch nichtmal den Artikel genau gelesen haben.


edit: Wie Lennart auch in seinem Artikel schreibt, gibt es am Anfang noch eine Menge Pakete, die damit nicht zurecht kommen. Sie kommen aber nur mit Modus 2) und 3) nicht zurecht, bei normalen Systemen funktionieren sie natürlich ganz normal weiter (warum sollten sie auch nicht?)
 
blöderidiot schrieb:
Ich hoffe nur, dass wenigstens eine bedeutende Distribution übrigbleibt, die nicht von der systemd-Krankheit befallen wird.
Nein, mit Debian und somit Ubuntu ist die letzte Bastion der Vernunft gefallen. RHEL 7 (und somit CentOS 7) hat die Seuche ja jetzt auch schon an Bord.

Die Komplexität von systemd erfordert eine fortgesetzte Verkomplizierung von systemd.
Tja, genau das war die absolut logische Argumentation, als es bei Debian um systemd vs. Upstart ging. Upstart funktioniert seit Jahren stabil auf Ubuntu (und ein paar anderen Distris), Upstart ist schlicht, Upstart ist schlank, Upstart greift nicht tief ins System.
Aber nöööö, die systemd-Fanatiker mussten sich durchsetzen und alle Warnungen in den Wind schlagen. Jetzt haben wir den Salat, einen Init-Dienst, der sich das GESAMTE OS unter den Nagel reißen will. Also wem bei dem Gedanken an einen Init-Dienst mit solcher Komplexität -> Fehleranfälligkeit nicht das kalte Grausen kommt...

Ich sag euch, mit der weiteren Evolution von systemd kriegen alle Distributionen Windows-artige Zustände. Bluescreen? Schulterzucken & rebooten...

confuso schrieb:
Selbstverständlich ist das ein großer Eingriff ins die Verzeichnisstruktur. Aber warum sollte gerade die Verzeichnisstruktur von der Evolution ausgenommen werden?
Weil der entstehende Schaden beträchtlich ist (JEDES Paket muss umgeschrieben werden, wirklich JEDE Anwendung) und der Nutzen quasi nicht existent ist. Einen Factory Reset kann man auch anders lösen, ohne so einen Schwachsinn.
 
Daaron schrieb:
Weil der entstehende Schaden beträchtlich ist (JEDES Paket muss umgeschrieben werden, wirklich JEDE Anwendung) und der Nutzen quasi nicht existent ist. Einen Factory Reset kann man auch anders lösen, ohne so einen Schwachsinn.


Bitte lies dir den Artikel nochmal durch …
 
Daaron schrieb:
Jetzt haben wir den Salat, einen Init-Dienst, der sich das GESAMTE OS unter den Nagel reißen will. Also wem bei dem Gedanken an einen Init-Dienst mit solcher Komplexität -> Fehleranfälligkeit nicht das kalte Grausen kommt...

Gut dass systemd modular ist und der ganze Kram mit PID 1 wenig zu tun hat, was? ;)
 
Zurück
Oben