Another Database Failed to Update - after image capture



  • Updated from SVN 7294 to 1.3.0-RC5 if that makes any difference.
    Running on CentOS7

    Have made the modification to /var/www/fog/lib/fog/fogmanagercontroller.class.php on line 23 to remove strict mode error spam.

    fogguiuser/pass are set in .fogsettings, all usernames and passwords are also set in .fogsettings, and the FTP access appears to work correctly now.

    Get the following error on the client being captured:

    0_1470254175291_fogerrorchmod.jpg

    In the images folder, the new image is there correctly, but shows the following ownership still

    drwxrwxrwx. 2 root root 4.0K Aug 3 15:19 Win10EngBaseInstall5

    Restoring images works fine with no errors however, so if seems to be failing to change ownership.


  • Senior Developer

    @jbender So that will be available relatively soon in the “RC” cycles (unless we decide to go full fledged lol).



  • @Tom-Elliott That looks to have removed the issue.


  • Senior Developer

    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.


  • Senior Developer

    @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.



  • @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.


  • Senior Developer

    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.



  • 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.



  • @Tom-Elliott

    No it is empty.


  • Senior Developer

    @jbender Is there anything the /var/log/xferlog file?



  • @Tom-Elliott

    Unfortunately, same result still.


  • Senior Developer

    @jbender Just on a limb, would you mind removing the /var/www/fog and /var/www/html/fog directories and rerun the installer?



  • Now updated to 1.3.0-RC6

    Still have the same error after image captured, database update fails.

    0_1470317677747_fogerrorfull.jpg
    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.



  • @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 ~]#


  • Moderator

    What is the output of sestatus and getenforce ?


  • Senior Developer

    @jbender

    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?


Log in to reply
 

329
Online

38729
Users

10555
Topics

99939
Posts

Looks like your connection to FOG Project was lost, please wait while we try to reconnect.