Monokultur

[Tim Ritberg]

Und es geht weiter:
https://linuxnews.de/debian-diskutiert-ueber-systemd-boot/

Tim

[Marco Moock]

Post by Tim Ritberg
https://linuxnews.de/debian-diskutiert-ueber-systemd-boot/

Erstmal nur im Expertenmodus, GRUB2 bleibt Standard.

Fragt sich, wie lange und vor allem wie das dann bei BIOS-Systemen
laufen soll. Der Standardinstaller müsste dann ja für beide Fälle
gewappnet sein und getestet werden.

[Ralph Aichinger]

Post by Tim Ritberg
https://linuxnews.de/debian-diskutiert-ueber-systemd-boot/

Die Logik kann ich nicht nachvollziehen: Ein weiterer EFI-Bootloader
soll in Debian kommen, aber du nennst das "Monokultur"?

/ralph

[Marco Moock]

Post by Ralph Aichinger
Die Logik kann ich nicht nachvollziehen: Ein weiterer EFI-Bootloader
soll in Debian kommen, aber du nennst das "Monokultur"?

Die Verwaltung und das Testen mehrerer macht mehr Aufwand. Früher oder
später wird es einen "Standardweg" geben. Ist das systemd-irgendwas,
ist man an systemd festgenagelt.

sysvinit wurde ja auch verdrängt. Ob man das noch in Debian einfast so
installieren kann ohne Zirkus, weiß ich nicht.
Jedenfalls müssen Pakete auf systemd-Units umstellen und daher 2 Sachen
pflegen. Ob das noch überall passiert, weiß ich nicht.

[Ralph Aichinger]

Post by Marco Moock
Die Verwaltung und das Testen mehrerer macht mehr Aufwand. Früher oder
später wird es einen "Standardweg" geben. Ist das systemd-irgendwas,
ist man an systemd festgenagelt.

Das kann so sein, muß aber nicht. Es kann auch umgekehrt sein, dass
draufkommt, dass Grub überlegen ist.

Post by Marco Moock
sysvinit wurde ja auch verdrängt.

sysvinit hat aber für viele Leute zu wenig Funktionalität gehabt, und
wurde nicht mehr wirklich weiterentwickelt.

Für mich ist es nicht klar, wie aktiv Grub noch entwickelt wird. Bei mir
tut Grub jedenfalls alles was ich will, auch Secure Boot auf einem
Microsoft-Notebook.

/ralph

[Gregor Szaktilla]

Post by Ralph Aichinger

Post by Marco Moock
sysvinit wurde ja auch verdrängt.

sysvinit hat aber für viele Leute zu wenig Funktionalität gehabt, und
wurde nicht mehr wirklich weiterentwickelt.

Könntest Du (oder einer der Umstehenden) das ein bisschen ausführen?
Welche Funktionen fehlen sysvinit denn?

Meine Rechner werkeln unter Devuan mit SysV-Init und mir fehlt nichts
(glaube ich zumindest). Was ist mit systemd möglich, das mit sysv nicht
geht?

Gruß

Gregor

[Ralph Aichinger]

Post by Gregor Szaktilla
Könntest Du (oder einer der Umstehenden) das ein bisschen ausführen?
Welche Funktionen fehlen sysvinit denn?

Naja, z.B. einfach Abhängigkeiten unter Init-Skripten zu definieren,
oder eben keine prozeduralen Skripte, sondern eine deklarative Syntax,
die die Vorteil bietet leichter durchschaubar zu sein.

Hast du mal selbst Init-Skripte gebastelt? Ich finde systemd-Units
deutlich einfacher und nachvollziehbarer.

/ralph

[Marc Haber]

Post by Ralph Aichinger

Post by Gregor Szaktilla
Könntest Du (oder einer der Umstehenden) das ein bisschen ausführen?
Welche Funktionen fehlen sysvinit denn?

Naja, z.B. einfach Abhängigkeiten unter Init-Skripten zu definieren,
oder eben keine prozeduralen Skripte, sondern eine deklarative Syntax,
die die Vorteil bietet leichter durchschaubar zu sein.
Hast du mal selbst Init-Skripte gebastelt? Ich finde systemd-Units
deutlich einfacher und nachvollziehbarer.

Was Ralph sagt.

Mal ganz abgesehen davon, dass man bei sicherheitsrelevanter Software
in einer systemd-Units Sicherheitsfeatures wie Chroot,
Dateizugriffsbechränkungen, Systemcallfilter, Capabilities etc einfach
hinschreibt während man das in einem Initscript umständlich
ausprogrammieren (und testen!) muss.

Aber ich glaube, das erwähnte ich in anderen Threads wie diesem¹
schon.

Grüße
Marc

¹ es ist ja immer dasselbe: Jemand berichtet von einem systemd-Feature
oder stellt eine Frage zu systemd, und daraus entsteht immer wieder
dieselbe verdammte Diskussion. Thread went systemd and died. Es nervt.

[Tim Ritberg]

Post by Marc Haber
¹ es ist ja immer dasselbe: Jemand berichtet von einem systemd-Feature
oder stellt eine Frage zu systemd, und daraus entsteht immer wieder
dieselbe verdammte Diskussion. Thread went systemd and died. Es nervt.

Ich schäm' mich ja so :-D

Tim

[Dietz Proepper]

Post by Marc Haber
¹ es ist ja immer dasselbe: Jemand berichtet von einem systemd-Feature
oder stellt eine Frage zu systemd, und daraus entsteht immer wieder
dieselbe verdammte Diskussion. Thread went systemd and died. Es nervt.

Tja. Systemd existiert halt leider und offenbar sind viele Leute damit
nachwievor nicht so recht glücklich.

[Thomas Klix]

Post by Dietz Proepper

Post by Marc Haber
¹ es ist ja immer dasselbe: Jemand berichtet von einem systemd-Feature
oder stellt eine Frage zu systemd, und daraus entsteht immer wieder
dieselbe verdammte Diskussion. Thread went systemd and died. Es nervt.

Tja. Systemd existiert halt leider und offenbar sind viele Leute damit
nachwievor nicht so recht glücklich.

Ohne formulieren zu können, *was* sie jetzt unglücklich macht. Tja.

Thomas

[Gregor Szaktilla]

Post by Thomas Klix

Post by Dietz Proepper

Post by Marc Haber
¹ es ist ja immer dasselbe: Jemand berichtet von einem systemd-Feature
oder stellt eine Frage zu systemd, und daraus entsteht immer wieder
dieselbe verdammte Diskussion. Thread went systemd and died. Es nervt.

Tja. Systemd existiert halt leider und offenbar sind viele Leute damit
nachwievor nicht so recht glücklich.

Ohne formulieren zu können, *was* sie jetzt unglücklich macht. Tja.

Au contraire!

Mich macht unglücklich, dass systemd auf älteren oder exotischen
Rechnern zu nicht-deterministischem Verhalten führt. Ich mag Linux
schließlich auch deshalb, weil ich solchen Rechnern zu einem längeren
Leben verhelfen möchte.

Gruß

Gregor

[Marc Haber]

Post by Gregor Szaktilla
Mich macht unglücklich, dass systemd auf älteren oder exotischen
Rechnern zu nicht-deterministischem Verhalten führt.

Ich benutze systemd auf Banana Pi Systemen; die älteste Hardware auf
der ich ein systemd-Linux ausgeführt habe ist von 2007.

Und der Nondeterminismus kommt aus der Parallelität der Aktionen. Die
Diskussion ist nicht unähnlich dessen, was bei der Einführung der
Multitaskingsysteme diskutiert wurde.

Dass man das in systemd nicht abschalten kann und dass systemd manche
Dinge bewusst elimieren möchte (z.B. Skripte) finde ich auch doof,
aber unterm Strich ist systemd für mich ein Gewinn.

Grüße
Marc

[Dietz Proepper]

Post by Thomas Klix

Post by Dietz Proepper

Post by Marc Haber
¹ es ist ja immer dasselbe: Jemand berichtet von einem
systemd-Feature oder stellt eine Frage zu systemd, und daraus
entsteht immer wieder dieselbe verdammte Diskussion. Thread went
systemd and died. Es nervt.

Tja. Systemd existiert halt leider und offenbar sind viele Leute
damit nachwievor nicht so recht glücklich.

Ohne formulieren zu können, *was* sie jetzt unglücklich macht. Tja.

Sie können doch. Die Argumente werden von der Gegenseite allerdings als
nicht relevant bewertet. Umgekehrt natürlich genauso. Tja.

[Marc Haber]

Post by Dietz Proepper

Post by Marc Haber
¹ es ist ja immer dasselbe: Jemand berichtet von einem systemd-Feature
oder stellt eine Frage zu systemd, und daraus entsteht immer wieder
dieselbe verdammte Diskussion. Thread went systemd and died. Es nervt.

Tja. Systemd existiert halt leider und offenbar sind viele Leute damit
nachwievor nicht so recht glücklich.

Wenn ich anfange für alles womit ich nicht so recht glücklich bin
solche Megathreads zu führen hätte ich nichts andere mehr zu tun.

[Sieghard Schicktanz]

Hallo Ralph,

Post by Ralph Aichinger
oder eben keine prozeduralen Skripte, sondern eine deklarative Syntax,

Prozzedural: Der Ablauf der durchzuführenden Aktionen wird definiert. Das
Ergebnis entsteht während der Ausführung der Ablaufschritte.

Deklarativ: Das zu erreichende Ergebnis wird definiert, der Weg dahin muß
von der ausführenden Software bestimmt werden und kann unterschiedlich
ausfallen.

Post by Ralph Aichinger
die die Vorteil bietet leichter durchschaubar zu sein.

Kommt darauf an, _was_ Du "durchschauen" willst.

[Ralph Aichinger]

Post by Sieghard Schicktanz
Kommt darauf an, _was_ Du "durchschauen" willst.

Was findest du durchschaubarer? Das da:

| # LSB log_* functions
| . /lib/lsb/init-functions
|
| do_start()
| {
| start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON --test > /dev/null \
| || return 1
| start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON -- \
| $DAEMON_ARGS \
| || return 2
| }
|
| do_stop()
| {
| start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile $PIDFILE --name $NAME
| RETVAL="$?"
| [ "$RETVAL" = 2 ] && return 2
| start-stop-daemon --stop --quiet --oknodo --retry=0/30/KILL/5 --exec $DAEMON
| [ "$?" = 2 ] && return 2
| rm -f $PIDFILE
| return "$RETVAL"
| }

oder das da:

| [Unit]
| Description=LLDP daemon
| Documentation=man:lldpd(8)
| After=network.target
| RequiresMountsFor=/run/lldpd
|
| [Service]
| Type=notify
| NotifyAccess=main
| EnvironmentFile=-/etc/default/lldpd
| EnvironmentFile=-/etc/sysconfig/lldpd
| ExecStart=/usr/sbin/lldpd $DAEMON_ARGS $LLDPD_OPTIONS
| Restart=on-failure
| PrivateTmp=yes
| ProtectHome=yes
| ProtectKernelTunables=no
| ProtectControlGroups=yes
| ProtectKernelModules=yes
| #ProtectSystem=full
|
| [Install]
| WantedBy=multi-user.target


/ralph

[Dietz Proepper]

Post by Ralph Aichinger

Post by Sieghard Schicktanz
Kommt darauf an, _was_ Du "durchschauen" willst.

| # LSB log_* functions
| . /lib/lsb/init-functions
|
| do_start()
| {
| start-stop-daemon --start --quiet --pidfile $PIDFILE --exec
| $DAEMON --test > /dev/null \
| || return 1
| start-stop-daemon --start --quiet --pidfile $PIDFILE --exec
| $DAEMON -- \ $DAEMON_ARGS \
| || return 2
| }
|
| do_stop()
| {
| start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5
| --pidfile $PIDFILE --name $NAME RETVAL="$?"
| [ "$RETVAL" = 2 ] && return 2
| start-stop-daemon --stop --quiet --oknodo
| --retry=0/30/KILL/5 --exec $DAEMON [ "$?" = 2 ] && return 2
| rm -f $PIDFILE
| return "$RETVAL"
| }

Zwar war der Skriptautor ein wenig verwirrt, wie man am do_stop
und der $?-Verwendung sehen kann. Allerdings ist die Funktionalität des
Skripts innerhalb weniger Sekunden verstehbar.

Post by Ralph Aichinger
| [Unit]
| Description=LLDP daemon
| Documentation=man:lldpd(8)
| After=network.target
| RequiresMountsFor=/run/lldpd
|
| [Service]
| Type=notify
| NotifyAccess=main
| EnvironmentFile=-/etc/default/lldpd
| EnvironmentFile=-/etc/sysconfig/lldpd
| ExecStart=/usr/sbin/lldpd $DAEMON_ARGS $LLDPD_OPTIONS
| Restart=on-failure
| PrivateTmp=yes
| ProtectHome=yes
| ProtectKernelTunables=no
| ProtectControlGroups=yes
| ProtectKernelModules=yes
| #ProtectSystem=full
|
| [Install]
| WantedBy=multi-user.target

Du kannst mir aus dem ff sagen, was "ProtectKernelTunables" oder
"ProtectContolGroups" bewirkt? Auch noch, was es in systemd($current-12
Monate) tat? Ganz offen, glaub' ich Dir nicht.

Richtig albern wird es mit dependencies. Ich sag's mal so,
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034022 sagt
eigentlich alles. Um einen komplett trivialen use case zu lösen wird
auf ein komplett opakes zfs-mount-generator verwiesen. Das
lustigerweise im Wesentlichen auf Poetterings Laptop
funktioniert. (vermute ich mal, nach einigen Stunden Experimentieren
ohne das gewünschte Ergebnis zu erzielen, hab' ich halt die imo
sinnvolle Lösung gewählt und /lib/systemd/system/zfs-mount.service von
Hand gepatcht.)

[Ralph Aichinger]

Post by Dietz Proepper

Post by Ralph Aichinger
| do_stop()
| {
| start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5
| --pidfile $PIDFILE --name $NAME RETVAL="$?"
| [ "$RETVAL" = 2 ] && return 2
| start-stop-daemon --stop --quiet --oknodo
| --retry=0/30/KILL/5 --exec $DAEMON [ "$?" = 2 ] && return 2
| rm -f $PIDFILE
| return "$RETVAL"
| }

Zwar war der Skriptautor ein wenig verwirrt, wie man am do_stop
und der $?-Verwendung sehen kann. Allerdings ist die Funktionalität des
Skripts innerhalb weniger Sekunden verstehbar.

Das wird AFAIK so in Debian ausgeliefert, Verwirrung und alles. Und
nein, ich versteh das nicht innerhalb weniger Sekunden. Wahrscheinlich
bist du ein deutlich besserer Shellprogrammierer als ich. Aber wenn
solche "verwirrten" Sachen in einer Mainstream-Distribution landen, dann
ist das wohl eher ein Zeichen eines Problems, als einer einfach
nachvollziehbaren Lösung.

Post by Dietz Proepper

Post by Ralph Aichinger
| ProtectKernelTunables=no
| ProtectControlGroups=yes

Du kannst mir aus dem ff sagen, was "ProtectKernelTunables" oder
"ProtectContolGroups" bewirkt? Auch noch, was es in systemd($current-12
Monate) tat? Ganz offen, glaub' ich Dir nicht.

Nein, natürlich weiß ich solche Sachen nicht auswendig, und verwende
sie aktiv auch in meinen Units nicht. Aber:

1. Kann man das sehr einfach nachschlagen.

https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html#ProtectControlGroups=

2. Ist das wiederum selbst ein Beispiel für ein Feature, das man mit
SysV-Init gar nicht so einfach realisieren kann. Wenn man das System aus
Securitygründen weiter zunageln will, dann ist das eine echte Hilfe.

Post by Dietz Proepper
Richtig albern wird es mit dependencies. Ich sag's mal so,
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034022 sagt

Das hätte dir aber mit einem Init-Sktipt genauso passieren können, wenn
der Maintainer sagt, dass er auf deinen Use-Case keine Rücksicht nehmen
will.

/ralph

[Dietz Proepper]

Post by Ralph Aichinger

Post by Dietz Proepper

Post by Ralph Aichinger
| do_stop()
| {
| start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5
| --pidfile $PIDFILE --name $NAME RETVAL="$?"
| [ "$RETVAL" = 2 ] && return 2
| start-stop-daemon --stop --quiet --oknodo
| --retry=0/30/KILL/5 --exec $DAEMON [ "$?" = 2 ] && return 2
| rm -f $PIDFILE
| return "$RETVAL"
| }

Zwar war der Skriptautor ein wenig verwirrt, wie man am do_stop
und der $?-Verwendung sehen kann. Allerdings ist die Funktionalität
des Skripts innerhalb weniger Sekunden verstehbar.

Das wird AFAIK so in Debian ausgeliefert, Verwirrung und alles.

Ja, ich kenne den (init-)Skriptzoo ein wenig. Und es gibt auch deutlich
schlimmere Skripte.

Post by Ralph Aichinger
Und nein, ich versteh das nicht innerhalb weniger Sekunden.

23 systemd-Configstanzas sind einfacher zu verstehen?

Post by Ralph Aichinger
Wahrscheinlich
bist du ein deutlich besserer Shellprogrammierer als ich.

Naja, zu "admin" gehört imho die Beherrschung der einen oder anderen
(Shell-)Skriptsprache. Und die man page von start-stop-daemon habe ich
vmtl. das letzte Mal vor fünf Jahren gelesen.

Post by Ralph Aichinger
Aber wenn
solche "verwirrten" Sachen in einer Mainstream-Distribution landen,
dann ist das wohl eher ein Zeichen eines Problems, als einer einfach
nachvollziehbaren Lösung.

Nun, meine Anmerkung war stilistischer Natur. Semantisch dürfte das auf
den ersten Blick machen was es soll.

Post by Ralph Aichinger

Post by Dietz Proepper

Post by Ralph Aichinger
| ProtectKernelTunables=no
| ProtectControlGroups=yes

Du kannst mir aus dem ff sagen, was "ProtectKernelTunables" oder
"ProtectContolGroups" bewirkt? Auch noch, was es in
systemd($current-12 Monate) tat? Ganz offen, glaub' ich Dir nicht.

Nein, natürlich weiß ich solche Sachen nicht auswendig, und verwende
sie aktiv auch in meinen Units nicht.

D.h., Du bist auch nicht schlauer als bei klassischem sysv-Init? Hum.

Post by Ralph Aichinger
1. Kann man das sehr einfach nachschlagen.
https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html#ProtectControlGroups=

Die Beschreibung dünkt mir ... komplex. Ibs. der Verweis auf
"ReadOnlyPaths" ... Wo nochmal finde ich das? ;-)

Post by Ralph Aichinger
2. Ist das wiederum selbst ein Beispiel für ein Feature, das man mit
SysV-Init gar nicht so einfach realisieren kann. Wenn man das System
aus Securitygründen weiter zunageln will, dann ist das eine echte
Hilfe.

CGroups als Sicherheitsfeature. O Tempora. Abgesehen davon -
cgroup-tools existiert. Und ja, das ist dann nicht mehr soo transparent.

Post by Ralph Aichinger

Post by Dietz Proepper
Richtig albern wird es mit dependencies. Ich sag's mal so,
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034022 sagt

Das hätte dir aber mit einem Init-Sktipt genauso passieren können,
wenn der Maintainer sagt, dass er auf deinen Use-Case keine Rücksicht
nehmen will.

Ein individuelles Initskript für den use case ist imo /DEUTLICHST/
weniger invasiv, als unter /lib/systemd herumzufummeln. Before= lässt
sich nicht overriden.
Rate mal, was bei der fraglichen Maschine in der Update-Checkliste
steht.

[Stefan+ (Stefan Froehlich)]

Post by Dietz Proepper

[triviales start-stop-script]
| [Unit]
| Description=LLDP daemon
| Documentation=man:lldpd(8)
| After=network.target
| RequiresMountsFor=/run/lldpd
|
| [Service]
| Type=notify
| NotifyAccess=main
| EnvironmentFile=-/etc/default/lldpd
| EnvironmentFile=-/etc/sysconfig/lldpd
| ExecStart=/usr/sbin/lldpd $DAEMON_ARGS $LLDPD_OPTIONS
| Restart=on-failure
| PrivateTmp=yes
| ProtectHome=yes
| ProtectKernelTunables=no
| ProtectControlGroups=yes
| ProtectKernelModules=yes
| #ProtectSystem=full
|
| [Install]
| WantedBy=multi-user.target

Du kannst mir aus dem ff sagen, was "ProtectKernelTunables" oder
"ProtectContolGroups" bewirkt? Auch noch, was es in
systemd($current-12 Monate) tat? Ganz offen, glaub' ich Dir nicht.

Als Gelegenheitsuser kann (und würde) ich die meisten Optionen nur
mutmaßen, was im übrigen eine große Gefahr solcher
konfigurationsbasierten Systeme ist: Man *glaubt*, sie seien einfach
verständlich, zwingend ist das aber keineswegs.

Letztendlich kenne ich das von meiner Software, sobald halbwegs
ähnliche Codeteile mehr als ein dutzend Mal auftreten und ich sie
durch Konfigurationen ersetze. Am Anfang wird alles viel einfacher
und übersichtlicher, danach mächtiger, bis am Ende die
Übersichtlichkeit schlechter ist als zuvor, ich das Teil aber wegen
der durchaus gewünschten Zusatzfunktionalitäten nicht mehr in die
Tonne treten kann.

Ist halt immer eine Abwägungsfrage; beim systemd kommt noch die sehr
unterschiedliche Nutzerstruktur vom Distributions-Maintainer über
den Softwareentwickler bis hin zu den routinierten und
Gelegenheitsanwendern dazu.

Angesichts des Funktionsumfangs (wenn *ich* versuche, Dinge in den
systemd man-Pages nachzuschlagen, schreibe ich in Gedanken schon
einmal einen halben Arbeitstag ab) ist die Frage, ob man das Zeug
nicht von Anfang in in ein simples, basisnahes Init- und ein
beliebig komplexes Prozessverwaltungssystem hätte aufteilen können
und sollen, die unabhängig voneinander entwickelt und betrieben
werden hätten können.

Servus,
Stefan

[Marc Haber]

Post by Dietz Proepper

Post by Ralph Aichinger
| [Unit]

Und "das da" leistet noch erheblichst mehr.

Post by Dietz Proepper
Du kannst mir aus dem ff sagen, was "ProtectKernelTunables" oder
"ProtectContolGroups" bewirkt? Auch noch, was es in systemd($current-12
Monate) tat? Ganz offen, glaub' ich Dir nicht.

Würde ich dasselbe Featureset in einem Initscript erreichen wollen,
müsste ich auch nachlesen was die entsprechende Tools machen.

In 99,76% der Fälle würde man das einfach bleiben lassen un der
Prozess liefe als unrestricted root.

Grüße
Marc

[Dietz Proepper]

Post by Marc Haber

Post by Dietz Proepper

Post by Ralph Aichinger
| [Unit]

Und "das da" leistet noch erheblichst mehr.

Post by Dietz Proepper
Du kannst mir aus dem ff sagen, was "ProtectKernelTunables" oder
"ProtectContolGroups" bewirkt? Auch noch, was es in
systemd($current-12 Monate) tat? Ganz offen, glaub' ich Dir nicht.

Würde ich dasselbe Featureset in einem Initscript erreichen wollen,
müsste ich auch nachlesen was die entsprechende Tools machen.
In 99,76% der Fälle würde man das einfach bleiben lassen un der
Prozess liefe als unrestricted root.

Der Sicherheitsimpact war genau welcher?

[Gregor Szaktilla]

Post by Dietz Proepper

... Würde ich dasselbe Featureset in einem Initscript erreichen wollen,
müsste ich auch nachlesen was die entsprechende Tools machen.
In 99,76% der Fälle würde man das einfach bleiben lassen un der
Prozess liefe als unrestricted root.

Der Sicherheitsimpact war genau welcher?

Welchen der Fälle, die 99,76% ausmachen, hättest Du denn gerne?

Gruß

Gregor

[Ralph Aichinger]

Post by Dietz Proepper

Post by Marc Haber

Post by Dietz Proepper
Du kannst mir aus dem ff sagen, was "ProtectKernelTunables" oder
"ProtectContolGroups" bewirkt? Auch noch, was es in
systemd($current-12 Monate) tat? Ganz offen, glaub' ich Dir nicht.

Würde ich dasselbe Featureset in einem Initscript erreichen wollen,
müsste ich auch nachlesen was die entsprechende Tools machen.

Der Sicherheitsimpact war genau welcher?

Naja, Kernel-Parameter wie von ProtectKernelTunables gesperrt können
schon hilfreich sein, z.B. Denial of Service/Resource Exhaustion zu
verhindern. Wenn man es services etwas schwerer machen kann, auf /sys&Co
zuzugreifen, das kann schon helfen. Nein, es ist kein Allheilmittel,
aber was ist das schon?

/ralph

[Dietz Proepper]

Ralph Aichinger <***@pi.h5.or.at> wrote:
[Du quotest unüblich ...]

Post by Ralph Aichinger

Post by Dietz Proepper

Post by Marc Haber

Post by Dietz Proepper
Du kannst mir aus dem ff sagen, was "ProtectKernelTunables" oder
"ProtectContolGroups" bewirkt? Auch noch, was es in
systemd($current-12 Monate) tat? Ganz offen, glaub' ich Dir nicht.

Würde ich dasselbe Featureset in einem Initscript erreichen wollen,
müsste ich auch nachlesen was die entsprechende Tools machen.

Der Sicherheitsimpact war genau welcher?

Naja, Kernel-Parameter wie von ProtectKernelTunables gesperrt können
schon hilfreich sein, z.B. Denial of Service/Resource Exhaustion zu
verhindern.

Eh? Warum sollte ein daemon diese anfassen wollen? Und wenn wir das
Szenario "muss vertrauensunwürdige Software laufen lassen" betrachten,
dann wird es ohnehin grotesk.

Wenn in der Hersteller-Unit all diese Sachen explizit abgeschalten sind
z.B..

Aber Marc brachte den Aspekt, dass es doch ganz nifty sei, all diese
schönen features zu haben. Abgesehen davon, dass ProtectKernelTuneables
per default ohnehin aus ist fällt mir halt immer wieder auf, dass z.B.
auf
https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html
der Terminus "implicit.*" bei den config stanzas so knappe 30x
vorkommt. Ich wünsche viel Spaß beim Debuggen.

[Ralph Aichinger]

Post by Dietz Proepper
Eh? Warum sollte ein daemon diese anfassen wollen? Und wenn wir das
Szenario "muss vertrauensunwürdige Software laufen lassen" betrachten,
dann wird es ohnehin grotesk.

Das Leben ist nicht Schwarz-Weiß. Software gegen andere Software
abzuschotten, wenn keine Verbindung da sein muß, oder in den Rechten und
Möglichkeiten zu beschränken aufs Minimum ist eine best practice
bezüglich Sicherheit. Das kann den Unterschied zwischen einem toten
Service und einem toten Server, einem beschränkten Exploit auf ein
Directory oder einem Root-Exploit, oder einen Unterschied von vielen
tausend Euro auf der AWS-Cloudrechnung machen.

Post by Dietz Proepper
Wenn in der Hersteller-Unit all diese Sachen explizit abgeschalten sind
z.B..

Mal mehr, mal weniger, aber mit jeder Verfeinerung von
Distributionspolicies oder Hardening-Guidelines halt mehr. Das Leben ist
wie gesagt nicht Schwarz-Weiß, Alles-Nichts.

Post by Dietz Proepper
Ich wünsche viel Spaß beim Debuggen.

sytemd-Units sind eher gutartig zu debuggen. Aber das siehst du
vermutlich auch anders.

/ralph

[Marc Haber]

Post by Dietz Proepper

Post by Marc Haber

Post by Dietz Proepper

Post by Ralph Aichinger
| [Unit]

Und "das da" leistet noch erheblichst mehr.

Post by Dietz Proepper
Du kannst mir aus dem ff sagen, was "ProtectKernelTunables" oder
"ProtectContolGroups" bewirkt? Auch noch, was es in
systemd($current-12 Monate) tat? Ganz offen, glaub' ich Dir nicht.

Würde ich dasselbe Featureset in einem Initscript erreichen wollen,
müsste ich auch nachlesen was die entsprechende Tools machen.
In 99,76% der Fälle würde man das einfach bleiben lassen un der
Prozess liefe als unrestricted root.

Der Sicherheitsimpact war genau welcher?

Ah, sind wir jetzt bei "brauch ich nicht, braucht keiner"?

[Dietz Proepper]

Post by Marc Haber

Post by Dietz Proepper

Post by Marc Haber

Post by Dietz Proepper
Du kannst mir aus dem ff sagen, was "ProtectKernelTunables" oder
"ProtectContolGroups" bewirkt? Auch noch, was es in
systemd($current-12 Monate) tat? Ganz offen, glaub' ich Dir nicht.

Würde ich dasselbe Featureset in einem Initscript erreichen wollen,
müsste ich auch nachlesen was die entsprechende Tools machen.
In 99,76% der Fälle würde man das einfach bleiben lassen un der
Prozess liefe als unrestricted root.

Der Sicherheitsimpact war genau welcher?

Ah, sind wir jetzt bei "brauch ich nicht, braucht keiner"?

Du hast einen bestimmten Aspekt aufgebracht. Warum beklagst Du, dass
dieser aufgenommen wird?

[Stefan Reuther]

[---]

Post by Dietz Proepper

Post by Ralph Aichinger
| do_stop()
| {
| start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5
| --pidfile $PIDFILE --name $NAME RETVAL="$?"
| [ "$RETVAL" = 2 ] && return 2
| start-stop-daemon --stop --quiet --oknodo
| --retry=0/30/KILL/5 --exec $DAEMON [ "$?" = 2 ] && return 2
| rm -f $PIDFILE
| return "$RETVAL"
| }

Zwar war der Skriptautor ein wenig verwirrt, wie man am do_stop
und der $?-Verwendung sehen kann. Allerdings ist die Funktionalität des
Skripts innerhalb weniger Sekunden verstehbar.

Kannst du mir aus dem Kopf sagen, was --retry=0/30/KILL/5 oder --oknodo
ist? Auch, was es in RHEL6 oder Gentoo tut? Warum ruft der überhaupt
start-stop-daemon zweimal auf? Und warum sehe ich da so viele
un-escapede Shellvariablen?

Post by Dietz Proepper

Post by Ralph Aichinger
| ProtectControlGroups=yes
| ProtectKernelModules=yes

[...]

Post by Dietz Proepper
Du kannst mir aus dem ff sagen, was "ProtectKernelTunables" oder
"ProtectContolGroups" bewirkt? Auch noch, was es in systemd($current-12
Monate) tat? Ganz offen, glaub' ich Dir nicht.

Das sind halt auf beiden Seiten jede Menge Fakten, die man im
Zweifelsfall nachlesen muss.

Und systemd hat halt Konfigurationsoptionen für Features an Stellen, wo
sysvinit nicht mal Stellen hat.


Stefan

[Sieghard Schicktanz]

Hallo Ralph,

Post by Sieghard Schicktanz
Kommt darauf an, _was_ Du "durchschauen" willst.

[Shell-Skript Machart "init"]
[ellenlange systemd-"Unit"]

Sollen die _vergleichbar_ sein?
Beim Überfliegen würde ich da mal sagen, da wird ein "simple minded"
Init-Skript mit einer in "jeder" Hinsicht ausgetüftelten und ausgebauten
systemd-"Unit" verglichen. Also nichtmal die berüchtigten "Äpfel und
Birnen", sondern völlig unbrauchbar.

Außerdem habe ich lediglich versucht, eine Gegenüberstellung der
grundlegenden Eigenschaften von "prozedural" und "deklarativ" zu geben.
Aber wenn Du unbedingt willst, kann ich Dir auch eine (Art) "Wertung"
liefern:
"Prozedural" ist das Stellen einer Aufgabe, indem erklärt wird, _wie_ die
Aufgabe gelöst werden soll.
"Deklarativ" ist das Stellen einer Aufgabe, indem einfach gesagt wird, was
am Ende los sein soll.
Erstere Methode bewirkt, daß die Verantwortung für Durchführung und Erfolg
der Bearbeitung beim Auftraggeber liegt. Sozusagen die Methode "aus der
Praxis, für die Praxis" für produktive Nutzung.
Letztere Methode schiebt die Verantwortung für Durchführung und Erfolg der
Bearbeitung auf die Verarbeiter ab, die sich um die anzuwendenden Methoden
zu kümmern haben. Das wäre dann eher eine Methode für das "gehobene
Management", das irgendwelche Vorgaben an die Produktion gibt (auch ohne
sich drum zu kümmern, ob die erfüllbar sind). Das hat dann "gelegentlich"
Verzögerungen zur Folge, oft ineffiziente Vorgehensweisen, weitere
Delegation und im Endeffekt einen vielfach größeren Aufwand als die
Direktmethoe.
Dafür kann diese (die Direktmethoe) halt auch zum Zementieren
althergebrachter Traditionen führen, die nicht mehr den aktuellen
Möglichkeiten und Anforderungen entsprechen, und oft auch neue, bessere
Lösungen behindern. Dafür gibt sie vorhandenes Wissen weiter.
Die "Management"-Methode schert sich nicht um die Kenntnisse und
Fähigkeiten der Ausführenden. Kenntnisse und Wissen können verfallen.

So, jetzt kannst Du Dir aussuchen, was Du meinen willst.

BTW: Es gab mal eine Phase, wo deklarative Programmierung sehr im Schwang
war. Eine gewisse Popularität hatte damals die Programmiersprache "Prolog".
Schon mal was davon gehört? Aktuell?

[Jens Schuessler]

Post by Ralph Aichinger
Hast du mal selbst Init-Skripte gebastelt? Ich finde systemd-Units
deutlich einfacher und nachvollziehbarer.

Da das ja alle Nas lang als Argument kommt, wer sind eigentlich die
armen Entwickler die anscheinend alle 2 Tage neu init-Skripte schreiben
mußten, aber deren Dasein jetzt mit mit Borg-D so viel lebenswerter
geworden ist. Und treffen die sich noch immer im Paulanergarten?

[Ralph Aichinger]

Post by Jens Schuessler
Da das ja alle Nas lang als Argument kommt, wer sind eigentlich die
armen Entwickler die anscheinend alle 2 Tage neu init-Skripte schreiben
mußten, aber deren Dasein jetzt mit mit Borg-D so viel lebenswerter
geworden ist. Und treffen die sich noch immer im Paulanergarten?

Ich seh mich nicht als Entwickler, sondern als Sysadmin, und auch ich
hab schon Init-Skripte gebastelt. Nein, nicht alle 2 Tage, aber doch
immer wieder mal.

Und nach dem Motto: Beides probiert, kein Vergleich: systemd-Units sind
um Größenordnungen schneller und fehlerfreier hinzukriegen. Bei
init-Skripten hab ich halt immer irgendein einfaches (früher das vom lpd
oder so) hergenommen, kopiert und zurechtgebastelt, dass es auf mein
Problem gepaßt hat. Testen von Initskripten ist auch oft blöd, jenachdem
worum es sich handelt.

Bei Systemd hab ich in ein paar Minuten was, was funktioniert.

/ralph

[Marc Haber]

Post by Ralph Aichinger
Ich seh mich nicht als Entwickler, sondern als Sysadmin, und auch ich
hab schon Init-Skripte gebastelt. Nein, nicht alle 2 Tage, aber doch
immer wieder mal.
Und nach dem Motto: Beides probiert, kein Vergleich: systemd-Units sind
um Größenordnungen schneller und fehlerfreier hinzukriegen. Bei
init-Skripten hab ich halt immer irgendein einfaches (früher das vom lpd
oder so) hergenommen, kopiert und zurechtgebastelt, dass es auf mein
Problem gepaßt hat. Testen von Initskripten ist auch oft blöd, jenachdem
worum es sich handelt.
Bei Systemd hab ich in ein paar Minuten was, was funktioniert.

Amen. Genau so ist es.

Man macht das oft genug dass es nervt, aber selten genug als dass es
sich lohnen würde sich ein framework zu schreiben damit die
Initscripte einfacher und vor allen Dingen gleicher zu machen.

Dieses "ich nehme mir ein anderes Initsript und mutiere es von dort
weg" führt übrigens zu einer Multiplikation der Bugs und dazu, dass
ältere Initscripts sich anders verhalten als neuere und auch andere
Ausgabe erzeugen. Das ist einfach eklig.

Grüe
Marc

[Dietz Proepper]

Post by Marc Haber

Post by Ralph Aichinger
Ich seh mich nicht als Entwickler, sondern als Sysadmin, und auch ich
hab schon Init-Skripte gebastelt. Nein, nicht alle 2 Tage, aber doch
immer wieder mal.
Und nach dem Motto: Beides probiert, kein Vergleich: systemd-Units
sind um Größenordnungen schneller und fehlerfreier hinzukriegen. Bei
init-Skripten hab ich halt immer irgendein einfaches (früher das vom
lpd oder so) hergenommen, kopiert und zurechtgebastelt, dass es auf
mein Problem gepaßt hat. Testen von Initskripten ist auch oft blöd,
jenachdem worum es sich handelt.
Bei Systemd hab ich in ein paar Minuten was, was funktioniert.

Amen. Genau so ist es.

Im Fall "einfach starten und stoppen" baue ich Dir mit sysvinit genauso
schnell etwas. Copy, adopt, paste.

[Marc Haber]

Post by Dietz Proepper
Im Fall "einfach starten und stoppen" baue ich Dir mit sysvinit genauso
schnell etwas. Copy, adopt, paste.

Und dann ändert die Distribution irgendwas dass Du andere Ausgaben
erzeugen musst. Been there, done that. Wasted days of my time.

[Dietz Proepper]

Post by Marc Haber

Post by Dietz Proepper
Im Fall "einfach starten und stoppen" baue ich Dir mit sysvinit
genauso schnell etwas. Copy, adopt, paste.

Und dann ändert die Distribution irgendwas dass Du andere Ausgaben
erzeugen musst. Been there, done that. Wasted days of my time.

Und dann ändert sich subtil die Syntax irgendeiner systemd-Direktive.

Wie das Stefan nebenan schrieb - systemd ist einfach scheißkomplex und
vermischt Dinge, die nix miteinander zutun haben zu einem Riesenmoloch.

[Marco Moock]

Post by Dietz Proepper
Wie das Stefan nebenan schrieb - systemd ist einfach scheißkomplex und
vermischt Dinge, die nix miteinander zutun haben zu einem
Riesenmoloch.

Dem muss ich leider Recht geben. Mir wäre es auch lieber, wenn sich das
nur um das Starten von Diensten und ggf. Berechtigungen dieser kümmern
würde.

[Marc Haber]

Post by Marco Moock

Post by Dietz Proepper
Wie das Stefan nebenan schrieb - systemd ist einfach scheißkomplex und
vermischt Dinge, die nix miteinander zutun haben zu einem
Riesenmoloch.

Dem muss ich leider Recht geben. Mir wäre es auch lieber, wenn sich das
nur um das Starten von Diensten und ggf. Berechtigungen dieser kümmern
würde.

Das kannst du haben wenn Du nur möchtest.

Grüße
Marc

[Marc Haber]

Post by Dietz Proepper
Wie das Stefan nebenan schrieb - systemd ist einfach scheißkomplex und
vermischt Dinge, die nix miteinander zutun haben zu einem Riesenmoloch.

Wie Ralph das schon schrieb: Die typische systemd-Unit ist eine
Größenordnung einfacher als auch schon das einfachste policykonforme
Initscript.

Grüße
Marc

[Marc Haber]

Post by Jens Schuessler
, wer sind eigentlich die
armen Entwickler die anscheinend alle 2 Tage neu init-Skripte schreiben
mußten

Niemand spricht hier von "alle zwei tage". Darf ich fragen, wieviel
Debian-Pakete Du so maintainst?

Grüße
Marc

[Paul Muster]

Post by Marc Haber

Post by Jens Schuessler
, wer sind eigentlich die
armen Entwickler die anscheinend alle 2 Tage neu init-Skripte schreiben
mußten

Niemand spricht hier von "alle zwei tage". Darf ich fragen, wieviel
Debian-Pakete Du so maintainst?

Wieso muss eigentlich der Debian-Maintainer die init-Skripte pflegen?
Wäre das nicht ein Job für Upstream?


mfG Paul

[Ralph Aichinger]

Post by Paul Muster
Wieso muss eigentlich der Debian-Maintainer die init-Skripte pflegen?
Wäre das nicht ein Job für Upstream?

Ich denke ein Grund ist, dass Debian diverse Helper hat, die
Debian-spezifisch sind. Was auch eine Folge davon ist, dass es halt
keinen zentralen SysV-Init-Upstream mehr gibt, der sagt: Macht eure
Skripte so.

/ralph

[Marco Moock]

Was auch eine Folge davon ist, dass es halt keinen zentralen
SysV-Init-Upstream mehr gibt, der sagt: Macht eure Skripte so.

Gab es den jemals?
War das nicht immer was, was verschiedene Systeme (*BSD, UNIX von xyz,
Linux) unterschiedlich gehandhabt haben?

[Ralph Aichinger]

Post by Marco Moock
Gab es den jemals?
War das nicht immer was, was verschiedene Systeme (*BSD, UNIX von xyz,
Linux) unterschiedlich gehandhabt haben?

Eventuell wie System V ein echtes Produkt war, das von AT&T (oder so)
verkauft wurde. Keine Ahnung. Ich hab irgendwann mal auf einer Sun
gearbeitet, die glaub ich offiziell System V war, aber erinnere mich
nicht mehr.

/ralph

[Sieghard Schicktanz]

Hallo Ralph,

Post by Ralph Aichinger
Eventuell wie System V ein echtes Produkt war, das von AT&T (oder so)
verkauft wurde. Keine Ahnung. Ich hab irgendwann mal auf einer Sun
gearbeitet, die glaub ich offiziell System V war, aber erinnere mich
nicht mehr.

Was ich mal so nebenbei mitgekriegt habe, sind die "Init-Skripte" mehr oder
weniger ein "Abfallprodukt" der Funktion von "init", eine ausführbare Datei
(also _nicht_ nur Shell-Skripte) starten zu können, um die Benutzer-Umgebung
einer Maschine einzurichten und zu organisieren.
Alles darüber hinausgehende wäre demnach lediglich Konvention. (Oder auch
Tradition.)

[Marco Moock]

Post by Paul Muster
Wieso muss eigentlich der Debian-Maintainer die init-Skripte pflegen?
Wäre das nicht ein Job für Upstream?

Upstream wird das schwer, weil jedes System da seine eigene Suppe kocht.
Wenn z.B. ein Prozess das Netzwerk nutzen soll, muss der nach der
Einrichtung vom Netzwerk gestartet werden. Klingt einfach, ist aber
selbst bei Debian auf verschiedene Weise realisierbar. Sowas wollte ich
nicht noch im Upstream machen müssen, wenn ich denn da Software
entwickeln würde.

[Marc Haber]

Post by Paul Muster

Post by Marc Haber

Post by Jens Schuessler
, wer sind eigentlich die
armen Entwickler die anscheinend alle 2 Tage neu init-Skripte schreiben
mußten

Niemand spricht hier von "alle zwei tage". Darf ich fragen, wieviel
Debian-Pakete Du so maintainst?

Wieso muss eigentlich der Debian-Maintainer die init-Skripte pflegen?
Wäre das nicht ein Job für Upstream?

Initscripts waren früher DER punkt wo die Integration in die
Distribution stattgefunden hat. Das will man nicht von einem Upstream
haben, dann sind die Initscripts ja noch verrückter und noch
chaotischer und noch uneinheitlicher.

[Gregor Szaktilla]

Post by Ralph Aichinger

Post by Gregor Szaktilla
Könntest Du (oder einer der Umstehenden) das ein bisschen ausführen?
Welche Funktionen fehlen sysvinit denn?

Naja, z.B. einfach Abhängigkeiten unter Init-Skripten zu definieren,
oder eben keine prozeduralen Skripte, sondern eine deklarative Syntax,
die die Vorteil bietet leichter durchschaubar zu sein.
Hast du mal selbst Init-Skripte gebastelt? Ich finde systemd-Units
deutlich einfacher und nachvollziehbarer.

Danke für die Erläuterung – insbesondere für das Beispiel, das Du im
weiteren Subthread-Verlauf bringst.

Dass ich Init-Skripte bearbeitet habe ist lange her. Ungefähr so lange,
wie es systemd als Vorgabe für eine 08/15-Installation von Debian gibt.
Meine Ablehnung von systemd als „Zwangs-Init“ war bei dessen Einführung
mit Debian 8 so stark, dass ich mich damals dafür entschieden habe, mich
aus der System-Administriererei zurückzuziehen und zu einem mehr oder
weniger reinen Anwender zu werden.

Erst seit meinem Wechsel zu Devuan mit SysV-Init habe ich allmählich
wieder Lust, mich mit derlei Zeug zu befassen. Meinem Eindruck nach
erzeugt systemd eine höhere Grundlast, d.h. es bremst ein System IMO
unnötig. Dazu passt, dass sich meine Rechner seit dem Umstieg schneller
anfühlen und sich v.A. deterministisch verhalten (bei einem Mac Mini
funktionierte der IR-Empfänger nach etwa jedem fünften Boot-Vorgang
nicht, jetzt funktioniert er schlicht *immer*).

Nunja, systemd ist mit seinen Units meinem Eindruck nach einfach nur
„Windows-artiger“ geworden. Und Windows kann ich halt nicht leiden.

Gruß

Gregor

[Tim Ritberg]

Post by Gregor Szaktilla
Erst seit meinem Wechsel zu Devuan mit SysV-Init habe ich allmählich
wieder Lust, mich mit derlei Zeug zu befassen. Meinem Eindruck nach
erzeugt systemd eine höhere Grundlast, d.h. es bremst ein System IMO

Ja, vorallem dieses "waiting for..." beim Booten und sogar beim Shutdown.
Wie oft musste ich da schon Reset drücken...

Tim

[Gregor Szaktilla]

Post by Tim Ritberg

Post by Gregor Szaktilla
Erst seit meinem Wechsel zu Devuan mit SysV-Init habe ich allmählich
wieder Lust, mich mit derlei Zeug zu befassen. Meinem Eindruck nach
erzeugt systemd eine höhere Grundlast, d.h. es bremst ein System IMO

Ja, vorallem dieses "waiting for..." beim Booten und sogar beim Shutdown.
Wie oft musste ich da schon Reset drücken...

Oh ja ... v.A. dass die Wartezeit nach deren Ende/Runterzählen durch
eine noch längere Zeit ersetzt wurde, hat zeitweise für echte
Hassgefühle gesorgt. Schließlich fahre ich meine Kiste runter, weil ich
endlich ins Bett will.

Gruß

Gregor

[Thomas Klix]

Post by Tim Ritberg

Post by Gregor Szaktilla
Erst seit meinem Wechsel zu Devuan mit SysV-Init habe ich allmählich
wieder Lust, mich mit derlei Zeug zu befassen. Meinem Eindruck nach
erzeugt systemd eine höhere Grundlast, d.h. es bremst ein System IMO

Ja, vorallem dieses "waiting for..." beim Booten und sogar beim Shutdown.
Wie oft musste ich da schon Reset drücken...

Beg your pardon, aber da scheint dein System etwas miskonfiguriert zu
sein.
dmesg könnte "Hänger" zeigen.

Thomas

[Tim Ritberg]

Post by Thomas Klix

Post by Tim Ritberg

Post by Gregor Szaktilla
Erst seit meinem Wechsel zu Devuan mit SysV-Init habe ich allmählich
wieder Lust, mich mit derlei Zeug zu befassen. Meinem Eindruck nach
erzeugt systemd eine höhere Grundlast, d.h. es bremst ein System IMO

Ja, vorallem dieses "waiting for..." beim Booten und sogar beim Shutdown.
Wie oft musste ich da schon Reset drücken...

Beg your pardon, aber da scheint dein System etwas miskonfiguriert zu
sein.
dmesg könnte "Hänger" zeigen.

Scheiss egal, so ein Timeout sollte nicht höher sein als 10 Sekunden.

Tim

[Marc Haber]

Post by Tim Ritberg

Post by Thomas Klix

Post by Tim Ritberg

Post by Gregor Szaktilla
Erst seit meinem Wechsel zu Devuan mit SysV-Init habe ich allmählich
wieder Lust, mich mit derlei Zeug zu befassen. Meinem Eindruck nach
erzeugt systemd eine höhere Grundlast, d.h. es bremst ein System IMO

Ja, vorallem dieses "waiting for..." beim Booten und sogar beim Shutdown.
Wie oft musste ich da schon Reset drücken...

Beg your pardon, aber da scheint dein System etwas miskonfiguriert zu
sein.
dmesg könnte "Hänger" zeigen.

Scheiss egal, so ein Timeout sollte nicht höher sein als 10 Sekunden.

Ein Datenbankserver der eine saubere Datenstruktur auf der Platte
hinterlassen möchte wird das eventuell anders sehen.

Ja, mich nervt das fünf minuten warten auf den Shutdown einer
unwilligen VM auch, aber dass eine VM auf ein ACPI Shutdown nicht
zeitnah reagiert ist fast immer ein Fehler in dieser VM oder ein
Adminfehler, und die Leute die sich über zu langeTimeouts beschweren
sind sehr oft auch diejenigen die sagen man sollte niemals nie einen
Rechner abschalten ohne ihn ordentlich herunterzufahren. Und ja, es
nervt mich auch dass zuerst die ttys abgeschaltet und dann die Dienste
runtergefahren werden so dass man einem unwilligen Prozess nicht mehr
nachhelfen kan. Und ja, es nervt mich auch dass die Debian-Maintainer
von systemd seit ein paar Monaten mehr Wert darauf legen, möglichst
wenig von der Upstream-Vorgabe abzuweichen als ein eiheitliches, gut
integriertes Debian abzuliefern.

Ja, das nervt. Aber die Bilanz ist immer noch positiv.

Grüe
Marc

[Paul Muster]

Post by Marc Haber
Ja, mich nervt das fünf minuten warten auf den Shutdown einer
unwilligen VM auch, aber dass eine VM auf ein ACPI Shutdown nicht
zeitnah reagiert ist fast immer ein Fehler in dieser VM oder ein
Adminfehler, und die Leute die sich über zu langeTimeouts beschweren
sind sehr oft auch diejenigen die sagen man sollte niemals nie einen
Rechner abschalten ohne ihn ordentlich herunterzufahren. Und ja, es
nervt mich auch dass zuerst die ttys abgeschaltet und dann die Dienste
runtergefahren werden so dass man einem unwilligen Prozess nicht mehr
nachhelfen kan. Und ja, es nervt mich auch dass die Debian-Maintainer
von systemd seit ein paar Monaten mehr Wert darauf legen, möglichst
wenig von der Upstream-Vorgabe abzuweichen als ein eiheitliches, gut
integriertes Debian abzuliefern.
Ja, das nervt. Aber die Bilanz ist immer noch positiv.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Das sehen halt nach wie vor viele Leute anders - und angesichts der
immer weiter fortschreitenden Übergriffigkeit des Tools systemd
vielleicht sogar eine steigende Zahl von Menschen.


mfG Paul

[Marc Haber]

Post by Paul Muster
Das sehen halt nach wie vor viele Leute anders - und angesichts der
immer weiter fortschreitenden Übergriffigkeit des Tools systemd
vielleicht sogar eine steigende Zahl von Menschen.

Dann benutzt es halt einfach nicht.

[Stefan Reuther]

Post by Gregor Szaktilla

Post by Ralph Aichinger

Post by Marco Moock
sysvinit wurde ja auch verdrängt.

sysvinit hat aber für viele Leute zu wenig Funktionalität gehabt, und
wurde nicht mehr wirklich weiterentwickelt.

Könntest Du (oder einer der Umstehenden) das ein bisschen ausführen?
Welche Funktionen fehlen sysvinit denn?

Die Frage kommt ja nun ausnahmslos in jedem systemd-ist-doof-Thread.

Strenggenommen kann sysvinit alles, was man braucht, spätestens wenn man
noch einen Haufen Tools und Scriptlibraries draufwirft.

Auf die gleiche Art und Weise kann auch Assembler alles, was man
braucht. Mit ein paar Makros und Tools wird das sogar richtig benutzbar,
wenn man sich genau an die Konventionen hält! Trotzdem hat man Sprachen
wie C und später C++ erfunden. Die können auch nicht mehr als Assembler,
lösen aber eine Menge Probleme viel übersichtlicher und setzen
Konventionen durch.

systemd hat z.B. eine Konvention für "einem Dienst noch eine zusätzliche
Umgebungsvariable geben" oder "den User ändern, unter dem der Service
läuft": einfach unter /etc/systemd/system/dingens.service.d noch eine
Datei anlegen und darin die passende Variable setzen.

Bei systemd müsste ich dazu hoffen, dass der Autor des Initskripts einen
solchen Mechanismus vorgesehen hat, und wenn er das wie üblich nicht
hat, das Skript patchen und jenen Patch vor jedem Systemupdate schützen.


Stefan

[Gregor Szaktilla]

Post by Stefan Reuther

Post by Gregor Szaktilla

Post by Ralph Aichinger

Post by Marco Moock
sysvinit wurde ja auch verdrängt.

sysvinit hat aber für viele Leute zu wenig Funktionalität gehabt, und
wurde nicht mehr wirklich weiterentwickelt.

Könntest Du (oder einer der Umstehenden) das ein bisschen ausführen?
Welche Funktionen fehlen sysvinit denn?

Die Frage kommt ja nun ausnahmslos in jedem systemd-ist-doof-Thread.
Strenggenommen kann sysvinit alles, was man braucht, spätestens wenn man
noch einen Haufen Tools und Scriptlibraries draufwirft.

Dass die Dinge im Laufe der Zeit immer komplexer werden ist ja okay. Ich
fand halt außerordentlich blöd, dass mir systemd mit Debian 8 einfach
aufs Auge gedrückt wurde. Das und unerklärliche Hänger meiner damaligen
„Hauptkiste“ waren echt ärgerlich.
Jetzt, vom „gemütlichen SysV-Sofa Devuan aus“, sehe ich systemd
wesentlich entspannter.

Post by Stefan Reuther
Auf die gleiche Art und Weise kann auch Assembler alles, was man
braucht. Mit ein paar Makros und Tools wird das sogar richtig benutzbar,
wenn man sich genau an die Konventionen hält! Trotzdem hat man Sprachen
wie C und später C++ erfunden. Die können auch nicht mehr als Assembler,
lösen aber eine Menge Probleme viel übersichtlicher und setzen
Konventionen durch.

Dabei fällt mir ein, dass ich vor ein paar Monaten über die Info
gestolpert bin, dass C++ in alten Versionen keine Garbage Collection
durchgeführt hat. Das erklärt einige merkwürdige Verhaltensweisen meiner
damaligen Programmierereien.

Danke für Deine Ausführungen zu /etc/systemd/system/dingens.service.d.
Dass eine andere Handhabe komfortabler oder übersichtlicher ist, ist ein
guter Grund, Dinge zu ändern. Bei meiner Hardware hat das halt in zwei
Fällen dazu geführt, dass sie nicht mehr zuverlässig lief.

Also, ich finde systemd aus der Ferne gar nicht mehr so doof. Blöd isses
trotzdem :-)

Gruß

Gregor

[Ralph Aichinger]

Post by Gregor Szaktilla
gestolpert bin, dass C++ in alten Versionen keine Garbage Collection
durchgeführt hat. Das erklärt einige merkwürdige Verhaltensweisen meiner

C++ führt auch in aktuellen Versionen keine Garbage Collection durch?

/ralph

[Marc Haber]

Post by Marco Moock
Jedenfalls müssen Pakete auf systemd-Units umstellen und daher 2 Sachen
pflegen. Ob das noch überall passiert, weiß ich nicht.

Die Initscripte muss man nicht mehr pflegen, die dürfen verrotten. Ich
bin sehr froh das ich das nicht mehr machen muss.

Grüße
Marc

[Marco Moock]

Post by Marc Haber
Die Initscripte muss man nicht mehr pflegen, die dürfen verrotten. Ich
bin sehr froh das ich das nicht mehr machen muss.

Dann ist damit aber klar, dass sysvinit für den Normalbetrieb tot ist
und man selbst Initskripte schreiben müsste.
Ergo: Wenn das mit GRUB2 auch passiert, wird der mehr oder weniger
nutzlos im Alltagsbetrieb.

[Marc Haber]

Post by Marco Moock

Post by Marc Haber
Die Initscripte muss man nicht mehr pflegen, die dürfen verrotten. Ich
bin sehr froh das ich das nicht mehr machen muss.

Dann ist damit aber klar, dass sysvinit für den Normalbetrieb tot ist
und man selbst Initskripte schreiben müsste.

Ich akzeptiere Patches. Muss halt jemand anders machen die Arbeit.

Post by Marco Moock
Ergo: Wenn das mit GRUB2 auch passiert, wird der mehr oder weniger
nutzlos im Alltagsbetrieb.

Das wird nicht passieren. systemd-boot kann sicher viel weniger als
grub, z.B. grml-rescueboot?

Grüße
Marc

[Peter Blancke]

systemd-boot kann sicher viel weniger als grub,

Ich setze systemd-boot hier als Rettungs-CD auf meinem installierten
System (Archlinux) ein, das klappt sehr gut und erspart mir im
Ernstfall das Einstecken irgendwelcher CD oder USB_Stöcke.

Möglicher (mir fehlt dazu Detailwissen) Vorteil von Grub:

Grub kann mit einer Bootpartition auf einem Raid1 (/dev/mdX)
starten, das ist praktisch, wenn man zwei gespiegelte Festplatten
hat. Bei systemd-boot weiß ich nicht, wie man das hinkriegt und ob
es überhaupt geht, daher kopiere ich den Inhalt der
EFI-Bootpartition bei Änderung von Kernel und/oder initramfs immer
extra auf die Spiegelplatte -- ein Arbeitsschritt mehr.

z.B. grml-rescueboot?

Also, "systemrescue-cd" wird hier einwandfrei mit systemd-boot
gestartet. Eintrag unter den "entries" dazu bei mir wie folgt:

,----
| title System Rescue
| linux /systemrescue/vmlinuz
| initrd /systemrescue/sysresccd.img
| options
| img_dev=/dev/disk/by-id/XXX-XXXX_XXXXXXXX_XXXXXXXXXX-XXXXXXXX-part1 img_loop=/systemrescue/systemrescue.iso archisobasedir=sysresccd copytoram setkmap=de-latin1
| sort-key 70
`----

Die beiden Dateien (vmlinuz, sysrescuecd.img) sind dabei aus dem ISO
zu extrahieren, das ISO selber einfach komplett reinkopieren. Die
letzte Zeile bestimmt bei mir lediglich die Position, unter welcher
das Rettungssystem erscheinen soll.

Das sollte alles mit grml-rescue ähnlich hinhauen.

Gruß,

Peter Blancke

[Peter Blancke]

systemd-boot kann sicher viel weniger als grub,

Ich setze systemd-boot hier als Rettungs-CD auf meinem installierten
System (Archlinux) ein, das klappt sehr gut und erspart mir im
Ernstfall das Einstecken irgendwelcher CD oder USB_Stöcke.

Möglicher (mir fehlt dazu Detailwissen) Vorteil von Grub:

Grub kann mit einer Bootpartition auf einem Raid1 (/dev/mdX)
starten, das ist praktisch, wenn man zwei gespiegelte Festplatten
hat. Bei systemd-boot weiß ich nicht, wie man das hinkriegt und ob
es überhaupt geht, daher kopiere ich den Inhalt der
EFI-Bootpartition bei Änderung von Kernel und/oder initramfs immer
extra auf die Spiegelplatte -- ein Arbeitsschritt mehr.

z.B. grml-rescueboot?

Also, "systemrescue-cd" wird hier einwandfrei mit systemd-boot
gestartet. Eintrag unter den "entries" dazu bei mir wie folgt:

,----
| title System Rescue
| linux /systemrescue/vmlinuz
| initrd /systemrescue/sysresccd.img
| options
| img_dev=/dev/disk/by-id/XXX-XXXX-part1 img_loop=/systemrescue/systemrescue.iso archisobasedir=sysresccd copytoram setkmap=de-latin1
| sort-key 70
`----

Die beiden Dateien (vmlinuz, sysrescuecd.img) sind dabei aus dem ISO
zu extrahieren, das ISO selber einfach komplett reinkopieren. Die
letzte Zeile bestimmt bei mir lediglich die Position, unter welcher
das Rettungssystem erscheinen soll.

Das sollte alles mit grml-rescue ähnlich hinhauen.

Gruß,

Peter Blancke

[Peter Blancke]

systemd-boot kann sicher viel weniger als grub,

Ich setze systemd-boot hier als Rettungs-CD auf meinem installierten
System (Archlinux) ein, das klappt sehr gut und erspart mir im
Ernstfall das Einstecken irgendwelcher CD oder USB_Stöcke.

Möglicher (mir fehlt dazu Detailwissen) Vorteil von Grub:

Grub kann mit einer Bootpartition auf einem Raid1 (/dev/mdX)
starten, das ist praktisch, wenn man zwei gespiegelte Festplatten
hat. Bei systemd-boot weiß ich nicht, wie man das hinkriegt und ob
es überhaupt geht, daher kopiere ich den Inhalt der
EFI-Bootpartition bei Änderung von Kernel und/oder initramfs immer
extra auf die Spiegelplatte -- ein Arbeitsschritt mehr.

z.B. grml-rescueboot?

Also, "systemrescue-cd" wird hier einwandfrei mit systemd-boot
gestartet. Eintrag unter den "entries" dazu bei mir wie folgt:

,----
| title System Rescue
| linux /systemrescue/vmlinuz
| initrd /systemrescue/sysresccd.img
| options
| img_dev=/dev/disk/by-id/XXX-XXXX-part1 img_loop=/systemrescue/systemrescue.iso archisobasedir=sysresccd copytoram setkmap=de-latin1
| sort-key 70
`----

Die beiden Dateien (vmlinuz, sysrescuecd.img) sind dabei aus dem ISO
zu extrahieren, das ISO selber einfach komplett reinkopieren.

"img-dev=..." ist dabei die Bootpartition, in welcher das ISO
kopiert wurde.

Die letzte Zeile bestimmt bei mir lediglich die Position, unter
welcher das Rettungssystem im Bootmenue erscheinen soll.

Das sollte auch alles mit der grml-rescue-cd ähnlich hinhauen.

Gruß,

Peter Blancke

[Martin Schnitkemper]

Post by Marco Moock
Jedenfalls müssen Pakete auf systemd-Units umstellen und daher 2 Sachen
pflegen. Ob das noch überall passiert, weiß ich nicht.

Welche Pakete wären denn neben dem Bootmanager noch an dem Startprozess
beteiligt, die es zu pflegen gilt? Oder anders herum gefragt: welche Pakete
sind denn heute von GRUB abhängig?

Bei Arch ist es so, dass systemd-boot schon seit jeher mit dem systemd-
Paket ausgeliefert wird, aber man muss es nicht installieren. Bei Debian
sieht es ähnlich aus, da wird systemd-boot nur in einem separaten Paket
ausgeliefert, aber auch heute schon von den Maintainern gepflegt.

Solange Debian grub nicht vollkommen fallen lässt, dürfte man auch in
Zukunft alleine schon wegen der fehlenden BIOS-Unterstützung zwischen den
Bootmanagern wählen können, auch wenn systemd-boot zum Standard erhoben
werden sollte.

[Tim Ritberg]

Post by Ralph Aichinger

Post by Tim Ritberg
https://linuxnews.de/debian-diskutiert-ueber-systemd-boot/

Die Logik kann ich nicht nachvollziehen: Ein weiterer EFI-Bootloader
soll in Debian kommen, aber du nennst das "Monokultur"?
/ralph

Ich meine damit systemd. Der Klotz frisst am Ende alle.
Es wird kein Nebeneinander geben, siehe SysV-Init.

Tim

[Marc Haber]

Post by Tim Ritberg
Es wird kein Nebeneinander geben, siehe SysV-Init.

Und DNS. Und SNTP. Und Netzwerkinitialisierung. Da gibt es nirgendwo
ein Nebeneinander, alles benutzt die systemd-Varianten und es gibt
auch keinerlei Weg das zu ändern.

Jaja.

[Marco Moock]

Post by Marc Haber
Und DNS. Und SNTP. Und Netzwerkinitialisierung. Da gibt es nirgendwo
ein Nebeneinander, alles benutzt die systemd-Varianten und es gibt
auch keinerlei Weg das zu ändern.

Das stimmt nicht.
Ich nutze hier nscd als Cache und der Server steht in der resolv.conf,
direkt vom NM reingeschrieben.

(S)NTP kann man ebenfalls anders realisieren ohne großen Zirkus.

[Marc Haber]

Post by Marco Moock

Post by Marc Haber
Und DNS. Und SNTP. Und Netzwerkinitialisierung. Da gibt es nirgendwo
ein Nebeneinander, alles benutzt die systemd-Varianten und es gibt
auch keinerlei Weg das zu ändern.

Das stimmt nicht.
Ich nutze hier nscd als Cache und der Server steht in der resolv.conf,
direkt vom NM reingeschrieben.
(S)NTP kann man ebenfalls anders realisieren ohne großen Zirkus.

Ironie ist nicht so Deins, oder?

Grüße
Marc

[Thomas Klix]

Post by Marco Moock

Post by Marc Haber
Und DNS. Und SNTP. Und Netzwerkinitialisierung. Da gibt es nirgendwo
ein Nebeneinander, alles benutzt die systemd-Varianten und es gibt
auch keinerlei Weg das zu ändern.

Das stimmt nicht.

Ach was.
Marc mag kein systemd-Bashing, hat die Ironie aber vielleicht etwas versteckt.

Post by Marco Moock
Ich nutze hier nscd als Cache und der Server steht in der resolv.conf,
direkt vom NM reingeschrieben.

Me: unbound. Kein Provider-DNS. DNS-Sperren kenne ich nicht.

Thomas

[Hermann Riemann]

Post by Ralph Aichinger

Post by Tim Ritberg
https://linuxnews.de/debian-diskutiert-ueber-systemd-boot/

Die Logik kann ich nicht nachvollziehen: Ein weiterer EFI-Bootloader
soll in Debian kommen, aber du nennst das "Monokultur"?

Momentan scheint es mir noch so,
als könne man Linux nur neben windows problemlos installieren.

Nach meiner vagen Erinnerung auf meinen Haupt PC:

Jede Installation eigene / und eigene /home partition.

Debian installiert, ging letztlich nicht wegen Grafikkarte.
Ubuntu installiert, scheiterte wegen snap Problem
SuSE installiert, beim booten sind andere nicht mehr sichtbar.
Mint installiert, SuSE nach reboot nicht sichtbar.
wegen Paketauswahl (sdl2 nicht gefunden) erst mal kaum verwendbar.
SuSE tumbleweed neu installiert.
Nach dem einschalten wird mir außer SuSE nur Debian angeboten.
Dafür habe ich einige rätselhafte Auswahl in BIOS boot.

Zukunftsvorstellung:
Jede Installation eigene /usr und /home partition.
Mit BIOS boot start Laufwerk etwa fuer_SuSE ( auf m2 SSD )
fuer_Mint ( auf HD ?) fuer_Debian ( auf SATA SSD )
und den Rest USB.
Auf dem boot start Laufwerk gibt es / für diverse partitions.

[Marco Moock]

Momentan scheint es mir noch so, als könne man Linux nur neben windows
problemlos installieren.

Kann problematisch werden, wenn die die gleiche EFI-Parition nutzen und
dann den GRUB gegenseitig überschreiben.
Schonmal mit eigenen EFI-Partitionen für jedes OS probiert?

[Sieghard Schicktanz]

Hallo Marco,

Post by Marco Moock

Momentan scheint es mir noch so, als könne man Linux nur neben windows
problemlos installieren.

Kann problematisch werden, wenn die die gleiche EFI-Parition nutzen und
dann den GRUB gegenseitig überschreiben.

Seit wann kennt Windows den grub und kann dem was überschreiben? Oder
meinst Du den Vorgang, daß Windows den _EFI-Lader_ mittels seiner
Boot-Tabelle "gerne" immer wieder auf sich selber setzt? Da gibt's aber
kein "GRUB gegenseitig überschreiben", weil Windows den grub überhaupt
nicht beachtet.

Post by Marco Moock
Schonmal mit eigenen EFI-Partitionen für jedes OS probiert?

Geht das überhaupt? Wie?

[Marco Moock]

Post by Sieghard Schicktanz

Post by Marco Moock

Momentan scheint es mir noch so, als könne man Linux nur neben
windows problemlos installieren.

Kann problematisch werden, wenn die die gleiche EFI-Parition nutzen
und dann den GRUB gegenseitig überschreiben.

Seit wann kennt Windows den grub und kann dem was überschreiben?

Bei 2x Ubuntu ist sowas glaub schon passiert, bei Windows wäre mir das
neu.

Post by Sieghard Schicktanz
Oder meinst Du den Vorgang, daß Windows den _EFI-Lader_ mittels seiner
Boot-Tabelle "gerne" immer wieder auf sich selber setzt?

Das betrifft ja nur die Bootreihenfolge, die problemlos geändert werden
kann.

Post by Sieghard Schicktanz

Post by Marco Moock
Schonmal mit eigenen EFI-Partitionen für jedes OS probiert?

Geht das überhaupt? Wie?

Ich habe es nicht explizit getestet, aber:
2. Partition mit Typ EF00 anlegen, fat32 drauf, als /boot/efi im
Installer eintragen.
Die andere Partition wird dann vom installierten OS nicht spezielle
angefasst.

[Sieghard Schicktanz]

Hallo Marco,

Post by Marco Moock

Post by Sieghard Schicktanz
Seit wann kennt Windows den grub und kann dem was überschreiben?

Bei 2x Ubuntu ist sowas glaub schon passiert, bei Windows wäre mir das
neu.

Ja, bei unpassender Konfiguration könnte ich mir das vorstellen. Aber Du
schriebst ja von Windows.

Post by Marco Moock

Post by Sieghard Schicktanz
Oder meinst Du den Vorgang, daß Windows den _EFI-Lader_ mittels seiner
Boot-Tabelle "gerne" immer wieder auf sich selber setzt?

Das betrifft ja nur die Bootreihenfolge, die problemlos geändert werden
kann.

Im Prinzip schon, man muß es "nur" wissen, und auch wissen, wie man
damit umgehen und es ggfs. ändern kann.

Post by Marco Moock

Post by Sieghard Schicktanz

Post by Marco Moock
Schonmal mit eigenen EFI-Partitionen für jedes OS probiert?

Geht das überhaupt? Wie?

2. Partition mit Typ EF00 anlegen, fat32 drauf, als /boot/efi im
Installer eintragen.
Die andere Partition wird dann vom installierten OS nicht spezielle
angefasst.

Ja, _einrichten_ kannst Du sowas, aber die "andere Partition" sollte dann
nicht nur "vom installierten OS", sondern auch vom EFI-Lader nicht
"angefasst" werden, d.h. die sollte komplett ignoriert werden und wäre
damit völlig überflüssig.
BTW, die einzige Möglichkeit, die irgendwie zu nuten, die ich kenne, wäre
ein EFI-Shell-Skript, das irgendwas mit dieser _anderen_ Partition
anstellt. Das kann die EFI-Shell, und evtl. kann die auch FAT- und mglw.
sogar NTFS-Partitionen bearbeiten. ext<n> oder sowas nicht "nativ", und
einen Treiber dafür schreibt wohl kaum ein Linuxer...

D.h. - evtl. kann man den EFI-Lader mittels seiner Boot-Tabelle auf eine
andere als die erste EFI-Partition (oder gar eine andere?) schalten und von
der was laden, halt, sofern er mit dem Dateisystem umgehen kann.

[Ralph Aichinger]

Post by Hermann Riemann
Jede Installation eigene / und eigene /home partition.

Ich würde mehr als eine Installation einfach in jeweils einer virtuellen
Maschine ausführen.

/ralph

[Hermann Riemann]

Post by Ralph Aichinger

Post by Hermann Riemann
Jede Installation eigene / und eigene /home partition.

Ich würde mehr als eine Installation einfach in jeweils einer virtuellen
Maschine ausführen.

Beim Suchen für virtuelle Maschinen habe ich nicht herausgefunden,
wie ich diverse partitions auf unterschiedliche Laufwerke
einzelnen virtuellen Distributionen virtuelle zuteilen kann.

[Marco Moock]

Post by Hermann Riemann
Beim Suchen für virtuelle Maschinen habe ich nicht herausgefunden,
wie ich diverse partitions auf unterschiedliche Laufwerke
einzelnen virtuellen Distributionen virtuelle zuteilen kann.

Den Satz musst du uns erläutern. Stück für Stück, sodass es jeder
versteht.

[Hermann Riemann]

Post by Marco Moock

Post by Hermann Riemann
Beim Suchen für virtuelle Maschinen habe ich nicht herausgefunden,
wie ich diverse partitions auf unterschiedliche Laufwerke
einzelnen virtuellen Distributionen virtuelle zuteilen kann.

Den Satz musst du uns erläutern. Stück für Stück, sodass es jeder
versteht.

Beispiel: Gegeben 1 SSD, 1 HD.

Auf der SSD will ich je eine partition
für SuSE, Debian und Mint / haben.
auf der HD will ich je eine partition
für SuSE, Debian und Mint /home haben.
Debian soll Basis sein, SuSE und Mint virtuell.

Und dann
Was passiert mit einer swap partition?
Oder braucht jede Distribution eine eigene swap partition?
..

[Marco Moock]

Post by Hermann Riemann
Beispiel: Gegeben 1 SSD, 1 HD.

Für die VM egal. Die hat Images irgendwo auf einem Host-Dateisystempfad,
die der VM präsentiert werden. Kannst du beliebig anlegen. Eine VM kann
auch 10 Platten a 2GB haben. Sind dann 10 Images, die irgendwo auf
deinem Host-System liegen können.

[Marc Haber]

Post by Marco Moock

Post by Hermann Riemann
Beispiel: Gegeben 1 SSD, 1 HD.

Für die VM egal. Die hat Images irgendwo auf einem Host-Dateisystempfad,
die der VM präsentiert werden. Kannst du beliebig anlegen. Eine VM kann
auch 10 Platten a 2GB haben. Sind dann 10 Images, die irgendwo auf
deinem Host-System liegen können.

Und es ist _sehr_ hilfreich, einfach LVM zu verwenden. Dann haben die
logical volumes einen Namen und sind auch im virt-manager mit diesem
Namen sichtbar. Das senkt die Verwechslungsgefahr doch erheblichst.

Grüße
Marc

[Hermann Riemann]

Und es ist _sehr_ hilfreich, einfach LVM zu verwenden. Dann haben die > logical volumes einen Namen und sind auch im virt-manager mit diesem>

Namen sichtbar. Das senkt die Verwechslungsgefahr doch erheblichst.
Irgendwann hatte ich ein Dateisystem, welches logische partitions
nicht auf die hardware legte, die ich haben wollte.
Seitdem verwende ich außer bei /boot/efi und swap nur ext*.

[Tim Ritberg]

Post by Marc Haber

Post by Marc Haber
Und es ist _sehr_ hilfreich, einfach LVM zu verwenden. Dann haben die

logical volumes einen Namen und sind auch im virt-manager mit diesem>

Namen sichtbar. Das senkt die Verwechslungsgefahr doch erheblichst.
Irgendwann hatte ich ein Dateisystem, welches logische partitions
nicht auf die hardware legte, die ich haben wollte.
Seitdem verwende ich außer bei /boot/efi und swap nur ext*.

Partitionen können auch Namen haben...

Tim

[Hermann Riemann]

Post by Tim Ritberg

Post by Marc Haber

Post by Marc Haber
Und es ist _sehr_ hilfreich, einfach LVM zu verwenden. Dann haben die

logical volumes einen Namen und sind auch im virt-manager mit diesem>

Namen sichtbar. Das senkt die Verwechslungsgefahr doch erheblichst.
Irgendwann hatte ich ein Dateisystem, welches logische partitions
nicht auf die hardware legte, die ich haben wollte.
Seitdem verwende ich außer bei /boot/efi und swap nur ext*.

Partitionen können auch Namen haben...

Meistens habe ich mit SuSE Partitionierer partitioniert.
Und denen dann Verzeichnisnamen zugeordnet.

z.B. USB-Platten.
Etwa unter /xyz eingebunden,
da ein Verzeichnis etwa /xyz/abc angelegt.
den mit chmod und chown auf user und ich berechtigt.
und dann wieder ausgehängt.
Damit kann ich dann ohne su Dateien zwischen verschiedenen
Linux PCs transportieren.
Bei einem neuen PC habe ich meist mit SuSE partitioniert.

Spätere Experimente ergaben,
parted ist gut zum löschen von partitions,
gparted zum anlegen und anschauen.
Ob das noch aktuell ist, weiß ich nicht.

[Hermann Riemann]

Post by Marco Moock

Post by Hermann Riemann
Beispiel: Gegeben 1 SSD, 1 HD.

Für die VM egal. Die hat Images irgendwo auf einem Host-Dateisystempfad,
die der VM präsentiert werden.
Kannst du beliebig anlegen.

Und wenn ich für ein Image 2 partitions haben will?
wovon der Teil für / auf SSD, der Teil für /home auf HD liegt?

[Marc Haber]

Post by Hermann Riemann

Post by Marco Moock

Post by Hermann Riemann
Beispiel: Gegeben 1 SSD, 1 HD.

Für die VM egal. Die hat Images irgendwo auf einem Host-Dateisystempfad,
die der VM präsentiert werden.
Kannst du beliebig anlegen.

Und wenn ich für ein Image 2 partitions haben will?
wovon der Teil für / auf SSD, der Teil für /home auf HD liegt?

Dann gibst Du der VM halt zwei virtuelle Festplatten und legst die
eine auf eine SSD und eine auf den rotierenden Rost. Abgesehen davon
dass ich im Jahr 2024 solche elaborierten Setups für völlig
overengineered halte.

Grüße
Marc

[Sieghard Schicktanz]

Hallo Marco,

Post by Marco Moock

Post by Hermann Riemann
Beispiel: Gegeben 1 SSD, 1 HD.

Für die VM egal. Die hat Images irgendwo auf einem Host-Dateisystempfad,

Das kennt Hermann aber nicht, und er _hat_ die Systempartitionen ja schon
auf den physischen Platten. Die möchte er dann mit den virtuellen Maschinen
nutzen, und zwar genauso wie die gewohnten "Einzel-Stiefel^WBoots", nur
dann halt vielleiht beliebig umschaltbar, falls ihm bekannt wäre, daß das
geht.

[Marc Haber]

Post by Ralph Aichinger

Post by Hermann Riemann
Jede Installation eigene / und eigene /home partition.

Ich würde mehr als eine Installation einfach in jeweils einer virtuellen
Maschine ausführen.

Hermann installiert seine Linuxe nicht um damit zu arbeiten. Er
verbringt den ganzen Tag mit Installieren, Partitionieren und
Umbooten.

Grüße
Marc

[Hermann Riemann]

Post by Marc Haber

Post by Ralph Aichinger

Post by Hermann Riemann
Jede Installation eigene / und eigene /home partition.

Ich würde mehr als eine Installation einfach in jeweils einer virtuellen
Maschine ausführen.

Hermann installiert seine Linuxe nicht um damit zu arbeiten. Er
verbringt den ganzen Tag mit Installieren, Partitionieren und
Umbooten.

Die Installationszeit liegt unter 10%
Es kann durchaus für 1 oder 2 Tage Hauptbeschäftigung sein.
Ein Installation wird aufwendig, wenn etwas nicht funktioniert.
Und die Nachinstallation vieler Pakete kostet auch viel Zeit.

Meistens verwende ich SuSE, mit wachsendem Anteil auch Debian.
Und zeitweise auch das Betriebssystem für raspberry pi.
Früher war es nur SuSE.
Andere Distris sind nicht über Experimente hinausgekommen.
Außer selten Knoppix.

[Gerald E¡scher]

Post by Hermann Riemann
Momentan scheint es mir noch so,
als könne man Linux nur neben windows problemlos installieren.

Nein, man kann Linux noch problemloser neben macOS installieren,
jedenfalls auf Intel-Macs.

[Sieghard Schicktanz]

Hallo Ralph,

Post by Ralph Aichinger

Post by Tim Ritberg
https://linuxnews.de/debian-diskutiert-ueber-systemd-boot/

Die Logik kann ich nicht nachvollziehen: Ein weiterer EFI-Bootloader
soll in Debian kommen, aber du nennst das "Monokultur"?

Welche Systeme / Kernel kann der denn laden? Wenn der auf Linux beschränkt
sein sollte, dann kann er weniger als der im EFI-BIOS integrierte, sowieso
vorhandene Lader. Der hat halt vielleicht kein so schönes Boot-Menü...
Für den EFI-Lader hat der Kernel ja schon standardsmäßig den "EFI-Stub".

[Thomas Klix]

Post by Tim Ritberg
https://linuxnews.de/debian-diskutiert-ueber-systemd-boot/

Abwarten.
Für mich tut Grub2 alles, was ich brauche - ein systemd-boot müsste
mich erst einmal überzeugen...
Und vorerst ist und bleibt Grub2 Standard.

Thomas

[Marco Moock]

Post by Thomas Klix
Für mich tut Grub2 alles, was ich brauche - ein systemd-boot müsste
mich erst einmal überzeugen...

Für die meisten User wird das systemd-boot auch tun, speziell in Zeiten
von EFI, wo einfach jedes OS einen eigenen Bootloader mitbringen kann.

[Thomas Klix]

Post by Marco Moock

Post by Thomas Klix
Für mich tut Grub2 alles, was ich brauche - ein systemd-boot müsste
mich erst einmal überzeugen...

Für die meisten User wird das systemd-boot auch tun, speziell in Zeiten
von EFI, wo einfach jedes OS einen eigenen Bootloader mitbringen kann.

Mag sein.
Ich möchte aber Dinge wie "Grml-ISO-Boot" nicht missen.

Als sid-User ist man Kummer gewöhnt, aber in den letzten Tagn war es
heftig. Alles wieder gut, aber Werkzeuge wie timeshift habe ich
benötigt. Ein Grml in Bereitschaft hilft, Nervosität zu lindern.
(Ich bin auf einer "Emerency-Konsole" gelandet - hatte ich noch nie.
Aber: alles wieder gut. :-)

Thomas

[Sieghard Schicktanz]

Hallo Marco,

Post by Marco Moock
Für die meisten User wird das systemd-boot auch tun, speziell in Zeiten
von EFI, wo einfach jedes OS einen eigenen Bootloader mitbringen kann.

Du meinst wohl, wo _kein_ OS einen eigenen Boot-Lader braucht, weil das das
EFI-BIOS machen kann? (Könnte, aber die Linuxer trauen dem ja offenbar
nicht...)

[Gerald E¡scher]

Post by Sieghard Schicktanz

Post by Marco Moock
Für die meisten User wird das systemd-boot auch tun, speziell in Zeiten
von EFI, wo einfach jedes OS einen eigenen Bootloader mitbringen kann.

Du meinst wohl, wo _kein_ OS einen eigenen Boot-Lader braucht, weil das das
EFI-BIOS machen kann? (Könnte, aber die Linuxer trauen dem ja offenbar
nicht...)

Die UEFI-Firmware kann den Linux Kernel direkt booten.
https://docs.kernel.org/admin-guide/efi-stub.html

[Marco Moock]

Post by Sieghard Schicktanz
Du meinst wohl, wo _kein_ OS einen eigenen Boot-Lader braucht, weil
das das EFI-BIOS machen kann? (Könnte, aber die Linuxer trauen dem ja
offenbar nicht...)

Ich kenne bisher keine Distribution, die sowas im Installer anbietet
und ebenfalls weiß ich nicht, wie dann das Handling der Bootoptionen im
Bedarfsfall gelöst wird.

[Tim Landscheidt]

Post by Marco Moock

Post by Sieghard Schicktanz
Du meinst wohl, wo _kein_ OS einen eigenen Boot-Lader braucht, weil
das das EFI-BIOS machen kann? (Könnte, aber die Linuxer trauen dem ja
offenbar nicht...)

Ich kenne bisher keine Distribution, die sowas im Installer anbietet
und ebenfalls weiß ich nicht, wie dann das Handling der Bootoptionen im
Bedarfsfall gelöst wird.

Apropos: Gibt es irgendwo einen aktuellen, umfassenden,
fettlosen Artikel, der das heutige „Bootsystem“ erklärt, oh-
ne dabei auch die Geschichte von dessen Entwicklung zu er-
zählen?

Sprich: Woran erkennt man (zuverlässig), welche Bootverfah-
ren ein System unterstützt, mit welchem wurde ein laufendes
System gestartet, etc.?

Tim

[Marco Moock]

Post by Tim Landscheidt
Sprich: Woran erkennt man (zuverlässig), welche Bootverfah-
ren ein System unterstützt, mit welchem wurde ein laufendes
System gestartet, etc.?

[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
Wenn es das gibt, wurde mit EFI gestartet.

Zum Rest würde ich einen separaten Thread vorschlagen.