Archlinux & Co auf einem Banana Pi

[berni51]

Und ich befürchte, dass Du damit sehr richtig liegst!
Hab ja schon beide Images (arm7 und arm64) probiert, dass auch noch mit verschiedenen dts und u-booten - bisher alles vergeblich.
Die fetten Ubuntus und Debians, die der Quasi-Standard sind, sagen mir überhaupt nicht zu, immerhin hab ich ein schlankes Arch zum Laufen bekommen. Aber es werden wohl noch genügend kalte, graue Wintertage zum Probieren kommen.

 

[CommanderZed]

Und ich befürchte, dass Du damit sehr richtig liegst!
Hab ja schon beide Images (arm7 und arm64) probiert, dass auch noch mit verschiedenen dts und u-booten - bisher alles vergeblich.
Die fetten Ubuntus und Debians, die der Quasi-Standard sind, sagen mir überhaupt nicht zu, immerhin hab ich ein schlankes Arch zum Laufen bekommen. Aber es werden wohl noch genügend kalte, graue Wintertage zum Probieren kommen.

Ich fürchte auch - der ARM-Support von OpenBSD ist eher ... knapp und geht soweit ich weiß nicht über das Hinaus was in der Manpage steht.

Du könntest natürlich mal auf @arm fragen ob nen entwickler lust hat mit dir etwas zu basteln sofern ihr beide zeit habt - ich verfolge @arm son bisschen und gelegentlich ist da mal was draus geworden.

Debian/Arch> Ich hab für mein Raspberry jetzt auch erstmal Arch genommen, wobei ich debian in der minimalinstall nicht als "Fett" bezeichnen würde, zumindest nicht was die Laufenden Prozesse etc angeht.
Was mir aufgefallen ist, archlinuxarm scheint dem normalen archlinux etwas hinterherzuhängen was die Package-Aktualität angeht.

Wenn du lust hast dich drüber auszutauschen würde ich mit den letzten Posts einen neuen Thread im geplauder erstellen.

 

[berni51]

Gegenüber dem BananaPi ist die Situation beim Raspberry ja geradezu traumhaft: Alle 3 BSDs laufen, jede Menge Linuxe, da ist doch immer was Passendes dabei. Das Archlinuxarm etwas hinterher hängt stimmt wohl, die sind gerade bei Kernel 4.9.241-3. Läuft aber schön stabil, auch auf dem BananaPi.

Und ja, lass uns doch im allgemeinen Geplauder darüber austauschen.

Berni

 

[CommanderZed]

Gegenüber dem BananaPi ist die Situation beim Raspberry ja geradezu traumhaft: Alle 3 BSDs laufen, jede Menge Linuxe, da ist doch immer was Passendes dabei. Das Archlinuxarm etwas hinterher hängt stimmt wohl, die sind gerade bei Kernel 4.9.241-3. Läuft aber schön stabil, auch auf dem BananaPi.

Und ja, lass uns doch im allgemeinen Geplauder darüber austauschen.

Berni

Beim Berry bekomm ich 5.19.8 - du hast natürlich recht, der berry hat eine etwas breitere OS-Auswahl. Trotzdem ist es jetzt erstmal archlinux geworden. Letztlich soll da meine nextcloud hinwandern die zurzeit noch bei einer gemieteten openbsd-vm bei einem bekannten vserver-beträiber läuft.

Alternativ wäre noch OpenBSD gewesen, aber auf der einen Seite scheint mir arm64 nicht so hyper-stabil und simpel und auf der anderen Seite gibt es wohl ein Problem wie nextcloud die downloads über php handelt die dadurch unter httpd sehr langsam sind - das heist da müsste ich vermutlich auch unter OpenBSD auf Apache oder Nginx wechseln.

Letztlich hab ich das Problem das meine Energie momentan für diese Projekte etwas "schmal" ist weshalb ich da an 2 stellen leider auf Linux wechsel da ich nicht ressourcen habe da lösungen am "Standard-Weg" der jeweiligen Software & Hardware vorbei zu suchen - ich hoffe das wird noch mal besser, dann wird da evtl. auch mal ein OpenBSD wieder werkeln (Oder, da bin ich aber blutiger Anfänger, evtl. auch mal ein FreeBSD)

Bislang bin ich mit dem arch recht zufrieden außer die leicht verspätete Software-Sache, aber das scheint mir jetzt auch nicht XX Wochen zu sein.

 

[Yamagi]

Das Archlinuxarm etwas hinterher hängt stimmt wohl, die sind gerade bei Kernel 4.9.241-3. Läuft aber schön stabil, auch auf dem BananaPi.

Ohne je einen BananaPi in der Hand gehabt zu haben, ist das Problem halt meist der bemitleidenswerte Zustand des SoC-Ökosystems. Diese ARM-SoC sind meist hochgradig proprietäre Suppe ohne allzu viel bis keiner Doku und Blobs statt freien Treiber. Das läuft dann auf exakt dem Linux-Kernel, für den der SoC-Hersteller seine Blobs veröffentlicht hat. Der gleiche Grund, aus dem Android-Smartphones meist an Uraltkernel gebunden sind... Andere Betriebssysteme wie FreeBSD oder OpenBSD drauf zum Laufen zu bringen ist schwer bis unmöglich.

Der RaspberryPi ist dort die sehr positive Ausnahme, denn die Raspberry Foundation hat viele Mühen auf sich genommen, um zusammen mit Broadcom zu einem vollständig dokumentierten und durch freie Treiber unterstützten SoC zu kommen. Mit dem RPi 4 sind sie dort inzwischen auch sehr weit gekommen.

 

[berni51]

Wahre Worte, Yamagi, leider. Und ich hab das Gefühl, dass es bei Lemaker, also dem BananaPi, besonders schlimm ist. Soviel schlechte und teils falsche Infos ins Netz zu baggern, dazu gehört schon was.

 

[GrandDixence]

Das Archlinuxarm etwas hinterher hängt stimmt wohl, die sind gerade bei Kernel 4.9.241-3.

Arch Linux (ARM) ist eine Linuxdistribution nach dem "Rolling Release"-Prinzip. Somit wird in dieser Linuxdistribution alle Software möglichst unmodifiziert von Upstream übernommen und verteilt.

Der offizielle Linux Kernel 4.9 wie auch die Kernelversion 4.19 sind LTS-Kernelversionen (longterm maintenance). Die Kernelversion 4.9 erhält noch bis Januar 2023 Sicherheitsupdates. Die Kernelversion 4.19 erhält noch bis Ende 2024 Sicherheitsupdates. Siehe dazu:

Active kernel releases

www.kernel.org

Linux-Kernel-Security: Linux-Distributionen fixen manche Kernel-Lücken nicht

Ihre Kernel-Version wird laut Kernel.org nicht mehr gepflegt? Dann weist sie vermutlich Sicherheitslücken auf, die anderswo schon längst gestopft wurden.

www.heise.de

Upstream ist bereits Version 4.9.336 des Linux Kernels erhältlich.

The Linux Kernel Archives

www.kernel.org

Arch Linux (x86_64) listet Version 4.9.335:

AUR (en) - linux-lts49

aur.archlinux.org

Kernel - ArchWiki

wiki.archlinux.org

Somit ist der hier eingesetzte Linux Kernel (4.9.241) voller bekannter Sicherheitslücken und sollte rasch möglichst ersetzt werden. Sieht danach aus, als wäre Arch Linux ARM eine "tote" Linuxdistribution:

Arch Linux ARM • View topic - No kernel update from Sep. 9th

Vielleicht mal einen Blick auf die gängigen LTS-Linuxdistributionen Ubuntu Server, SUSE Linux Enterprise Server (SLES) und die RedHAT Enterprise Linux (RHEL)-Abkömmlinge AlmaLinux und Rocky Linux werfen. Eventuell haben diese LTS-Linuxdistributionen ein aktuelles "Banana Pi"-Image im Angebot.

Die meisten Linuxdistributionen verwenden in den Raspberry Pi-Images nicht den offiziellen Linux Kernel (von kernel.org). Sondern ein von der Rasberry Foundation modifizierter Linux Kernel. Nennenswerte Ausnahme ist SUSE Linux Enterprise Server (SLES). SLES verwendet im Rasberry Pi-Image seit der Erstveröffentlichung den offiziellen AArch64/ARM8-Linux Kernel (von kernel.org).

Auszug aus dem "Raspberry Pi Quick Start Guide" von SLES15 SP4:

Based on upstream kernel
Raspberry Pi OS uses a kernel with modifications especially for the Raspberry Pi. SUSE
Linux Enterprise Server for Arm uses the default SUSE Linux Enterprise kernel for AArch64,
which is derived from the official mainline kernel.

Weitere Linuxdistributionen verwenden in der Zwischenzeit für das Raspberry Pi-Image den offiziellen Linux Kernel (von kernel.org). Siehe dazu die Kommentare unter:

Upstream Raspberry Pi 4 B support · Issue #43 · lategoodbye/rpi-zero

The Raspberry Pi 4 B has a new brand SoC BCM2711 (1.5GHz Quad A72, VideoCore 6) LPDDR4 (1-8 GB) VIA Labs VL805 USB 3.0 Host controller (XHCI) USB bridge with 2x USB 3.0 and 2x USB 2.0 ports DWC2 co...

github.com

 

[-Nuke-]

Du vermischst gerade ArchLinux, ArchLinux ARM und das AUR. Die drei Sachen haben alle nichts direkt miteinander zu tun in Sachen Release-Support.

 

[CommanderZed]

Arch Linux (ARM) ist eine Linuxdistribution nach dem "Rolling Release"-Prinzip. Somit wird in dieser Linuxdistribution alle Software möglichst unmodifiziert von Upstream übernommen und verteilt.

Ich wollte hier keinen Distro-Wars starten - das Package was mir anfang november aufgefallen ist das etwas veraltet war (php) gegenüber arch ist inzwischen sauber aktualisiert und auch das nächste update ist dann ähnlich schnell gekommen soweit ich das gesehen hab. Es gibt für den PI auch ein neueres Firmware-Package mit em 6er wenn man möchte, das ist sogar im von dir verlinkten Thread erwähnt.

Es wäre nett wenn wir uns hier friedlich auf das Thema konzentrieren, ich behalte es mir vor das sonst ggf. zu löschen.

 

[mr44er]

@GrandDixence
Ich will dir nicht deinen Enthusiasmus bei den posts nehmen, aber hier sind überwiegend keine blutigen Anfänger, die nach 40 Jahren eine Umschulung auf IT gemacht haben.
Und wenn doch, dann ergibt sich das anhand Nachfragen.

 

[-Nuke-]

Wie Yamagi schon angedeutet hat. ARM ist nicht x86. ARM fehlt so ein gewisser "IBM PC"-ähnlicher Standard, der es einem Betriebssystem ermöglicht auf möglichst vielen Prozessorvarianten und Systemkonfigurationen zu laufen. Entsprechende "IBM PC" Standard ARM Systeme (mit EFI und Co.) gibt es zwar im Serverbereich, aber an sich nicht oft als kleiner SBC und wesentlich teurer. Für normale Endnutzer z.B. der Phytium D2000

Wenn man relativ frust-frei ein ARM System betreiben will, kommt man eigentlich um ein Raspberry Pi nicht drum herum. Es hat auch gut 10 Jahre gedauert, bis der RPi mit OpenSource Treibern "gut genug" funktioniert und man hier verhältnismäßig gute Erfahrung mit dem System so allgemein hat.

Andere Boards mögen mehr Performance und/oder mehr Schnittstellen haben, aber irgendwas anderes ist dann trotzdem noch. Alter Kernel, schlechte Grafiktreiber, Stabilitätsprobleme, etc. pp.

Es gibt auch noch ein paar Boards die haben einen PCIe Slot. Dort gibt es auch ein paar, wo man mit einem generischen Kernel und etwas U-Boot Setup schon weit genug kommt, um mit einer handelsüblichen AMD Radeon-Karte zumindest einen grundlegenden funktionierenden ARM Computer mit Open Source Grafiktreibern zu haben. Preis/Leistung ist aber jenseits von Gut und Böse, sodass ich das auch nicht großartig selbst ausprobiert habe.

 

[berni51]

Der BananaPi M5 läuft zwar mit dem Archlinuxarm sehr gut, aber dann gab es ein Problem mit dem auditd, also mit systemd. Das hab ich nicht so ganz in den Griff gekriegt, und bin dann auf Armtix mit openrc umgestiegen. Läuft deutlich unkomplizierter und die etwas schwächere Paketauswahl ist bei nem SBC nicht wirklich schlimm. Für mich passts!
Die Versuche mit OpenBSD laufen aber weiter - bislang ohne Erfolg.

 

[CommanderZed]

Der BananaPi M5 läuft zwar mit dem Archlinuxarm sehr gut, aber dann gab es ein Problem mit dem auditd, also mit systemd. Das hab ich nicht so ganz in den Griff gekriegt, und bin dann auf Armtix mit openrc umgestiegen. Läuft deutlich unkomplizierter und die etwas schwächere Paketauswahl ist bei nem SBC nicht wirklich schlimm. Für mich passts!

Bei mir funktioniert systemd unfallfrei bislang - hab aber auch noch nie von auditd gehört.

Die Versuche mit OpenBSD laufen aber weiter - bislang ohne Erfolg.

Ich fürchte ohne einen Entwickler einzuschalten wirst du da kaum weiterkommen, arm ist wie der yamagi schreibt echt nicht schön was einige sachen angeht)

 

[berni51]

Ich steig mal in die mailing list ein ...

 

[-Nuke-]

Bei mir funktioniert systemd unfallfrei bislang - hab aber auch noch nie von auditd gehört.

Das ist ein Service der mit dem Kernel zusammenarbeitet, um bestimmte, konfigurierbare Aktionen am System zu loggen. Kannst dir z.B. loggen lassen wer wann eine Datei gelesen, geschrieben und/oder ausgeführt hat. Anders als behauptet hat auditd nichts mit systemd zu tun.

Auditing ist zumindest bei ArchLinux standardmäßig aktiviert, kann man aber auch deaktivieren.

 

[CommanderZed]

Das ist ein Service der mit dem Kernel zusammenarbeitet, um bestimmte, konfigurierbare Aktionen am System zu loggen. Kannst dir z.B. loggen lassen wer wann eine Datei gelesen, geschrieben und/oder ausgeführt hat. Anders als behauptet hat auditd nichts mit systemd zu tun.

Auditing ist zumindest bei ArchLinux standardmäßig aktiviert, kann man aber auch deaktivieren.

Und dafür liebe ich dieses Forum - schon hat man wieder etwas interessantes, neues gelernt.

(Ich hab mich für arch on arm entschieden, das hatte ich vergessen zu schreiben, da der Berry Hand-in-Hand mit einer AMD64 Kiste die auch arch haben wird zusammenarbeiten soll - dachte das macht den ganzen bums etwas einfacher)

 

[berni51]

Mein Problem ist, dass der auditd deaktiviert ist (von mir), aber trotzdem alle Bildschirme zumüllt. Laut /proc ist audit aber im kernel aktiviert, und mit dem kernel bauen bei Linux möchte ich mich eigentlich nicht beschäftigen.
Ich krieg zwar die audit-logs reduziert, aber nicht ganz abgeschaltet. Das Problem taucht aber nur bei archlinuxarm auf und da gar nicht so selten.
Das Armtix dagegen ist mit dem wunderbaren openrc viel besser zu händeln.
@-Nuke- hat natürlich recht damit, dass auditd kein Bestandteil von systemd ist, aber die beiden hängen dennoch eng zusammen. Zitat aus dem ArchWiki:

Note: In order to disable audit completely and suppress audit messages from appearing in journal you may set audit=0 as kernel parameter and/or mask systemd-journald-audit.socket.

Also bisschen kernel, bisschen Service, bisschen systemd socket - ich kriegs jedenfalls nicht richtig auseinander klamüsert und war nur noch genervt von den audit Meldungen. Jetzt ist Ruhe im Karton.

 

[CommanderZed]

Wo sieht man die denn?

Ist das etwas was einen ... beunruigen sollte?

Oder spamt das voll weil mans deaktiviert hat?

 

[double-p]

Nur mal so aus dem OFF: der "Note"-Meldung nach koennte man sinngemaess auch sagen, dass postfix zu rc.d gehoert, weil man das /var/log/maillog per "rcctl disable postfix" abstellt ;-)

(fix the problem, not the logger)

 

[medV2]

Systemd kann Socketactivation, es erstellt also einen Socket und startet den zugehörigen Daemon wenn jemand darauf zugreifen will. Wenn du per systemctl den auditd service deaktiviert kann er also trotzdem noch gestartet werden, eben über die socketactiviation. Da musst du auch diese abschalten. Idr. weißt einem systemd aber auch darauf hin, aber kA was die Defaulteinstellungen bei Arch sind.

 

[double-p]

Davon ist auditd aber nicht "abhaengig"..

 

[-Nuke-]

Mein Problem ist, dass der auditd deaktiviert ist (von mir), aber trotzdem alle Bildschirme zumüllt. Laut /proc ist audit aber im kernel aktiviert, und mit dem kernel bauen bei Linux möchte ich mich eigentlich nicht beschäftigen.

Du musst keinen Kernel bauen um ein Feature zu deaktivieren. Wie du unten schon zitiert hast, einfach audit=0 als boot-Parameter hinzufügen und dann ist es abgeschaltet. Das ist im Regelfall einfacher als das komplette OS neu zu installieren. Gerade auf ARM SBCs ist das in der Regel das Editieren einer einzelnen Config-Datei.

Also bisschen kernel, bisschen Service, bisschen systemd socket

Der von dir zitierte Text ist einfach nur sehr allgemein gefasst. Wenn du auditing im Kernel deaktivierst, geht auch der Dienst nicht an. Wie auch? Der Kernel stellt die entsprechenden Funktionen gar nicht mehr bereit. Der Dienst kann gar nicht mehr funktionieren.

Wo sieht man die denn?
Ist das etwas was einen ... beunruigen sollte?
Oder spamt das voll weil mans deaktiviert hat?

Meine Vermutung ist, dass bei der ArchLinux ARM Installation irgendwas mit dem Kernel Log Ziel nicht gestimmt hat und das alles relativ wenig mit auditd selbst zu tun hat. Die Meldungen wirft ja der Kernel selbst. Das sieht dann in dmesg so aus:

[Fr, 23. Dez 2022, 09:45:29] audit: type=1106 audit(1671785129.306:106): pid=3882 uid=1000 auid=1000 ses=4 msg='op=PAM:session_close grantors=pam_systemd_home,pam_limits,pam_unix,pam_permit acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success'
[Fr, 23. Dez 2022, 09:45:29] audit: type=1104 audit(1671785129.306:107): pid=3882 uid=1000 auid=1000 ses=4 msg='op=PAM:setcred grantors=pam_faillock,pam_permit,pam_faillock acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success'
[Fr, 23. Dez 2022, 09:45:56] audit: type=1101 audit(1671785156.477:108): pid=3889 uid=1000 auid=1000 ses=4 msg='op=PAM:accounting grantors=pam_unix,pam_permit,pam_time acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success'
[Fr, 23. Dez 2022, 09:45:56] audit: type=1110 audit(1671785156.477:109): pid=3889 uid=1000 auid=1000 ses=4 msg='op=PAM:setcred grantors=pam_faillock,pam_permit,pam_env,pam_faillock acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success'
[Fr, 23. Dez 2022, 09:45:56] audit: type=1105 audit(1671785156.477:110): pid=3889 uid=1000 auid=1000 ses=4 msg='op=PAM:session_open grantors=pam_systemd_home,pam_limits,pam_unix,pam_permit acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success'
[Fr, 23. Dez 2022, 09:45:56] audit: type=1106 audit(1671785156.507:111): pid=3889 uid=1000 auid=1000 ses=4 msg='op=PAM:session_close grantors=pam_systemd_home,pam_limits,pam_unix,pam_permit acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success'
[Fr, 23. Dez 2022, 09:45:56] audit: type=1104 audit(1671785156.507:112): pid=3889 uid=1000 auid=1000 ses=4 msg='op=PAM:setcred grantors=pam_faillock,pam_permit,pam_env,pam_faillock acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success'
[Fr, 23. Dez 2022, 09:49:35] audit: type=1100 audit(1671785375.296:113): pid=4035 uid=1000 auid=1000 ses=4 msg='op=PAM:authentication grantors=pam_faillock,pam_permit,pam_faillock acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success'
[Fr, 23. Dez 2022, 09:49:35] audit: type=1101 audit(1671785375.296:114): pid=4035 uid=1000 auid=1000 ses=4 msg='op=PAM:accounting grantors=pam_unix,pam_permit,pam_time acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success'
[Fr, 23. Dez 2022, 09:49:35] audit: type=1110 audit(1671785375.300:115): pid=4035 uid=1000 auid=1000 ses=4 msg='op=PAM:setcred grantors=pam_faillock,pam_permit,pam_faillock acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success'
[Fr, 23. Dez 2022, 09:49:35] audit: type=1105 audit(1671785375.300:116): pid=4035 uid=1000 auid=1000 ses=4 msg='op=PAM:session_open grantors=pam_systemd_home,pam_limits,pam_unix,pam_permit acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success'

Hier sieht man einfach, dass ich als user mit der id 1000 mehrfach eine root session mittels sudo eröffnet und wieder geschlossen habe.

 

[berni51]

Die Meldungen laufen auf dem Bildschirm auf, und das auf allen VTs. Sie beginnen alle mit "auditd: einer Nummer aus dem Bereich 110x und Text. Beunruhigend ist das nicht, nur nervig. Taucht beim Anmelden auf, aber auch irgendwann mitten in der Arbeit und müllt alles zu, z.B. auch den Editor oder die email.
Klar habe ich den Service nicht nur gestoppt, sondern auch dauerhaft deaktiviert, dazu in der auditd.conf noch alles mögliche abgegeschaltet. Kommt trotzdem noch, und wie die systemd socket Aktivierung abgestellt wird, weiss ich noch nicht. Einen auditd.socket oder ähnliches hab ich auch unter /run nicht gefunden. Auch ein "audit=0" in der boot.ini hat nichts geändert.
Zu dem Problem findet sich ja recht viel im Netz, und es werden etliche mögliche Ursachen benannt. Die meisten davon hab ich abgearbeitet, leider ohne Erfolg. Vielleicht hätte ich das ganze audit-Framework deinstallieren sollen, aber den grundsätzlichen Sinn des Systems bezweifel ich ja nicht. Wenn die Meldungen schön ins Log geschrieben würden oder zumindest nur auf vt0 aufliefen, wär's ja OK. Aber einfach alles zuzumüllen deutet doch auf einen Bug hin. Die Installation von Arch ist ja hinlänglich bekannt, und da hab ich garantiert nix mit audit angestellt.

Und OK, systemd mag nicht direkt daran schuld sein, aber es hängt sich einfach in zu vieles rein. Das ist nicht mehr unixoid, das ist MSoid. Ausserdem ist es mir einfach unsympathisch.

Mein Fazit: Wenn ich einen Service daektiviere, hat der einfach die Klappe zu halten. Ein schönes init oder openrc ist eindeutig durchsichtiger und verständlicher.

@-Nuke- : Danke für die gute Erläuterung, aber aber (s.o.) auch der Versuch in der boot.ini war erfolglos.

 

[-Nuke-]

Da das Problem jetzt eh durch ein Distributionswechsel "gelöst" ist, ist es jetzt sowieso schwer das zu debuggen. Man lernt halt nur schlicht nichts, wenn man dem Problem aus dem Weg geht und einfach nur eine Hexenjagd à la "systemd hat zwar nichts damit zu tun, ist aber trotzdem schuld und böse" veranstaltet.

Da es nun leider doch wieder in allgemeines systemd bashing abgedriftet ist, hab ich eigentlich keine Lust da noch großartig weiter zu helfen, aber an sich nur allgemeine Hinweise für alle:

• wäre interessant gewesen, ob dein Eintrag in der boot.ini (kA wie man das beim BananaPi konfiguriert) überhaupt angekommen ist. dmesg listet die Kernel Commandline mit. Es war ja auch nicht mal so ganz klar woher dein Kernel genau kam. Vllt. war dort auch einfach nur intensives Debugging eingeschaltet.
• Wohin der Kernel loggt und was er loggt lässt sich einstellen. "console" Kernel Parameter und "sysctl kernel.printk"
• Ich will nur noch einmal erwähnen, dass auditing ein Kernel-Feature ist und entsprechende Meldungen vom Kernel veranlasst werden und nichts mit auditd oder systemd zu tun haben. Auditd verarbeitet diese Meldungen ggf. einfach nur weiter und das Einzige wo hier systemd zum Einsatz kommt ist der Start von auditd und das Logging durch journald allgemein. Selbst wenn du auditd hart von deinem system gelöscht hättest, hättest du entsprechende Meldungen gesehen.

 

[medV2]

Davon ist auditd aber nicht "abhaengig"..

Hab ich ja auch nicht behauptet, ich wollte nur die Funktionsweise der Socketactivation erklären.

Die Meldungen laufen auf dem Bildschirm auf, und das auf allen VTs. Sie beginnen alle mit "auditd: einer Nummer aus dem Bereich 110x und Text. Beunruhigend ist das nicht, nur nervig. Taucht beim Anmelden auf, aber auch irgendwann mitten in der Arbeit und müllt alles zu, z.B. auch den Editor oder die email.
Klar habe ich den Service nicht nur gestoppt, sondern auch dauerhaft deaktiviert, dazu in der auditd.conf noch alles mögliche abgegeschaltet. Kommt trotzdem noch, und wie die systemd socket Aktivierung abgestellt wird, weiss ich noch nicht. Einen auditd.socket oder ähnliches hab ich auch unter /run nicht gefunden. Auch ein "audit=0" in der boot.ini hat nichts geändert.
Zu dem Problem findet sich ja recht viel im Netz, und es werden etliche mögliche Ursachen benannt. Die meisten davon hab ich abgearbeitet, leider ohne Erfolg. Vielleicht hätte ich das ganze audit-Framework deinstallieren sollen, aber den grundsätzlichen Sinn des Systems bezweifel ich ja nicht. Wenn die Meldungen schön ins Log geschrieben würden oder zumindest nur auf vt0 aufliefen, wär's ja OK. Aber einfach alles zuzumüllen deutet doch auf einen Bug hin. Die Installation von Arch ist ja hinlänglich bekannt, und da hab ich garantiert nix mit audit angestellt.

Tippe da auch eher auf einen Bug oder ein ernstes Problem.

Für die Zukunft: Einen Socket deaktiverst du wie einen Service, also in dem Fall wäre das wohl systemctl disable --now systemd-journald-audit.socket

Und OK, systemd mag nicht direkt daran schuld sein, aber es hängt sich einfach in zu vieles rein. Das ist nicht mehr unixoid, das ist MSoid. Ausserdem ist es mir einfach unsympathisch.

Mein Fazit: Wenn ich einen Service daektiviere, hat der einfach die Klappe zu halten. Ein schönes init oder openrc ist eindeutig durchsichtiger und verständlicher.

Da bin ich anderer Meinung, es hilft einem dabei das System aufgeräumt zu halten, weil eben nicht jeder Daemon dauernd laufen muss. Auf Unixsystemen gab es sowas für Networkservices schon immer, inetd und xinetd die einen Dienst erst dann gestartet haben, wenn etwas auf dem entsprechenden Port kam.

Für die Zukunft: Systemd kennt auch Abhängigkeiten, es wird dir also auch einen deaktivierten Dienst starten, wenn er von einem anderen als Abhängigkeit gelistet wird.
Systemd informiert dich aber darüber, also einfach mit offenen Augen die Tools benutzen.

Ich hab hier zwar auf meinen Systemen wo ich grad testen kann keinen auditd der über Socket aktiviert wird (ist überall nur der Service), aber Beispielhaft am docker-service der automatisch gestartet wird, aber sich auch per socketactivation startet:

[root@FH-001-demo ~]# systemctl disable --now docker.service
Warning: Stopping docker.service, but it can still be activated by:
  docker.socket
[root@FH-001-demo ~]#