Hi, my long lasting project ... Ein Host möchte/soll sein Journal-Einträge an einen existierenden journal-Server übergeben: Die Konfiguration: # o /etc/systemd/journal-upload.conf [Upload] URL=https://192.168.2.13:19532 ServerKeyFile=/etc/ssl/private/host13-journal-upload.key.pem ServerCertificateFile=/etc/ssl/private/host13-journal-upload.cer.pem TrustedCertificateFile=/etc/ssl/private/CA.crt # NetworkTimeoutSec=10 Die Zertifikate: /etc/ssl/private # l insgesamt 20 drwx------ 2 root root 4096 19. Jul 11:02 ./ drwxr-xr-x 3 root root 4096 8. Jul 09:25 ../ -r-------- 1 systemd-journal-upload root 1944 19. Jul 11:40 host13-journal-upload.cer.pem -r-------- 1 systemd-journal-upload root 3243 19. Jul 11:02 host13-journal-upload.key.pem -r-------- 1 systemd-journal-upload root 1814 19. Jul 11:02 CA.crt Die Antwort: Jul 20 09:11:27 host13 systemd-journal-upload[21589]: Upload to https://192.168.2.13:19532/upload failed: could not load PEM client certificate, OpenSSL error error:0200100D:system library:fopen:Permission denied, (no key found, wrong pass phrase, or wrong file format?) Das gleiche Ergebnis erscheint wenn die Rechte für Zertifikate und Key 777 lauten. Das Zertifikat ist ein Client-Zertifikat, was von der gleichen CA ausgestellt wurde wie das Server-Zertifikat des journal-remote Servers (192.168.2.13). Wenn ich das ganze ohne Zertifikate versuche (also URL=http://... und mit auskommentierten Zertifikatszeilen in der journal-upload.conf) lautet die Antwort: Jul 20 09:13:39 host13 systemd-journal-upload[21837]: Upload to http://192.168.2.13:19532/upload failed: Empty reply from server Wo suche ich denn nun weiter? Bernd -- Die normative Kraft des Faktischen behindert die Entwicklung zum Besseren.
On 20.07.22 09:39, Bernd Nachtigall wrote:
/etc/ssl/private # l insgesamt 20 drwx------ 2 root root 4096 19. Jul 11:02 ./ drwxr-xr-x 3 root root 4096 8. Jul 09:25 ../ -r-------- 1 systemd-journal-upload root 1944 19. Jul 11:40 host13-journal-upload.cer.pem -r-------- 1 systemd-journal-upload root 3243 19. Jul 11:02 host13-journal-upload.key.pem -r-------- 1 systemd-journal-upload root 1814 19. Jul 11:02 CA.crt
Das Verzeichnis /etc/ssl/private ist für den User systemd-journal-upload nicht lesbar. HTH und viele Grüße Ulf
Am 20.07.22 um 10:03 schrieb Ulf Volmer:
On 20.07.22 09:39, Bernd Nachtigall wrote:
/etc/ssl/private # l insgesamt 20 drwx------ 2 root root 4096 19. Jul 11:02 ./ drwxr-xr-x 3 root root 4096 8. Jul 09:25 ../ -r-------- 1 systemd-journal-upload root 1944 19. Jul 11:40 host13-journal-upload.cer.pem -r-------- 1 systemd-journal-upload root 3243 19. Jul 11:02 host13-journal-upload.key.pem -r-------- 1 systemd-journal-upload root 1814 19. Jul 11:02 CA.crt
Das Verzeichnis /etc/ssl/private ist für den User systemd-journal-upload nicht lesbar. ja, ok ... das war einfach ... ;-)
Habe nun /etc/ssl/journal angelegt und systemd-journal-upload:root zum Eigentümer gemacht. Nun ist die Meldung: Jul 20 09:45:11 host13 systemd-journal-upload[22657] [69B blob data] Sieht besser aus aber sagt mir nichts. (Ich weiß natürlich was "blob data" umschreibt, aber ...) Gibt es da irgendwo eine Erläuterung für? Der Service steht auch immer noch auf 'failed' ... Bernd
Ich lese das als "69 Bytes binary large object data" was ein bisschen paradox klingt :o) Aber vielleicht hat es ja grad nix zu melden. Am 20.07.22 um 11:58 schrieb Bernd Nachtigall:
...[69B blob data]...
-- Viele Grüße Michael ____________________________________________________________ PROSTEP AG, Dolivostraße 11, D-64293 Darmstadt HR: Amtsgericht Darmstadt, HRB 8383 Vorstand: Dr. Bernd Pätzold (Vorsitz), Dr. Karsten Theis Aufsichtsrat: Dr. Heinz-Gerd Lehnhoff (Vorsitz) ____________________________________________________________
Am 20.07.22 um 13:02 schrieb Michael Behrens:
Ich lese das als
"69 Bytes binary large object data"
was ein bisschen paradox klingt :o) Aber vielleicht hat es ja grad nix zu melden.
Am 20.07.22 um 11:58 schrieb Bernd Nachtigall:
...[69B blob data]... Ja, dafür ist jedes Bit soooo lang ;-) Aber es kommt halt auch nix am Journald des Ziels an.
Daher dachte ich das es evtl. eine spezifische Übersetzung dieser Meldung im Kontext des journald gibt. Bernd -- Die normative Kraft des Faktischen behindert die Entwicklung zum Besseren.
Am 20.07.22 um 09:39 schrieb Bernd Nachtigall: (...)
Ein Host möchte/soll sein Journal-Einträge an einen existierenden journal-Server übergeben:
OK, nach ein wenig suchen war ein Fehler, das das Zertifikat für systemd-journal-upload einen Eintrag im Feld Common Name benötigt. (Ich hatte irgendwo gelesen das darf/soll nicht mehr ... egal, ist evtl. hier noch nicht eingeflossen.) Nun ist die Meldung: "Client is not authorized" ... wo (Ich nehme mal an beim systemd-journal-remote) muss sich der Client denn bitte wie autorisieren? Bernd -- Die normative Kraft des Faktischen behindert die Entwicklung zum Besseren.
participants (3)
-
Bernd Nachtigall -
Michael Behrens -
Ulf Volmer