Dirk Sohler schriebAber was anderes: Warum nicht journald? Es ist besser is systemd integriert, und bietet vor allem signierte Logs an.
Weil, wie ich festgestellt habe, journald die logs in so ein pseudoproprietäres Binaryformat oder was das auch immer sein soll schreibt. Heißt, ich komme mit einem normalen Texteditor nicht an die logs ran, sondern nur über journalctl. Um mit einem beliebigen Werkzeug rangehen zu können, müsste ich also das Log mit journald in ein Textfile leiten, was insbesondere nicht mehr geht, wenn mir das System abraucht und ich die Platte an ein anderes System anschließe, das kein systemd-System ist. Dabei hat journalctl zum Auswerten der Logs meinem Eindruck nach keine Funktionalität, die ich nicht auch mittels eines grep-Kommandos in einer Zeile nachbilden könnte.
Und keiner kann mir erzählen, dass dieses krude Logformat für das Versiegeln von Logs relevant ist, signieren kann ich ein Log auch, wenn's ein Plaintextfile ist. Da ist es mir wichtiger, dass ich die Logs im Zweifel überall auswerten kann, im Notfall auch auf einem Nicht-Linux (was mit journalctl aus offensichtlichen Gründen eher schwierig ist).
Auch sonst kann ich keinen Vorteil des Formates erkennen, außer man sagt, ein Angreifer kann nicht in's Log schreiben wegen diesem kruden Format, was allerdings für mich in die Kategorie Snake Oil fällt.
Wenn mir jemand den Sinn dieses Logformates klarmachen kann, gerne, ich bin für Erklärungen offen!
Auch, wenn dieses Format wenigstens Vorteile hat, selbst wenn sie nicht überwiegen! Es ist einfach eine Designentscheidung, die ich überhaupt nicht nachvollziehen kann.
In meiner syslog-ng.conf findet sich ein, ich nehme an, Array:
source src {
unix-dgram("/run/systemd/journal/syslog");
internal();
file("/proc/kmsg");
};
Ist das der "Eingangskanal"? Da wäre systemd auf jeden Fall eingetragen, die Frage ist, ob /.../syslog auch das Richtige ist?