If I had to guess it’s to do with selinux.
https://wiki.fogproject.org/wiki/index.php?title=CentOS_7#CentOS_7_pre-config

I could be wrong but epel is a fedora/centos thing, not a redhat (native) thing.

You could try this:
https://access.redhat.com/discussions/3140721

Particularly (or as root):

sudo rpm -ivh https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
sudo yum update

@gordon-taylor please try editing the /var/www/fog/service/ipxe/refind.conf file and set the scan_delay to 0. I’ve heard of this seeming to be a fix for this type of problem.

@gordon-taylor The binary might have changes (refind.efi) though we don’t know what changed (we don’t write the refind program stuff.)

I’ve made scan_delay = 0 the default when 1.5.1 releases.

I think this is not such a good idea.

For one, snapins aren’t an installing/uninstalling utility. Snapins are just (in the simplest of terms) a way of running some executable, be it a script, program, or what have you.

If anything, the message of snapins should really be (in my opinion) “Running snapin…”

And the status of that snapin should be displayed on the task management page.

These status’ are able to be configured, and I’ll request @lee-rowlett to take a look at this as I know he’s doing similar types of things for snapins and status messages.

Using the “Running snapin” message you could name your snapins so it more pertains to the message.

For example, the name being “Google Chrome Uninstaller” you would see the message:

“Running Google Chrome Uninstaller”

Mind trying the working-1.5.1 branch?

I’ve made a lot of headway in performance issues from 1.5.0 that I think is now addressed in 1.5.1, but need more people to test live to ensure the fixes are indeed working as expected.

You would cd to where your current git environment is. Then you do:

git checkout working-1.5.1
git pull
cd bin
./installfog.sh -y

(changing installfog.sh with your normally run arguments if you have any differences.)

@sebastian-roth I’ve made a patch that includes these fixes. I’m currently building the new init’s which will take quite a long time, but I have uploaded the patch to our fos repository. Sorry it will take a while to get some inits built.

I don’t know what the problem was. All I did was patch the ntfs-3g files with the suggested fixes from Sebastian and rebuilt the inits with the changes.

The code in php is:

     /**
      * Returns hash of passed file.
      *
      * @param string $file The file to get hash of.
      *
      * @return string
      */
     public static function getHash($file)
     {
         usleep(50000);
         $file = escapeshellarg($file);
         $filesize = self::getFilesize($file);
         if ($filesize <= 10485760) {
             return trim(
                 shell_exec("sha512sum $file | awk '{print $1}'")
             );
         }
         return trim(
             shell_exec(
                 sprintf(
                     "(%s -c %d %s; %s -c %d %s) | sha512sum | awk '{print $1}'",
                     'head',
                     10486760,
                     $file,
                     'tail',
                     10486760,
                     $file
                 )
             )
         );
     }

The function is not necessary to be in a class file. The url that gets called is: http://{nodeip}/fog/status/gethash.php

The passed data (the $file parameter) comes from the sent link: ($_POST['file']).

If you can create a file on the storage node in /path/to/web/files

mkdir -p fog/status

Create a php file named gethash.php

Add the lines:

<?php
// Delay for 50 milliseconds.
usleep(50000);
// File is passed base64 encoded, decode it here.
$debase_file = base64_decode($_POST['file']);
// We can't trust user inputs, so escape the file we will check.
$file = escapeshellarg($debase_file);
// The file doesn't exist, return blank.
if (!file_exists($file)) {
    return '';
}
// Get the filesize.
$filesize = trim(
    shell_exec("du -b $file | awk '{print $1}'")
);
// If the file is less than one meg, return the hash of the full file.
if ($filesize <= 10485760) {
    return trim(
        shell_exec("sha512sum $file | awk '{print $1}'")
    );
}
// Otherwise return the first and last meg hashed -- hashing full files takes a long time
return trim(
    shell_exec(
        sprintf(
            "(%s -c %d %s; %s -c %d %s) | sha512sum | awk '{print $1}'",
            'head',
            10486760,
            $file,
            'tail',
            10486760,
            $file
        )
    )
);

This of course assumes a few things.

FIrst:
PHP is installed on the NAS (probably is)
du is installed and available.
awk is installed and available.
sha512sum is installed and available.
head is installed and available.
tail is installed and available.

Hopefully this helps.

Sorry I posted this originally in the wrong thread, too much reading I guess.

I’ve updated the ipxe files to use be built with FTP and NFS. These files will be in 1.5.1, and are currently in the working-1.5.1 branch of github repository.

I’ve confirmed and fixed this. Just retagging the 1.5.1 branch.

@sebastian-roth It’s possible, but that can be done right in the gui.

@joshuaian What exactly was the date that it was passing. It wouldn’t matter if it was: 2018-05-13 but if the file was 2018/05/03 then it may have issues as the / represent directory separators in linux.

please update to the working branch where this is now addressed.

If you need immediate access, edit:
/etc/php/7.1/fpm/php.ini

Search for:
upload_max_filesize and replace the value 3000M
post_max_size and replace the value with 3000M

Save the file and restart php-fpm service: systemctl restart php7.1-fpm

I’m going to gues this is happening with kernel version 4.16.6? I ask because I found earlier the kernel architectures were backward. I’ve corrected this on the server, so you should be able to redownload the kernels and have success.

The search bar at the top is the search. I’m aware of what you’re talking about and this is semi intentional. 1.6 will have this addressed much more properly.

Just a show here:
https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_FTP#Credentials_.2F_Passwords

Notice it tells you everything you are saying we need to add.

I’d also like to know what Wiki page you’re referring to that we shouldn’t refer you to, as well the ‘forums’ you found the correct answer on.

I’m happy that you solved your issue, but I’m finding a hard time knowing where the issue was with the wiki (when I don’t know what wiki page you were looking at.)

@andythemayor still waiting a bit more information on a few other bugs that were reported. If you’d like to test things as well checkout the working branch and install.

Setup the TX node as a master node in its own group? Associate the image directly to that group.