@Tom-Elliott Thank you for the info. I apologize if “new feature” was the wrong term to use. I will take a look at the FOG Project Documentation as you suggest to see if I think it may be something that I can pursue myself.
Thanks again for all your fantastic work!

@Wayne-Workman said:

DHCP responds with lease which includes next-server and boot file

I would suggest that you consider pointing out that this stage will include the response from the normal DHCP server and may possibly also include a response from a separate proxy DHCP server (if one is in use).

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.

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