Another Database Failed to Update - after image capture
-
I’m running rc5 at work and have uploaded many images without this issue. That said, the chmod simply tries to change the file permissions to 0755. From the sounds of this, it almost seems the /images folder is masked?
-
What is the output of
sestatusandgetenforce? -
@Wayne-Workman
[root@fogmachine ~]# sestatus
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: permissive
Mode from config file: permissive
Policy MLS status: enabled
Policy deny_unknown status: allowed
Max kernel policy version: 28
[root@fogmachine ~]# getenforce
Permissive
[root@fogmachine ~]# -
Now updated to 1.3.0-RC6
Still have the same error after image captured, database update fails.
jbender Storage Group: default
Storage Node: DefaultMember 2016-08-04
09:01:45 2016-08-04
09:17:20 15 minutes 35 seconds Win10-EngBase-Install-6 Capture Complete– On the FOG Interface side, Image capture is complete
My /images mount had been set to 777 permissions, have set back to 755, with fog:root as owner as before.
drwxr-xr-x. 21 fog root 4.0K Aug 4 09:17 images
/dev/sdb1 on /images type xfs (rw,relatime,seclabel,attr2,inode64,noquota)– Nothing special about /images that I know of.
Directory listing of images:
drwxr-xr-x. 21 fog root 4.0K Aug 4 09:17 .
dr-xr-xr-x. 21 root root 4.0K Aug 3 17:07 …
drwxr-xr-x. 2 fog root 22 Aug 4 09:17 dev
-rwxr-xr-x. 1 fog root 0 Apr 18 16:10 .mntcheck
drwxr-xr-x. 2 fog root 29 Apr 18 16:10 postdownloadscripts
drwxr-xr-x. 2 fog root 4.0K May 11 12:43 Win10BaseInstall4
drwxr-xr-x. 2 fog root 4.0K May 19 15:09 Win10BaseInstall5
drwxr-xr-x. 2 fog root 6 May 9 12:48 Win10BaseInstallStartCustom1
drwxr-xr-x. 2 fog root 6 May 9 13:22 Win10BaseInstallSysprep1
drwxr-xr-x. 2 fog root 4.0K Aug 3 15:19 Win10EngBaseInstall5
drwxrwxrwx. 2 root root 4.0K Aug 4 09:17 Win10EngBaseInstall6– /images/dev folder gets emptied correctly after capture, the new image gets moved into /images/imagename
I’ve noticed that the image while being captured in /images/dev is owned by root:root, and when it gets moved back into /images, it is still owned by root:root. All other images where captured under SVN version 72xx series and have ownership set to fog:root. Should there be a step that changes ownership to fog:root before the chmod is done?
Forgot to add:
– From httpd error log:
[Thu Aug 04 09:17:20.183936 2016] [:error] [pid 17703] [client 10.70.58.123:57320] PHP Warning: ftp_chmod(): SITE CHMOD command failed. in /var/www/html/fog/lib/fog/fogftp.class.php on line 31
— VSFTP.conf
anonymous_enable=NO
local_enable=YES
write_enable=YES
local_umask=022
dirmessage_enable=YES
xferlog_enable=YES
connect_from_port_20=YES
xferlog_std_format=YES
listen=YES
pam_service_name=vsftpd
userlist_enable=NO
tcp_wrappers=YES
seccomp_sandbox=NO– Not really sure what else to check.
-
@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).
