If you think it is the iptables firewall that is causing you your problems then try turning on logging of dropped/rejected packets to help debug your problem:
iptables -A INPUT -m limit --limit 3/m -j LOG --log-level info \ --log-prefix "iptables: dropped input: " this rule needs to go before the DROP/REJECT rule that is at the end of your INPUT chain, or just at the bottom if you have a default policy set to DROP/REJECT. Then watch /var/log/messages for iptables logs to see what ganglia related traffic is getting blocked. Also, I assume that you have a rule allowing your gmetad server to connect to your cluster, something like: iptables -A INPUT -p tcp -m state --state NEW -m tcp -s gmetad.host.ip \ --dport 8649 -j ACCEPT ~Jason On Tue, 2005-09-20 at 00:12, Alex Davies wrote: > I am afraid that I still experience the complete loss of monitoring as > soon as I start my firewall even with those rules added... > > I cant seem to find any clear instructions on this, but is there any > way to get each gmond daemon just to collect statistics from its local > host and have one server collect all the xml files every 20 seconds or > so? > > Many thanks, > > Alex > > > On 20/09/05, Jason A. Smith <[EMAIL PROTECTED]> wrote: > > If your network switches are configured to do igmp, then you will > > probably want to add an iptables rule like this: > > > > iptables -A INPUT -p igmp -j ACCEPT > > > > We have iptables configured on all of our systems running ganglia > > without any problems and only have 2 related rules, the igmp one above > > and a multicast rule like this: > > > > iptables -A INPUT -p udp -m udp -d 239.2.11.71 --dport 8649 -j ACCEPT > > > > ~Jason > > > > > > On Mon, 2005-09-19 at 22:47, Alex Davies wrote: > > > Dear Mike, > > > > > > Many thanks for your very fast reply :) > > > > > > All my nodes are on the same switch, but we are using software > > > firewalls. The cluster is trying to use the second ethernet port which > > > is plugged into a dedicated switch, which is "trusted" and not > > > supposed to be firewalled but I have a hunch that the multicasting > > > thing is not going over that port, and I am not sure how to force it > > > to (nor am I sure if it matters). > > > > > > However, could you confirm how you forced ganglia to use your tunnel - > > > particularly for the multicast packets? > > > > > > Many thanks, > > > > > > Alex > > > > > > On 20/09/05, michael chang <[EMAIL PROTECTED]> wrote: > > > > On 9/19/05, Alex Davies <[EMAIL PROTECTED]> wrote: > > > > > I have been trying to install ganglia on my 13-node cluster and had > > > > > it all working wonderfully and was amazed how easilly until I > > > > > restarted my firewall :) > > > > > > > > This is probably impratical, and the worst advice I can give you, so > > > > I'm going to BEG one of the others on the list to come up with a > > > > better answer, but I can tell you that I've got Ganglia working just > > > > fine over a OpenVPN tunnel (provided that peer-to-peer client > > > > communication is online, and the PC hosting the OpenVPN tunnel is > > > > online). Maybe that's something you want...? I doubt it, but I > > > > figured I'd mention it anyways, just in case. > > > > > > > > I'm wondering, when the firewall restarts, what happens to the > > > > interfaces that Ganglia is multicasting over? Maybe you need > > > > something that automatically restarts ganglia when the firewall > > > > restarts ...? Like I said, someone else probably has a better answer. > > > > > > > > My apologies for any unhelpfulnesses. > > > > > > > > -- > > > > ~Mike > > > > - Just my two cents > > > > - No man is an island, and no man is unable. > > > > > > > > > >
