a2enconf munin, soweit ich das richtig im Kopf habe, hast Du ausgeführt?
Danach den Indianer reloaden oder neustarten…
a2enconf munin, soweit ich das richtig im Kopf habe, hast Du ausgeführt?
Danach den Indianer reloaden oder neustarten…
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.
# a simple host tree
[Master]
address 127.0.0.1
use_node_name yes
[Node]
address 123.123.123.123
use_node_name yes
# 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.
2023/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"
Alles anzeigen
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:
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)
Also keine Ahnung warum, aber aktuell scheint es zu funktionieren...
Im Master gab es übrigens keine Fehlermeldung.
Wie kann ich selber auf die Einrichtung wie von aRaphael geschildert kommen? Rein durch die Doku? Ich meine dort nicht im Ansatz das gefunden zu haben, was aRaphael mir aufgelistet zu haben. Oder war ich so blind?
Mir geht es darum, dass ich euch ja nicht wegen jeder (für euch) Kleinigkeit schreiben möchte...
Vielen Dinge stehen (nach der jeweiligen Paketinstallation) z.B. in /usr/share/doc/..., ist immer eine gute Quelle bei Problemen.
Ich habe mich mit meinem sudo und dem entsprechenden private-key mittels FileZilla auf meinen Server eingeloggt. Dort wollte ich ein Verzeichnis erstellen, was nicht funktioniert hat:
Status: Anzeigen des Verzeichnisinhalts für "/etc/munin" abgeschlossen
Status: Erstelle Verzeichnis '/etc/munin/netcup'...
Befehl: mkdir "netcup"
Fehler: mkdir /etc/munin/netcup: permission denied
Befehl: mkdir "/etc/munin/netcup"
Fehler: mkdir /etc/munin/netcup: permission denied
Okay, relativ schnell ist mir aufgefallen das FileZilla kein sudo vor mkdir geschrieben hat. 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? Selbst als ich extra für diesen Zweck den Login via root wieder zugelassen habe, hat er mich nicht auf den Server gelassen, trotz sudo systemctl restart ssh.
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
Ich wollte gerade damit anfangen einen neuen (Minecraft-)Server aufzusetzen, und wurde direkt am Anfang ausgebremst
Leider hat mir die letzte Installation folgenden Fehler ausgespuckt:
Fehler traten auf beim Bearbeiten von:
ca-certificates-java
openjdk-17-jre-headless:amd64
openjdk-17-jre:amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)
Nach einiger Suche habe ich folgendes gefunden: https://debianforum.de/forum/viewtopic.php?t=187193
Leider macht das bei mir doch keinen Sinn mehr, oder? Heißt, ich müsste mein OS neu installieren (lassen), und dann wie folgt vorgehen:
Des Weiteren bin ich mir nicht sicher, wo genau der Fehler liegt. Zumindest lese ich das weder aus dpkg --list ca-certificates noch dpkg --list openjdk*
root@ThomasChr:~# dpkg --list ca-certificates-java
Gewünscht=Unbekannt/Installieren/R=Entfernen/P=Vollständig Löschen/Halten
| Status=Nicht/Installiert/Config/U=Entpackt/halb konFiguriert/
Halb installiert/Trigger erWartet/Trigger anhängig
|/ Fehler?=(kein)/R=Neuinstallation notwendig (Status, Fehler: GROSS=schlecht)
||/ Name Version Architektur Beschreibung
+++-====================-============-============-=====================================
iF ca-certificates-java 20230103 all Common CA certificates (JKS keystore)
root@ThomasChr:~# dpkg --list openjdk*
Gewünscht=Unbekannt/Installieren/R=Entfernen/P=Vollständig Löschen/Halten
| Status=Nicht/Installiert/Config/U=Entpackt/halb konFiguriert/
Halb installiert/Trigger erWartet/Trigger anhängig
|/ Fehler?=(kein)/R=Neuinstallation notwendig (Status, Fehler: GROSS=schlecht)
||/ Name Version Architektur Beschreibung
+++-=============================-==================-============-==================================================
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)
Alles anzeigen
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:
dpkg-reconfigure openjdk-17-jre openjdk-17-jre-headless --force
dpkg-reconfigure ca-certificates-java
Also 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
Muss stattdessen ein
folgen. 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
+++-====================-============-============-=====================================
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
+++-====================-============-============-=====================================
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.
Vielen lieben Dank dir, scheint funktioniert zu haben!
Dann mach ich mal weiter
root@ThomasChr:~# dpkg-reconfigure openjdk-17-jre openjdk-17-jre-headless --force
dpkg: Zyklus bei der Triggerverarbeitung gefunden:
Kette der Pakete, deren Trigger verantwortlich sind oder sein könnten:
ca-certificates-java -> ca-certificates-java
anhängige Trigger von Paketen, die nicht auflösbar sind oder sein könnten:
ca-certificates-java: update-ca-certificates-java
dpkg: Fehler beim Bearbeiten des Paketes ca-certificates-java (--configure):
Trigger bilden eine Schleife, aufgegeben
Fehler traten auf beim Bearbeiten von:
ca-certificates-java
root@ThomasChr:~# apt install ca-certificates-java
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
ca-certificates-java ist schon die neueste Version (20230103).
ca-certificates-java wurde als manuell installiert festgelegt.
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
1 nicht vollständig installiert oder entfernt.
Nach dieser Operation werden 0 B Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren? [J/n] J
ca-certificates-java (20230103) wird eingerichtet ...
done.
root@ThomasChr:~# dpkg-reconfigure ca-certificates-java
done.
root@ThomasChr:~# dpkg --list ca-certificates-java openjdk*
Gewünscht=Unbekannt/Installieren/R=Entfernen/P=Vollständig Löschen/Halten
| Status=Nicht/Installiert/Config/U=Entpackt/halb konFiguriert/
Halb installiert/Trigger erWartet/Trigger anhängig
|/ Fehler?=(kein)/R=Neuinstallation notwendig (Status, Fehler: GROSS=schlecht)
||/ Name Version Architektur Beschreibung
+++-=============================-==================-============-==================================================
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)
root@ThomasChr:~#
Alles anzeigen