Posts made by ictadmin

Thanks for the pointers Enrico.

The mulitcast task log (multicast.log.udpcast.tasknumber) looks like this:

[CODE]Udp-sender 20120424
Using mcast address 236.16.1.48
UDP sender for (stdin) at 172.16.1.48 on bond0
Broadcasting control to 224.0.0.1
New connection from 172.16.12.2 (#0) 00000009
New connection from 172.16.12.10 (#1) 00000009
New connection from 172.16.12.17 (#2) 00000009
Starting transfer: 00000009
Timeout notAnswered=[0,1,2] notReady=[0,1,2] nrAns=0 nrRead=0 nrPart=3 avg=10000
Timeout notAnswered=[0,1,2] notReady=[0,1,2] nrAns=0 nrRead=0 nrPart=3 avg=10000
Timeout notAnswered=[0,1,2] notReady=[0,1,2] nrAns=0 nrRead=0 nrPart=3 avg=10000
Timeout notAnswered=[0,1,2] notReady=[0,1,2] nrAns=0 nrRead=0 nrPart=3 avg=10000
Timeout notAnswered=[0,1,2] notReady=[0,1,2] nrAns=0 nrRead=0 nrPart=3 avg=10000
Timeout notAnswered=[0,1,2] notReady=[0,1,2] nrAns=0 nrRead=0 nrPart=3 avg=10000
Timeout notAnswered=[0,1,2] notReady=[0,1,2] nrAns=0 nrRead=0 nrPart=3 avg=10000
Timeout notAnswered=[0,1,2] notReady=[0,1,2] nrAns=0 nrRead=0 nrPart=3 avg=10000
Timeout notAnswered=[0,1,2] notReady=[0,1,2] nrAns=0 nrRead=0 nrPart=3 avg=10000
Timeout notAnswered=[0,1,2] notReady=[0,1,2] nrAns=0 nrRead=0 nrPart=3 avg=10000
Timeout notAnswered=[0,1,2] notReady=[0,1,2] nrAns=0 nrRead=0 nrPart=3 avg=10000
Timeout notAnswered=[0,1,2] notReady=[0,1,2] nrAns=0 nrRead=0 nrPart=3 avg=10000
Timeout notAnswered=[0,1,2] notReady=[0,1,2] nrAns=0 nrRead=0 nrPart=3 avg=10000
Timeout notAnswered=[0,1,2] notReady=[0,1,2] nrAns=0 nrRead=0 nrPart=3 avg=10000
[/CODE]

The multicast.log looks like:

[CODE][07-29-14 12:12:22 pm] CMD: cat /images/WIN7V13/sys.img.*|/usr/local/sbin/udp-sender --min-receivers 3 --portbase 57722 --interface bond0 --full-duplex --ttl 32 --nokbd;
[07-29-14 12:12:22 pm] | Task (45) test has started.
[07-29-14 12:12:32 pm] | Task (45) test is already running PID 22373
[07-29-14 12:12:42 pm] | Task (45) test is already running PID 22373
[07-29-14 12:12:52 pm] | Task (45) test is already running PID 22373
[07-29-14 12:13:02 pm] | Task (45) test is already running PID 22373
[07-29-14 12:13:12 pm] | Task (45) test is already running PID 22373
[/CODE]

and this goes on until we switch the machines off where the task is marked as complete.

The only other thing I can see is the /bon/fog.download line 70 error which I highlighted in a earlier post.

The FOGMulticastManagerService is running.

Thanks!

IA

Hi Tom,

For us the multicast task never starts, it’s as if the computers are waiting for another computer to join - or for something to kick the session off.

How can I check if the FOGMulitcastManager is running please?

Thanks,

IA

Thanks Junkhacker, when the clients are set to multicast individually, the job completes just fine, when they are part of a group job they don’t even begin, they just sit at the blue screen as if they are waiting for another computer to join the group, have left them for an hour in this state and nothing I’m afraid!

One last thing on this issue, when the client boots into it’s multicast runtime we get an error saying:

/bin/fog.download: line 70: [: too many arguments

Is this normal? Just going to start googling it now!

Thanks for the suggestions, the fog sever is connected to the internet via a proxy, but the proxy port the server connects to is unauthenticated (locked down only but network acls)

I’ve just tried removing the proxy information and this seems to have fixed the issues (both slow task creation and the multicast grouping issue)

Thanks for your help!

Thanks for the suggestions, the fog sever is connected to the internet via a proxy, but the proxy port the server connects to is unauthenticated (locked down only but network acls)

I’ve just tried removing the proxy information and this seems to have fixed the issues (both slow task creation and the multicast grouping issue)

Thanks for your help!

Hopefully the attached images will help explain what’s going on a bit better.

[ATTACH=full]1214[/ATTACH][ATTACH=full]1215[/ATTACH][ATTACH=full]1216[/ATTACH][ATTACH=full]1217[/ATTACH]

When the machines are turned on from this point they will just image (they won’t wait for the others in their group) so if we were to turn one machine on it will just image.

[url=“/_imported_xf_attachments/1/1214_Multicast1.PNG?:”]Multicast1.PNG[/url][url=“/_imported_xf_attachments/1/1215_Multicast2.PNG?:”]Multicast2.PNG[/url][url=“/_imported_xf_attachments/1/1216_Multicast3.PNG?:”]Multicast3.PNG[/url][url=“/_imported_xf_attachments/1/1217_Multicast4.PNG?:”]Multicast4.PNG[/url]

It connects to the internet via a proxy.

Thanks Sully,
Yes, the time it takes from clicking the button “Create ‘Multi-Cast’ task for group ‘x’” is taking around 30 seconds before the message saying the task has been created appears (in green box). Used to be almost instant in version 0.32.
We have restarted the fog server but still have the same issue. Anything else we can try?
Thanks.

We have a group set up for the computers we’re trying to multicast, we’re clicking the Multicast icon next to the group name in order to set up the multicast. So we are telling it to be a multicast task.

Hi sorry, we’re running fog version 1.2.0 on Ubuntu 12.04.

It appears that fog is creating an individual multicast session per host rather than one multicast session for the whole group.

If you need any further info please let us know!

Hi there,
When creating a Multicast task for a group of (30) hosts it looks as though the multicast task is created individually per host and when the suite of computers is booted, the download starts but works as if we had just set a unicast for all. In other words, unlike our old 0.32 setup, the server is not waiting for all hosts to get to the same ‘checkpoint’ before downloading.
Hope that makes sense.
Thanks for any help.

Fog Version 1.2.0
When creating a task in the GUI e.g Download or Upload or Hardware Inventory etc. It takes at least 30 seconds to complete and display a message saying the task has been created. Creating a multicast task with 30 hosts takes an age…All hosts, don’t even go there!
This was never the case with our old 0.32 setup.
Anyone else got this problem? Any help to sort would be much appreciated.
Thanks.