Another Database Failed to Update - after image capture
-
@jbender Just on a limb, would you mind removing the /var/www/fog and /var/www/html/fog directories and rerun the installer?
-
Unfortunately, same result still.
-
@jbender Is there anything the /var/log/xferlog file?
-
No it is empty.
-
Would it be possible to include a CHOWN command ahead of the CHMOD attempt?
From what I can tell that is what is missing. The images are captured owned by Root, the process that does the CHMOD in ftp is logged in as the “fog user” (I think). So if the CHMOD succeeds, the “fog user” would be cut off from having permissions to the final file.
I’ve been trying to find the relevant parts in the php files, and only know enough to be dangerous. Where are the commands that the fog capture script runs from? If I can find that might be able to add it myself as a test.
-
From the sounds of things, the chmod is working either way, because at the point the command runs the files are in 777 mod, the chmod simply changes it from 777 to 755.
-
@Tom-Elliott No the chmod does not run. The files have a 777 mod, and do not change until I manually run a chmod myself afterwards. I’ve also been manually changing the files ownership afterwards, since they are not owned by the fog user.
Since the chmod fails to complete, it signals an error in the capture script, never finishes a database update (which I am unsure what update that is), and causes the captured machine to run an auto-reboot after 1 minute.
However, the task completes on the fog server and the image captured this way seems to be ok.
Again this was not the behavior previously, and the system had not been changed otherwise until updating to the 1.3.0-RC5-6 trunk from svn 7929 trunk. Honestly never paid attention to ownership when they were captured previously, but the previous images were all correctly owned by fog user from before.
-
@jbender I suppose the chmod is not really necessary then. It was there as a failsafe I believe.
I’ll remove it for RC-8, which should fix the problem for you a bit more readily.
-
https://github.com/FOGProject/fogproject/commit/f61e8904c328a131df7e7aa69a2ecce68e4b07c8
Can you try applying the fix as described in the patch and see if uploads work for you now? I’ve added this to what will be RC-8 at least.
-
@Tom-Elliott That looks to have removed the issue.
-
@jbender So that will be available relatively soon in the “RC” cycles (unless we decide to go full fledged lol).
