FOG Client error
-
@Junkhacker Got it, thanks for the tip! And thanks for your hard work on the project, as well as Tom.
-
@Tom Elliott “1.2.0 will NOT work with the new client.”
Now everything is clear thank you for your answer. Solved
-
@lionheart1986 I feel it must be added, 1.2.0 won’t work with the new client because the way the new client operates was only coded within the trunk versions. I want to say somewhere around SVN version 3k+ is when the new client work really got started. 2094 SVN was the release of 1.2.0.
Because of this, the new client will not work with 1.2.0 as the elements needed did not exist.
-
@Tom-Elliott said in FOG Client error:
@lionheart1986 I feel it must be added, 1.2.0 won’t work with the new client because the way the new client operates was only coded within the trunk versions. I want to say somewhere around SVN version 3k+ is when the new client work really got started. 2094 SVN was the release of 1.2.0.
Because of this, the new client will not work with 1.2.0 as the elements needed did not exist.
Okay… how about a situation I’m in. I’m on trunk and am still getting the error. Any suggestions?
-
@TreyBentley make sure you set the fog address in the installer when installing. Leave the web root as default.
Failing to have these set correctly will produce the above described error.
-
@Wayne-Workman said in FOG Client error:
@TreyBentley make sure you set the fog address in the installer when installing. Leave the web root as default.
Failing to have these set correctly will produce the above described error.
I did and I have confirmed, time and time and time again. That’s why I said something…
My current theory is Firewall on the server side. I’m testing that theory now. -
@TreyBentley the fog server address can be just an ip, or the host name of the server. This is not a web address, it’s just the server address.
-
@Wayne-Workman said in FOG Client error:
I did and I have confirmed, time and time and time again. That’s why I said something…
My current theory is Firewall on the server side. I’m testing that theory now.Theory blown. I disabled the firewall on both the server and client as well as yet again confirmed the server IP address. Still…same message. I’m open to suggestions…
-
The client uses port 80. Unless you’re blocking all web traffic it’s safe to assume no port issues. Can you post a screenshot of what you enter into the MSI? (the configuration page with the server address and webroot). I just want to double check everything is being entered properly (this is the usual suspect).
-
@Jbob
…And I’ve officially hi-jacked this thread.
-
@TreyBentley does the CA certificate reside under /opt/fog/snapins/ssl?
-
@Tom-Elliott
Seems to. I have:ls -Za /opt/fog/snapins/ssl/
drwxrwxr-x. fog apache unconfined_u:object_r:usr_t:s0 . drwxrwxr-x. fog apache unconfined_u:object_r:usr_t:s0 .. drwxrwxr-x. fog apache unconfined_u:object_r:usr_t:s0 CA -rwxrwxr-x. fog apache unconfined_u:object_r:usr_t:s0 fog.csr -rwxrwxr-x. fog apache unconfined_u:object_r:usr_t:s0 .srvprivate.key
and
ls -Za /opt/fog/snapins/ssl/CAdrwxrwxr-x. fog apache unconfined_u:object_r:usr_t:s0 . drwxrwxr-x. fog apache unconfined_u:object_r:usr_t:s0 .. -rwxrwxr-x. fog apache unconfined_u:object_r:usr_t:s0 .fogCA.key -rwxrwxr-x. fog apache unconfined_u:object_r:usr_t:s0 .fogCA.pem -rwxrwxr-x. fog apache unconfined_u:object_r:usr_t:s0 .srl
-
Is selinux running?
-
@Tom-Elliott
Not right now; I’ve ransetenforce 0
for troubleshooting purposes for this and some other issues. -
@TreyBentley Can you hit me on chat here?
-
@TreyBentley do basic network troubleshooting. Ping the server from the host. Attempt to download the ca in a browser from the host. I’m on cellular right now, you should be able to find examples in the forums.
-
@Wayne-Workman I remoted in and we found this was due to any webpage requiring ad auth to access. As that access was not granted it couldn’t download the file.