Image not syncing between nodes

[Wayne Workman]

@msi Ok, now verify that the image captured properly on the master node. I don’t know your image’s name, but you would check by changing into it’s directory like this:
cd /images/<image name here>/
and then running this command:
ls -laht

[msi]

@wayne-workman the two images doesn’t exist on master. I can see those on NJED45; the place where I created those two images.
Below picture is from NJED45

Below picture is from Master

[Wayne Workman]

@msi Then I would ask you to ensure the IP addresses for your nodes are correct in the Storage Management area. Also check the IP addresses set on the nodes via CLI with this command: ip addr

[msi]

@wayne-workman
NJED45

Master

[Wayne Workman]

@msi Please verify the IPs via CLI too. The command is ip addr

[msi]

@wayne-workman
NJED

Master
It matches.

[Wayne Workman]

@msi What happens when you go to http://10.134.200.230/fog/management using your browser?

[msi]

@wayne-workman Below Message
‘This is a storage node, please do not access the web ui here!’

[Wayne Workman]

@msi Well then something is really messed up here. Going to ask for help from the @developers and @moderators for ideas.

[msi]

@wayne-workman Sure, thanks

[Tom Elliott]

@wayne-workman he’s using location plugin so uploads will go to the hosts location even if the location node is not a master. Replication only happens from master nodes though. Hope this helps.

[george1421]

I guess before we dig into this what I’m (as well as Wayne) is having an issue with understanding is that you are saying something is happening (or not happening) that is not normally possible with FOG.

Let me state the rules according to FOG

1. Only full FOG servers (ones with local databases) can replicate images. The storage nodes do not have the replicator service installed. Any images that were able to make it to a storage node will aways remain there since there is no replicator service to move them.
2. FOG replication is aways a push replication and never a pull replication.
3. Only master nodes in each storage group is authorized to replicate images. If you have one or more full fog servers in a storage group only the master node in that storage group is allowed to replicate (push) images to other nodes in its storage group.
4. Only master nodes in each storage group can capture images. All nodes in each storage group can deploy images.

So what you are saying that your storage node at the branch captured an image and is not replicating to the master mode at HQ. The short answer is you are right, but what you suggest is not possible.

[george1421]

@tom-elliott said in Image not syncing between nodes:

he’s using location plugin so uploads will go to the hosts location even if the location node is not a master.

Well who the hell programmed that? That is counter to what we’ve been taught!!

@msi Well then, I guess the system is working as designed.

[msi]

@george1421 It was working up until as Tom mentioned, by using location plugin. However, its not working today. I just don’t understand why suddenly it stopped working.

[Wayne Workman]

@msi said in Image not syncing between nodes:

I just don’t understand why suddenly it stopped working.

There’s no telling. Probably to get this going though, you need to manually transfer the image with rsync from the storage node to the master node. Then this should be fixed.

If you run this command from your Master Node, it will prompt you for the storage node’s local fog user’s password. You can find that in that node’s storage management area or from this file on it: /opt/fog/.fogsettings

rsync <options> <source> <destination>

rsync -r --bwlimit=6250 fog@10.134.200.230:/images/Laptop2.1 /images
rsync -r --bwlimit=6250 fog@10.134.200.230:/images/Laptop /images

The 6250 is supposed to be 6250Kbps, or 50Mbps. If you want slower, you can do the math to figure out what you need with the calculator I reference below.

scp is another option if the rsync commands don’t work out. Something like this from the master node and again you’d be prompted for the remote node’s fog password.

scp -r fog@10.134.200.230:/images/Laptop2.1 /images
scp -r fog@10.134.200.230:/images/Laptop /images

References:
https://www.cyberciti.biz/tips/linux-use-rsync-transfer-mirror-files-directories.html
https://linux.die.net/man/1/rsync
https://www.checkyourmath.com/convert/data_rates/per_second/megabits_kilobytes_per_second.php

[Wayne Workman]

@george1421 said in Image not syncing between nodes:

That is counter to what we’ve been taught!!

I guess when you think about it, this behavior is better than trying to run a capture for 10 days across a 5Mps link to a master node on the other side of the planet. Worst case scenario to get the image where it belongs is you put it onto a USB stick and just mail it (Or perhaps IP over Avian Carriers?).

@msi I’m very curious now, can you deploy the image successfully at the remote site even with this replication problem?

[msi]

@wayne-workman said in Image not syncing between nodes:

@msi I’m very curious now, can you deploy the image successfully at the remote site even with this replication problem?

With the replication problem, NO

[msi]

@wayne-workman said in Image not syncing between nodes:

If you run this command from your Master Node, it will prompt you for the storage node’s local fog user’s password. You can find that in that node’s storage management area or from this file on it: /opt/fog/.fogsettings

rsync <options> <source> <destination>

rsync -r --bwlimit=6250 fog@10.134.200.230:/images/Laptop2.1 /images
rsync -r --bwlimit=6250 fog@10.134.200.230:/images/Laptop /images

The 6250 is supposed to be 6250Kbps, or 50Mbps. If you want slower, you can do the math to figure out what you need with the calculator I reference below.

It took some times but it is working after issuing the rsync command. I had to delete the image from the NJED node after rsync completion.