Pulling from Wrong Node
-
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.
-
@Psycholiquid Why is the unix fog user’s password password?
-
@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.
-
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.
-
@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.
-
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. .
-
@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.
- just manually delete those that don’t have definitions.
- 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.
-
@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.
-
@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.
-
@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.
-
@Wayne-Workman roger that. Appreciate the input.
