Munin holt keine Daten beim externen Node ab

extremmichi · 3. Oktober 2016

Hallo zusammen.
ich habe den VPS50(debian minimal) als master und einen weiteren Server als Node eingerichtet
Auf dem Master funktioniert alles einwandfrei,
nur holt er keine Daten beim Node ab.
leider erhalte ich folgende Fehlermeldung auf dem Master.

Code

2016/10/02 23:11:05 [FATAL] Socket read from srv1 failed.  Terminating process. at /usr/share/perl5/Munin/Master/UpdateWorker.pm line 2542016/10/02 
23:11:05 [ERROR] Munin::Master::UpdateWorker<srv1;srv1> died with '[FATAL] Socket read from srv1 failed.  Terminating process. at /usr/share/perl5/Munin/Master/UpdateWorker.pm line 254

/etc/munin/munin.conf(Master)

Code

[srv1] 
 address 46.38.XX.XX 
 use_node_name yes

auf dem Node habe ich in /etc/munin/munin-node.conf Folgendes eingetragen:

Code

allow^46\.38\.XX\.XX$

ein Telnet auf dem Node:

Code

telnet localhost 4949 
Trying 127.0.0.1... 
Connected to localhost.Escape character is '^]'. 
# munin node at srv1

Ein telnet vom Master :

Code

telnet 46.38.XX.XX 4949
Trying 46.38.XX.XX...

und dann nix mehr

den Port 4949 habe ich auf dem Node folgendermassen freigegeben:

Code

/sbin/iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 4949 -j ACCEPT
 #und auch:
 /sbin/iptables -A INPUT -s 46.38.XXX.XXX  -m tcp -p tcp --dport 4949 -j ACCEPT

Google bring leider nichts zur Fehlermeldung

Danke im voraus
michi

linuxUser123 · 3. Oktober 2016

Ich glaube nach [srv1] fehlt ein Strichpunkt, also [srv1;]

Kann aber auch an was anderem liegen...

KB19 · 3. Oktober 2016

linuxUser123: Das Semikolon bei der Serverdefinition darf fehlen.

Da fehlt ein Leerzeichen nach dem allow:

Code

allow^46\.38\.XX\.XX$

Danach den Dienst am Node neustarten und nochmals mit telnet versuchen. Ansonsten bitte einmal die Logs vom Munin-Node posten und vorher log_level bei Bedarf in der munin-node.conf erhöhen. Und auch einmal überprüfen, ob der Dienst nach dem Neustart überhaupt läuft und auf einem Port lauscht.

MfG Christian

extremmichi · 3. Oktober 2016

Hallo Christian,
danke für deine Antwort
das Leerzeichen ist in der config drin, das Kopieren aus der bash heraus klappt nicht ganz richtig.
es verschwinden alle Zeilenumbrüche sowie Leerzeichen.
log_level ist schon auf 4

Code

#
# Example config-file for munin-node
#
log_level 4
log_file /var/log/munin/munin-node.log
pid_file /var/run/munin/munin-node.pid
background 1
setsid 1
user root
group root




# Regexps for files to ignore
ignore_file [\#~]$
ignore_file DEADJOE$
ignore_file \.bak$
ignore_file %$
ignore_file \.dpkg-(tmp|new|old|dist)
$ignore_file \.rpm(save|new)$
ignore_file \.pod$




# Set this if the client doesn't report the correct hostname when# telnetting to localhost, port 4949#
#host_name localhost.localdomain




host_name srv1




allow ^127\.0\.0\.1$
#allow ^::1$
allow  ^46\.38\.xx\.xx$




# Which address to bind to;#
#host * 
host 127.0.0.1




# And which port
port 4949

Alles anzeigen

die logs auf dem node sind absolut sauber

Code

2016/10/03-11:22:00 Server closing!




Process Backgrounded




2016/10/03-11:22:01 Munin::Node::Server (type Net::Server::Fork) starting! pid(28754)
Binding to TCP port 4949 on host 127.0.0.1 with IPv4
2016/10/03-11:39:23 Server closing!
Process Backgrounded

Alles anzeigen

der Dienst scheint zu laufen

Code

#top |grep munin




29547 root      20   0 49596 9656 1968 S   0,3  0,2   0:00.20 munin-node

Mir gehen die Ideen aus....

Gruss
michi

Mordor · 3. Oktober 2016

Moin

Zitat von extremmichi

Code

# Which address to bind to;#
#host * 
host 127.0.0.1

Externer Zugriff und Loopback passen nicht zusammen.

Mordor

extremmichi · 3. Oktober 2016

Zitat von Mordor

Moin

Externer Zugriff und Loopback passen nicht zusammen.

Mordor

Hallo Mordor,
du hast Recht
Leider bringt es aber keinerlei Änderung
ob ich nun host * oder host "IP" einsetze.
Ich glaube fast dass das Problem beim Matser liegt
und nicht beim Node.

munin-update.log sagt :(Domain und Servernamen anonymisiert)

Code

[INFO]: Starting munin-update
2016/10/03 13:55:01 [INFO] starting work in 11510 for master.munin.de/127.0.0.1:4949.
2016/10/03 13:55:01 [INFO] Process 11063 is dead, stealing lock, removing file
2016/10/03 13:55:01 [INFO] starting work in 11511 for node/46.38.XX.XX:4949.
2016/10/03 13:55:06 [INFO]: Munin-update finished for node munin.de;master.munin.de (4.56 sec)
2016/10/03 13:55:16 [INFO] Remaining workers: node;node, 
2016/10/03 13:55:16 [INFO] Reaping Munin::Master::UpdateWorker<munin.de;master.munini.de>.  Exit value/signal: 0/0
2016/10/03 13:55:56 [INFO] Remaining workers: node;node,
2016/10/03 13:56:04 [FATAL] Socket read from node failed.  Terminating process. at /usr/share/perl5/Munin/Master/UpdateWorker.pm line 254
2016/10/03 13:56:04 [ERROR] Munin::Master::UpdateWorker<node;node> died with '
2016/10/03 13:56:04 [FATAL] Socket read from node failed.  Terminating process. at /usr/share/perl5/Munin/Master/UpdateWorker.pm line 254
2016/10/03 13:56:06 [INFO] Reaping Munin::Master::UpdateWorker<node;node>.  Exit value/signal: 18/0
2016/10/03 13:56:06 [INFO] No old data available for failed worker node;node.  This node will disappear from the html web page hierarchy
2016/10/03 13:56:06 [INFO]: Munin-update finished (64.74 sec)

Alles anzeigen

die 2te Zeile gibt mir zu denken "der Prozess ist tot"

Wie finde ich heraus was Fehler 18 bedeutet?

gruss
michi

KB19 · 3. Oktober 2016

Was zeigt ein netstat -tulpen am Node? Funktioniert es über telnet auf localhost am Node?

Der 18er-Fehlercode sagt nicht mehr aus, als Du eh schon siehst: munin/ProcessManager.pm at 3552273136d8273db7d51574103d31af8b3a07a5 · munin-monitoring/munin · GitHub

MfG Christian

extremmichi · 3. Oktober 2016

Danke für eure Hilfe

Zitat von killerbees19

netstat -tulpen

Es geht dir sicher nur um die eine Zeile

tcp 0 0 46.38.XX.XX:4949 0.0.0.0:* LISTEN 0 36900327 2100/munin-node

telnet auf localhost am node geht.
siehe mein erster Post

Gruss

michi

KB19 · 3. Oktober 2016

Stimmt, ganz übersehen. Dann bitte noch einmal die Firewallregeln von Node und Master:

Code

iptables -n -v --list

Kann ja eigentlich nur noch daran liegen…

MfG Christian

extremmichi · 3. Oktober 2016

das wird eine richtig lange Liste
brauchst du alles?

KB19 · 3. Oktober 2016

Wäre von Vorteil…

Schicks mir mal per PN, wenn Du es nicht öffentlich posten möchtest.

MfG Christian

extremmichi · 3. Oktober 2016

Zitat von killerbees19

Wäre von Vorteil…

Schicks mir mal per PN, wenn Du es nicht öffentlich posten möchtest.

MfG Christian

Alles anzeigen

kommt per email
PN kann nur 10k Zeichen

KB19 · 3. Oktober 2016

Du blockierst in der INPUT-Chain alles, bevor Du es zulässt:

Code

0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW tcp dpt:4949
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW tcp dpt:4949
    0     0 ACCEPT     tcp  --  *      *       46.38.***.*          0.0.0.0/0            tcp dpt:4949

Wie werden diese Firewallregeln erstellt? Du könntest jetzt einfach den iptables-Befehl aus Deinem ersten Beitrag abändern und -I (Insert) statt -A (Append) verwenden. Oder Du fügst es nicht zu INPUT sondern z.B. zur Kette INPUT_CHAIN hinzu, die vorher abgearbeitet wird. Das würde dein Problem lösen, rebootfest ist es damit aber noch nicht. Ohne zu wissen, woher diese Regeln kommen bzw. wie sie verwaltet werden, kann man da keine allgemein gültige Antwort geben. Die wirken sowieso ziemlich Overkill und sind größtenteils unnötig.

MfG Christian

extremmichi · 3. Oktober 2016

Hallo Christian,
ja genau das war es
Danke

ich verwende die arno-iptables-firewall, duie eine Menge Rules selbstständig erstellt.
und natürlich fail2ban. Möglicherweise ist da was doppelt und auch nicht perfekt,
das zeigt dieser Post ja . FW ist ein Thema mit so vielen Aspekten, dass es auch unübersichtlich werden kann,
aber lieber doppelt gemoppelt als zuwenig.
Trotzdem muss ich da wohl nochmal ran.
Jedenfalls danke ich dir für deine Hilfe

Gruss
michi