First time FOG Client installation - can't authenticate with server
-
I’m having some trouble getting the FOG Client to work, and I’d be very appreciative of any help anyone here might be able to provide.
Server
FOG 1.5.0-RC-11
OS: Ubuntu 16.04Client
FOG Client 0.11.12
OS: Windows 8.1I’ve been using FOG (server only) without issue for several years now, but I recently migrated my ancient FOG 1.2.0 images and database over to a new server with a fresh install of the latest FOG trunk code. I updated because I wanted to start using the FOG client for the first time, and so much has changed with that since 1.2.0, that I figured it wasn’t even worth starting on the legacy client version.
Everything is working perfectly with the new FOG server including the new web UI, PXE booting, and image deploy & capture.
I tried installing the FOG client on a clean Win 8.1 VM to test it out and play with it, and while the installer completes without error, and after a reboot the FOG tray icon shows up as expected, I can’t seem to get the client to actually talk to the server. Here is the
fog.logfrom the client:2/1/2018 8:10 PM Main Overriding exception handling 2/1/2018 8:10 PM Main Bootstrapping Zazzles 2/1/2018 8:10 PM Controller Initialize 2/1/2018 8:10 PM Controller Start 2/1/2018 8:10 PM Service Starting service 2/1/2018 8:10 PM Bus Became bus server 2/1/2018 8:10 PM Bus Emmiting message on channel: Status 2/1/2018 8:10 PM Service Invoking early JIT compilation on needed binaries ------------------------------------------------------------------------------ --------------------------------Authentication-------------------------------- ------------------------------------------------------------------------------ 2/1/2018 8:10 PM Client-Info Version: 0.11.12 2/1/2018 8:10 PM Client-Info OS: Windows 2/1/2018 8:10 PM Middleware::Authentication Waiting for authentication timeout to pass 2/1/2018 8:10 PM Middleware::Communication Download: https://fog.redacteddomain.com/fog/management/other/ssl/srvpublic.crt 2/1/2018 8:10 PM Middleware::Communication ERROR: Could not download file 2/1/2018 8:10 PM Middleware::Communication ERROR: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. 2/1/2018 8:10 PM Middleware::Authentication ERROR: Could not authenticate 2/1/2018 8:10 PM Middleware::Authentication ERROR: The system cannot find the file specified.If I let things run for a while, the “Authentication” section starts repeating itself verbatim every minute or so as it keeps adding to the end of the log.
Taking the error message at face value, I tried manually accessing
https://fog.redacteddomain.com/fog/management/other/ssl/srvpublic.crtfrom a web browser on the client, and I was able to download the cert file without issue, so I’m at a bit of a loss as to why the client “Could not download file”.Other things I’ve tried:
- Installing with both the Smart Installer and the MSI
- Installing the client in both HTTP and HTTPS mode
- Running a packet capture on the client. There’s definitely a conversation happening between the client and server, but it’s hard to tell exactly what’s happening due to the encryption. It looks like the client is closing the TCP socket right after the server responds to the handshake. I can supply the pcap if that would be helpful.
Does anyone have any bright ideas for how I can get the FOG client working? If you need more information, please let me know, and I’ll be happy to provide it. Thanks.
-
I remoted in with @blkeller and helped fix the issue. It was with the ssl cert being assigned to the IP instead of the FQDN. There is another bug we discovered with tunnel macs, but I will post an update about that later.
-
@blkeller Going to ping @joe-schmitt so he’s aware. I’d suggest starting out by looking at the FOG server’s apache error log. On ubuntu, that should be here:
/var/log/apache2/error.logSee if you can correlate an apache error with the client log’s timestamps. -
@blkeller what error does the client provide when set for
http? Are you redirecting port 80 to port 443? Is the certificate on “https://fog.redacteddomain.com/fog/management/other/ssl/srvpublic.crt” trusted by the computer? This definitely seems to be related to the SSL cert. -
@Wayne-Workman Thanks for getting the right eyes on this problem. I also checked the Apache error log like you suggested, but it’s very, very quiet. The only messages in that log were about normal restarts of the Apache service, nothing correlated with any FOG client activity.
@Joe-Schmitt I’d agree that this definitely seems related to the SSL cert. I haven’t done any manual customization of the Apache config, but I did install FOG with
./installfog.sh -S, which I believe automatically sets up redirects from 80 to 443.I tested the client set for both HTTP and HTTPS, but the error messages were the same each time. The
fog.logfiles looked identical except for the URL starting withhttp://when the client was set to HTTP mode. A packet capture on the client set to HTTP mode showed the client receiving a 302 response from Apache saying to fetch the same page athttps://. Then the client dutifully switched over and attempted to establish a TLS session with the server, but the client “hung up” after the Server Hello just like it did when installed in its HTTPS mode.For your reference, here’s a
fog.logfrom an HTTP mode installation of the client:2/2/2018 4:55 PM Main Overriding exception handling 2/2/2018 4:55 PM Main Bootstrapping Zazzles 2/2/2018 4:55 PM Controller Initialize 2/2/2018 4:55 PM Controller Start 2/2/2018 4:55 PM Service Starting service 2/2/2018 4:56 PM Bus Became bus server 2/2/2018 4:56 PM Bus Emmiting message on channel: Status 2/2/2018 4:56 PM Service Invoking early JIT compilation on needed binaries ------------------------------------------------------------------------------ --------------------------------Authentication-------------------------------- ------------------------------------------------------------------------------ 2/2/2018 4:56 PM Client-Info Version: 0.11.12 2/2/2018 4:56 PM Client-Info OS: Windows 2/2/2018 4:56 PM Middleware::Authentication Waiting for authentication timeout to pass 2/2/2018 4:56 PM Middleware::Communication Download: http://fog.redacteddomain.com/fog/management/other/ssl/srvpublic.crt 2/2/2018 4:56 PM Middleware::Communication ERROR: Could not download file 2/2/2018 4:56 PM Middleware::Communication ERROR: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. 2/2/2018 4:56 PM Middleware::Authentication ERROR: Could not authenticate 2/2/2018 4:56 PM Middleware::Authentication ERROR: The system cannot find the file specified.I have not done anything on the client computer to manually add trust for
https://fog.redacteddomain.com/fog/management/other/ssl/srvpublic.crtexcept for the time I tested downloading this file in a browser. To do that, I told Firefox to make a temporary exception to accept FOG’s self-signed cert, but it shouldn’t have stored that exception, and Firefox keeps a private cert store from the rest of the OS anyway.Do you think there is an issue with the FOG client handling the self-signed cert that the FOG server installer generated?
-
@blkeller said in First time FOG Client installation - can’t authenticate with server:
FOG’s self-signed cert
Did you do something to setup https using the cert that the fog server installer generates?
-
@blkeller Probably best if you post your apache config here. Should be
/etc/apache2/sites-available/001-fog.confon your server. Did you modify that file or any other one in/etc/apache2? -
I remoted in with @blkeller and helped fix the issue. It was with the ssl cert being assigned to the IP instead of the FQDN. There is another bug we discovered with tunnel macs, but I will post an update about that later.
-
@joe-schmitt Thanks again for taking the time to remote in and sort out the FQDN vs. IP issue. I didn’t realize that when the FOG installer asked for the IP address for the server that a fully-qualified domain name was also acceptable and even preferable.
I just wanted to follow up here and say that I upgraded from 1.5.0-RC-11 to RC-12 and installed the new 0.11.13 FOG Client, and it seems to have solved the other problem I was having with tunnel MACs. I finally have the FOG Client talking to the server and accepting tasks, so thank you for that! Looking forward to testing it out and seeing if it can solve my organization’s configuration management problems!
One small bug report: as a quick test to see if the FOG Client would accept orders from the server, I set the auto-logout timeout to 1 minute for the host, thinking this would be a fast way to validate things. Nothing happened, and I thought things were still broken until I read in the wiki that the minimum acceptable timeout value is 5 minutes. Setting it to 5 minutes then led to the expected results.
I’d like to suggest making it not possible to set values of 1, 2, 3, or 4 in the server’s web UI if they will not be respected by the client, plus adding something to the tooltip help text mentioning the minimum of 5 minutes.Thanks again!
-
@blkeller said in First time FOG Client installation - can’t authenticate with server:
I thought things were still broken until I read in the wiki that the minimum acceptable timeout value is 5 minutes. Setting it to 5 minutes then led to the expected results.
Just be careful if you have more than 50-100 hosts checking into your fog server every 5 minutes. At that stepping rate your fog server will be busy handling fog client check-ins and not able to image machines very well.
-
@george1421 He’s referring to the autologout module, but you’re definitely not wrong.
@blkeller, duly noted. Updating the time restraints means updating the entry in SQL, not hard, and I can have that done fairly easily. Even not allowing the setting to hold on to anything less than 5 minutes isn’t too hard, though do I set it to 0 if it’s below 5? Just thoughts on how best to approach. I don’t think it should warrant an “error” to update the host because that field isn’t really necessary for normal imaging functions.
