From the top output it does show you have a lot of apache stuff and they are all doing something since it also appears that msyql is running pretty hard too. So your system IS doing something.

What is going on at the time this snapshot was run? Were you deploying? Do you have a large campus where you have a lot of devices talking back to the fog server?

/var/log/httpd/access_log and /var/log/httpd/error_log might give insight on what is hitting your apache server.

FWIW: On my centos system the permissions are 755 and owned by fog.fog for all files and folders in /images

What does top show you? That will tell you what is consuming your clock cycles.

@Joseph-Hales said:

As the images are already compressed I’m not sure if rsync with compression would be of any benefit or might actually make copy times worse.

Testing shows that data compression “does work” but the actual amount of compression does not add any value in a WAN transfer. I took a 4.8GB captured image and gzip’d it. The resultant image was only 50MB smaller than the source image (not much to really matter). The but the other benefits of rsync would still be worth looking into for my project.

Following up on this in the AM, I now see all of the ‘files’ that were in /images/drivers on the master node now on the storage node. The FOG replicator only appears to copy just the files under the faux drivers image. What is missing now are the sub folders and files under /images/drivers (the actual driver files we push to the target just after imaging). So the idea to create a fake image kind of worked but not the way I needed it. As long as your files are located one level below the fake image folder then this is a workable solution.

Being very self centered I would like to see FOG support something like rsync to sync/manage the images folder, especially if the storage node is located across a slow WAN connection because these image files tend to be very large and we could benefit from the transmittal data compression intelligent replication such a tool could provide.

Just a contributor here:

We had a similar issue here after a trunk upgrade. The OP needs to check the Apache error log in (at least in the Redhat realm) /var/log/httpd/error_log

The OP can run the <…>/fog/management/ url to generate the blank page then immediately run this command from the linux console.

tail /var/log/httpd/error_log

That should show the OP the error that generated the blank page.

My preference would be to not do something out of band if possible. It does appear that creating a fake image with its path set to /image/drivers is choking the FOG replicator because of the sub folders, so I’m going to back out that change. Because no replication is happening because of that error.

I haven’t dug into the fog replicator code yet, but I’m wondering if rsync wouldn’t be a better method to replicate the images from the master node to the other storage nodes. Rsync would give us a few more advanced options like data compression and only syncing files that were changed than just a normal file copy.

Its a trunk build 5040.

Looking at the drivers folder. I have a combination of files and sub folders. Depending on how smart the replicator is it may not handle or traverse the sub folders.

The structure of the drivers folder is such.
/images/drivers/OptiPlex7010.zip
/images/drivers/OptiPlex7010/audio
/images/drivers/OptiPlex7010/audio/<many files and sub folders>
/images/drivers/OptiPlex7010/video/<many files and sub folders>
<…>

I suspect that the replicator was only designed to copy the image folder and one level of files below.

Rebooting the storage node appears to have started the replication /images/drivers but so far only the first file has replicated.

Looking at /opt/fog/logs/fogreplicator.log on the master node I see this error.

[10-22-15 8:19:52 pm] * shvstorage - SubProcess -> mirror: Fatal error: 500 OOPS: priv_sock_get_cmd
[10-22-15 8:21:08 pm] * shvstorage - SubProcess -> Mirroring directory drivers' [10-22-15 8:21:08 pm] * shvstorage - SubProcess -> Making directory drivers’
[10-22-15 8:21:08 pm] * shvstorage - SubProcess -> Transferring file `drivers/DN2820FYK.zip’

the zip file is the only thing in /images/drivers on the storage node.

Correction that error was on line 12 not line 1. I missed the last character when I copied the error.

Well that was interesting. Trying to force the replication by stopping and restarting the FOGImageReplicator service on the master node restarted without issue. Stopping and starting the same service on the storage node caused an error to be thrown

PHP Fatal error: Call to undefined method ImageReplicator::getBanner() in /opt/fog/service/FOGImageReplicator/FOGImageReplicator on line 1

Both the master node and storage nodes are running build 5040.

OK that sounds like a plan. I’ll set that up right away.

Do you know what the replication cycle interval is or where to find the setting? Under “normal” production once a days is sufficient, but I can see during development that we might need to shorten it to just a few hours.

I’m working on a multisite proof of concept configuration. I setup a fog storage node and everything worked great. All of the images were copied over to the storage node. I currently have the target machine drivers in /images/drivers folder and this folder was not copied to the storage node, which was kind of expected since this folder is not standard to FOG. My question is how can I add this directly to the list of directories that gets replicated between the storage nodes? Or am I going about it the wrong way. I need the target machine’s drivers replicated to all storage nodes too.

The OS is Centos 6.7. But I think what was changed works across the linux distros. The wgetrc thing is specific to wget and I know I’ve made that change on FreeBSD as well as various flavors of linux. The environment settings should also be universal.

Here is an update on this issue for those that may find the same issue.

I added the following lines to the /etc/bashrc profile script at the very bottom.

export http_proxy=http://<proxy_ip>:<proxy_port>
export https_proxy=http://<proxy_ip>:<proxy_port>

saved the file then logged out and back in. After I did that the installer script downloaded the FOGService.msi file without error and the kernel and init.xz files existed when the installer was done.

Just to restate the issue, if you have your FOG server behind a proxy server you must update the bashrc file with your proxy server settings AND wgetrc with the proxy server settings, because both commands are used to download files in FOG.

Ok looking a bit deeper into this, the link you referred to the diff file uses wget to get the kernel images and init.xz from sourceforge. Looking into the actual file commom/functions.sh it uses curl to get the files. In my install my fog server sits behind a proxy server. I’ve got the command in place in /etc/wgetrc to support proxy downloads. I’m going to have to look into what can be done for curl behind a proxy. But as a side note, I’m suspecting that’s also the reason for FOGService.msi failing to download every time during the install process.

Sorry just so I’m clear (my apologies I had several different comments in my post):

When I run the install from the local svn location that will remove the bzImage and init.xz files. But then redownload them during the update process?

If that is true, then something is broken. I can manually install the bzImages from inside the fog management console, but I have to get the init.xz images from sourceforge via wget. If this is SOP then I’m OK with it, but one would think the update/installer would put all of the bits in place for me.

After running the update from 4866 to 4876 both the boot kernels (bzImage) and init.xz have been removed. Is this an expected behavior of the upgrade process?

Running through the built in kernel upgrade process returned these two errors in the apache error log:
[Wed Oct 07 07:40:46 2015] [error] [client 192.168.1.167] PHP Warning: http_build_query(): Parameter 1 expected to be Array or Object. Incorrect value given in /var/www/html/fog/lib/fog/FOGURLRequests.class.php on line 60, referer: http://192.168.1.53/fog/management/index.php?node=about&sub=kernel&install=1&file=aHR0cHM6Ly9mb2dwcm9qZWN0Lm9yZy9rZXJuZWxzL0tlcm5lbC5Ub21FbGxpb3R0LjQuMi4yLjMy
[Wed Oct 07 07:41:07 2015] [error] [client 192.168.1.167] PHP Warning: http_build_query(): Parameter 1 expected to be Array or Object. Incorrect value given in /var/www/html/fog/lib/fog/FOGURLRequests.class.php on line 60, referer: http://192.168.1.53/fog/management/index.php?node=about&sub=kernel&install=1&file=aHR0cHM6Ly9mb2dwcm9qZWN0Lm9yZy9rZXJuZWxzL0tlcm5lbC5Ub21FbGxpb3R0LjQuMi4yLjY0

After the kernel upgrade the init.xz file was still missing. Upon the next reboot of the client this error was thrown in the apache error log:

[Wed Oct 07 07:43:07 2015] [error] [client 192.168.1.199] File does not exist: /var/www/html/fog/service/ipxe/init.xz

I can fix the missing bzImage and init.xz but is this expected behavior or should the upgrade . Neither bzImage or init.xz appear in the svn trunk.

I can also confirm that version 4866 resolved the issue.

In reviewing the Apache error logs I did see this error being generated when I try to access host information.

[Tue Oct 06 15:45:37 2015] [error] [client 192.168.1.167] PHP Warning: Invalid argument supplied for foreach() in /var/www/html/fog/lib/pages/HostManagementPage.class.php on line 403, referer: http://192.168.1.53/fog/management/index.php?node=host&sub=list

It only appears to be a problem with the host general pane, the other ones work as intended.