Archlinux & Co auf einem Banana Pi

Also wir sollten versuchen den Thread bei "Linux on Arm" zu lassen und nicht zu einem Systemd Thread ausufern zu lassen - sollte jemand das konstruktiv besprechen wollen könnte er ja einen eigenen Thread aufmachen

(Ich sehe hier speziell das aber auch eher wie Nuke - da scheint systemd nur als starter eines von der distri im default gestarteten Dienst zu fungieren)

Ich hab ja das Berry-Image für arm64 genommen (Es gibt auch noch eins mit armv7 mit propitären berry-treibern wenn man möchte) - danach hab ich nen paar pakete installiert und nen bisschen was am apache2 gedoktort und ich bekomme im dmesg keine auffälligen audit meldungen.

Der meldet sich lediglich jeweils wenn ich micht anmelde
zb
[20089.852600] audit: type=1334 audit(1671580832.996:42): prog-id=27 op=LOAD
[20089.859638] audit: type=1334 audit(1671580833.003:43): prog-id=28 op=LOAD
[20089.866578] audit: type=1334 audit(1671580833.010:44): prog-id=29 op=LOAD
[20089.873507] audit: type=1130 audit(1671580833.014:45): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=shadow comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[20089.988343] audit: type=1131 audit(1671580833.131:46): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=shadow comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Zum Vergrößern anklicken....

Ich vermute systemd taucht da auf weil das irgendetwas beim login macht, ist ja nachvollziehbar.

Insgesamt bei ner laufzeit von ein paar Tagen villeicht 2,3 dutzend Meldungen. Das kommt mir nicht so speziell vor und ich denke mir "Da werden sich die arch-entwickler schon was bei gedacht haben".

Hattest du evtl. irgendwas am System noch geändert?

Ich neige ja dazu, wie es ja auch das OpenBSD Team immer wieder empfiehlt, an einen System gegenüber dem auslieferungszustand nur etwas zu ändern wenn es dafür gute gründe gibt und ich weiß was ich da änder - die entwickler zb der distri werden sich da ja vermutlich etwas bei gedacht haben.

(Ich betreibe das ganze headless, ohne X und nur mit den Basis-Paketen des images + nen lamp stack sowie wireguard)
 
Das Archlinux-Image hab ich über einen Link auf banana-pi.org, wo es als Third-Party-Image aufgeführt ist.
Die Boot-SD und die SSD mit dem System sind auch noch vorhanden, wenn mir langweilig ist, kann ich mich nochmal damit beschäftigen.
Der Versuch, das audit-Framework komplett zu deinstallieren ist übrigens daran gescheitert, dass eine Abhängigkeit mit systemd besteht. Damit hätte ich mir also das System komplett zerschossen.
 
Die Geschichte hat mir einfach keine Ruhe mehr gelassen, und so hab ich um17:00 die SD mit dem ArchLinuxARM u-boot und die SSD mit dem System angeschlossen. Dann rekapituliert, was ich bisher getan hab, um die audit-Meldungen zu stoppen:

root@banana2 ~ # pacman -R audit
Abhängigkeiten werden geprüft …
:: Entfernen von audit verletzt Abhängigkeit »audit«, benötigt von dbus
:: Entfernen von audit verletzt Abhängigkeit »libaudit.so=1-64«, benötigt von dbus
:: Entfernen von audit verletzt Abhängigkeit »audit«, benötigt von pam
:: Entfernen von audit verletzt Abhängigkeit »libaudit.so=1-64«, benötigt von pam
:: Entfernen von audit verletzt Abhängigkeit »audit«, benötigt von shadow
:: Entfernen von audit verletzt Abhängigkeit »libaudit.so=1-64«, benötigt von shadow
:: Entfernen von audit verletzt Abhängigkeit »audit«, benötigt von systemd
:: Entfernen von audit verletzt Abhängigkeit »libaudit.so=1-64«, benötigt von systemd

So gehts also nicht.

Weitere Aktionen:
  • systemctl auditd disable
  • boot.ini: audit=0
  • auditd.conf: local_events=no, write_logs=no
  • journald.conf: audit=yes auskommentiert

Nach jeder Aktion wurde das System rebootet. Zwar wurden es dann immer weniger audit-Meldungen, aber ganz verschwunden waren sie nie. Meist kamen sie im Schwung von 5-10 Zeilen.

Dann im heutigen dmesg nachgeschaut, und da gab es nur zwei audit-Meldungen:
[ 0.000000] audit: disabled (until reboots)
[ 8.389060] systemd [1]: Journal Audit Socket was skipped because of an unmet condition check (Condition Security=audit)

Die zweite dmesg-Meldung hatte ich vorher noch nicht. Dann habe ich bis jetzt (22:15) mit der Maschine gearbeitet - und was soll ich sagen: Es gab keine, nicht eine einzige audit-Meldung. Dabei ist der BananaPi in exakt dem gleichen Zustand wie vorher, ich habe nichts geändert, nichts installiert, nichts deinstalliert.
Diese systemd-Meldung in dmesg deute ich allerdings so, dass jetzt an der Socket-Aktivierung etwas nicht stimmt, und deshalb keine Meldungen mehr erscheinen. Irgend etwas scheint also immer noch das audit aktivieren zu wollen, was (zum Glück) nicht klappt.

Jedenfalls ist das Arch für mich jetzt in Ordnung, es bleibt jedoch das ungute Gefühl, dass nur ein Fehler durch einen weiteren behoben wurde. Werde jetzt in kleinen Trippelschritten versuchen, das audit wieder zu aktivieren, und zwar so, dass es nur noch ins Log schreibt.
Wollte ich euch nur kurz mitteilen.
 
berni51 schrieb:
  • systemctl auditd disable
  • boot.ini: audit=0
  • auditd.conf: local_events=no, write_logs=no
  • journald.conf: audit=yes auskommentiert
Zum Vergrößern anklicken....

Das erste dürfte garnicht funktionieren, aber vermutlich nur falsch aus der Erinnerung hier ins Forum getipped ;) Korrekt ist es systemctl disable auditd.

Ich denke der letzte Eintrag verhindert die Socketactivation. Du kannst diese aber auch "richtig" deaktivieren wie ich in einem vorhergehenden Post beschrieben habe.
 
Uebrigens "formal" - wenn man so einen Dienst wirklich abstellen will, dann bitte: systemctl mask auditd.
Ein disable verhindert nicht, dass ein Dienst als Abhaengigkeit gestartet wird - mask tut das.
 
Ihr habt Recht! Ich hab mich wohl doch zu wenig mit dem systemd Framework beschäftigt und damit fast zwei Forumsseiten gefüllt. :mad:
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben