Debian12 & upcoming releases - bleibt rsyslog verfügbar? [GELÖST]
Debian12 & upcoming releases - bleibt rsyslog verfügbar?
@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?
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?
Re: Debian12 & upcoming releases - bleibt rsyslog verfügbar? [GELÖST]
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:
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
Mit freundlichen Grüßen / Best regards
Alexander Mahr
**************************************************************
Keyweb AG - Die Hosting Marke
Neuwerkstr. 45/46, 99084 Erfurt / Germany
http://www.keyweb.de - http://www.keyhelp.de
**************************************************************
Alexander Mahr
**************************************************************
Keyweb AG - Die Hosting Marke
Neuwerkstr. 45/46, 99084 Erfurt / Germany
http://www.keyweb.de - http://www.keyhelp.de
**************************************************************
Re: Debian12 & upcoming releases - bleibt rsyslog verfügbar?
Danke, gut zu wissen ... genau ich meinte damit vor allem die Auswirkung auf fail2ban ...Alexander wrote: ↑Mon 11. Sep 2023, 17:07 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
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
Re: Debian12 & upcoming releases - bleibt rsyslog verfügbar?
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 .
Re: Debian12 & upcoming releases - bleibt rsyslog verfügbar?
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).
Re: Debian12 & upcoming releases - bleibt rsyslog verfügbar?
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.
Welche Log Paths meinst du?
Mit freundlichen Grüßen / Best regards
Alexander Mahr
**************************************************************
Keyweb AG - Die Hosting Marke
Neuwerkstr. 45/46, 99084 Erfurt / Germany
http://www.keyweb.de - http://www.keyhelp.de
**************************************************************
Alexander Mahr
**************************************************************
Keyweb AG - Die Hosting Marke
Neuwerkstr. 45/46, 99084 Erfurt / Germany
http://www.keyweb.de - http://www.keyhelp.de
**************************************************************
Re: Debian12 & upcoming releases - bleibt rsyslog verfügbar?
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?
Re: Debian12 & upcoming releases - bleibt rsyslog verfügbar?
Prinzipiell schon, manchmal reicht das aber nicht aus. Beispiel phpmyadmin. Der loggte vorher auch ins auth.log.Ralph wrote:OK, werde ich heute nochmal testen ohne rsyslog, in dem Fall müßte ja dann das Backend auf > "backend = systemd" richtiig?
Hier muss z.B. noch ein Zusatz stehen, damit der Filter greift.
Code: Select all
backend = systemd[journalflags=1]
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 wrote:backend = systemd kann das überhaupt global dann gesetzt werden oder muß es per jeweiligem Jail gesetzt werden?
Mit freundlichen Grüßen / Best regards
Alexander Mahr
**************************************************************
Keyweb AG - Die Hosting Marke
Neuwerkstr. 45/46, 99084 Erfurt / Germany
http://www.keyweb.de - http://www.keyhelp.de
**************************************************************
Alexander Mahr
**************************************************************
Keyweb AG - Die Hosting Marke
Neuwerkstr. 45/46, 99084 Erfurt / Germany
http://www.keyweb.de - http://www.keyhelp.de
**************************************************************
Re: Debian12 & upcoming releases - bleibt rsyslog verfügbar?
Alexander wrote: ↑Tue 12. Sep 2023, 11:20Prinzipiell schon, manchmal reicht das aber nicht aus. Beispiel phpmyadmin. Der loggte vorher auch ins auth.log.Ralph wrote:OK, werde ich heute nochmal testen ohne rsyslog, in dem Fall müßte ja dann das Backend auf > "backend = systemd" richtiig?
Hier muss z.B. noch ein Zusatz stehen, damit der Filter greift.
Code: Select all
backend = systemd[journalflags=1]
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 wrote:backend = systemd kann das überhaupt global dann gesetzt werden oder muß es per jeweiligem Jail gesetzt werden?
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 ...
Re: Debian12 & upcoming releases - bleibt rsyslog verfügbar?
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.
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.
Last edited by Ralph on Thu 21. Sep 2023, 16:29, edited 6 times in total.
Re: Debian12 & upcoming releases - bleibt rsyslog verfügbar?
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!
Möge es auf anderen Servern reifen. Ich überlege mir das frühestens in einem Jahr. Frühestens!
Gruß,
Tobi
-----------------------------
wewoco.de
Das Forum für Reseller, Digital-Agenturen, Bildschirmarbeiter und Mäuseschubser
Tobi
-----------------------------
wewoco.de
Das Forum für Reseller, Digital-Agenturen, Bildschirmarbeiter und Mäuseschubser
Re: Debian12 & upcoming releases - bleibt rsyslog verfügbar?
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
Re: Debian12 & upcoming releases - bleibt rsyslog verfügbar?
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.
Re: Debian12 & upcoming releases - bleibt rsyslog verfügbar?
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:
und der regex check für die Filter sieht dann in etwas so aus:
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
Code: Select all
fail2ban-regex systemd-journal /etc/fail2ban/filter.d/postfix-pregreet.conf