Gentoo systemd - Erfahrungsbericht

Message

ManfredB · Post by **ManfredB** » Wed Nov 06, 2019 10:06 am

Hallo zusammen,

Gestern habe ich einen neuen Versuch gestartet, Gentoo systemd zu installieren.

Vor kurzem hatte ich hier einen Thread geöffnet mit der Frage, welches der Handbücher
zu nutzen ist oder ob beide zusammenhängen....

Mein Versuch basiert allein auf dem systemd-WIKI, und damit hatte ich Erfolg.

Denn dort beginnt die Installation an einem anderen Punkt als im AMD64-Handbuch:

Zuerst kommt der Kernel an die Reihe, und erst, wenn die Konfiguration gelaufen ist,
eselect profile list
emerge -avuDN world

Ich nutze beim Kernel immer auch genkernel, weil ich in --menuconfig eine bessere Übersicht habe.
In dem systemd-Handbuch steht da
genkernel --install all

Das habe ich zuerst gemacht in der Annahme, daß da alles drin ist, was für systemd erforderlich ist.

Doch da habe ich mich geirrt.
Als ich mit der gesamten Installation fertig war, kam ich nicht auf den Desktop.
Grund: die für die nvidia-Grafikkarte zu ändernden Einstellungen waren nicht vorgenommen.

Also habe ich erneut
genkernel --menuconfig all
durchgeführt und dabei alle NVIDIA-Sachen gelöscht.

Als das fertig war, konnte ich problemlos auf dem plasma-Desktop landen,
das hier schreibe ich von dort aus.

Übrigens habe ich einmal in der chroot-Umgebung, als das große Basis-Update kam,
aufgeschrieben, wie lange das gedauert hat:
Um 8.44 Uhr begann der Prozess mit 371 Paketen
Da sys-devel/gcc während dieses Prozesses ein Update erfährt,
wurde der Prozess unterbrochen, weil einige Pakete nicht installiert werden konnten.
Also gcc-config -l 8.3.0-r1
und gcc-config -f 2 9.2.0-r2
Danach 93 Pakete, die zT rebuilds waren
Der Rest des Updates 57 Pakete
Ende des Updates um 12.14 Uhr
Also 3 1/2 Stunden

Weil ich sicher gehen wollte, daß am Ende kein Problem ensteht,
habe ich innerhalb der chroot-Umgebung
kde-plasma/plasma-meta und kde-plasma/plasma-nm
kde-apps (nur 4 Gruppen und einige zusätzliche Pakete)
installiert.

Als ich mit allem ferig war, habe ich das System neu gestartet.
Was zuerst nicht geklappt hat, war das Internet, obwohl Kabel-Anschluss am PC vorhanden ist.

systemctl enable systemd-networkd.service
systemctl start systemd-networkd.service

Trotzdem hatte ich kein Internet.
Bis ich auf den Fehler kam, den ich gemacht hatte:
/etc/resolv.conf als Link zu /run/systemd/resolve/resolv.conf
Als ich irgendwann diese /etc/resolv.conf mal in mc angeklickt habe,
dabei habe ich entdeckt, daß dort
resolf.conf
stand. Als ich diesen Schreibfehler korrigiert hatte, mußte ich die beiden Zeilen
systemctl enable systemd-networkd.service
systemctl start systemd-networkd.service
wiederholen.
Nach Neustart des Systems hatte ich dann endlich Internet.

Ehrlich: ich habe schon viele Versuche mit systemd gestartet,
bin immer wieder an irgendwelchen Einstellungen gescheitert.

Doch diesmal habe ich Erfolg gehabt, und darüber bin ich sehr froh.

Gentoo-stable
Gentoo-unstable (ACCEPT_KEYWORDS="~amd64"
Gentoo-systemd (ACCEPT_KEYWORDS="~amd64"

Fazit: so intensiv, wie ich mich in den letzten Monaten mit gentoo beschäftigt habe,
habe ich das zuvor noch nie gemacht.
Aber ich habe sehr viel gelernt und nutze diese Kenntnisse
mit Freude.

Gruß
Manfred

schmidicom · Post by **schmidicom** » Wed Nov 06, 2019 12:24 pm

Gerade beim Netzwerk wundert es mich nicht das es nicht auf Anhieb geklappt hat, denn das ist auch genau der Teil der meiner Meinung nach im Gentoo-Wiki viel zu kurz kommt.

EDIT: Ubuntu hat eine recht gute Doku zu networkd.
https://wiki.ubuntuusers.de/systemd/networkd/

ManfredB · Post by **ManfredB** » Wed Nov 06, 2019 5:22 pm

Übrigens habe ich im AMD64-Handbuch einen Fehler gefunden:

grub2-mkconfig -o /boot/grub/grub.cfg
funktioniert nicht, denn auch wenn bei der Installation
emerge --ask --verbose sys-boot/grub:2
angezeigt wird, heisst es dennoch
grub-mkconfig -o /boot/grub/grub.cfg

Das noch als kleiner Nachtrag.

Gruß
Manfred

ManfredB · Post by **ManfredB** » Thu Nov 07, 2019 9:04 am

Neue Info:

Internet-Verbindung klappt nicht auf Anhieb.

Ich kann nur eins sagen: mein "Gentoo-Arzt" ist inzwischen ArchLinux.
Warum?
2 Programme, die es bei gentoo so nicht gibt, habe ich mir von ArchLinx geholt.

Nur damit das nicht mißverstanden wird: keine Installation im üblichen Sinn.

Meine erste Erfahrung habe ich mit genfstab gemacht, das ArchLinux-Paket
im mc angeklickt, dann wird es geöffnet und man sieht Verzeichnisse.
Genau die habe ich genutzt, um die Inhalte in dieselben Verzeichnisse bei Gentoo zu kopieren,
genfstab ist Inhalt des Programms arch-install-scripts.
3 Programme beinhaltet dieses script, eines davon genfstab.

Und dieses Programm funktioniert einwanfrei unter gentoo.

Nun kommt Programm 2:
netctl
/etc/netctl
Aus dem Unterverzeichnis "examples" habe ich "ethernet-dhcp" ins Verzeichnis /etc/netctl kopiert
und im Inhalt eth0 durch enp3s0 ersetzt.

Dann habe ich den Test gemacht:
netctl enable ethernet-dhcp
netctl start ethernet-dhcp

Und was ich erst nicht glauben wollte, hat funktioniert.
So wie bei ArchLinux habe ich jetzt unter gentoo systemd Internet ohne weitere Eingriffe.

Ich weiss, daß das nicht ein normaler Vorgang ist, aber da er funtkioniert, ist mir das schon recht.

Gruß
Manfred

SkaaliaN · Post by **SkaaliaN** » Wed Nov 13, 2019 12:43 pm

Hallo zusammen,

hatte von euch schonmal jemand das Problem, dass ein Daemon trotz "systemctl enable xxx.service" nicht beim nächsten Neustart ausgeführt wird?
Die Verlinkung hat stattgefunden.

Code: Select all

 systemctl start xxx.service

funktioniert ebenfalls einwandfrei.

Danke,

lg

schmidicom · Post by **schmidicom** » Wed Nov 13, 2019 12:51 pm

@SkaaliaN
Ja, bei mir war es eine fehlerhafte Abhängigkeit innerhalb des jeweiligen Service-Unit.
Mein Dienst hatte ein "Requires=mysqld.service" drin aber installiert war ein MariaDB weshalb es kein "mysqld.service" gab.

mike155 · Post by **mike155** » Wed Nov 13, 2019 2:41 pm

hatte von euch schonmal jemand das Problem, dass ein Daemon trotz "systemctl enable xxx.service" nicht beim nächsten Neustart ausgeführt wird?
Die Verlinkung hat stattgefunden.

Was sagt denn

Code: Select all

systemctl status xxx.service

direkt nach dem Neustart (bevor Du xxx mit "systemctl enable" von Hand gestartet hast)?

Steht sonst irgendetwas dazu im Journal?

Code: Select all

journalctl -b | grep xxx

SkaaliaN · Post by **SkaaliaN** » Wed Nov 13, 2019 4:07 pm

mike155 wrote:
hatte von euch schonmal jemand das Problem, dass ein Daemon trotz "systemctl enable xxx.service" nicht beim nächsten Neustart ausgeführt wird?
Die Verlinkung hat stattgefunden.
Was sagt denn
Code: Select all
systemctl status xxx.service 
direkt nach dem Neustart (bevor Du xxx mit "systemctl enable" von Hand gestartet hast)?

Steht sonst irgendetwas dazu im Journal?
Code: Select all
journalctl -b | grep xxx

Code: Select all

 systemctl status dhcpcd
            ● dhcpcd.service - Lightweight DHCP client daemon
   Loaded: loaded (/lib/systemd/system/dhcpcd.service; disabled; vendor preset: disabled)
   Active: inactive (dead)

Code: Select all

journalctl -b  | grep dhcpcd
Nov 13 17:02:56 localhost dhcpcd[4022]: dev: loaded udev
Nov 13 17:02:56 localhost dhcpcd[4022]: no interfaces have a carrier

Die Netzwerkverbindung ist definitiv vorhanden und per Kabel verbunden.
Der Netzwerkservice ist ebenfalls gestartet:

Code: Select all

systemctl status systemd-networkd.service
● systemd-networkd.service - Network Service
   Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2019-11-13 17:01:14 CET; 1min 28s ago
     Docs: man:systemd-networkd.service(8)
 Main PID: 3074 (systemd-network)
   Status: "Processing requests..."
      CPU: 198ms
   CGroup: /system.slice/systemd-networkd.service
           └─3074 /lib/systemd/systemd-networkd

Starte ich dhcpcd selbst, funktioniert es einwandfrei:

Code: Select all

systemctl status dhcpcd
● dhcpcd.service - Lightweight DHCP client daemon
   Loaded: loaded (/lib/systemd/system/dhcpcd.service; disabled; vendor preset: disabled)
   Active: active (running) since Wed 2019-11-13 17:02:56 CET; 5min ago
  Process: 4022 ExecStart=/sbin/dhcpcd -q (code=exited, status=0/SUCCESS)
 Main PID: 4034 (dhcpcd)
      CPU: 85ms
   CGroup: /system.slice/dhcpcd.service
           └─4034 /sbin/dhcpcd -q

mike155 · Post by **mike155** » Wed Nov 13, 2019 4:47 pm

Systemd startet beim Booten die Netzwerk-Dienste bereits frühzeitig, auch wenn die Netzwerk-Interfaces noch nicht "up and running" sind.

Wenn die Netzwerk-Dienste dann Sockets öffnen, die an bestimmte Interfaces gebunden sind, gibt es Fehler - weil die Interfaces zu diesem Zeitpunkt noch nicht vorhanden sind.

Lösung: Wenn man Systemd verwendet, darf man Dienste nicht an einzelne Interfaces binden.

Beispiel für sshd_config:

Code: Select all

Falsch bei Systemd:  ListenAddress 10.0.0.1  
Richtig bei Systemd: ListenAddress 0.0.0.0

Max Steel · Post by **Max Steel** » Wed Nov 13, 2019 5:27 pm

Find ich doof...
ich hab Services die auf dem "Gast-Netz" nichts zu suchen haben, diese möchte ich auch nicht dort sehen.

Naja und die Aussage "Falsch und Richtig" ist eher was für Philosophen, ich würde es begrüßen müsste ich das nicht mit der Firewall erschlagen, weil die Firewall sowieso mit läuft, sondern verstehe die Firewall da als zusätzliche Netzseparation.

mike155 · Post by **mike155** » Wed Nov 13, 2019 5:45 pm

Find ich doof...
ich hab Services die auf dem "Gast-Netz" nichts zu suchen haben, diese möchte ich auch nicht dort sehen.

Sehe ich ganz genauso. Es ist eine klassische Sicherheits-Maßnahme, den SSH-Daemon nur am Management-Interface lauschen zu lassen - und nirgendwo sonst.

Aber Systemd ist nicht einfach nur ein Ersatz für Sysvinit oder OpenRC - sondern vieles funktioniert grundlegend anders. Hier muss man umdenken!

Zu dem "Network up and running"-Problem gibt es einen Artikel von Lennart Poettering: https://www.freedesktop.org/wiki/Softwa ... orkTarget/. Es gibt auch noch einen zweiten Artikel, in dem er denjenigen, die einen Dienst wirklich nur an einem Interface lauschen lassen wollen, den Einsatz einer Firewall-Regel empfiehlt - aber den finde ich gerade nicht.

schmidicom · Post by **schmidicom** » Wed Nov 13, 2019 6:56 pm

Hmm, so wirklich aktiviert sieht der Dienst aber nicht aus.

Loaded: loaded (/lib/systemd/system/dhcpcd.service; disabled; vendor preset: disabled)

Und wenn der Dienst aufgrund seiner Konfiguration, oder wegen irgend etwas anderem, erst starten soll wenn das Netzwerk fertig eingerichtet ist wäre es möglicherweise sinnvoll eine entsprechende Abhängigkeit (mit "Requires=" und "After=") hinzuzufügen.
https://www.digitalocean.com/community/ ... unit-files

EDIT:
Ich habe mir mal das Service-Unit von dhcpcd angesehen und es hat eine Abhängigkeit zu "network-online.target", aber dieses Target kann (wenn networkd in Verwendung ist) nur richtig funktionieren wenn auch "systemd-networkd-wait-online.service" aktiviert wird. Dann geht "network-online.target" erst auf den Status gestartet wenn networkd alle seine Aufgaben erledigt hat.

mike155 · Post by **mike155** » Wed Nov 13, 2019 7:56 pm

erst starten soll wenn das Netzwerk fertig eingerichtet ist

Wie ich oben schon schrieb: von diesem Konzept sollte man sich unter Systemd schnellstmöglich verabschieden (siehe auch der Link oben zu Lennarts Artikel). Stattdessen sollte man seine Dienste so schreiben oder konfigurieren, dass sie auch laufen, wenn das Netzwerk noch nicht fertig konfiguriert wurde!

schmidicom · Post by **schmidicom** » Wed Nov 13, 2019 8:09 pm

mike155 wrote:
erst starten soll wenn das Netzwerk fertig eingerichtet ist
Wie ich oben schon schrieb: von diesem Konzept sollte man sich unter Systemd schnellstmöglich verabschieden (siehe auch der Link oben zu Lennarts Artikel). Stattdessen sollte man seine Dienste so schreiben oder konfigurieren, dass sie auch laufen, wenn das Netzwerk noch nicht fertig konfiguriert wurde!

Im seinem Fall geht es aber offenbar nicht anders und unabhängig davon ist es besser wenn dafür gesorgt wird das auf network-online.target verlass ist.

musv · Post by **musv** » Thu Nov 14, 2019 7:46 am

hatte von euch schonmal jemand das Problem, dass ein Daemon trotz "systemctl enable xxx.service" nicht beim nächsten Neustart ausgeführt wird?
Die Verlinkung hat stattgefunden.
Code: Select all
 systemctl status dhcpcd
            ● dhcpcd.service - Lightweight DHCP client daemon
   Loaded: loaded (/lib/systemd/system/dhcpcd.service; disabled; vendor preset: disabled)
   Active: inactive (dead)
 

Da hätte ich meine Zweifel. Das erste "disabled" sagt eindeutig aus, dass der Link nicht gesetzt ist (multi-user.target.wants/).

Davon mal abgesehen bringt systemd einen eigenen DHCP-Client mit. Du brauchst DHCPCD nicht.