Fog: multicasting across subnets
-
How do I set up this storage node? Sorry for the dumb question but we loaded fog as a storage node and we think we put it on the fog server correctly but apparently not.
-
@K.Hays During the storage node installation, you choose
s
for storage node. It will ask for the main server’s IP, and it will ask for the main server’s mysql credentials to use - you find those inside the FOG Settings -> Storage Nodes area. At the end, it gives you a username and password at the end that you use to setup a new node in the web interface’s storage management area. -
@Wayne-Workman We got the node setup but multicast still doesnt work. We can unicast no problem.
-
@K.Hays it will do the same thing as before, and it just stops at the partclone screen.
-
@K.Hays is the stoage node in it’s own group, and set as a master? Is the image associated with the new group?
-
@Wayne-Workman yes,yes,and yes. We made sure of all that.
-
@K.Hays and you watched the image replicate? And it’s physically present on the new node?
You might also look this over: https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_Downloading_-_Multicast
-
@Wayne-Workman yeah i watched it but i didnt check the storage node itseld to see if it actually saved there. I cant see why it wouldnt have though unless its a problem some people have. I think it was set up correctly. We were able to image to and from it.
-
@K.Hays is the
FOGMulticastManager
running? Any logs about it in the log viewer? -
@Wayne-Workman When i try to enable FOGMulticastManager it tells me it fails.
Edit: Never mind, i stopped it then restarted it and now it says it’s running. -
@K.Hays said in Fog: multicasting across subnets:
@Wayne-Workman When i try to enable FOGMulticastManager it tells me it fails.
Inside of
/opt/fog/log
there are logs for the multicast manager. They are also accessible via the log viewer. Try to start the service, and then look at the logs - share what you find. -
@Wayne-Workman It says the image file was not found. Which is weird because we were able to unicast using that file.
specifically it said the task was found but it failed to execute because the image was not found. -
This post is deleted! -
@Wayne-Workman I found another log for multicast manager and it says “unable to locate udp sender”
-
@K.Hays Notifying a few folks that might be able to help.
-
Well here is the updated situation. As you know not too long ago we set up a fog server that could unicast and do all that across subnets no problem. Theoretically it should have been able to multicast (since we had a fog server up and running before which was able to do so, but it is currently and permanently inaccessible) but it would pause at the partclone screen. Then we decided to try storage nodes, as making modifications to the switches may be complicated at the moment. So we set up two different storage nodes in two different buildings, both with trunk and both set up AS storage nodes. They were loaded correctly and were also able to unicast too and from them, the images were physically stored on them also. When we tried to multicast though, it stopped again at the partclone screen. I’m assuming this is most likely a network issue, which we will be more able to solve this summer, as during the school year it gets complicated. But i just wanted to check to see if there is another solution, or possibly something that I am not doing correctly. Sorry for the influx of questions but it would be great if this was ready by the time we started summer maintenance.
-
@K.Hays if you go to Image Management and click on one of your images, and then click on “Storage Group” on the left, what do you see?
-
@Wayne-Workman It depends on the image. For the ones linked to the storage node, i.e the middle school group we have, it says Middle School. But the checkbox isn’t checked, should it be? Thats all thats in there though
-
@K.Hays what is the OS you are using on these nodes? What are the actual interface names and are they reflected properly in the db.
-
@Tom-Elliott Im using 14.04 on the nodes also. The interface names on both are eth2. One of the nodes defaulted to eth0 in the database and the other we manually changed to eth2. I believe we got the same results regardless.