Liegen denn in /var/cache/munin/www/ die von munin generierten html-Dateien, inkl. index.html?
Nein, das Verzeichnis ist leer
OK. Das sollte nicht sein. Dann liegt da der Fehler.
Munin schreibt die Graphen (warum auch immer) nicht in dieses Verzeichnis und auch keine index.html und deshalb gibt Apache ein "Forbidden" aus, eben weil da keine Index-Datei zu finden ist.
Liesse sich ja recht einfach testen, indem man eine index.html da reinlegt mit den passenden Rechten. Eine andere Möglichkeit wäre natürlich, dass Munin die Dateien wohl schreiben will, aber wegen fehlenden Rechten nicht kann. Das sollte sich dann aber auch in einer Logdatei finden lassen. Seh schon, die (funktionierende!) Keyhelp-Installation wird den heutigen Tag vermutlich nicht überleben. Wollte eigentlich auch Plesk noch ausprobieren, wenn man schon eine Lizenz dazubekommt. Die hat wohl mehr Beschränkungen als Keyhelp, aber auch Vorteile.
Das sollte sich dann aber auch in einer Logdatei finden lassen
Ja, über die logs in /var/log/munin sollte man das Problem eingrenzen können
Alles anzeigenHast du alles, was ich weiter oben geschrieben habe mal überprüft?
Ist auf dem neuen node Port 4949 offen?
Hast du auf dem neuen node auch den Master erlaubt? (Wie sieht der Eintrag in munin-node.conf genau aus? Regular Expression bei allow verwendet?)
Danach "service munin-node restart" durchgeführt?
Hast du auf dem Master entweder "use_node_name yes" verwendet oder wirklich den korrekten FQDN (hostname -f) des nodeservers angegeben?
Wie sieht der Eintrag in munin.conf auf dem Master genau aus? Keine Leerzeichen im Servernamen? address mit 2 d geschrieben? (Nicht lachen, ist kein seltener Fehler
)
(Und immer bis zu den nächsten vollen fünf Minuten warten
/var/log/munin/munin-update.log)
Hier von vor wenigen Minuten des Master
/var/log/munin/munin-update.log
2023/08/16 11:40:05 [INFO] Reaping Munin::Master::UpdateWorker<foo.foobar.de;localhost.foo.foobar.de>. Exit value/signal: 18/0
2023/08/16 11:40:15 [INFO] Remaining workers: foo.foobar.de;localhost.foo.foobar.de
2023/08/16 11:40:15 [INFO] Reaping Munin::Master::UpdateWorker<cube-2375;localhost.master>. Exit value/signal: 0/0
2023/08/16 11:40:15 [INFO] No old data available for failed worker foo.foobar.de;localhost.foo.foobar.1blu.de. This node will disappear from the html web page hierarchy
2023/08/16 11:40:15 [INFO]: Munin-update finished (14.43 sec)irgendetwas mache ich wohl total falsch
Die zwei unteren logs haben ja nur was mit dem Node zu tun, sind also irrleveant?
Auf dem Master läuft ja auch munin-node (Damit er sich selbst überwachen kann)
Mach mal folgendes in der munin-node.conf (Auf dem Master!)
Das allow ^::1$ auskommentieren
Auch das host * auskommentieren und dafür das darunterstehende host 127.0.0.1 aktivieren.
Danach service munin-node restart und service munin restart (+5min )
Dann sollte nach einiger Zeit in der munin-node.log statt der obigen Meldung folgendes erscheinen:
Binding to TCP port 4949 on host 127.0.0.1 with IPv4
Jetzt zeigt es mir den node zweiten Server im Master von Munin an.
Auch ich musste von IPv4 auf IPv6 wechseln.
Hmm, das muss dann aber ein Munin-Ding sein und ist ggf bestimmt irgendwie konfigurierbar. Viele Server haben kein (öffentliches) IPv6, auch heute noch. Mein Mailserver ist ja auch vom gleichen Anbieter. Und da sieht Apache2 auch so aus:
root@mail:~# netstat -tulpen | grep apache2
tcp6 0 0 :::80 :::* LISTEN 0 17447 779/apache2
tcp6 0 0 :::443 :::* LISTEN 0 17451 779/apache2Und das, obwohl er keine öffentliche IPv6-Adresse hat und somit von aussen nur per IPv4 zugegriffen werden kann. Und er funktioniert trotzdem. Address mapping?
Edit: Scheint ja schon gelöst zu sein, wie vermutet durch Konfiguration von Munin.
Dann sollte nach einiger Zeit in der munin-node.log statt der obigen Meldung folgendes erscheinen:
Binding to TCP port 4949 on host 127.0.0.1 with IPv4
Was ist denn "einiger Zeit", mehr als die klassischen 5 Minuten?
Ich habe die Änderungen durchgeführt, aber in der log taucht nichts neues auf...
Mein Fehler, die Uhrzeiten haben mich verwirrt:
2023/08/15-13:15:10 Munin::Node::Server (type Net::Server::Fork) starting! pid(12384)
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/08/15-13:20:53 Server closing!
2023/08/15-13:20:53 Munin::Node::Server (type Net::Server::Fork) starting! pid(12986)
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/08/16-07:56:42 Server closing!
2023/08/16-07:56:42 Munin::Node::Server (type Net::Server::Fork) starting! pid(14470)
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/08/16-07:56:45 Server closing!
2023/08/16-07:56:45 Munin::Node::Server (type Net::Server::Fork) starting! pid(14680)
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/08/16-08:18:43 Server closing!
2023/08/16-08:18:43 Munin::Node::Server (type Net::Server::Fork) starting! pid(15176)
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/08/16-08:18:50 Server closing!
2023/08/16-08:18:50 Munin::Node::Server (type Net::Server::Fork) starting! pid(15385)
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/08/16-10:32:32 Server closing!
2023/08/16-10:32:33 Munin::Node::Server (type Net::Server::Fork) starting! pid(16025)
Binding to TCP port 4949 on host 127.0.0.1 with IPv4
Setting gid to "0 0"
2023/08/16-10:32:36 Server closing!
2023/08/16-10:32:36 Munin::Node::Server (type Net::Server::Fork) starting! pid(16221)
Binding to TCP port 4949 on host 127.0.0.1 with IPv4
Setting gid to "0 0"
2023/08/16-10:43:34 Server closing!
2023/08/16-10:43:34 Munin::Node::Server (type Net::Server::Fork) starting! pid(16518)
Binding to TCP port 4949 on host 127.0.0.1 with IPv4
Setting gid to "0 0"
2023/08/16-10:43:38 Server closing!
2023/08/16-10:43:38 Munin::Node::Server (type Net::Server::Fork) starting! pid(16728)
Binding to TCP port 4949 on host 127.0.0.1 with IPv4
Setting gid to "0 0"Aber das Ergebnis bleibt das gleiche.
ich habe nochmals eine Fragen zu Munin. An meinem Master-Munin verwende ich eine Sub-Domain (per DNS A-Record eingerichtet) welche https verwendet und hinter einer htaccess sich befindet.
Muss ich auf den node welche ich hinzufüge (jeweils an den node auch noch was explizit zwecks Web absichern wenn ich keine Sub-Domain jeweils eingerichtet habe?
ich habe nochmals eine Fragen zu Munin. An meinem Master-Munin verwende ich eine Sub-Domain (per DNS A-Record eingerichtet) welche https verwendet und hinter einer htaccess sich befindet.
Muss ich auf den node welche ich hinzufüge (jeweils an den node auch noch was explizit zwecks Web absichern wenn ich keine Sub-Domain jeweils eingerichtet habe?
Nein, du brauchst auf deinen Nodes weder Port 80 noch Port 443 öffnen. Diese haben ja nichts mit der Web-Oberfläche deines Masters zu tun. Diese kannst du, insofern auf deinen Nodes kein weiterer Web-Dienst läuft, durch die Firewall einfach schließen.
Nein, du brauchst auf deinen Nodes weder Port 80 noch Port 443 öffnen. Diese haben ja nichts mit der Web-Oberfläche deines Masters zu tun. Diese kannst du, insofern auf deinen Nodes kein weiterer Web-Dienst läuft, durch die Firewall einfach schließen.
Danke für die Info
Die Ports kann ich nicht sperren da sie für weitere Web-anwendungen benötigt werden.
Nur neine Mails lasse ich über mein Webhosting-Paket laufen.
Alle anderen Dienste selbst über die jeweiligen Server.
ich habe nochmals eine Fragen zu Munin. An meinem Master-Munin verwende ich eine Sub-Domain (per DNS A-Record eingerichtet) welche https verwendet und hinter einer htaccess sich befindet.
Muss ich auf den node welche ich hinzufüge (jeweils an den node auch noch was explizit zwecks Web absichern wenn ich keine Sub-Domain jeweils eingerichtet habe?
Ich kenne munin nicht, aber ich hab in den letzten Posts gesehen, dass die Nodes über Port 4949 angesprochen werden.
Keine Ahnung, wie munin das absichert, aber da jeder im Internet auf den Port zugreifen kann, könnte das ein potentielles Sicherheitsrisiko darstellen.
Da aber in dem Fall ganz genau bekannt ist, wer auf den Port zugreifen will, kann man das in der Firewall sehr gut absichern:
indem man per default deny hat, und dann
sudo ufw allow from 1.2.3.4 to any port 4949Wobei 1.2.3.4 die IP des masters sein sollte. dann kann nur der darauf zugreifen.
Für den master selbst, da er ja auch ein Node ist, wäre das dann
sudo ufw allow from 127.0.0.1 to any port 4949Gegebenenfalls noch IPv6, aber das scheint hier ja nicht zu gehen.
So würde ich das zumindest machen 
Das ist in der Konfigurationsdatei des Nodes schon so realisiert.
Dort muss man die ip des Masters freigeben, nur dorthin gibt munin dann über 4949 was raus.
Das ist in der Konfigurationsdatei des Nodes schon so realisiert.
Dort muss man die ip des Masters freigeben, nur dorthin gibt munin dann über 4949 was raus.
Das ist ja vorbildlich. Super!
Man sollte halt nichts zu Sachen schreiben die man nicht kennt 
Wegen dem Thema eigene Distro installieren:
Genau für solche Situationen wollte ich mal netboot.xyz ausprobieren. https://github.com/netbootxyz/netboot.xyz
Vielleicht hat ja jemand Lust das mal zu probieren, und dann zu berichten
Einfach im laufenden System, oder in der Rettungskonsole (/dev/sda evtl anpassen)
Code
wget https://boot.netboot.xyz/ipxe/netboot.xyz.img
dd if=netboot.xyz.img of=/dev/sda
sync
rebootUnd dann nach dem reboot das system auswählen dass man installieren möchte.
Sollte theoretisch funktionieren (Hoffe ich 
)
Jetzt bin ich neugierig geworden. Ich probiere das jetzt auch mal aus.
Ich wollte so einen Mini-vserver bei denen sowieso schon immer mal antesteten. Da ist das eine gute Gelegenheit.
Hab soeben munin auf einem VC1-1 installiert und es hat auf Anhieb geklappt. (ufw disabled)
Es liegt also nicht an der fehlenden ipv6.
Auch einen anderen Server (netcup) hinzufügen hat geklappt.
Allerdings habe ich Ubuntu 22.04 als Image genommen und nicht Debian. (Macht der Gewohnheit )
Ich habe meinen VC1-1 nun nochmal platt gemacht, und es unter Debian 11 probiert und es hat auf Anhieb geklappt.
Es liegt tatsächlich am Debian 12 Image von Strota. Mich würde nur brennend interessieren, warum.Denn an und für sich würde ich schon sehr gerne Debian 12 verwenden.
Hmm, geht mir genauso. Man weiss natürlich bei solchen Images nie, welche Änderungen gegenüber älteren Versionen da vom Hoster eingebaut wurden. Macht eigentlich die Defaulteinstellung Sinn, dass die Kiste alle paar Minuten mit dem DHCP-Server telefoniert? Muss da die IP irgendwie reserviert werden oder was soll das. Dass der DHCP-Server plötzlich eine andere IP zuweist wird ja wohl hoffentlich nicht passieren Sonst hat mein Mailserver ein Problem 
. Insofern sollte man die doch auch einfach statisch eintragen können wie hier bei netcup!? Oder bietet das DHCP sonst noch irgendwelche Vorteile, außer dass unnötig Traffic erzeugt und CPU-Zeit abgezwackt wird?
Es liegt tatsächlich am Debian 12 Image von Strota.
Hmm, geht mir genauso.
Kann ich nun auch bestätigen.
Habe das exakt Gleiche nun nochmal mit dem Debian 12 Image durchgeführt und auch ich bekomme nun ein "forbidden" und /var/cache/munin/www bleibt leer.
Nicht dass das bei mir ein Problem wäre, denn ich nutze eh immer Ubuntu, aber es reizt mich jetzt doch, herauszufinden woran das liegt.
