Best posts made by Joe Schmitt

@zavo , the problem is that the server still has an active encryption session from last boot, so re-authentication is not running. I’ll push a patch in a couple days (I need to ensure it won’t accidentally denial of service the server if there are errors on the server side).

https://github.com/FOGProject/fog-client/issues/32

@techworld I also run my dev servers on nginx. Here is my upgrade-fog.sh script for CentOS:

#!/bin/bash
echo
echo ===========================================================
echo Stopping nginx
echo ===========================================================
echo

systemctl stop nginx

echo
echo ===========================================================
echo Upgrading FOG
echo ==========================================================
echo

cd /opt/fogproject
git pull
cd /opt/fogproject/bin
./installfog.sh -y

echo
echo ===========================================================
echo Reconfiguring Web Server
echo ===========================================================
echo

systemctl stop httpd
systemctl disable httpd
systemctl start nginx

echo

As you can see I leave apache (httpd) installed, but I just disable the service. As for uploading images, that is done through NFS, and not http(s) (nginx).

And the nginx configuration Tom posted is exactly what you should be using. We (and some google fu) made it together when porting our servers to nginx and it works flawlessly for us.

This is server 2012, meaning esxi treats it like windows 8. You will need to use the 3.0.1 kernel.

@george1421 Centos 6 appears to be missing some of the modules I require. I’ve been trying to hunt down the exact dependencies I’d need, or if need be, a new policy with different rules / modules.

@zavo v0.9.8 released. This should correct this issue. Can you confirm when you have a chance?

Just follow the end of my upgrade script (obviously you will need to alter it for Debian). Simply stop and disable Apache, there is no need to uninstall it.

See https://forums.fogproject.org/topic/5243/kernel-panic-with-svn-3553-and-virtual-esxi-image

@Arrowhead-IT what issues are you experiencing with including the client in the image? Its actually safer / more secure to install the client into the image rather than after imaging completes.

@Kiweegie GPO is your best bet. One msiexec to remove the old client, and then another to install the new one.

@dureal99d until 0.11.7 is released (which should be within a day), you can simply delete the Mono.Security.dll file present in the fog-service directory. Then restart the service.

@anthonyglamis Can you post the new client log with the error?

@Wayne-Workman I’ll update the policy hopefully within the week.

@mrayzies I’ll push out a patch when I get a chance.

@Omar-rodriguez please provide the fog.log file for the problematic host. It can be found in /opt/fog-server/fog.log.

@anthonyglamis I am in agreement with @Wayne-Workman. That log file you posted indicates that your image has the wrong certificates. This could have been caused by a server re-install / key re-generation after making your image. Simply updating your image with a re-installed client should fix it.

@Sebastian-Roth Tom is correct, all mac filtering is done server side. While I could certainly add basic mac format checks ultimately there is no need. Not all mac addresses are six octets long such as the one you posted. From an implementation standpoint its better to have all mac processing happen at one location; if we need to patch that filtering, we only need to update 1 line of code instead of accompanying it with an additional client release.

I have done work with analyzing interfaces and detecting which ones are backed by physical hardware and it can be done with some know-how about win32 api, network interface registry entries are structured, and windows driver conventions (I have made a proof-of-concept before that was able to filter out all virtual adapters, including TAP drivers, virtualbox, vmware, and such). This is something I may provide in 0.10.0 due to its success rate.

However, I will not provide mac format filtering as that should be left to the server. The only filtering I may add is checking if its backed by detectable physical hardware. Even then, I may provide an option to disable my analysis in case of false-positives.

v0.9.10 has been released and addresses this issue.

@PeterAxis

@Wayne-Workman provided a recommendation on upgrading to the latest version of Cent OS. That is not critiquing. Secondly, the solution to your problem was the first post on this thread, thanks to @Tom-Elliott. A bug was found in the latest release with CentOS 6, and was patched in our current RCs.

To be blunt here, providing unneeded hostility does not help. We’re a completely free open source project developed and supported by people donating their spare time because they want to help further FOGs goal. Our documentation is mostly community built; if you see an issue with it, politely report it or even request wiki write access and help fix it.

@Sebastian-Roth that registry key is perfectly fine. The reason it looks like it’s missing a backslash is because of a bug in the registry handler logging mechanism in pre-0.9.12. But even if it was missing that slash, that registry key will not affect anything of importance

@zacksiga If you’re willing to have your server run SEPermissive for a little bit, I can assist with creating a policy from the collected data, and if it works I’ll update our main repository with the new policy.