a2enconf munin, soweit ich das richtig im Kopf habe, hast Du ausgeführt?
Danach den Indianer reloaden oder neustarten…
Server administrieren - wo fange ich an?
- Bud
- Erledigt
-
-
a2enconf munin, soweit ich das richtig im Kopf habe, hast Du ausgeführt?
Danach den Indianer reloaden oder neustarten…
Daran hat es gelegen. Vielen Dank dir!
Angezeigt wird mir leider nur der master. Hab nochmal meine munin.conf und munin-node.conf überprüft, und weiß nicht, warum mein node nicht mit aufgelistet wird.Code: munin.conf auf meinem master# a simple host tree [Master] address 127.0.0.1 use_node_name yes [Node] address 123.123.123.123 use_node_name yesCode: munin-node.conf auf meinem node# A list of addresses that are allowed to connect. This must be a # regular expression, since Net::Server does not understand CIDR-style # network notation unless the perl module Net::CIDR is installed. You # may repeat the allow line as many times as you'd like allow ^123\.123\.123\.123$ allow ^127\.0\.0\.1$ allow ^::1$ -
Stimmt die ip-Adresse des Masters in der Konfig auf der node?
Auf der node mal service munin-node restart ausgeführt?
Ist Port 4949 offen, auf der node?
Mal im Master [Node] ersetzen durch [Node;FQDN]
wobei FQDN das ist was auf der node bei hostname -f ausgegeben wird.
Jede Änderung wird immer erst zu den nächsten vollen 5 min auf dem Master wirksam.
-
Was sagen die Logs? (/var/log/munin/munin-update.log am Master und /var/log/munin/munin-node.log am Node.)
Kannst Du Dich vom Master aus händisch mit dem Node verbinden?
telnet ip-des-nodes 4949
Falls es klappt: Mit "quit" kommst Du raus, ist ein sehr einfaches Textprotokoll bei Munin.
-
Tip: Das "Rauskommen" ist bei manch( ander)en telnet-Tests ein Problem; hier nutze ich allgemein immer gerne timeout 10 telnet ip-des-nodes 4949 o. ä.
-
Stimmt die ip-Adresse des Masters in der Konfig auf der node?
Yes, das hatte ich schon ungefähr 10 Mal kontrolliert
Auf der node mal service munin-node restart ausgeführt?
Mal gemacht, hat leider keine Änderung bewirkt.
Mal im Master [Node] ersetzen durch [Node;FQDN]
wobei FQDN das ist was auf der node bei hostname -f ausgegeben wird.
Das habe ich mal nicht gemacht, weil ich ja die IP verwende, und mir FQDN dann ja nichts bringt, oder?
Jede Änderung wird immer erst zu den nächsten vollen 5 min auf dem Master wirksam.
Die Zeit hab ich abgewartet.
Code: node log
Alles anzeigen2023/07/07-15:53:17 Munin::Node::Server (type Net::Server::Fork) starting! pid(136504) Resolved [*]:4949 to [::]:4949, IPv6 Not including resolved host [0.0.0.0] IPv4 because it will be handled by [::] IPv6 Binding to TCP port 4949 on host :: with IPv6 Setting gid to "0 0" 2023/07/07-18:30:01 CONNECT TCP Peer: "[::ffff:MASTER-IP]:60408" Local: "[::ffff:NODE-IP]:4949" 2023/07/07-18:30:01 [137625] Denying connection from: ::ffff:MASTER-IP 2023/07/07-18:30:56 Server closing! 2023/07/07-18:30:56 Munin::Node::Server (type Net::Server::Fork) starting! pid(137633) Resolved [*]:4949 to [::]:4949, IPv6 Not including resolved host [0.0.0.0] IPv4 because it will be handled by [::] IPv6 Binding to TCP port 4949 on host :: with IPv6 Setting gid to "0 0" 2023/07/07-18:33:24 CONNECT TCP Peer: "[::ffff:MASTER-IP]:59772" Local: "[::ffff:NODE-IP]:4949" 2023/07/07-18:35:02 CONNECT TCP Peer: "[::ffff:MASTER-IP]:56014" Local: "[::ffff:NODE-IP]:4949" 2023/07/07-18:40:02 CONNECT TCP Peer: "[::ffff:MASTER-IP]:53774" Local: "[::ffff:NODE-IP]:4949"Der "Mittlere"-Teil wird alle 5 Minuten je 3x ausgegeben. Bin mir nicht sicher, aber liegt es daran das ich IPv6 in ufw nicht geöffnet habe?
telnet hat einwandfrei funktioniert:
Code: telnettelnet NODE-IP 4949 Trying NODE-IP... Connected to NODE-IP. Escape character is '^]'. # munin node at v12345678901234567890.megasrv.de quit Connection closed by foreign host. -
Das habe ich mal nicht gemacht, weil ich ja die IP verwende, und mir FQDN dann ja nichts bringt, oder?
Ich würde das trotzdem mal testen. Normalerweise überprüft munin, ob der Name zum fqdn passt.
-
Zitat
[137625] Denying connection from: ::ffff:MASTER-IP
Wenn das noch immer alle fünf Minuten auftaucht, stimmt Deine IP-Freigabe in der munin-node.conf nicht.
Also bitte genau die angezeigte Adresse eintragen (inkl. Maskierung von Punkten mit \ da es ein regulärer Ausdruck ist) und danach munin-node neustarten.
-
Und was steht währenddessen im Log des Masters? (munin-update.log)
Plugins hast Du am Node aber schon aktiv? (ls -l /etc/munin/plugins)
-
Vielen Dinge stehen (nach der jeweiligen Paketinstallation) z.B. in /usr/share/doc/..., ist immer eine gute Quelle bei Problemen.
-
Also hab ich das Verzeichnis schnell über die Konsole erstellt. Dann habe ich versucht in den Ordner "netcup" mehrere Dateien mit FileZilla hochzuladen, was aufgrund von fehlenden Berechtigungen nicht funktioniert hat. Wie kann ich das Problem lösen?
Wenn du das Verzeichnis mit "sudo" erstellt hast, dann hat es ja den Besitzer "root"
Ändere den auf den Nutzer. mit dem du immer was hochladen willst.
-
Ändere den auf den Nutzer. mit dem du immer was hochladen willst.
Nach chown user netcup/ hat der SFTP-Upload funktioniert, danke dir
-
Das Problem hatte ich beim Upgrade von Debian 11 auf 12 ebenfalls. Hier drehen sich wohl leider die Abhängigkeiten des JRE und der Java Cert Library im Kreis.
Das heißt beide sind von einem vollständig installierten/konfigurierten Version des anderen abhängig. Was nicht funktionieren kann, wenn der Konfigurationsprozess von ca-certificates-java bereits java-code ausführt.
Meine Lösung war:
Codedpkg-reconfigure openjdk-17-jre openjdk-17-jre-headless --force dpkg-reconfigure ca-certificates-javaAlso die Konfiguration der JRE erzwingen und danach die Cert Library (normal) konfigurieren.
-
Meine Lösung war: die Konfiguration der JRE erzwingen und danach die Cert Library (normal) konfigurieren.
Vielen Dank dir schon mal, werde ich ausprobieren! Frage hierzu:
Wie kann ich mir den Fehler davor anzeigen lassen, und wie danach überprüfen, ob das funktioniert hat? -
Beim rekonstruieren des Fehlers in einer VM, um dir sagen zu können, wie du erkennst ob er weg ist, ist mir noch eine Kleinigkeit aufgefallen.
Nach
Codedpkg-reconfigure openjdk-17-jre openjdk-17-jre-headless --forceMuss stattdessen ein
Codeapt install ca-certificates-javafolgen. Das Paket ist nämlich nicht nur in einem unkonfiguriertem Zustand sondern die Installation vollständig gescheitert/abgebrochen.
Wie kann ich mir den Fehler davor anzeigen lassen, und wie danach überprüfen, ob das funktioniert hat?
Um das nun aber zu beantworten.
Erstens wird dich jede Datenbank veränderte apt Aktion (apt install/autoremove/remove/purge usw.) an den inkonsistenten Zustand der drei Pakete erinnern, bis dieser Umstand behoben ist.
Zweitens zeigt dir dpkg --list ca-certificates-java openjdk* den Zustand der Pakete an.
Aus
Code+++-====================-============-============-===================================== iF ca-certificates-java 20230103 all Common CA certificates (JKS keystore) un openjdk-11-jdk-headless <keine> <keine> (keine Beschreibung vorhanden) iU openjdk-17-jre:amd64 17.0.7+7-1~deb12u1 amd64 OpenJDK Java runtime, using Hotspot JIT iU openjdk-17-jre-headless:amd64 17.0.7+7-1~deb12u1 amd64 OpenJDK Java runtime, using Hotspot JIT (headless)sollte also
Code+++-====================-============-============-===================================== ii ca-certificates-java 20230103 all Common CA certificates (JKS keystore) un openjdk-11-jdk-headless <keine> <keine> (keine Beschreibung vorhanden) ii openjdk-17-jre:amd64 17.0.7+7-1~deb12u1 amd64 OpenJDK Java runtime, using Hotspot JIT ii openjdk-17-jre-headless:amd64 17.0.7+7-1~deb12u1 amd64 OpenJDK Java runtime, using Hotspot JIT (headless)werden.
-
-
