Posts made by utopia

@Wayne-Workman said

@Joe-Schmitt Yes I can, #wiki worthy.

@Wayne-Workman Here is some info I’ve gathered for consideration as a potential starting point for a Wiki article on FOG Rebranding.

Rebranding was introduced to the FOG client in version 0.11.6 of the client. It has since been improved with additional features. So to clarify, the information in this posting refers to FOG client version 0.11.12, and FOG version 1.4.0-RC-5 (dev-branch).

The following was pulled from fogproject/packages/web/commons/schema.php found at
https://github.com/FOGProject/fogproject/blob/33586365cea09444b5f35c071e72d3357462b220/packages/web/commons/schema.php
sections 240 through 243 (currently lines 3499 through 3574).
The first quote for each setting is the popup text currently displayed in the web GUI, except for
the two settingDesc quotes which are used as the GUI popup text for their respective settings.

FOG_CLIENT_BANNER_IMAGE ‘This setting defines an image for the banner on the fog client.’
settingDesc=‘This setting defines an image for the banner on the fog client. The width must be 650 pixels, and the height must be 120 pixels.’

FOG_CLIENT_BANNER_SHA ‘This setting stores the sha value of the banner to be applied.’

FOG_COMPANY_NAME ‘This setting defines the name you would like presented on the client.’

FOG_COMPANY_COLOR ‘This setting is the hex color code you want progress bar colors to display as.’

FOG_COMPANY_TOS ‘This allows setting the company terms of service.’

FOG_COMPANY_SUBNAME ‘This allows setting the company sub unit.’
settingDesc=‘This allows setting the sub unit, and is only used on the Equipment loan report for tracking.’

The following was pulled from the original announcement at https://news.fogproject.org/fog-client-v0-11-6-released/

Rebranding
This release includes the ability to rebrand the shutdown prompt. This means you can change the colors, text, and images of the prompt to match your company’s. While this feature is free, we ask that if plan on using the rebranding option please consider providing a donation https://sourceforge.net/donate/index.php?group_id=201099 .
To set these options, go to FOG Configuration -> FOG Settings -> Rebranding.
Notes:
FOG_COMPANY_COLOR: This option is a hex value of your company’s color
FOG_CLIENT_BANNER_IMAGE: This should be a PNG image with 650x120 dimensions, note that the background can be transparent. See the default banner for an example. https://github.com/FOGProject/fog-client/blob/master/resources/banner.png (fog-client/resources/banner.png).

Additional notes and info.

FOG_CLIENT_BANNER_IMAGE
This setting is used for more that just the FOG client shutdown/reboot prompt. For example, it is also used as a heading within the PDF exports of certain reports. It is NOT used to rebrand the background image during network/PXE booting (that screen continues to use the default FOG branding). As noted above, the background for the banner image can be transparent. This is an option, not a requirement. The PNG file can have any arbitrary name when uploaded into the web GUI. However, when automatically copied to the clients, the image gets renamed to “banner.png” and is saved to the clients’ program installation folder (depending upon a check-box selection during the initial client installation). On the server, uploaded files are saved in the directory /var/www/fog/management/other. One can disable the custom banner image (which returns to using the default FOG banner image) from within the web GUI via the browse button (up arrow). To do so, simply submit a blank path. The banner.png file remains on the clients even if the FOG_CLIENT_BANNER_IMAGE setting is cleared. But the remaining banner.png file will not be used by the clients unless it is enabled/resubmitted via the web GUI.

FOG_CLIENT_BANNER_SHA
This field uses the SHA512 algorithm to automatically generate and display a hash value when a banner image is uploaded via the web GUI. This field is used to detect differences between the source banner image file on the server and the copies on the clients. Upon each and every client check-in event with the server, the client recalculates the SHA512 value of its current banner.png file and compares it against the SHA512 value calculated on the server. If the hash values do not match (or if there is no banner.png file on the client), the client will download the banner image file from the server, rename it and overwrite any existing banner.png file on the client. This effectively identifies and self-corrects for cases of tampering with the banner.png file on the client, and it automatically keeps the banner image file on the clients up-to-date whenever the file gets changed on the server.

I don’t have immediate plans to use the remaining four rebranding settings. So I have not tested them, and therefore don’t have anything additional to add for them.
FOG_COMPANY_NAME
FOG_COMPANY_COLOR
FOG_COMPANY_TOS
FOG_COMPANY_SUBNAME

I hope this is useful as a potential starting point for a Wiki article on FOG Rebranding.

@Joe-Schmitt I suspected that it was the mismatch between the server’s SHA512 and the client’s SHA256 that needed correcting at https://github.com/FOGProject/fog-client/blob/master/Service/FOGSystemService.cs#L65 . I won’t be back on-site to test against my clients until later this week. But I’m sure that’s it.

Will do. I agree, not an issue for me. Thanks for letting me know.

So within the /var/log folder I should have a subfolder named php7.1-fpm. Then what should it’s ownership, permissions, and contents be if I choose to try to create it manually? Or should I just wait for a dev-branch update to do this for me?

Server

• FOG Version: 1.4.0-RC-5
• OS: Ubuntu 14.04.01 LTS

Description

The following looks like a possible typo in the fog installer/updater for chmod.

“chmod: cannot access ‘/var/log/php*fpm’: No such file or directory”

It should probably be set to “/var/log/php*fpm.log”
instead of the current string “/var/log/php*fpm”.

It’s possible this is just a remnant from when my server was updated from php5 to php7.0, since I did have problems with that as outlined in the already solved topic found at https://forums.fogproject.org/post/83191 . However, I thought I would post it anyway since it’s possible others could be affected as well, and it will apparently prevent php logging for FOG. Can anyone else confirm this error in their …/fogproject/bin/error_logs/fog_error_…log file? Or is it just me?

root@Fog01:/# date
Sat Apr 15 16:35:59 2017
root@Fog01:/# tail -5 /git/fogproject/bin/error_logs/fog_error_1.4.0-RC-5.log 
 * Exporting directories for NFS kernel daemon...
   ...done.
 * Starting NFS kernel daemon
   ...done.
chmod: cannot access ‘/var/log/php*fpm’: No such file or directory
root@Fog01:/# ls -l /var/log | grep php
-rw-------  1 root              root         0 Nov 13 13:13 php5-fpm.log
-rw-------  1 root              root       291 Nov 13 12:52 php5-fpm.log.1
... (unnecessary output removed) ...
-rw-------  1 root              root       123 Sep 13  2016 php5-fpm.log.9.gz
-rw-------  1 root              root         0 Nov 13 13:17 php7.0-fpm.log
-rw-------  1 root              root         0 Mar 24 20:14 php7.1-fpm.log

As a footnote, I just noticed that the new Snapin Log Report web page has the wrong title. It is currently showing as “FOG Imaging Log” instead of “FOG Snapin Log”.

@Tom-Elliott said:

I will try to add more “selectables” but don’t expect it like tomorrow lol.

The new 1.4.0-RC-5 multiple simultaneous “selectables” are excellent! Very useful and fast. I’ve also checked the report exports. By including additional table info in the CSV export, that really opens up possibilities for external data manipulation as well.

@Tom-Elliott said:

The table will look a little weird, probably, but the “Host Name” column will also contain the snapin task’s Start date and Complete date.
That’s all in one cell.

Truly great work on the web interface! It looks and works great. I did notice that the PDF export appears as though there is bit of extra left margin white space causing the “Create Time” info to be cut off on the right side of the page. But that is probably just due to my rather long Snapin Names. Certainly not a big deal by any means. The remaining more important info is still visible in the PDF. So it doesn’t bother me, and I wouldn’t worry about that if I were you.

This new web interface for the report significantly improves usability. It is much appreciated. And I thank you once again for the great work!

@Tom-Elliott That will do very nicely. Thank you, again!

@Tom-Elliott Awesome! So glad to hear that. And thank you so much - this will really make a difference.

@Tom-Elliott You’re so fast! I feel foolish having just spent a rediculous amount of time researching and organizing a request for this. I was waiting for the @Moderators to merge the two threads before submitting anything else. I was going to also request that the clients’ Task Completion Time (stCompleteDate from the snapinTasks table) be included, as well as perhaps a bit more in-line documentation in the /var/www/fog/lib/hooks/…hook.php file that I assume you have created for this. Is it too late to still request that? At least the Task Completion Time, the documentation is less important.

This thread is a duplicate of the previous thread found at https://forums.fogproject.org/topic/5224/checkin-date-time-and-host-name-in-snapin-log
So to help keep things tidy, can one of the @moderators please merge this thread onto the end of that prior thread.
Once that is done, I will add my two cents worth of research to try and help clarify and focus this request.

@Joe-Schmitt I’m glad to hear that you’re on top of it. I’ll be looking forward to the patch.

Also, while on this subject, do you have any plans to update the client wiki at https://wiki.fogproject.org/wiki/index.php?title=FOG_Client to reflect this new feature? I haven’t been able to find much on it since the announcement https://news.fogproject.org/fog-client-v0-11-6-released/
If so, then may I suggest:

1. Let everyone know the requirements for the FOG_CLIENT_BANNER_IMAGE / banner.png file, and
2. For the six Rebranding fields in the web gui, perhaps a little more detailed description than what is given by the mouse hovering popups or what is listed in the actual code on github?

Either way, thank you so much for your great work! I especially really appreciate your work on security and snapins.

This is a question for @Joe-Schmitt to try to clarify the operation of the FOG clients’ intended interaction with the FOG server relative to the client rebranding image file banner.png.

Joe, I have recently tested using a 650x120 pixel banner.png client rebranding image which works just fine. Thank you for adding this nice feature! However, I have noticed in the fog.log on the clients that they appear to be redownloading the banner.png file from the server upon every client check-in event whenever a banner.png file is specified in the server’s web gui. So I was wondering if this is the intended mode of operation for this feature or if it may be a bug.

First indicator - Client fog.log excerpt that repeats for every client check-in event:
4/4/2017 9:08 AM Middleware::Communication Download: http://server_IP_address_removed/fog/management/other/banner.png

Second indicator - The client’s banner.png file timestamp is continuously updated to match the timestamp of the client’s fog.log.

It seems to me that the SHA-512 checksum (which I have verified matches what is shown in the web gui) would be used not only to identify tampering with the banner.png file on the client, but also as a check to see if the file on the client matches the file on the server in order to determine whether or not redownloading the file is necessary when the client checks in with the server. Am I correct in this assumption? If so, then my observed activity would indicate a bug. If not, then perhaps this may be a potential area of improvement to help reduce unnecessary network bandwidth usage between the FOG client and server, and unnecessary file system writes on the clients.

Some additional testing environment context FYI:
FOG Server OS: Ubuntu 14.04 LTS
FOG Version: 1.3.5 (svn 6067)
FOG Client: 0.11.11
In the FOG web gui, I have only uploaded the FOG_CLIENT_BANNER_IMAGE and verified that its calculated checksum shown in FOG_CLIENT_BANNER_SHA matches the checksum I calculate for the source banner.png file. I have left the remaining four rebranding fields blank:
FOG_COMPANY_NAME
FOG_COMPANY_COLOR
FOG_COMPANY_TOS
FOG_COMPANY_SUBNAME
Also, I get the same consistent file redownloading activity regardless of whether the rebranding image is named banner.png or whether I give it another name such as MyTest_banner.png prior to uploading it. When testing an alternate name, I notice that the file gets renamed to the generic name of banner.png on the clients.
Lastly, if I clear the FOG_CLIENT_BANNER_IMAGE entry from the web gui, the generically renamed banner.png file remains on the clients. But since it is not specified anymore in the web gui, the rebranding image is then correctly NOT displayed in the clients’ shutdown/reboot prompt.

Thank you again for this useful new feature. I’m just curious to find out if it is actually working as intended in my environment.

@Tom-Elliott “apt-get install apache2 -f” fails. However, aptitude was able to untangle the dependency trees. For your reference, the attached file shows a rough summary of the steps I took to sort it out.
0_1479102893333_Fog_troubleshooting_161113d.txt

Based upon the new php 7.0, I was able to successfully upgrade FOG from RC-18 to RC-22. This gave me running FOG processes and a functional GUI with the new apache2. Then, to test it out further, I upgraded again from RC-22 to RC-23. That successfully showed that I once again get automated DB backup files created during the FOG upgrade process which now do contain data (no longer zero byte size files). There are still some stray php5 processes which try to start and get killed during server bootup - which I will look into cleaning up. And I will be monitoring this server a bit more closely over the next few upgrades to make sure it remains stable.

I do have a final related follow-up question. As the end of the attached file shows, the database backup files have different sizes depending upon whether they are created automatically during the FOG upgrade or created manually via the command line, such as “mysqldump --allow-keywords -x -v fog > fogbackup.sql”. I assume that both types of DB backup are equally useful for restoring or transferring the DB to either the same or a different FOG server - assuming of course that the target server is running the proper FOG version to match the DB backup file. Would that be a correct assumption that either method of creating the DB backup files is equally useful for restore or transfer?

Lastly, I most certainly do THANK YOU for your insight in helping sort this out. Your assistance is VERY MUCH APPRECIATED!

root@FogU1404T01:~# rm -rf /etc/apache*; apt-get purge apache2
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages were automatically installed and are no longer required:
  libntdb1 python-ntdb
Use 'apt-get autoremove' to remove them.
The following packages will be REMOVED:
  apache2* libapache2-mod-php5*
0 upgraded, 0 newly installed, 2 to remove and 3 not upgraded.
After this operation, 10.2 MB disk space will be freed.
Do you want to continue? [Y/n] y
(Reading database ... 173250 files and directories currently installed.)
Removing libapache2-mod-php5 (5.6.23+dfsg-1+deprecated+dontuse+deb.sury.org~trusty+1) ...
apache2_invoke php5 prerm: No action required
Purging configuration files for libapache2-mod-php5 (5.6.23+dfsg-1+deprecated+dontuse+deb.sury.org~trusty+1) ...
apache2_invoke php5 postrm: No action required
Removing apache2 (2.4.18-1+deb.sury.org~trusty+2) ...
/etc/init.d/apache2: 64: .: Can't open /etc/apache2/envvars
/etc/init.d/apache2: 76: .: Can't open /etc/apache2/envvars
ERROR: APACHE_PID_FILE needs to be defined in /etc/apache2/envvars
invoke-rc.d: initscript apache2, action "stop" failed.
Purging configuration files for apache2 (2.4.18-1+deb.sury.org~trusty+2) ...
dpkg: warning: while removing apache2, directory '/var/www/html' not empty so not removed
Processing triggers for man-db (2.6.7.1-1ubuntu1) ...
root@FogU1404T01:~# 

Then reran script

 * Adding needed repository....................................OK
 * Preparing Package Manager...................................OK
 * Packages to be installed:

apache2 bc build-essential cpp curl g++ gawk gcc gzip htmldoc lftp libapache2-mod-php7.0 libc6 libcurl3 m4 mysql-client mysql-server net-tools nfs-kernel-server openssh-server php7.0 php7.0-bcmath php7.0-cli php7.0-curl php7.0-fpm php7.0-gd php7.0-json php7.0-ldap php7.0-mbstring php7.0-mcrypt php7.0-mysqlnd php-gettext sysv-rc-conf tar tftpd-hpa tftp-hpa vsftpd wget xinetd zlib1g 


 * Installing package: apache2.................................Failed!

I assumed that I would touch the envvars file after the apache2 package was reinstalled, then run the installer again after that if necessary. But since the package installation fails, I can’t get that far. Do you want the two log files from this?

root@FogU1404T01:~# a2dismod envvars
ERROR: Module envvars does not exist!
root@FogU1404T01:~#

@Tom-Elliott Rerunning the installer fails with the same results as before. Restoring the snapshot and trying the steps again after killing the three old php5 running processes also fails with the same results. Here are the logs from the last attempt with no php5 processes running.
1_1479073227092_foginstall.log
0_1479073227091_fog_error_1.3.0-RC-22.log

As with the other attempts, the directory /etc/apache2 only contains the subdirectories conf-available and mods-available. /etc/apache2/envvars does not exist.

After rebooting the server I now have the FOG processes and the new php7 processes running as shown here.

root@FogU1404T01:~# ps -ef | grep php
root       1146      1  0 10:59 ?        00:00:00 php-fpm: master process (/etc/php/7.0/fpm/php-fpm.conf)
www-data   1557   1146  0 10:59 ?        00:00:00 php-fpm: pool www
www-data   1558   1146  0 10:59 ?        00:00:00 php-fpm: pool www
root       1576      1  0 10:59 ?        00:00:00 /usr/bin/php -q /opt/fog/service/FOGSnapinReplicator/FOGSnapinReplicator
root       1600      1  0 10:59 ?        00:00:00 /usr/bin/php -q /opt/fog/service/FOGTaskScheduler/FOGTaskScheduler
root       1623      1  0 10:59 ?        00:00:00 /usr/bin/php -q /opt/fog/service/FOGMulticastManager/FOGMulticastManager
root       1646      1  0 10:59 ?        00:00:00 /usr/bin/php -q /opt/fog/service/FOGImageReplicator/FOGImageReplicator
root       1670      1  0 10:59 ?        00:00:00 /usr/bin/php -q /opt/fog/service/FOGPingHosts/FOGPingHosts
root       2167   1600  0 10:59 ?        00:00:00 /usr/bin/php -q /opt/fog/service/FOGTaskScheduler/FOGTaskScheduler
root       2168   1646  0 10:59 ?        00:00:00 /usr/bin/php -q /opt/fog/service/FOGImageReplicator/FOGImageReplicator
root       2169   1670  0 10:59 ?        00:00:00 /usr/bin/php -q /opt/fog/service/FOGPingHosts/FOGPingHosts
root       2170   1576  0 10:59 ?        00:00:00 /usr/bin/php -q /opt/fog/service/FOGSnapinReplicator/FOGSnapinReplicator
root       2171   1623  0 10:59 ?        00:00:00 /usr/bin/php -q /opt/fog/service/FOGMulticastManager/FOGMulticastManager
root       3570   3526  0 11:01 pts/4    00:00:00 grep --color=auto php

But I don’t have any web GUI, obviously since the installfog.sh script never completed. So I’m going to first try rerunning the installer. And if that doesn’t work, I’ll restore my snapshot and try the steps again - this time making sure I don’t have any old php5 processes running.

@Tom-Elliott OK, this is pretty much what I was expecting. So I’ve tried those steps and it looks good up until the point where installfog.sh fails at “Stopping web service”. Here is the foginstall.log which ends with:
0_1479061190246_foginstall.log

* Setting up fog user.........................................Already setup
* Setting up fog password.....................................OK
* Stopping FOGMulticastManager Service........................OK
* Stopping FOGImageReplicator Service.........................OK
* Stopping FOGSnapinReplicator Service........................OK
* Stopping FOGScheduler Service...............................OK
* Stopping FOGPingHosts Service...............................OK
* Setting up and starting MySQL...............................OK
* Backing up user reports.....................................Done
* Stopping web service........................................Failed!

Here is the fog_error_1.3.0-RC-22.log which ends with:
0_1479061317524_fog_error_1.3.0-RC-22.log

* Stopping FOG Computer Imaging Solution: FOGScheduler
  ...done.
* Stopping FOG Computer Imaging Solution: FOGPingHosts
  ...done.
mysql stop/waiting
mysql start/running, process 25774
/etc/init.d/apache2: 64: .: Can't open /etc/apache2/envvars
/etc/init.d/apache2: 76: .: Can't open /etc/apache2/envvars
ERROR: APACHE_PID_FILE needs to be defined in /etc/apache2/envvars

/etc/apache2/envvars does not exist. Here is a listing of the /etc/apache2 directory:

root@FogU1404T01:/etc/apache2# lsa
total 24
drwxr-xr-x   4 root root  4096 Nov 13 09:53 .
drwxr-xr-x 141 root root 12288 Nov 13 10:04 ..
drwxr-xr-x   2 root root  4096 Nov 13 09:54 conf-available
drwxr-xr-x   2 root root  4096 Nov 13 09:51 mods-available
root@FogU1404T01:/etc/apache2# 

I think this may be caused by old php5 processes still running as shown here:

root@FogU1404T01:~# ps -ef | grep php
root       1717      1  0 09:26 ?        00:00:00 php-fpm: master process (/etc/php5/fpm/php-fpm.conf)
www-data   1719   1717  0 09:26 ?        00:00:00 php-fpm: pool www
www-data   1720   1717  0 09:26 ?        00:00:00 php-fpm: pool www
root      25547      1  0 10:04 ?        00:00:00 php-fpm: master process (/etc/php/7.0/fpm/php-fpm.conf)
www-data  25550  25547  0 10:04 ?        00:00:00 php-fpm: pool www
www-data  25551  25547  0 10:04 ?        00:00:00 php-fpm: pool www
root      26194   3422  0 10:28 pts/4    00:00:00 grep --color=auto php

I could restore my snapshot and try again after making sure there are no php5 processes running. What do you think?

Server

• FOG Version: 1.3.0-RC-18 (svn5991)
• OS: Ubuntu 14.04.5 LTS (running as a VMware guest)

Client

• Service Version: NA
• OS: NA

Description

I am attempting to upgrade my FOG server beyond its current RC-18 (to RC-22). While the installfog.sh script appears to run and complete as it normally does, it has resulted in two odd problems.

First, it is no longer possible to start any processes for the five FOG services (FOGSnapinReplicator, FOGScheduler, FOGMulticastManager, FOGImageReplicator, FOGPingHosts). The processes can not be started from either 1) running the installfog.sh script, 2) rebooting the OS, or 3) manual attempts to stop/start or restart the services via cli (the listing below would also show the FOG processes if they were running).

root@FogU1404T01:~# ps -ef | grep php
root      15633      1  0 15:03 ?        00:00:00 php-fpm: master process (/etc/php5/fpm/php-fpm.conf)                    
www-data  15636  15633  0 15:03 ?        00:00:00 php-fpm: pool www
www-data  15637  15633  0 15:03 ?        00:00:00 php-fpm: pool www
root      19272  19258  0 15:38 pts/14   00:00:00 grep --color=auto php

Second, I have my fogsettings config file set to enable automated DB backups during FOG upgrades. This has been working fine for many months. However, the upgrade to 1.3.0-RC-22 produces an empty (zero byte) file for the automated DB backup. I can successfully create a good DB backup manually from the cli both before and after the step which updates the DB schema. This second issue is less of a concern since I know I can work around it manually as needed. So my main focus is on the first issue.

I have attached the three files from FOG installer/updater …/bin/error_logs folder.
The foginstall.log shows that the installfog.sh script appears to have run normally.
0_1478999699458_foginstall.log

But the presence of fog_err_1.3.0-RC-22.log is new to me (I haven’t seen it prior to RC-13).
0_1478999647595_fog_err_1.3.0-RC-22.log
In particular, that log contains:

Considering dependency proxy for proxy_fcgi:
Module proxy already enabled
Module proxy_fcgi already enabled
Module setenvif already enabled
ERROR: Module php5-fpm does not exist!

Here is the file fog_error_1.3.0-RC-22.log.
0_1479000379589_fog_error_1.3.0-RC-22.log
In particular, the tail of that log ends with:

 * Starting FOG Computer Imaging Solution: FOGMulticastManager
   ...done.
 * Starting FOG Computer Imaging Solution: FOGImageReplicator
   ...done.
 * Starting FOG Computer Imaging Solution: FOGSnapinReplicator
   ...done.
 * Starting FOG Computer Imaging Solution: FOGScheduler
   ...done.
 * Starting FOG Computer Imaging Solution: FOGPingHosts
   ...done.
 * Stopping NFS kernel daemon
   ...done.
 * Unexporting directories for NFS kernel daemon...
   ...done.
 * Exporting directories for NFS kernel daemon...
   ...done.
 * Starting NFS kernel daemon
   ...done.
chmod: cannot access ‘/var/log/php*fpm’: No such file or directory

It appears that there may be a problem with the script trying to modify non-existent log files. The relevant contents of the /var/log directory listing shows the following (Which would seem to explain the chmod failure above - “No such file or directory”. Perhaps correctable by changing to /var/log/php*fpm* or /var/log/php*fpm.log ?):

-rw-r-----  1 mysql             adm         20 Oct 24 15:12 mysql.log.7.gz
-rw-------  1 root              root         0 Nov 11 15:06 php5-fpm.log
-rw-------  1 root              root       388 Nov 11 15:03 php5-fpm.log.1
-rw-------  1 root              root       111 Sep  6 06:36 php5-fpm.log.10.gz
-rw-------  1 root              root       146 Aug 31 06:45 php5-fpm.log.11.gz
-rw-------  1 root              root       124 Aug 23 06:56 php5-fpm.log.12.gz
-rw-------  1 root              root       248 Nov  1 06:45 php5-fpm.log.2.gz
-rw-------  1 root              root       137 Oct 23 14:41 php5-fpm.log.3.gz
-rw-------  1 root              root       153 Oct 18 06:38 php5-fpm.log.4.gz
-rw-------  1 root              root       166 Oct  9 17:01 php5-fpm.log.5.gz
-rw-------  1 root              root       131 Oct  3 15:18 php5-fpm.log.6.gz
-rw-------  1 root              root       111 Sep 29 06:38 php5-fpm.log.7.gz
-rw-------  1 root              root       134 Sep 21 06:34 php5-fpm.log.8.gz
-rw-------  1 root              root       123 Sep 13 06:49 php5-fpm.log.9.gz
-rw-r--r--  1 root              root     10005 Nov 11 14:28 pm-powersave.log

From what I can see, everything seems to point to php5-fpm (the PHP FastCGI Process Manager) as the potential cause of the problem. It doesn’t matter whether I try the FOG upgrade from a fully updated OS or not, or whether I try it from a snapshot prior to when I first see the fog_err_1.3.0-RC-22.log (going back to RC-13). The FOG upgrade always results in the same two problems of no startable FOG processes and an empty automated DB backup file.

So for now, I am unable to upgrade FOG. And I am stuck functioning at 1.3.0-RC-18 which I am able to get back to using VMware snapshots. I’m hoping that the info I’ve provided can help identify a solution. And I appreciate any insight and assistance in finding one.