Debian12 & upcoming releases - bleibt rsyslog verfügbar? [GELÖST]

[Ralph]

@Alexander
Bei Debian12 etc. wird ja nuh per default (warum auch immer) komplett alles ins journal logged ...
Bleibt bei den kommenden Releases weiterhin rsyslog im Einsatz bzw. sind die /var/log/* (auth.log, syslog usw.) dann noch verfügbar?

[Alexander]

Zunächst einmal, KeyHelp hat rsyslog nie explizit installiert.
Ich habe lediglich darauf zurückgegriffen, da es Teil des Standard-Umfangs einer Betriebssysteminstallation war.
Mit Debian 12 ist rsyslog nicht mehr by default Teil des Systems, kann vom Admin aber gern noch nachinstalliert werden.

Ab KeyHelp 23.2 verwendet KeyHelp bei allen unterstützen Betriebssystemversionen intern nur noch journalctl.
Auch die fail2ban Grundkonfiguration ist auf journalctl umgestellt.

---

Damit ergibt sich also Folgendes:

• Ab Debian 12 müssen Admins, die auf auth.log, syslog, etc. in Dateiform nicht verzichten wollen rsyslog nach-installieren

• Bestehende Systeme (Debian 10/11, Ubuntu 20/22) behalten weiterhin rsyslog, für den Betrieb von KeyHelp ist es aber nicht mehr notwendig und kann prinzipiell deinstalliert werden

[Ralph]

Zunächst einmal, KeyHelp hat rsyslog nie explizit installiert.
Ich habe lediglich darauf zurückgegriffen, da es Teil des Standard-Umfangs einer Betriebssysteminstallation war.
Mit Debian 12 ist rsyslog nicht mehr by default Teil des Systems, kann vom Admin aber gern noch nachinstalliert werden.

Ab KeyHelp 23.2 verwendet KeyHelp bei allen unterstützen Betriebssystemversionen intern nur noch journalctl.
Auch die fail2ban Grundkonfiguration ist auf journalctl umgestellt.

---

Damit ergibt sich also Folgendes:

• Ab Debian 12 müssen Admins, die auf auth.log, syslog, etc. in Dateiform nicht verzichten wollen rsyslog nach-installieren

• Bestehende Systeme (Debian 10/11, Ubuntu 20/22) behalten weiterhin rsyslog, für den Betrieb von KeyHelp ist es aber nicht mehr notwendig und kann prinzipiell deinstalliert werden

Danke, gut zu wissen ... genau ich meinte damit vor allem die Auswirkung auf fail2ban ...
rsyslog habe ich vorhin mal mit bookworm getestet F2B blockt damit weiterhin auch bei eigenen Filtern, frage mich ob das über Journal weiterhin so stabil bleibt ... auch für die Fehlersuche usw. kann das schon etwas nervig und gewöhnungsbedürftig werden.
D.h. wenn rsyslog nachinstalliert wird muß dann ggf. auch die von KH installierten Log Paths angepasst werden um doppeltes logging zu vermeiden.
Schon strange das ganze und ob es nun wirklich etwas bringt bezweifele ich momentan noch, unnötiges Gefummel

[tab-kh]

Also ich erhoffe mir z.B. davon, dass das ganze Gefummel beim logrotate damit etwas problemloser funktioniert. Das ist aber nur meine Hoffnung und muss nicht zwingend so sein .

[Ralph]

Also ich erhoffe mir z.B. davon, dass das ganze Gefummel beim logrotate damit etwas problemloser funktioniert. Das ist aber nur meine Hoffnung und muss nicht zwingend so sein .

Hm, also für eine Workstation ist es ausreichend alles ins Journal zu loggen, bin ich seit Jahren so gewohnt (Arch Linux KDE) ...
Aber ob es für Server Systeme ausreichend und eine gute Idee ist bezweifele ich noch, bei Systemen mit vielen Zugriffen wird dies zu einer Endlos Rotation des journals führen (ungeeignet für Fehlersuche und die Log Auswertung für spezielle Schutzfilter).

[Alexander]

Also ich erhoffe mir z.B. davon, dass das ganze Gefummel beim logrotate damit etwas problemloser funktioniert. Das ist aber nur meine Hoffnung und muss nicht zwingend so sein .

In jedem Fall hören damit so Sachen auf wie, Fail2Ban kann eine Log-Datei nicht finden und verweigert anschließend komplett den Dienst.
Es loggt zwar noch nicht jeder Dienst ins journal, aber es geht vorwärts.

D.h. wenn rsyslog nachinstalliert wird muß dann ggf. auch die von KH installierten Log Paths angepasst werden um doppeltes logging zu vermeiden.

Welche Log Paths meinst du?

[Ralph]

Also ich erhoffe mir z.B. davon, dass das ganze Gefummel beim logrotate damit etwas problemloser funktioniert. Das ist aber nur meine Hoffnung und muss nicht zwingend so sein .

In jedem Fall hören damit so Sachen auf wie, Fail2Ban kann eine Log-Datei nicht finden und verweigert anschließend komplett den Dienst.
Es loggt zwar noch nicht jeder Dienst ins journal, aber es geht vorwärts.

D.h. wenn rsyslog nachinstalliert wird muß dann ggf. auch die von KH installierten Log Paths angepasst werden um doppeltes logging zu vermeiden.

Welche Log Paths meinst du?

das machst mir Mut
OK, werde ich heute nochmal testen ohne rsyslog, in dem Fall müßte ja dann das Backend auf > "backend = systemd" richtiig?
Na ja, auth.log fände ich schon besser als eigenständiges Log file z.b. bei dictionary attacks kommt man mit dem Jounal dann nicht mehr so gut und übersichtlich vorran wenn alles was vorher ins syslog ging im Journal ständig eingefügt wird.

Mit den Log Paths wenn rsyslog verwendet wird, meinte ich Journal zu konfigurieren damit nicht alles doppelt geloggt wird, also so wie vorher.
Aber wenn KH jetzt auf Journal umgestellt wird/ist dann sollte alles ins Journal rein und die rsyslog Umstellung ist dann nicht die Lösung.

### edit ###
backend = systemd kann das überhaupt global dann gesetzt werden oder muß es per jeweiligem Jail gesetzt werden?

[Alexander]

OK, werde ich heute nochmal testen ohne rsyslog, in dem Fall müßte ja dann das Backend auf > "backend = systemd" richtiig?

Prinzipiell schon, manchmal reicht das aber nicht aus. Beispiel phpmyadmin. Der loggte vorher auch ins auth.log.
Hier muss z.B. noch ein Zusatz stehen, damit der Filter greift.

Code: Select all

backend = systemd[journalflags=1]

backend = systemd kann das überhaupt global dann gesetzt werden oder muß es per jeweiligem Jail gesetzt werden?

Ich würde es per Jail setzen, denn wie gesagt manche Dinge werden nach wie vor in regulären Dateien geloggt - z.B. für Fail2Ban recidive (/var/log/fail2ban.log) oder die Apache Webserver Logs (/home/users/*/logs/*/error.log)

[Ralph]

OK, werde ich heute nochmal testen ohne rsyslog, in dem Fall müßte ja dann das Backend auf > "backend = systemd" richtiig?

Prinzipiell schon, manchmal reicht das aber nicht aus. Beispiel phpmyadmin. Der loggte vorher auch ins auth.log.
Hier muss z.B. noch ein Zusatz stehen, damit der Filter greift.

Code: Select all

backend = systemd[journalflags=1]

backend = systemd kann das überhaupt global dann gesetzt werden oder muß es per jeweiligem Jail gesetzt werden?

Ich würde es per Jail setzen, denn wie gesagt manche Dinge werden nach wie vor in regulären Dateien geloggt - z.B. für Fail2Ban recidive (/var/log/fail2ban.log) oder die Apache Webserver Logs (/home/users/*/logs/*/error.log)

Danke Alex, das hilft auf jeden Fall weiter!
Ich teste aus alter Prepper Gewohnheit notwendige Vorbereitungen für Keyhelp auf Debian12

Kann aber nicht schaden vor einem Update oder ener kommenden Installation das ganze mal zu checken mit systemd journal ...

[Ralph]

nur zur Info!
Mir ist hier bei Bookworm aufgefallen das ionice Aneisungen ziemlich durchgehend und hart greifen (wohl der neue Kernel) und somit z.b. rsync oder clamav scans (mit ionice) sehr viel mehr Zeit in Anspruch nehmen wie z.b. bei Buster oder Bullseye ...
Ich bin noch nicht so glücklich mit dem Verhalten und Änderungen bei den neuen Releases

Also mit durchgehend meine ich das NI Level belibt Stundenlang 8-10 Stunden auf dem exakt gleichen (übergebenen ionice) Wert, bei den vorigen Releases war dies dynamischer und mehr nach Priorität, die CPU Grafik im Zabbix zeigt einen stundenlang durchgehenden Balken für ni bei Verwendung von ionice.

[Tobi]

Aktuell gibt es im Serverbetrieb keine unmittelbare Notwendigkeit auf Debian 12 zu wechseln.

Möge es auf anderen Servern reifen. Ich überlege mir das frühestens in einem Jahr. Frühestens!

[Ralph]

Aktuell gibt es im Serverbetrieb keine unmittelbare Notwendigkeit auf Debian 12 zu wechseln.

Möge es auf anderen Servern reifen. Ich überlege mir das frühestens in einem Jahr. Frühestens!

Wohl wahr
Mein Gedanke war eigentlich etwas verlorene Zeit aufzuholen durch aufsetzen von neuen Systemen, aber momentan sehe ich noch zu viele Dinge die gewonnene Zeit durch sehr viel Mehraufwand wieder zunichte machen.
Das geht alles viel zu schnell mit neuen Releases, 1 Jahr zusätzlich verlängern wäre gut ... hat sich alles zu einem Wettrennen entwickelt mit halbfertigen Releases die dann unbedingt pünktlich rausgehauen werden müssen ... ahhrrg

[tab-kh]

Ja, da lehne ich mich erst mal entspannt zurück und lese, was es alles an guten oder schlechten Erfahrungen gibt. Das beziehe ich jetzt nicht nur auf Keyhelp. Bei solchen doch recht heftigen Veränderungen mag es dann ja auch noch Anpassungen und Korrekturen geben seitens der (OS-)Entwickler. Mache ich bei Nextcloud auch so. Warum soll ausgerechnet ich mir die Logfiles meiner produktiven Cloud vollmüllen lassen, wenn nach Release einer neuen Version x.y.0 mal wieder gröbere Klopper drin sind? Bestenfalls vielleicht als Unterstützung für die Entwickler, um Fehler zu finden, in einer kleinen Testcloud.

[Ralph]

So langsam klappt es jetzt mit dem anpassen meiner vielen extra Fail2ban Filter, da muß dann je nach service ein extra init hinzugefügt werden z.b. bei Postfix filter:

Code: Select all

journalmatch = _SYSTEMD_UNIT=postfix@-.service

Code: Select all

# Fail2Ban Postscreen PREGREET
#
#
[INCLUDES]
before = common.conf

[Definition]
_daemon = postfix/postscreen
failregex = ^%(__prefix_line)sPREGREET \d+ after \d+\.\d+ from \[<HOST>\]:\d+: EHLO .*\\r\\n

ignoreregex =

[Init]
journalmatch = _SYSTEMD_UNIT=postfix@-.service

und der regex check für die Filter sieht dann in etwas so aus:

Code: Select all

fail2ban-regex systemd-journal /etc/fail2ban/filter.d/postfix-pregreet.conf