Multicast problems
-
Fog works fine for unicast, but it seems my network configuration is not entirely correct for multicast.
Fog server:
Debian 7.7 Wheezy fresh install with Fog 1.20 fresh install. Dependencies like mysql set up by Fog config.Separate DHCP/name server running Wheezy as well.
next-server pointed at my tftpboot, pxe in itself works fine, coupled with WoL.Separate Samba server with no LDAP running.
we’re using 255.255.255.0 range with address space quite filled right now (have about 15 dynamic addresses available with people using them often), need to get on a wider range.
There’s a minimum of two switches between every host and the dhcp server.
Fog server’s hosts file where king is the fog server:
[QUOTE]127.0.0.1 localhost
192.168.7.6 kingThe following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters[/QUOTE]config.php (it’s a little empty, is there something missing I should have?):
[QUOTE]<?php
define( “WEBROOT”, “/var/www/fog” );
?>
[/QUOTE]The steps I have taken:
Bringing test hosts on the same subnet, plugged in the same switch as the fog server.
Run all steps in [url]http://www.fogproject.org/wiki/index.php/Multicasting[/url] Troubleshooting section, everything working til Something else to try, where I get the connection and everything’s ready to send, but when I hit enter, the server shows both cliekala@king:~$ gunzip -c “/images/w72015pohi/d1p1.img” |
The udp defaults are the following:
[QUOTE]kala@king:~$ gunzip -c “/images/w72015pohi/d1p1.img” | /usr/local/sbin/udp-sender --min-receivers 2 --portbase 9000 --interface eth0 --half-duplex --ttl 32
Udp-sender 20120424
Using mcast address 232.168.7.6
UDP sender for (stdin) at 192.168.7.6 on eth0
Broadcasting control to 224.0.0.1[/QUOTE] -
The part you’re missing on the [code]kala@king:~$ gunzip -c “/images/w72015pohi/d1p1.img” | /usr/local/sbin/udp-sender --min-receivers 2 --portbase 9000 --interface eth0 --half-duplex --ttl 32
Udp-sender 20120424
Using mcast address 232.168.7.6
UDP sender for (stdin) at 192.168.7.6 on eth0
Broadcasting control to 224.0.0.1[/code]It should be:
[code]kala@king:~$ cat “/images/w72015pohi/d1p1.img” | /usr/local/sbin/udp-sender --min-receivers 2 --portbase 9000 --interface eth0 --half-duplex --ttl 32[/code]If you’re wanting the server to decompress the correct command should be:
[code]cat “/images/w72015pohi/d1p1.img” | gunzip -d -c | /usr/local/sbin/udp-sender --min-receivers 2 --portbase 9000 --interface eth0 --half-duplex --ttl 32[/code]You have to stream the data, then decompress.
But that’s not likely the issue.
At what point are you having issues? Is FOGMulticastManager running on the fog server? To find out:
[code]ps -ef|grep FOGMulti[/code]If, for whatever reason, it isn’t, you could do:
[code]service FOGMulticastManager stop
killall udp-sender
killall udp-sender
killall udp-sender
service FOGMulticastManager start[/code]Hopefully this helps.
The /opt/fog/etc/config.php is absolutely correct. All fog runs through the main Web configuration now.
-
Thanks for the reply.
Weirdly enough the process wasn’t running with two jobs waiting to be started on gui. Will update when I can get the test hosts back on the table.
-
For some reason, neither Multicast nor scheduler nor imagereplication services were up and wouldn’t start. Last log activity from them was on the 13th. They wouldn’t start with only start argument, but had to be stopped first even though they weren’t anywhere on process list and the command itself showed there was nothing to kill (no such process).
Now that I manually started all those services, multicasting works like a charm. Need to fix them not starting on boot in the first place…
-
This is kind of known. FOG Services start “too early” (before mysql is fully up). See here how I got this “fixed” on my system.
[url]http://fogproject.org/forum/threads/fogscheduler-needs-started-manually-since-upgrading-to-svn-2912-from-1-2-0.12266/#post-41094[/url]
I didn’t have the time to have a look into the start scripts yet. You are more than welcome to look into this!