OT: Munin Plugins können Daten nicht außerhalb von /var/lib/munin lesen
Hallo zusammen, ich denke ich habe das hier schon mal gefragt, kann den Thread aber nicht mehr finden. Ich meine die Antwort war AppAmor. Da ich nun schon einige Plugins für Munin erstellt habe, wird es langsam aufwendig die jeweiligen Datenfiles doppelt zu halten. Die Scripte, die die Datenfiles erstellen, laufen alle auf dem Host, auf dem auch Munin läuft. Ich kann sie natürlich nur nach /var/lib/munin schreiben, aber das widerstrebt mir. Da die Datenfiles ein User (nicht munin) auf dem Munin-Server erstellt, habe ich die Daten auch unter der User-Directory abgelegt. Und von dort muss ich sie auch nach /var/lib/munin kopieren. Was spricht dagegen, es so zu ändern, dass die Plugins von munin überall ihre Daten lesen können. Er würde ja reichen, wenn das nur für munin gilt (Falls es sonst zu unsicher sein würde). Was müsste ich wo ändern ? In /etc/apparmor.d/ habe ich sehr viele Dateien gefunden und darin nichts, was mir in dem Fall weiterhelfen würde. Was habe ich übersehen ? Danke für Tipps. Werner Franke
Am Mi., 7. Feb. 2024 um 15:52 Uhr schrieb Werner Franke <werner_franke@arcor.de>:
ich denke ich habe das hier schon mal gefragt, kann den Thread aber nicht mehr finden.
Ich meine die Antwort war AppAmor.
Ich vermute systemd. Zumindest hier (15.5) läuft munin-node mit ProtectHome=true man systemd.exec "If true, the directories /home/, /root, and /run/user are made inaccessible and empty for processes invoked by this unit."
Was spricht dagegen, es so zu ändern, dass die Plugins von munin überall ihre Daten lesen können. Er würde ja reichen, wenn das nur für munin gilt (Falls es sonst zu unsicher sein würde).
Security. Gruß Martin
Am Mi., 7. Feb. 2024 um 16:02 Uhr schrieb Martin Schröder <martin@oneiros.de>:
Security.
Siehe auch https://bugzilla.suse.com/show_bug.cgi?id=1212676 für einen Workaround. Gruß Martin
Am 07.02.24 um 15:51 schrieb Werner Franke:
Hallo zusammen,
ich denke ich habe das hier schon mal gefragt, kann den Thread aber nicht mehr finden.
Das war im August gewesen mit dem Betreff "15.5: Perl Code funktioniert nicht mehr". Wir sind damals zum gleichen Resultat gekommen, welches Martin eben gepostet hat. Viele Grüße Ulf
Am 07.02.24 um 18:12 schrieb Ulf Volmer:
Am 07.02.24 um 15:51 schrieb Werner Franke:
Hallo zusammen,
ich denke ich habe das hier schon mal gefragt, kann den Thread aber nicht mehr finden.
Das war im August gewesen mit dem Betreff "15.5: Perl Code funktioniert nicht mehr". Wir sind damals zum gleichen Resultat gekommen, welches Martin eben gepostet hat.
Viele Grüße Ulf
Hallo Martin, Ulf, Danke. ich habe nach ProtectHome=read-only geändert. Das funktioniert jetzt. Vorher habe ich es mit ProtectHome=true BindReadOnlyPaths=/home/admin/Data /home/admin/Buderus ausprobiert, das hat nicht funktioniert. Warum, habe ich nicht herausgefunden und zusätzliche print Ausgaben in dem Perl-Plugin haben auch nicht funktioniert. Irgendwie habe ich noch nicht herausgefunden, wie man das richtig testen kann. Gruss Werner
Am 07.02.24 um 18:31 schrieb Martin Schröder:
Am Mi., 7. Feb. 2024 um 18:29 Uhr schrieb Werner Franke <werner_franke@arcor.de>:
ich habe nach
ProtectHome=read-only
geändert. Das funktioniert jetzt.
Ich hoffe doch mit systemctl edit.
Gruß Martin
Ähhmm, nein. Mit einem Texteditor und dann systemctl daemon-reload systemctl restart munin-node Aber ich hab's mir für's nächste Mal notiert. Gruss Werne
Am 07.02.24 um 18:49 schrieb Werner Franke:
Am 07.02.24 um 18:31 schrieb Martin Schröder:
Am Mi., 7. Feb. 2024 um 18:29 Uhr schrieb Werner Franke <werner_franke@arcor.de>:
ich habe nach
ProtectHome=read-only
geändert. Das funktioniert jetzt.
Ich hoffe doch mit systemctl edit.
Gruß Martin
Ähhmm,
nein. Mit einem Texteditor und dann
systemctl daemon-reload systemctl restart munin-node
Aber ich hab's mir für's nächste Mal notiert.
Das Verfahren hat halt den Nachteil, dass ein 'zypper up' Dir die Änderung ggf. wieder überschreibt. Ein 'systemctl edit' hingegen erzeugt per Default eine Overlay Datei, die dem Paketmanagment egal ist. Viele Grüße Ulf
Am 07.02.24 um 19:26 schrieb Ulf Volmer:
Am 07.02.24 um 18:49 schrieb Werner Franke:
Am 07.02.24 um 18:31 schrieb Martin Schröder:
Am Mi., 7. Feb. 2024 um 18:29 Uhr schrieb Werner Franke <werner_franke@arcor.de>:
ich habe nach
ProtectHome=read-only
geändert. Das funktioniert jetzt.
Ich hoffe doch mit systemctl edit.
Gruß Martin
Ähhmm,
nein. Mit einem Texteditor und dann
systemctl daemon-reload systemctl restart munin-node
Aber ich hab's mir für's nächste Mal notiert.
Das Verfahren hat halt den Nachteil, dass ein 'zypper up' Dir die Änderung ggf. wieder überschreibt. Ein 'systemctl edit' hingegen erzeugt per Default eine Overlay Datei, die dem Paketmanagment egal ist.
OK, DAS ist ein Argument es gleich richtig zu machen. Habe also das /usr/lib/systemd/system/munin-node.service wieder in den Orginalzustand versetzt und systemctl daemon-reload gemacht. Dann in /usr/lib/systemd/system "systemctl edit munin-node.service". Jetzt meckert er herum: Editing "/etc/systemd/system/munin-node.service.d/override.conf" canceled: temporary file is empty. Muss ich "/etc/systemd/system/munin-node.service.d" händisch anlegen ? Und wird dann "override.conf" von dem systemctl Kommando angelegt ? Danke und Gruss Werner
Am 08.02.24 um 13:00 schrieb Werner Franke:
Am 07.02.24 um 19:26 schrieb Ulf Volmer:
Am 07.02.24 um 18:49 schrieb Werner Franke:
Am 07.02.24 um 18:31 schrieb Martin Schröder:
Am Mi., 7. Feb. 2024 um 18:29 Uhr schrieb Werner Franke <werner_franke@arcor.de>:
ich habe nach
ProtectHome=read-only
geändert. Das funktioniert jetzt.
Ich hoffe doch mit systemctl edit.
Gruß Martin
Ähhmm,
nein. Mit einem Texteditor und dann
systemctl daemon-reload systemctl restart munin-node
Aber ich hab's mir für's nächste Mal notiert.
Das Verfahren hat halt den Nachteil, dass ein 'zypper up' Dir die Änderung ggf. wieder überschreibt. Ein 'systemctl edit' hingegen erzeugt per Default eine Overlay Datei, die dem Paketmanagment egal ist.
OK, DAS ist ein Argument es gleich richtig zu machen.
Habe also das /usr/lib/systemd/system/munin-node.service wieder in den Orginalzustand versetzt und systemctl daemon-reload gemacht.
Dann in /usr/lib/systemd/system "systemctl edit munin-node.service".
Jetzt meckert er herum:
Editing "/etc/systemd/system/munin-node.service.d/override.conf" canceled: temporary file is empty.
Muss ich "/etc/systemd/system/munin-node.service.d" händisch anlegen ? Und wird dann "override.conf" von dem systemctl Kommando angelegt ?
Danke und Gruss Werner
ich habe die Dir /etc/systemd/system/munin-node.service.d händisch angelegt und die erzeugte Datei ".#override.confe2a2ba25a20fe14e" nach override.conf umbenannt. Danach "systemctl restart munin-node" Er wollte jedoch vorher ein "systemctl daemon-reload" haben. Also systemctl daemon-reload systemctl restart munin-node Irgendwie ist das seltsam. Im Internet ist das anders beschrieben. https://askubuntu.com/questions/659267/how-do-i-override-or-configure-system... Und es wird noch seltsamer. Das Munin Plugin hat nämlich wieder nicht funktioniert. Die Datei /home/admin/Data/bkw-2024-02.csv wurde wieder nicht mehr gefunden. Ich habe dann festgestellt, dass die orginale Datei /etc/systemd/system/munin-node.service verschwunden war und eine fast leere /etc/systemd/system/munin-node.service.d/override.conf bringt nicht so viel. Zum Glück war der orginale Inhalt von "munin-node.service" auch in der "override.conf" enthalten, nur mit # am Zeilenbeginn. So konnte ich die "munin-node.service" wieder herstellen. Danach wieder die beiden "systemctl" Befehle oben und jetzt tut das Plugin. Eine Idee was da falsch gelaufen sein könnte ? Laut Doku hätte das alles ohne händisches Eingreifen funktionieren sollen. Ein "systemctl cat munin-node.service" liefert jetzt: # /etc/systemd/system/munin-node.service ## Editing /etc/systemd/system/munin-node.service.d/override.conf ## Anything between here and the comment below will become the new contents of the file ## Lines below this comment will be discarded ## /usr/lib/systemd/system/munin-node.service [Unit] Description=Munin Node Requires=network.target [Service] # added automatically, for details please see # https://en.opensuse.org/openSUSE:Security_Features#Systemd_hardening_effort # ProtectSystem=full ProtectHome=true ProtectHostname=true ProtectKernelTunables=true ProtectKernelModules=true ProtectKernelLogs=true ProtectControlGroups=true # end of automatic additions Type=forking ExecStart=/usr/sbin/munin-node ExecStartPre=/usr/bin/mkdir -p /var/run/munin/ PIDFile=/var/run/munin/munin-node.pid [Install] WantedBy=multi-user.target # /etc/systemd/system/munin-node.service.d/override.conf ### Editing /etc/systemd/system/munin-node.service.d/override.conf ### Anything between here and the comment below will become the new contents of the file ### Lines below this comment will be discarded ### /usr/lib/systemd/system/munin-node.service # [Unit] # Description=Munin Node # Requires=network.target # [Service] # # added automatically, for details please see # # https://en.opensuse.org/openSUSE:Security_Features#Systemd_hardening_effort # # Ge344ndert: 08. Feb 2024 # # # ProtectSystem=full ProtectHome= ProtectHome=read-only # ProtectHostname=true # ProtectKernelTunables=true # ProtectKernelModules=true # ProtectKernelLogs=true # ProtectControlGroups=true # # end of automatic additions # Type=forking # ExecStart=/usr/sbin/munin-node # ExecStartPre=/usr/bin/mkdir -p /var/run/munin/ # PIDFile=/var/run/munin/munin-node.pid # # [Install] # WantedBy=multi-user.target Die # Zeilen wurden beim start von "systemctl edit" in override.conf erzeugt. root@hpserver (-bash) which systemctl /usr/bin/systemctl Danke und Gruss Werner
Am 08.02.24 um 16:36 schrieb Werner Franke:
Ich habe dann festgestellt, dass die orginale Datei /etc/systemd/system/munin-node.service verschwunden war und eine fast leere /etc/systemd/system/munin-node.service.d/override.conf bringt nicht so viel.
Es gibt **keine** originale /etc/systemd/system/munin-node.service. Das Original ist unter /usr/lib/systemd/system/munin-node.service zu finden. Grüße Ulf
Am 08.02.24 um 16:46 schrieb Ulf Volmer:
Am 08.02.24 um 16:36 schrieb Werner Franke:
Ich habe dann festgestellt, dass die orginale Datei /etc/systemd/system/munin-node.service verschwunden war und eine fast leere /etc/systemd/system/munin-node.service.d/override.conf bringt nicht so viel.
Es gibt **keine** originale /etc/systemd/system/munin-node.service.
Das Original ist unter /usr/lib/systemd/system/munin-node.service zu finden.
Nach Ulf's bedenkenswerten Tipp ist das orginale munin-node.service wieder auf wundersame Weise aufgetaucht :-) Manchmal ist das mit dem Lesen halt so eine Sache... Habe also aufgeräumt und es funktioniert immer noch. Gruss erner
Am 08.02.24 um 13:00 schrieb Werner Franke:
Dann in /usr/lib/systemd/system "systemctl edit munin-node.service".
Jetzt meckert er herum:
Editing "/etc/systemd/system/munin-node.service.d/override.conf" canceled: temporary file is empty.
Wenn Du 'systemctl edit munin-node.service' aufrufst, startet ein Editor mit einer Template Datei. Die enthält Kommentare. Dein Problem dürft sich erledigen, wenn Du diese Kommentare liest und beherzigst. Viele Grüße Ulf
Am Do., 8. Feb. 2024 um 16:43 Uhr schrieb Ulf Volmer <u.volmer@u-v.de>:
Wenn Du 'systemctl edit munin-node.service' aufrufst, startet ein Editor mit einer Template Datei. Die enthält Kommentare. Dein Problem dürft sich erledigen, wenn Du diese Kommentare liest und beherzigst.
Und nochmal meinen Bugreport liest. Gruß Martin
Am 08.02.24 um 17:24 schrieb Martin Schröder:
Am Do., 8. Feb. 2024 um 16:43 Uhr schrieb Ulf Volmer <u.volmer@u-v.de>:
Wenn Du 'systemctl edit munin-node.service' aufrufst, startet ein Editor mit einer Template Datei. Die enthält Kommentare. Dein Problem dürft sich erledigen, wenn Du diese Kommentare liest und beherzigst.
Und nochmal meinen Bugreport liest.
Hi Martin, gelesen und doch selbst drauf gekommen. Aber danke für den Bugreport. Ist dann hoffentlich irgendwann drin und muss nicht von jedem User neu bemerkt und implementiert werden. Gruss Werner
participants (3)
-
Martin Schröder -
Ulf Volmer -
Werner Franke