FOG server not replicating drivers correctly to secondary node
-
@george1421 That’s the way it seems.
Yes I did. Doesn’t seem to want to work still.
-
@themcv OK one comment first, make sure you protect these drivers to ensure they don’t get accidentally overwritten.
So the next steps…
- Go to the remote storage node configuration on the FOG server’s web gui.
- Collect and document the user management ID and password from the web gui.
- From the master node ftp to the storage node in question using the management user ID and password collected from step 2.
- Change to the /images directory using the ftp client.
- Create a directory in /images on the storage node (we are testing permissions)
- put a local test file from the master node to the remote storage node in that new directory.
- rm that file you put to the remote storage node.
If you can test the mechanics of the replication then we will move it over to a bug in 1.5.0. But test the mechanics first.
-
@george1421 This wouldn’t be a bug. The very same mechanism that handles images (which you’ve already pointed out) handles the drivers (particularly when you consider the drivers is also an image too). So while there is a problem, it’s highly unlikely this is a problem being caused by fog, at least not directly.
-
@george1421 If I did that right, then all worked okay for me when doing that. Made /images/testdir on the remote, used put testfile into that directory then deleted it.
Seemed okay doing that (i just want to make sure I did exactly how you asked! )
-
@themcv On the receiving storage node (assuming its a linux fog server) can you look in /var/logs there should be a log file for the ftp service. Check to see if there is any useful error messages when the drivers try to replicate.
The images replicate like they should, the drivers and images use the same replication engine.
The ftp process works.
Have we check the permissions on the master FOG server to ensure the directory and file permissions for /images/drivers match /images/<image_name>?
If Tom is saying its not a bug, then it has to be something simple we’re missing.
-
@george1421 I didn’t see anything in there related to ftp unfortunately.
I agree, this has to be something little that we’re missing.
I chmod 777’d /images/drivers to be sure.
-
@themcv chmod on both source and destination /images/drivers folders?
If that is the case and you restart the fog image replicator service with no joy then we will need to get the @Developers involved for additional debugging steps.
-
@george1421 Just upgraded to RC-7. I will restart both of the FOG servers just in case. @Tom-Elliott do you have time to remote in this week by any chance?
-
I’ve remoted in we are checking a change to see if the replication of sub sub sub folder stuff will work appropriately. Right now it’s in the middle of file 1.6million (I don’t really know but it’s a lot of them).
At least it appears to be checking the files iterative now.
Once it completes the first check, I’ll restart the service and hopefully it will work. It will take a while of course :(. -
@THEMCV Was this actually solved. Sounds like it but I am not absolutely sure.
-
@sebastian-roth Not yet. He setup a check to see if the servers were online, but right now the check doesn’t work so it doesn’t replicate. Still having issues, but for now I’m using rsync to send them.
-
@THEMCV You might want to upgrade to RC9 and see if this is working for you.
-
@sebastian-roth Doesn’t look like it. Doing an rsync for the time being and that seems to work okay for now.
-
@themcv Is it possible there’s a firewall blocking ping checks to port 21? All the change I made does is check that the server is available and responding on port 21. (or whatever your ftp port is defined within
/var/www/fog/lib/fog/fogftp.class.php
(Usually 21)) -
@tom-elliott Anything is possible where I work. : )
I will see if that could be the issue and let you know.