Pulling from Wrong Node

[Psycholiquid]

Setup Multi Node FOG implementation. Now images are being pulled from the wrong node (Over my WAN). I am sure I have something setup wrong.

Little help?

[Wayne Workman]

@Psycholiquid Location plugin with locations defined?

[Psycholiquid]

Yeah but I had to remove the locations, when I had them setup it wasn’t allowing PCs to boot into FOG at all. Again this is something I have setup wrong I am just not sure what I am doing wrong.

To get around this I am turning off the second node and it will allow pulling fo\rom the correct location.

[Wayne Workman]

@Psycholiquid What version are you using? Are both the main server and the nodes all on the same version?

[Psycholiquid]

@Wayne-Workman said:

@Psycholiquid What version are you using? Are both the main server and the nodes all on the same version?

Yes version 5233, I know there are other revisions but I cant update at the moment but there weren’t any updates pertaining to this issue in the commits that I noticed.

[Wayne Workman]

@Psycholiquid said:

Yes version 5233

I bet there is… look at this one…
https://forums.fogproject.org/topic/6134/location-plugin-host-location-not-updating

[Psycholiquid]

OK lets add a littel bit of troubleshooting to this. So I had the groups setup for locations. Once I removed them all and left the image as it was the first time it pulls form teh right location. So lets look at the layout.

I have two locations right now.

Cincinnati
Nashville

I have one image in my FOG system, that has seemed to replicate from Cincinnati to Nashville without problem.

Without setting up locations I can pull the image from the Cincinnati location from both Cincinnati and Nashville (all be it is slow from NAS)

If I setup the locations like so

It starts to pull from Nashville for some odd reason.

Also to add I cannot image more than one machine at a time. I am not talking multi-casting but if I start and image the next one I start says:

Not really sure what is going on here, anyone have any ideas.

[Psycholiquid]

Once I setup the locations I get this from the Nashville location:

Now the error is simple and I understand it. what I dont understand is why it works when it is pulling from the wrong side and when it is setup correctly it doesn’t work at all.

[Tom Elliott]

@Psycholiquid Why is the unix fog user’s password password?

[Psycholiquid]

@Tom Elliot showed me the fix. The storage node setup for Management wasn’t set correctly.

Pulled user and pass from .fogsettings on the node and entered into the web interface on the storage node.

This resolved the FTP error.

[Tom Elliott]

I’m fairly sure I just fixed the weirdness of a single image at a time, but I wasn’t able to replicate while I was remoted in, nor on my systems. However I was able to replicate the issue of the check in loop problem and fix this, which I think was partially responsible for the issue altogether. I’m not sure 100%, but I am definitely hoping.

[Psycholiquid]

@Tom-Elliott I will be able to test here in a bit, my network admin jsut killed my switch in Nashville waiting for the onsite tech to get to work. Kids and their sleeping in.

[Psycholiquid]

Everything is working like a champ got two running in CINCINNATI at the same time one using 12GB a min and one using 2GB a min which is very good. I also have one in NASHVILLE working at the same time as the others moving 10GB a min all from their respective images. The only thing I am seeing now that worries me is the CINCINNATI master is transferring something to the NASHVILLE node (I think it is the other images I had but told the FOG system to delete.) The files are there but not in the DB so we may need to look at the deletion of the files when removing an image from the GUI. .

[Wayne Workman]

@Psycholiquid Tom has said the image deleting has been fixed. I think he did that sometime this morning. Update again.

And if there are images in your /images directory that are not in the web interface - you have two options on how to fix that.

1. just manually delete those that don’t have definitions.
2. re-make the definitions (using the exact case-sensitive path), and then immediately delete them using the web interface.

A side note is that the image replicator only replicates things that have definitions. it does not care what’s in the /images directory. it looks at the DB and sees what the DB says, then acts according to that information.

[Psycholiquid]

@Wayne-Workman I think I will go the route of recreating and allow the DB to do the deleting to make it cleaner , but I am getting more schooling on how everything is working. I am glad you all are here to push me along, now back to my setup post to help others.

[Psycholiquid]

@Wayne-Workman You think I should wait for the transfer to finish before I do that? Don’t want to delete it in that state, might cause an issue.

[Wayne Workman]

@Psycholiquid the image replicator logs have been extensively worked on lately by Tom. if you look in the log viewer in the web-ui, under image replicator, you should be able to see exactly what it’s doing.

and now, killing the image replicator also kills all lftp instances that were spawned from it as well.

it’s up to you how to do it. Waiting it out only wastes some bandwidth.

[Psycholiquid]

@Wayne-Workman roger that. Appreciate the input.