Bericht: stretch mit anderem Init-System

Smalltalk
RobertDebiannutzer
Beiträge: 385
Registriert: 16.06.2017 09:52:36

Bericht: stretch mit anderem Init-System

Beitrag von RobertDebiannutzer » 12.03.2018 17:28:42

Hallo,

ich hatte kürzlich mal Lust, ein anderes Init-System auszuprobieren. Gründe spielen jetzt hierfür keine Rolle, ich will hier schließlich nicht die tausendste Diskussion anfangen, ob es systemd braucht oder nicht. Ich möchte nur für Interessierte darstellen, ob/wie man ein anderes Init-System verwenden kann, wenn man das möchte.
Dabei bleibt systemd in meinem jetzigen Entwicklungsstadium für folgende Dinge zuständig (psv ist ein Alias für "ps -eHo pid,pgid,sid,ppid,tty,user,ruser,time,comm"):

Code: Alles auswählen

robert@RobertDebian:~$ psv | grep systemd
  340   340   340     1 ?        root     root     00:00:00   systemd-udevd
 2229  1876  1876     1 ?        root     root     00:00:00   systemd-logind
Und folgendes ist von systemd installiert:

Code: Alles auswählen

ii  libpam-systemd:amd64                 232-25+deb9u2                     amd64        system and service manager - PAM module
ii  libsystemd0:amd64                    232-25+deb9u2                     amd64        systemd utility library
ii  systemd                              232-25+deb9u2                     amd64        system and service manager
ii  systemd-shim                         10-3                              amd64        shim for systemd
Gvfs und udisks2 habe ich deinstalliert, da ich das eigentlich nicht brauche - nicht, weil es nicht weiter funktioniert hätte (s. systemd-shim weiter unten).
Für Audio-CDs habe ich vlc, für Daten-CDs fstab:

Code: Alles auswählen

/dev/sr0				        /media/cdrom0	 udf,iso9660	 user,noauto			 0       0
Für meine Digital-Kamera habe ich zwei - mir ganz neue und sehr gut funktionierende - Programme entdeckt, nämlich Debiangphoto2 und Debiangphotofs. Basieren auf den gleichen gphoto-libraries wie Debiangvfs-backends.

Doch nun zum Init-System. Erst habe ich mir überlegt, ob ich in meiner Experimentierfreude gleich das init der suckless-Leute nehme, also sinit. Wenn man daraus - "the Debian way" - ein schönes deb-Paketchen schnürt, wird das bestimmt nicht übel. Aber das war mir dann doch erstmal zu viel für den Anfang, also habe ich ganz klassisch Debiansysvinit-core installiert, eine der möglichen Abhängigkeiten des "essential"-Paketes Debianinit. Reboot - funktioniert.

Rootless Xorg und alles drum und dran funktioniert immer noch, auch udisks2 würde immer noch funktionieren, wenn ich es nicht deinstalliert hätte. Das liegt an Debiansystemd-shim, einer Kompartibilitäts-Schicht zwischen systemd und einem beliebigen Init-System.

Insgesamt ist zu sagen: Wenn sich die Debian-Maintainer schon Mühe geben, dass man ein anderes Init-System nutzen kann, warum soll man's dann nicht mal probieren? Ich jedenfalls hatte Lust dazu, weil ich auch zusätzliche Funktionen von systemd nicht brauche (obwohl eine svg-Grafik des Boot-Vorgangs natürlich schon cool ist... :mrgreen: ).
Außerdem mag ich "ursprüngliche" und klassische Methoden, obwohl ich sicher wesentlich jünger bin als der Alters-Durchschnitt hier im Forum, wenn ich selbigen mal auf 40 Jahre schätze.

Vielleicht findet es der ein oder andere Leser ja interessant, diesen Beitrag hier zu lesen. Ich werde jetzt mal sehen, ob ich systemd wegen logind und polkit noch behalte oder wie ich das mache.
Systemd-udevd hängt - anders als der Prozessname suggeriert - eh nicht von systemd ab. Zwar sieht es erst so aus:

Code: Alles auswählen

robert@RobertDebian:~$ apt-file search systemd-udev
udev: /lib/systemd/system/sockets.target.wants/systemd-udevd-control.socket
udev: /lib/systemd/system/sockets.target.wants/systemd-udevd-kernel.socket
udev: /lib/systemd/system/sysinit.target.wants/systemd-udev-trigger.service
udev: /lib/systemd/system/sysinit.target.wants/systemd-udevd.service
udev: /lib/systemd/system/systemd-udev-settle.service
udev: /lib/systemd/system/systemd-udev-trigger.service
udev: /lib/systemd/system/systemd-udevd-control.socket
udev: /lib/systemd/system/systemd-udevd-kernel.socket
udev: /lib/systemd/system/systemd-udevd.service
udev: /lib/systemd/systemd-udevd
udev: /usr/share/man/man8/systemd-udevd-control.socket.8.gz
udev: /usr/share/man/man8/systemd-udevd-kernel.socket.8.gz
udev: /usr/share/man/man8/systemd-udevd.8.gz
udev: /usr/share/man/man8/systemd-udevd.service.8.gz
Aber: Das alles ist im Paket Debianudev, welches nicht vom Paket "systemd" abhängt:

Code: Alles auswählen

robert@RobertDebian:~$ aptitude show udev | grep Depends
Depends: libacl1 (>= 2.2.51-8), libblkid1 (>= 2.19.1), libc6 (>= 2.17), libkmod2 (>= 5~), libselinux1 (>= 2.1.9), adduser, libudev1 (= 232-25+deb9u2), lsb-base (>= 3.0-6), util-linux (>= 2.27.1), procps
PreDepends: dpkg (>= 1.17.14)

RobertDebiannutzer
Beiträge: 385
Registriert: 16.06.2017 09:52:36

Re: Bericht: stretch mit anderem Init-System

Beitrag von RobertDebiannutzer » 22.03.2018 16:12:01

Weiß eigentlich jemand von euch, was systemd-logind genau macht?
Wenn ich versuche, rootless X ohne systemd-logind zu erreichen, sind folgende Schritte notwendig:

# chown :input /usr/lib/xorg/Xorg
# chmod g+s /usr/lib/xorg/Xorg
Anmerkung: /usr/bin/X ist ein Link zu /usr/bin/Xorg, welches ein Script ist, das /usr/lib/xorg/Xorg ausführt.

Nun funktioniert input in rootless X auch ohne systemd-logind.
Die einzige weitere Auswirkung, die ich bis jetzt entdeckt habe, ist, dass der von Xorg gestartete backlight-helper für die integrierte Intel-Grafikkarte in der Prozessliste nun als "pkexec <defunct>" auftaucht.
Backlight lässt sich aber dennoch mit den entsprechenden Tasten regulieren (benutzter Treiber für X ist "intel").
Liegt wahrscheinlich an KMS, denn die Bildschirmhelligkeit lässt sich ja auch in den ttys mit den entsprechenden Tasten regulieren.

Aber wie ist mein Vorgehen wohl von der Sicherheit zu bewerten und macht logind es anders? :?:

Benutzeravatar
MartinV
Beiträge: 788
Registriert: 31.07.2015 19:38:52
Wohnort: Hyperion
Kontaktdaten:

Re: Bericht: stretch mit anderem Init-System

Beitrag von MartinV » 22.03.2018 16:35:25

Interessant, danke für den Bericht!

Ich kann Dir Deine Fragen nicht ganz beantworten, aber ein paar Aspekte beisteuern.

Von logind gibt es einen Fork ohne systemd-Abhängigkeit: elogind.
elogind im Gentoo Wiki: https://wiki.gentoo.org/wiki/Elogind
elogind ganz neu als Paket bei antiX (basiert auf debian):
Meldung: https://antixlinux.com/elogind-available/
Pakete: http://nl.mxrepo.com/antix/stretch/pool/main/e/elogind/

Deine Xorg-Änderungen entsprechen weitgehend dem Effekt des Paketes Debianxserver-xorg-legacy. Konfiguration ist möglich mit /etc/X11/Xwrapper.conf oder "dpkg-reconfigure xserver-xorg-legacy".

/usr/bin/X lief früher-legacy als suid Wrapper für Xorg. Das war in jessie auch noch so. Die Rechteregulierung ist jetzt irgendwie anders gelöst, um die Risiken duch setuid zu verringern. Die Details sind für mich aber nebulös, würde mich auch interessieren.

Alternativ ist es möglich, weston mit Xwayland anstatt Xorg zu verwenden. Das dürfte Risiken durch X deutlich verringern.
Die Vernunft kann einem schon leidtun. Sie verliert eigentlich immer.

RobertDebiannutzer
Beiträge: 385
Registriert: 16.06.2017 09:52:36

Re: Bericht: stretch mit anderem Init-System

Beitrag von RobertDebiannutzer » 22.03.2018 21:42:26

Aber X lief doch früher als root-Prozess?
Mit meinen Änderungen läuft X "rootless", also als User-Prozess - so wie bei Einsatz von systemd-logind.
Im Moment nutze ich auch logind noch, weil ich das Paket "systemd" (noch?) wegen polkit installiert habe. Ich habe aber eben schon mal getestet, ob/wie es ohne systemd-logind gehen könnte.
Schön wäre es schon, wenn die systemd-Alternativen vollumfänglich in Debian Einzug halten würden, Devuan hat da ja schon Arbeit geleistet. Aber gut, das kommt natürlich darauf an, ob sich für sowas ein Maintainer findet (s. "Wunsch-Thread" für Buster hier im Forum).

Benutzeravatar
MartinV
Beiträge: 788
Registriert: 31.07.2015 19:38:52
Wohnort: Hyperion
Kontaktdaten:

Re: Bericht: stretch mit anderem Init-System

Beitrag von MartinV » 22.03.2018 21:52:41

RobertDebiannutzer hat geschrieben: ↑ zum Beitrag ↑
22.03.2018 21:42:26
Aber X lief doch früher als root-Prozess?
Ja, war bis jessie noch Standard.
RobertDebiannutzer hat geschrieben: ↑ zum Beitrag ↑
22.03.2018 21:42:26
Mit meinen Änderungen läuft X "rootless", also als User-Prozess -
Nein, Du hast das setgid bit gesetzt:

Code: Alles auswählen

# chmod g+s /usr/lib/xorg/Xorg
Wenn ich nicht ganz falsch liege, wird Xorg jetzt als root Prozeß gestartet, weil es das setgid bit hat, egal welcher User es startet. Überprüf mal die Ausgabe von

Code: Alles auswählen

ps ux | grep Xorg
Die Vernunft kann einem schon leidtun. Sie verliert eigentlich immer.

RobertDebiannutzer
Beiträge: 385
Registriert: 16.06.2017 09:52:36

Re: Bericht: stretch mit anderem Init-System

Beitrag von RobertDebiannutzer » 22.03.2018 21:57:52

ps muss ich glaube ich nicht prüfen, denn ich habe vorher ja die Gruppe von Xorg nach "input" geändert. Wenn ich das Prinzip von setgid richtig verstehe, bedeutet das:
Ich starte Xorg per startx als User, er läuft also als User "robert" und Gruppe "robert". Wegen dem setgid, hat Xorg aber automatisch die Berechtigungen der Gruppe "input", auch wenn der ausführende User "robert" nicht selber in der Gruppe "input" ist. Das ändert allerdings nichts an der Tatsache, dass der Prozess "Xorg" als robert:robert läuft.
Aber ich schau gleich nochmal nach (muss nur erst X beenden, logind killen, deaktivieren usw.).

Benutzeravatar
MartinV
Beiträge: 788
Registriert: 31.07.2015 19:38:52
Wohnort: Hyperion
Kontaktdaten:

Re: Bericht: stretch mit anderem Init-System

Beitrag von MartinV » 22.03.2018 22:11:15

Ok, das habe ich vorhin nicht richtig beachtet, Du hast ja die Gruppe von Xorg geändert:

Code: Alles auswählen

 # chown :input /usr/lib/xorg/Xorg
Jetzt komme ich etwas ins Schwimmen ...

Xorg müßte durch die Gruppe input (+setgid) Zugriff auf Eingabegeräte wie Maus und Tastatur bekommen. Es braucht aber auch Zugriff auf Ausgabegeräte, mindestens den Monitor (Gruppe video). Wie ist das gegeben? Oder bist Du als Benutzer in der Gruppe video?

Könnte Xorg als root:root ohne setuid/setgid starten, wenn der Benutzer in den Gruppen input und video ist? Oder ist es besser, nur Xorg die input-Gruppe zu überlassen?

(Edit: Oder wird Gruppe video für Bildschirmausgabe gar nicht benötigt?)
Die Vernunft kann einem schon leidtun. Sie verliert eigentlich immer.

RobertDebiannutzer
Beiträge: 385
Registriert: 16.06.2017 09:52:36

Re: Bericht: stretch mit anderem Init-System

Beitrag von RobertDebiannutzer » 22.03.2018 22:20:08

Voilà:

Code: Alles auswählen

robert@RobertDebian:~$ ps ux | grep Xorg
robert   18536  3.4  0.8 289196 33948 tty1     Sl   22:09   0:01 /usr/lib/xorg/Xorg -nolisten tcp -nolisten local :0 vt1 -keeptty -auth /tmp/user/1000/serverauth.kcyETIRkmb tty
robert   19235  0.0  0.0  14320   960 pts/1    S+   22:10   0:00 grep --color=auto Xorg
Auschnitt aus "psv" (mein alias für 'ps -eHo pid,pgid,sid,ppid,tty,user,ruser,time,comm'):

Code: Alles auswählen

18494 18494 18494     1 tty1     root     root     00:00:00   login
18504 18504 18494 18494 tty1     robert   robert   00:00:00     bash
18513 18513 18494 18504 tty1     robert   robert   00:00:00       startx
18535 18513 18494 18513 tty1     robert   robert   00:00:00         xinit
18536 18536 18494 18535 tty1     robert   robert   00:00:02           Xorg
18542 18536 18494 18536 tty1     root     robert   00:00:00             pkexec <defunct>
18550 18550 18494 18535 tty1     robert   robert   00:00:00           i3
Nix logind... :mrgreen:

Code: Alles auswählen

robert@RobertDebian:~$ psv | grep logind
robert@RobertDebian:~$ 
Huh, Dein neuer Beitrag kam gerade, als ich meinen abschicken wollte...
Also:
Ja, ich bin in Gruppe "video". In Gruppe "input" bin ich nicht, denn dann hätte ich bzw. alle Prozesse, die unter meinem User gestartet werden, z.B. Zugriff auf alles in /dev/input. Ist glaube ich nicht so gut. Habe mich da auch an dem entsprechenden Eintrag im Gentoo-Wiki orientiert: https://wiki.gentoo.org/wiki/Non_root_Xorg (unter "Security concerns" wird davon abgeraten, den user der Gruppe "input" hinzuzufügen, unter "Alternative method" steht mein derzeitiger Ansatz).

Jetzt wäre wirklich mal interessant, was eigentlich systemd-logind macht. Leider reichen meine Kenntnisse in C nicht aus, um den Code einigermaßen zu verstehen und eine "user-readable" Dokumentation habe ich leider noch nicht gefunden.

RobertDebiannutzer
Beiträge: 385
Registriert: 16.06.2017 09:52:36

Re: Bericht: stretch mit anderem Init-System

Beitrag von RobertDebiannutzer » 22.03.2018 22:30:05

Habe noch Dein Edit gelesen. Also wenn ich mich bei Gruppe "video" rausnehme und versuche, X zu starten (ohne systemd-logind), funktioniert das nicht.
Grafikkarte: integrierte Intel-Card

RobertDebiannutzer
Beiträge: 385
Registriert: 16.06.2017 09:52:36

Re: Bericht: stretch mit anderem Init-System

Beitrag von RobertDebiannutzer » 22.03.2018 22:36:39

Wie ich schon vermutete: Wenn ich mich aus der Gruppe "video" rausnehme und systemd-logind nutze, funktioniert es.
Also dieses logind macht schon so einiges... :|

Edit: Korrektur

Benutzeravatar
MartinV
Beiträge: 788
Registriert: 31.07.2015 19:38:52
Wohnort: Hyperion
Kontaktdaten:

Re: Bericht: stretch mit anderem Init-System

Beitrag von MartinV » 22.03.2018 22:49:18

RobertDebiannutzer hat geschrieben: ↑ zum Beitrag ↑
22.03.2018 22:30:05
Also wenn ich mich bei Gruppe "video" rausnehme und versuche, X zu starten (ohne systemd-logind), funktioniert das nicht.
Danke fürs Austesten!
RobertDebiannutzer hat geschrieben: ↑ zum Beitrag ↑
22.03.2018 22:36:39
Also dieses logind macht schon so einiges... :|
Die soweit überschaubarste Doku zu systemd-logind bietet freedesktop.org: https://www.freedesktop.org/software/sy ... rvice.html

Ein wesentlicher Punkt scheint das "session management" zu sein. Dessen Rolle ist mir auch nicht ganz klar, ist aber wohl mit der Policykit-Geschichte eng verwoben.


Ich mache gerade ein paar Experimente mit Docker Containern, in denen ich mal gnadenlos ein "apt-get remove -y systemd" laufen lasse ... :twisted:
Bereits auffallend ist, daß ersatzweise Debianconsolekit installiert wird, das auch für session management zuständig ist
Die Vernunft kann einem schon leidtun. Sie verliert eigentlich immer.

RobertDebiannutzer
Beiträge: 385
Registriert: 16.06.2017 09:52:36

Re: Bericht: stretch mit anderem Init-System

Beitrag von RobertDebiannutzer » 23.03.2018 10:19:42

Ob Du mit consolekit nicht eher vom Regen in die Trauf kommst?
https://bugs.debian.org/cgi-bin/bugrepo ... bug=892738
Ich habe nicht alles gelesen, aber das hier ist denke ich mal wichtig:
You said, it "forces a dependency to a special init system".
And this is simply wrong.
You are mixing up systemd as init system with systemd-logind here.
systemd-logind is a maintained alternative to consolekit.
consolekit is dead upstream, unmaintained and has many design flaws.
That it breaks certain setups like in #888892 was just the last straw
that broke the camels back.

Keep in mind, I'm the former maintainer of consolekit, so I very much
know about its shortcomings.
Wenn wir mal davon ausgehen, dass der keinen Quatsch erzählt (Michael Biebl ist auch Maintainer von systemd), dann wäre consolekit jetzt nicht so das Gelbe vom Ei.
Alternativen wie consolekit2 oder das logind von Gentoo schaue ich mir mal noch genauer an, hoffentlich ist da auch die Dokumentation besser. Schließlich geht es ja nicht nur darum, alleinstehende Alternativen zum Gesamt-systemd-Paket zu haben, sondern auch transparentere Alternativen.

Benutzeravatar
MartinV
Beiträge: 788
Registriert: 31.07.2015 19:38:52
Wohnort: Hyperion
Kontaktdaten:

Re: Bericht: stretch mit anderem Init-System

Beitrag von MartinV » 23.03.2018 10:37:59

RobertDebiannutzer hat geschrieben: ↑ zum Beitrag ↑
23.03.2018 10:19:42
Ob Du mit consolekit nicht eher vom Regen in die Trauf kommst?
Vermutlich ja ...
Ich habe schon einmal einige Experimente damit gemacht und war eher frustriert.
Und in Deinem Zitat rät selbst der consolekit-Entwickler davon ab; das will was heißen.

Ich habe mein Setup etwas verändert. Anstatt systemd zu entfernen, installiere ich runit und runit-sysv. Das entfernt systemd, ohne consolekit zu installieren. Ich habe mich aud die Schnelle für runit statt sysvinit entschieden, weil ich es (etwas) besser kenne als sysvinit.

Schwammige Erkenntnis: Soweit ich bisher halbwegs verstanden habe, geht es bei logind/consolekit/elogind vor allem um ein session management, das vor allem für Multiuser-Betrieb interessant ist. Es macht irgend etwas mehr als das klassische /bin/login. Bei einem login mit /bin/login wird logind automatisch aufgerufen.
Erkennbar gebraucht wird es von policykit, das für mich auch ein sehr unklarer Bereich mit zweifelhaftem Nutzen ist.
RobertDebiannutzer hat geschrieben: ↑ zum Beitrag ↑
23.03.2018 10:19:42
Schließlich geht es ja nicht nur darum, alleinstehende Alternativen zum Gesamt-systemd-Paket zu haben, sondern auch transparentere Alternativen.
Guter Ansatz! Ich neige dazu, alles herauszuwerfen, was ich nicht verstehe; wenn mir dann etwas fehlen sollte, kann ich es ja noch einmal angucken. Policykit, logind, consolekit und dbus sind für mich sehr unklare Bereiche. systemd habe ich zumindet soweit verstanden, daß ich ein paar eigene units zum Laufen bekomme.
Bei Experimenten in Docker Containern fällt mir auf, daß vieles bereits vom dbus Dämon erledigt wird, und auch der oft verzichtbar ist.

Edit; Ich bin gerade auf ein interessantes Wiki zum Thema gestoßen: http://without-systemd.org/wiki/index.php/Main_Page
Die Vernunft kann einem schon leidtun. Sie verliert eigentlich immer.

RobertDebiannutzer
Beiträge: 385
Registriert: 16.06.2017 09:52:36

Re: Bericht: stretch mit anderem Init-System

Beitrag von RobertDebiannutzer » 23.03.2018 12:19:31

Zu der "without-systemd"-Wiki: Naja, manche systemd-Gegner machen mir persönlich zu viel Glaubenskrieg. Von der Website kann man sich möglicherweise den ein oder anderen technischen Tipp holen, aber sowas wie das folgende Zitat finde ich einfach nur bescheuert:
Arguments against systemd - a wiki sub-page containing discussion+links arranged under topical subsections:
Breaking promises, immaturity, and (in)stability
Scope creep
Absurd bugs and responses
Conceptional problems
Scope creep leads to vulnerabilities
Poor design
Ignorance of fundamental operating system concepts
Meiner Meinung nach ist das Scheiße. Systemd ist z.B. - jedenfalls bei mir in stretch - einfach nicht instabil. Solche Glaubenskrieger diskreditieren alle, die sich alternative Möglichkeiten wünschen.
MartinV hat geschrieben: ↑ zum Beitrag ↑
23.03.2018 10:37:59
Guter Ansatz! Ich neige dazu, alles herauszuwerfen, was ich nicht verstehe; wenn mir dann etwas fehlen sollte, kann ich es ja noch einmal angucken.
Genau so halte ich es auch - egal ob ein Projekt nun systemd heißt oder sonstwie. Natürlich kann man als "nur User" nicht immer alles vollumfänglich verstehen, doch gerade bei wichtigen System-Diensten finde ich es wichtig, dass man sich mit Hilfe einer guten Dokumentation auch als User ein grundlegendes Verständnis erarbeiten kann, also Prinzipien und Funktionen verstehen kann.

Im Readme von elogind wird ein bisschen was gesagt zu der Funktionsweise. Und da elogind ja eine (etwas modifizierte) Abspaltung von systemd-logind von systemd ist, lässt sich da auch bezüglich systemd-logind etwas mehr verstehen. Ausschnitt:
Unlike systemd, whose logind arranges to manage resources for user
sessions via RPC calls to systemd, in elogind there is no systemd so
there is no global cgroup-based resource management. This has a few
implications:

* Elogind does not create "slices" for users. Elogind will not
record that users are associated with slices.

* The /run/systemd/slices directory will always be empty.

* Elogind does not have the concept of a "scope", internally, as
it's the same as a session. Any API that refers to scopes will
always return an error code.

On the other hand, elogind does use a similar strategy to systemd in
that it places processes in a private cgroup for organizational
purposes, without installing any controllers (see
http://0pointer.de/blog/projects/cgroup ... roups.html). This
allows elogind to map arbitrary processes to sessions, even if the
process does the usual double-fork to be reparented to PID 1.
Jetzt muss ich mir mal cgroups anschauen. (Ich habe die schon so manches Mal in der Ausgabe von "mount" gesehen...)

guennid

Re: Bericht: stretch mit anderem Init-System

Beitrag von guennid » 23.03.2018 12:25:58

Wir haben hier ebenfalls einen Wiki-Eintrag zu Debian ohne systemd (https://wiki.debianforum.de/Debian_ohne_systemd). Den benutze ich, bei Systemen, bei denen ich ohne systemd auskommen will. Da habe ich weder mit systemd-shim noch mit logind zu tun.

breakthewall
Beiträge: 507
Registriert: 30.12.2016 23:48:51

Re: Bericht: stretch mit anderem Init-System

Beitrag von breakthewall » 23.03.2018 12:54:16

Ignorance of fundamental operating system concepts
Dieses Argument stinkt schon nach religiös angehauchtem Fanatismus. Als könne es nur einen einzigen Weg geben. Was somit im Geiste weniger nicht vorstellbar ist, darf auch nicht sein. Und was einer über 50 Jahre alten Unix-Philosophie zuwider läuft, die heutige Anforderungen nicht ansatzweise auf dem Schirm hatte, kann erst recht nicht angehen. Um mehr geht es idR. nicht. So wird man zumindest von der großen Masse nicht ernst genommen.

RobertDebiannutzer
Beiträge: 385
Registriert: 16.06.2017 09:52:36

Re: Bericht: stretch mit anderem Init-System

Beitrag von RobertDebiannutzer » 25.03.2018 23:37:15

@guennid: Und rootless X lässt Du einfach?
Das mit dem autologin mittels getty* in inittab aus dem Artikel finde ich praktisch, das mache ich vielleicht auch.

@breakthewall: Sag' ich ja.
Zu Unix: Das wurde da ja gar nicht namentlich angesprochen. Ich zweifele auch daran, ob jeder wirklich darüber informiert ist, was "Unix" ausmacht.** Obwohl man ja den Begriff eines "unixoiden" Betriebssystems oft hört.
Als ich kürzlich mal nachschaute, was "Unix" eigentlich genau bedeutet, war ich total überrascht, was da alles dahintersteckt, was über "do one thing and do it well" hinausgeht, - s. z.B.:
https://en.wikipedia.org/wiki/Unix_philosophy
oder auch in Deutsch: https://de.wikipedia.org/wiki/Unix-Philosophie

Cgroups sind etwas kompliziert. Mal sehen, ob ich da noch etwas mehr dahinter komme, auch dahingehend, was die jetzt genau mit X machen. Wenn jemand da zufällig bereits eine Quelle kennt: Natürlich immer gerne her damit... :wink:

*getty ist übrigens in stretch ein Link zu agetty.
Apropos: Was bedeuten eigentlich Nummern wie 38400 in einer inittab-Zeile wie:

Code: Alles auswählen

1:2345:respawn:/sbin/getty 38400 tty1
**Ich meine damit nicht Dich, sondern das ist eine generelle Überlegung, die mir kam, weil es mir so ging.

RobertDebiannutzer
Beiträge: 385
Registriert: 16.06.2017 09:52:36

Re: Bericht: stretch mit anderem Init-System

Beitrag von RobertDebiannutzer » 17.04.2018 10:27:30

Vor einigen Tagen habe ich jetzt doch mal systemd, libpam-systemd und polkit ganz runtergenommen (gemeinsam mit den Paketen, die nur Abhängigkeiten von diesen Programmen sind, so wie systemd-shim o.ä.).
Ich bin eh nicht so der Nutzer von grafischen root-Programmen und polkit war noch das letzte, was mich daran gehindert hat, libpam-systemd und damit auch systemd zu entfernen.

Jetzt bin ich aber auf ein komisches Problem gestoßen:

Also erstmal wollte pulseaudio nicht laufen. Das habe ich nach einiger googelei durch Entfernen von folgendem Schnipsel in "~/.config/pulse/default.pa" gelöst.

Code: Alles auswählen

### If autoexit on idle is enabled we want to make sure we only quit
### when no local session needs us anymore.
.ifexists module-console-kit.so
load-module module-console-kit
.endif
.ifexists module-systemd-login.so
load-module module-systemd-login
.endif
Nun ist wieder alles fein, außer firefox (Release, nicht ESR aus den Paketquellen), wenn er im default-Profile von firejail "0.9.52-2~bpo9+2" läuft.
Will ich dann z.B. ein Video auf youtube hören, meldet mir Firefox, dass ich doch bitteschön die erforderliche pulseaudio-Software installieren soll.
Lasse ich firefox ohne firejail laufen, besteht das Problem nicht!
Vor dem Entfernen von systemd und libpam-systemd (und damit logind) ging aber alles, auch mit dem (gleichen!) firejail-Profil und dem gleichen firefox.
Was ist denn hier los? 8O

OT: Warum hat eigentlich gefühlt so ziemlich jedes Progamm eine eigene Syntax für Konfigurationsdateien? (s. pulse-Schnipsel) Man könnte das doch alles im shell-script-Stil machen und nur Eigenes anfügen, wo es aufgrund von speziellen Funktionen nötig ist.

Benutzeravatar
MartinV
Beiträge: 788
Registriert: 31.07.2015 19:38:52
Wohnort: Hyperion
Kontaktdaten:

Re: Bericht: stretch mit anderem Init-System

Beitrag von MartinV » 17.04.2018 12:31:43

Ich habe diese Tage mit elogind in docker Containern experimentiert und bekomme es jetzt zum Laufen. Wenn Du Programme mit systemd-logind Abhängigkeit zum laufen bringen willst, ist elogind ein guter Ersatz. Es geht dabei vor allem um Session Management. (Consolekit erfüllt(e) auch diesen Zweck, wird aber nicht mehr gepflegt. Es gibt ein Consolekit2, das noch in Entwicklung ist.)
RobertDebiannutzer hat geschrieben: ↑ zum Beitrag ↑
17.04.2018 10:27:30
Will ich dann z.B. ein Video auf youtube hören, meldet mir Firefox, dass ich doch bitteschön die erforderliche pulseaudio-Software installieren soll.
Lasse ich firefox ohne firejail laufen, besteht das Problem nicht!
Bekommst Du eine Ausgabe von "pax11publish -d"? Kannst Du das auch in firejail ausführen?
Von docker Containern weiß ich, daß ich pulseaudio über TCP oder mit Bereitstellen vom pulse unix socket isolierten Programmen zur Verfügung stellen kann.
RobertDebiannutzer hat geschrieben: ↑ zum Beitrag ↑
17.04.2018 10:27:30
OT: Warum hat eigentlich gefühlt so ziemlich jedes Progamm eine eigene Syntax für Konfigurationsdateien?
https://xkcd.com/927/
*getty ist übrigens in stretch ein Link zu agetty.
Apropos: Was bedeuten eigentlich Nummern wie 38400
Das ist die BAUD Rate von deinem Analogmodem, auf das Du den Telefonhörer legst, wenn Du ins Internet gehst. :mrgreen:
Die Angabe der BAUD Rate ist sinnvoll für echte Terminals aus den 70er Jahren, aber bei einer virtuellen Konsole ziemlich sinnfrei.
Zuletzt geändert von MartinV am 17.04.2018 14:22:49, insgesamt 1-mal geändert.
Die Vernunft kann einem schon leidtun. Sie verliert eigentlich immer.

tobo
Beiträge: 1953
Registriert: 10.12.2008 10:51:41

Re: Bericht: stretch mit anderem Init-System

Beitrag von tobo » 17.04.2018 13:34:13

RobertDebiannutzer hat geschrieben: ↑ zum Beitrag ↑
17.04.2018 10:27:30
[...] was mich daran gehindert hat, libpam-systemd und damit auch systemd zu entfernen.
Und dein X läuft noch immer rootless?

guennid

Re: Bericht: stretch mit anderem Init-System

Beitrag von guennid » 17.04.2018 16:44:47

@guennid: Und rootless X lässt Du einfach?
Irgendwie missverständlich formuliert. Wenn du meinst: "Lässt du /usr/lib/xorg/Xorg mit Root-Rechten laufen?" ist die Antwort: Ja.

In diesem Zusammenhang hätte ich eine Frage: Wird wayland von systemd abhängig sein?

Benutzeravatar
MartinV
Beiträge: 788
Registriert: 31.07.2015 19:38:52
Wohnort: Hyperion
Kontaktdaten:

Re: Bericht: stretch mit anderem Init-System

Beitrag von MartinV » 17.04.2018 17:12:46

guennid hat geschrieben: ↑ zum Beitrag ↑
17.04.2018 16:44:47
Wird wayland von systemd abhängig sein?
Nein.
Es braucht derzeit lediglich ein XDG_RUNTIME_DIR, daß gewöhnlich von dbus angelegt wird. Kann man aber auch manuell anlegen. Zukünftig soll auch diese Notwendigkeit wegfallen. XDG_RUNTIME_DIR wird benötigt, um dem Unix Socket WAYLAND_DISPLAY einen Platz zu geben. Zukünftig soll man aber in WAYLAND_DISPLAY einen absoluten Pfad angeben können; derzeit ist nur der Socketname erlaubt.

Edit: Eine Abhängigkeit von udev oder eudev besteht auch.
Zuletzt geändert von MartinV am 21.04.2018 13:40:09, insgesamt 1-mal geändert.
Die Vernunft kann einem schon leidtun. Sie verliert eigentlich immer.

RobertDebiannutzer
Beiträge: 385
Registriert: 16.06.2017 09:52:36

Re: Bericht: stretch mit anderem Init-System

Beitrag von RobertDebiannutzer » 17.04.2018 18:29:23

Der Reihe nach:

@MartinV, 1. Beitrag:
Du hast elogind für stretch kompiliert und unter stretch zum Laufen gebracht? Geht das so einfach?
Welche Schritte hast Du außer dem Kompilieren vornehmen müssen?
Wenn das alles problemlos klappen würde, könnte man daraus dann ja vielleicht auch ein lokales Paketchen machen, welches libpam-systemd bereitstellt...
Allerdings natürlich nur unter der Vorraussetzung, dass man damit nicht in "Don't break Debian" tappt und sich sozusagen selbst ins Bein schießt... :?

"pax11publish -d" erzeugt bei mir keine Ausgabe, weder mit noch ohne firejail. Was heißt das?

Danke übrigens wegen der Auklärung bezüglich der BAUD Rate.

bzgl. OT: :mrgreen:


@tobo:
Ja, jetzt eben mit den genannten Modifikationen an der X-binary (/usr/lib/xorg/Xorg), also "chown :input" und "chmod g+s". (Und ich bin in der video-Gruppe.)
Ich finde es sehr wichtig, dass X rootless laufen kann. Mir scheint das wichtiger, als die Wahl des init-Systems oder so, denn schließlich wird ja immer gesagt, wie groß, unübersichtlich und wirr der X-Code sei - da würde ich mich unwohl fühlen, den mit root-Rechten laufen zu lassen...

Möglicherweise ist auch schon "chown :input" und "chmod g+s" aus Sicherheitsgründen unsicherer als das, was (e)logind macht? Mal sehen, ob ich das irgendwann noch herausfinden werde...


@guennid:
Stimmt, war missverständlich. Hast es aber richtig verstanden.
Aber ist Dir das nicht zu unsicher, X mit root-Rechten zu versehen?

DebianWeston z.B. hängt nicht von systemd ab, nur von der library Debianlibsystemd0, aber die hängt nicht von systemd als init-System oder von systemd als Paket ab.


@MartinV, 2. Beitrag:
Debianudev wurde bei Debian ja eh schon in ein separates Paket ohne systemd-Abhängigkeiten gesteckt.

Benutzeravatar
MartinV
Beiträge: 788
Registriert: 31.07.2015 19:38:52
Wohnort: Hyperion
Kontaktdaten:

Re: Bericht: stretch mit anderem Init-System

Beitrag von MartinV » 17.04.2018 18:44:56

RobertDebiannutzer hat geschrieben: ↑ zum Beitrag ↑
17.04.2018 18:29:23
Du hast elogind für stretch kompiliert und unter stretch zum Laufen gebracht?
Hm, nein. Ich habe ein devuan ascii docker Image mit elogind zum Laufen gebracht. Unter debian stretch habe ich noch keine Versuche gemacht. Man könnte es mal darauf ankommen lassen, stretch in einer VM zu installieren und ihm das elogind-Paket von devuan unterzujubeln.
elogind im docker container unter einem systemd host war eine Herausforderung für sich, siehe: https://github.com/elogind/elogind/issues/52
RobertDebiannutzer hat geschrieben: ↑ zum Beitrag ↑
17.04.2018 18:29:23
Wenn das alles problemlos klappen würde, könnte man daraus dann ja vielleicht auch ein lokales Paketchen machen, welches libpam-systemd bereitstellt...
Es gibt ein Paket libpam-elogind.
RobertDebiannutzer hat geschrieben: ↑ zum Beitrag ↑
17.04.2018 18:29:23
udev wurde bei Debian ja eh schon in ein separates Paket ohne systemd-Abhängigkeiten gesteckt.
Bist Du sicher, daß es ohne systemd Umgebung läuft? udev war seinerzeit, vor eudev, der größte Problempunkt für devuan.
RobertDebiannutzer hat geschrieben: ↑ zum Beitrag ↑
17.04.2018 18:29:23
"pax11publish -d" erzeugt bei mir keine Ausgabe, weder mit noch ohne firejail. Was heißt das?
Pulseaudio trägt einige Daten in die X Server Umgebungsvariablen ein, so daß andere Programme pulseaudio leichter finden können. Das scheint es bei Dir nicht gemacht zu haben. Beispielausgabe bei mir:

Code: Alles auswählen

$ pax11publish -d
Server: {1b453596804544d385d72d36f5482faf}unix:/run/user/1000/pulse/native
Cookie: 567cd4f792b44a2b161658bb272d97e446528d3e2ac166971c14225caee7810e170712a992e2a3b36b53f23029cf73243fbe109ed034a5b672fa17ef5df55795916781f0c8ea16b7e782692cba865d53c5fb2a4cca03a9ed14929691867760485913ffc681bdadc93757e572694f74c0c5a699391fb54010aa557b58a63ae2b7960ed42b9096751d060ff980c06ef565faaa458d0104756c0ba8649e0511f0db19ecb899693c69e5fbb3c46600079c3709fbb87d3d73f19a82dcd0a34b19a3e2586ac4448bb0756c422286b8d22780ae40f6b10d7cc5e93e6a48a8546c5db275696b23ec84da4373483625fa1337f3876f629b82f094e7995d4a85d869a0a6a0
Versuch mal,mit "pax11publish -e" die Daten in den X server einzutragen. "man pax11publish" kann Dir ein paar Hintergründe erzählen.
Die Vernunft kann einem schon leidtun. Sie verliert eigentlich immer.

tobo
Beiträge: 1953
Registriert: 10.12.2008 10:51:41

Re: Bericht: stretch mit anderem Init-System

Beitrag von tobo » 17.04.2018 18:47:49

RobertDebiannutzer hat geschrieben: ↑ zum Beitrag ↑
17.04.2018 18:29:23
@tobo:
Ja, jetzt eben mit den genannten Modifikationen an der X-binary (/usr/lib/xorg/Xorg), also "chown :input" und "chmod g+s". (Und ich bin in der video-Gruppe.)
Nochmal gezielt: Du hast ein rootless-X, mit sysvinit als init-System und ohne installiertes libpam-systemd?

Antworten