Best posts made by utopia

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