HTTPS FOG Client - Snapin download issue?
-
Hello,
I’ve been working on upgrading our production server to FOG 1.5.8, and clients to FOGService 0.11.19. We install the server with SSL enabled and the client with the HTTPS option enabled as well. Since starting the upgrade, snapins don’t seem to be downloading correctly. This is from a log on one of the clients.
------------------------------------------------------------------------------ ---------------------------------SnapinClient--------------------------------- ------------------------------------------------------------------------------ 2/26/2020 3:16:57 PM Client-Info Client Version: 0.11.19 2/26/2020 3:16:57 PM Client-Info Client OS: Windows 2/26/2020 3:16:57 PM Client-Info Server Version: 1.5.8 2/26/2020 3:16:57 PM Middleware::Response Success 2/26/2020 3:16:57 PM SnapinClient Running snapin Chemistry 115 Folder **2/26/2020 3:16:57 PM Middleware::Communication Download: http://xx.xx.xx.xx//fog/service/snapins.file.php?mac=B8:CA:3A:8A:C4:F4&taskid=14058** 2/26/2020 3:17:18 PM Middleware::Communication ERROR: Could not download file 2/26/2020 3:17:18 PM Middleware::Communication ERROR: Unable to connect to the remote server 2/26/2020 3:17:18 PM SnapinClient C:\Program Files (x86)\FOG\tmp\CHM_115_Setup.ps1 2/26/2020 3:17:19 PM Middleware::Communication URL: https://fogserver.gvsu.edu/fog/service/snapins.checkin.php?taskid=14058&exitcode=-1&mac=B8:CA:3A:8A:C4:F4&newService&json ------------------------------------------------------------------------------
From what i’m seeing, it looks like the download of the snapin file is still done over http instead of https? That hasn’t always been the case, correct? We’ve never had 80 open to our server, and were able to do snapins before.
Thanks,
Zach -
@hancocza This is definitely a bug and obviously introduced by a change where I tried to make download of snapins work on setups with location plugin enabled: https://forums.fogproject.org/topic/13823/snapins-not-deploying-from-storage-nodes-version-1-5-7-4
Though it turns out HTTPS enabled servers were not considered thoroughly when fixing this. Sorry! I do remember seeing this issue when working on it but obviously there were other things dragging me along and I never got to finish this up.
As a quick fix you can edit
/var/www/html/fog/lib/client/snapinclient.class.php
go to line 166 or search for the string “location” to get to the right spot. Change “http” to “https” in line 166 and save.This is definitely something we need to fix. Opened an issue on github to track this: https://github.com/FOGProject/fogproject/issues/371
I will mark this topic in the forums solved. Feel free to still post here. I will update the issue on github from now on.
-
@Sebastian-Roth gotcha, thanks for the fix!
-
@Sebastian-Roth Hey Sebastian,
Quick note, I had to make an additional change to get mine to work. I’m using a custon wildcard certificate that doesn’t hold the IP of the computer as a DN. So when changing it to https, I got a “RemoteCertificateNameMismatch” error. I changed the php at that section to look like this, and use the hostname instead of the IP. Not sure if there should be a change to use the hostname instead of IP if specified in the .fogsettings file, or maybe you have a better way of doing this?
$location = sprintf( 'https://fogserver.gvsu.edu/%s', #$StorageNode->get('ip'), $StorageNode->get('webroot') );
-
@hancocza said:
maybe you have a better way of doing this?
In your case you better just comment or remove those five lines from the PHP code. The fog-client code is made to check if “url” ($location in the PHP code) is empty and defaults to the values specified in
settings.json
on the client.Not sure if there should be a change to use the hostname instead of IP if specified in the .fogsettings file
Using DNS name is adding another layer of complexity and I wouldn’t want to add that as default for every FOG user. You can run FOG without setting up proper DNS and I see this as a good default to not add another hurdle for most of our users. If you want to switch to DNS/hostname you wre welcome to do so.
If there are issues in the code that we need to fix preventing you from using the hostname instead of IP, let us know. Best to open an issue on github and point out where things are going wrong.