FOG Client
Contents
The Different Installers
FOGService.msi - Windows only, and is ideal for network deployment
SmartInstaller.exe - This is the new default installer. It will work on all platforms.
Debugger.exe - Only use this when the above two are not working. This build has more detailed logs that you can use for troubleshooting or a bug report.
Installing - Windows
Prerequisites - .NET Framework version 4.0+
Installation
- May use SmartInstaller or msi. Simply download either one of them and run.
Limitations
- CUPS printers are not yet supported
Installing - Linux
Prerequisites
- Mono (latest stable build)
- xprintidle - This dependency is optional. If not installed AutoLogOut will not run. It should be available in your package manager. E.G. apt-get install xprintidle
Installing Mono Many distributions come with an out of date version of mono in their package manager. Therefore, do not attempt to install via your package manager without the below modifications
Debian 8+, Ubuntu 13.10+, and derivatives
sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 3FA7E0328081BFF6A14DA29AA6A19B38D3D831EF echo "deb http://download.mono-project.com/repo/debian wheezy main" | sudo tee /etc/apt/sources.list.d/mono-xamarin.list echo "deb http://download.mono-project.com/repo/debian wheezy-apache24-compat main" | sudo tee -a /etc/apt/sources.list.d/mono-xamarin.list sudo apt-get update sudo apt-get install mono-complete
CentOS 7, Fedora 19 (and later), and derivatives
yum install yum-utils rpm --import "http://keyserver.ubuntu.com/pks/lookup?op=get&search=0x3FA7E0328081BFF6A14DA29AA6A19B38D3D831EF" yum-config-manager --add-repo http://download.mono-project.com/repo/centos/ Yum install mono-complete
openSUSE and SLES
You can install using SUSE One-Click files:
Instructions derived from [1]
Installation
- Download SmartInstaller.exe from your FOG server and run sudo mono SmartInstaller.exe from the terminal
- When prompted for a web root, ‘’’there is no default’’’. If you do not know what to enter, put /fog
- The client will install to /opt/fog-service , and fog.log will be located at /opt/fog-service/fog.log
Limitations
- The FOG Tray is currently incompatible on all non-windows systems. Regardless of what you set during installation, it will not run.
- The follow modules / features are not yet supported
- Active Directory joining
- PrinterManager
- GreenFOG
Installing - OSX
Prerequisites
- Mono (latest stable build)
Installing Mono
- If you are running El Capitan, navigate to [2] and download Mono Universal Installer
- Otherwise, navigate to [3] and download Mono 32-bit
Installation
- Download SmartInstaller.exe from your FOG server and run sudo mono SmartInstaller.exe from the terminal
- When prompted for a web root, there is no default. If you do not know what to enter, put /fog
- The client will install to /opt/fog-service , and fog.log will be located at /opt/fog-service/fog.log
Limitations
- The FOG Tray is currently incompatible on all non-windows systems. Regardless of what you set during installation, it will not run.
- The follow modules / features are not yet supported
- PrinterManager
- GreenFOG
Additional details
Security design
Communications between the FOG Client (0.9.9+) and the FOG Server (1.3.0+) are secured with SSL.
A Certificate Authority and private key is generated on the FOG server during first installation in this location:
/opt/fog/snapins/ssl
The public certificate is generally located here:
/var/www/html/fog/management/other/ssl
The client installs your servers’ certificate and the FOG Project certificate.
The “FOG Project” CA (made by the FOG Project) serves two purposes:
- SYSTEM level services need to be digitally signed otherwise windows will throw security errors. This can also be used to ensure no tampering was done with the client files
- That certificate is used to “verify” upgrades. Lets say we release a patch for the client, the client will download the MSI from your server and check if it was signed by us. If the MSI was somehow tampered, the digital signature would no longer be valid.
Using HTTP over HTTPS has no security benefit to the client. Why? Because all traffic is already encrypted. Here’s a very basic overview of how the new client communicates
- Each client has a security token. This is used to prove to the server that the client is the actual host and not an impersonator. This token gets cycled constantly. When the client first makes contact, it encrypts its token and a proposed AES 256 key using RSA 4096 using your server’s public key. This public key is verified against the pinned server CA certificate by checking the x509 chain and fingerprints.
- If the server accepts the security token and the new AES key, all traffic from that point on is AES 256 encrypted using that securely transmitted key.
The whole point of our security model is to allow for secure communication over insecure medians. Even then, the client installation has an HTTPS option, but it serves no real security benefit.
References:
Certificate and Public Key Pinning
Transport_Layer_Protection_Cheat_Sheet
Maintain Control of hosts when building new server
Because of the security model of FOG 1.3.0 and the new client, without the proper CA and ssl certificates present on a new fog server, any currently deployed hosts with the new fog client installed will ignore the new server and not accept commands from it. This is by design.
In order to maintain control of existing hosts with existing new fog client deployments, you must copy this directories from the old server to the new server:
- /opt/fog/snapins/ssl
Copy the directory to a temporary location first. I would suggest /root/
cp -R /opt/fog/snapins/ssl /root
Then you can use scp to copy the directory (or some other method) to your new fog server:
scp -rp /opt/fog/snapins/ssl root@x.x.x.x:/root
Run this command from the old server, Where x.x.x.x is the new fog server's address.
Or, the reverse:
scp -rp root@x.x.x.x:/opt/fog/snapins/ssl /root
Run this command from the new server, where x.x.x.x is the old fog server's address.
Next, install fog. After the installation is complete, delete ssl folder the installer made, and place your old ssl (from /root that you copied) in there. the ownership should be fog:apache on redhat variants, should be fog:www-data on ubuntu. Then re-run the installer.
If you do not care about maintaining control of existing hosts with existing new fog client deployments (because there is only 1 or 2), you can recreate your CA with the -C argument during installation:
./installfog.sh -C
Note: Recreating the CA (--recreate-CA) is very strongly advised against if you have many clients deployed already, because it resets the identity of the FOG Server. This causes all fog clients to distrust the server, and will require total reinstallation of all fog clients in an environment. However, you may recreate the keys (--recreate-keys) safely.
FOG Client 0.10.0+ Installation options
msiexec /i FOGService.msi /quiet USETRAY="0" HTTPS="0" WEBADDRESS="192.168.1.X" WEBROOT="/fog" ROOTLOG="0"
Firstly, all options are optional. Here’s what they all do:
- USETRAY: defaults to "1", if "0" the tray will be hidden
- HTTPS: defaults to "0", if "1" the client will use HTTPS (not recommended)
- WEBADDRESS: defaults to "fog-server", this is the ip/dns name of your server
- WEBROOT: defaults to "/fog"
- ROOTLOG defaults to "0", if "1" the fog.log will be at C:\fog.log, otherwise %PROGRAMFILES%\FOG\fog.log
Reference: MSI Silent Install without Tray Icon
Manually reset encryption on ALL hosts
This applies to FOG 1.3.0 where the New Client is in use and for some reason you need to manually reset the encryption for all hosts.
mysql use fog UPDATE hosts SET hostPubKey="", hostSecToken="", hostSecTime="0000-00-00 00:00:00";