[gelöst] Was macht die /etc/rsyslog.d/49-haproxy.conf

[Spindoctor]

Hallo!

Im Paket haproxy gibt es eine Datei /etc/rsyslog.d/49-haproxy.conf mit dem folgenden Inhalt:

Code: Alles auswählen

# Create an additional socket in haproxy's chroot in order to allow logging via
# /dev/log to chroot'ed HAProxy processes
$AddUnixListenSocket /var/lib/haproxy/dev/log

# Send HAProxy messages to a dedicated logfile
if $programname startswith 'haproxy' then /var/log/haproxy.log
&~

Das weicht z.B. von der HAProxy-Doku ab (siehe hier) wo folgender Inhalt vorgeschlagen wird:

Code: Alles auswählen

# Collect log with UDP
$ModLoad imudp
$UDPServerAddress 127.0.0.1
$UDPServerRun 514

# Creating separate log files based on the severity
local0.* /var/log/haproxy-traffic.log
local0.notice /var/log/haproxy-admin.log

Außerdem ist die Konfiguration im Debian-Paket nach meinem Verständnis auch etwas invasiv, weil es einfach alles schnappt und in die haproxy.log speichert, wenn das Programm haproxy* heißt. Das hat zur Folge, dass man nichtmal in einem anderen File ein anderes Log definieren kann, so wie das in der HAProxy-Doku vorgeschlagen wird (zumindest mir ist das nicht gelungen).

Daher meine Frage: warum gibt es die /etc/rsyslog.d/49-haproxy.conf überhaupt und warum hat sie ausgerechnet den Inhalt?

Ich hoffe, das ist keine dumme Frage, ich kenn mich nicht sehr gut aus mit Webservern...

[wanne]

Du hast die Doku falsch verstanden. haproxy ist nicht in der Lage in Dateien zu loggen.
Schmeist du die Datei weg, hast du gar keine Logs mehr.
Du brauchst irgend einen Dienst, der dir die Log Messages in irgend welche Dateien umleitest. Deswegen ist irgend eine Defaultconfig sinnvoll. Red Hat macht das nicht und das ist dann nervig, wenn das erste mal was schief geht.

Alternativ kannst du natürlich alternative (zusätzliche) logschemen und Bedingungen überlegen und dann anpassen.

[Spindoctor]

Danke für die Antwort!

Du hast natürlich recht: irgendeine Default-Konfiguration soll es natürlich geben, sonst gibt es gar kein Log. Insofern war meine Frage unglücklich formuliert.

Aber warum sieht die Default-Config so aus und nicht beispielsweise wie in der Doku vorgeschlagen? Und warum ist die Default-Config so invasiv (zumindest, wenn ich sie richtig verstehe)?

Meine Probleme sind:

1. Die Default-Config logt lediglich, wenn HAProxy eingeschaltet ist.
2. Wenn man eine zweite Config-Datei z.b. /etc/rsyslog.d/50-haproxy.conf erstellt mit dem Inhalt so wie in der Doku (und wenn HAProxy auch richtig konfiguriert ist), dann ist das HAProxy-Log zwar etwas brauchbarer, allerdings wird trotzdem ausschließlich in die /var/log/haproxy.log geschrieben, weil die 49-haproxy.conf "sich alles schnappt".
3. Man kann die 49-haproxy.conf auskommentieren, löschen oder mit einem anderren Inhalt überschreiben. Dann läuft man aber Gefahr, dass durch ein Update oder durch Neu-Installieren die eigene Konfiguration wieder weg ist oder von der Default-Version der 49-haproxy.conf überladen wird.

Wenn man damit rechnet, ist das ja eh alles halb so schlimm, aber die Chance auf sowas zu vergessen ist schon groß

Ich möchte eine Anleitung für Fail2Ban auf OctoPi schreiben und bin nun unentschlossen, was ich den Usern raten soll: die datei 49-haproxy.conf zu ändern, sie zu löschen und mit einer eigenen zu ersetzen oder sie in einer anderen Datei zu "ergänzen" und damit leben, dass alle logs nach /var/log/haproxy.log wandern und man kein anderes Log erstellen kann...

[Tintom]

• Man kann die 49-haproxy.conf auskommentieren, löschen oder mit einem anderren Inhalt überschreiben. Dann läuft man aber Gefahr, dass durch ein Update oder durch Neu-Installieren die eigene Konfiguration wieder weg ist oder von der Default-Version der 49-haproxy.conf überladen wird.

Bei einem Update passiert dein Szenario nicht. Es wird nachgefragt, bevor die Config überschrieben wird.
Bei einer Neuinstallation hast du natürlich Recht. Deswegen sichert man auch die Konfigurationsdateien bei einem Backup

[wanne]

[*] Wenn man eine zweite Config-Datei z.b. /etc/rsyslog.d/50-haproxy.conf erstellt mit dem Inhalt so wie in der Doku (und wenn HAProxy auch richtig konfiguriert ist), dann ist das HAProxy-Log zwar etwas brauchbarer, allerdings wird trotzdem ausschließlich in die /var/log/haproxy.log geschrieben, weil die 49-haproxy.conf "sich alles schnappt".

Ich habe rsyslog schon immer gehasst. Aber du wirst es doch wohl schaffen eine Zahl die kleiner als 49 ist zu finden. Die 49 ist absichtlich ausreichend hoch gewählt, dass da kaum jemand auf die Idee kommt was höheres anzulegen.
Oder halt die ~ auszukommentieren. Apt fragt dann im Fall eines Updates halt ob die Datei überschrieben werden soll. (Default ist nein.)

Anders gehts halt nicht mit rsyslog. Du willst halt sicher auch nicht, dass dir der Access Log o.ä. per default den Syslog vollspamt.

[Spindoctor]

Danke für den Hinweis!

War nicht ganz sicher, ob die Zahlen höher oder niedriger sein müssen. Dachte, ich hätte beides probiert und nie hat rsyslog ein eigenes log angelegt. Hab es jetzt nochmal probiert - hat mit der niedrigeren Zahl funktioniert. Da hab ich wohl letztens was übersehen...

Nochmals vielen Dank!