Best posts made by Joe Schmitt

@ablohowiak for both your cases, it would work best (and probably quickest) if you had/made a simple CRON script that runs the appropriate SQL commands. Not every user would want/need these features, and in general we take the approach of not making assumptions of what data users need to keep.

In *nix systems putting a / infront of a path means it’s at the root. So what you were doing is this:

cd /var <-- Basically C:\var
cd /log <-- Basically C:\log

You need to enter the whole path like this :

cd  /var/log 

OR

cd /var
cd log

Please see https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#FOG_Client_with_Sysprep

@cojohnson That’s pretty straight forward. Using the tray icon would probably be the most effective yet least intrusive; for example it could have some kind of indicator color on the icon if its pending.

@zavo Thank you so much for reporting this. While working on this bug, I came across the reason why I was never able to get my v0.10 builds running on Windows! It was a problem with the authentication handshake stalling the Windows Service Controller. I’m currently re-designing how/when authentication happens in the client and will retrofit the patch onto v0.9.X shortly.

This patch will also prevent the service from killing VM network connections for the first few minutes after windows starts.

@ryan.mckenzie The lines for setupcomplete should be placed at the end (since once the restart command is issued, the script can’t do anything else).

@Scott-Adams each host has its own copy of the AD password, and each one is encrypted with AES, where the same message can have different encrypted outputs (this is because of a unique initialization vector). As for the client not working, I would need to see a log file of one of the hosts which doesn’t work to help further.

@aruhuno one more thought:

The client runs as 32 bit, so it launches a 32 bit powershell and thus registry paths are their 32 bit versions. (The same registry path run under 32 and 64 bit will sometimes be different).

I’d try setting the Snapin Run With to %WINDIR%\sysnative\windowspowershell\v1.0\powershell.exe as that will launch your script in a 64 bit process.

---

Thread about 64 bit powershell snapins: https://forums.fogproject.org/topic/11628/snapin-template-powershell-cannot-load-modules-is-this-normal

@sourcaffeine see https://news.fogproject.org/fog-client-v0-11-0-released , specifically the “PowerManagement Module” for details on power management controls.

There doesn’t seem to be much documentation on how to actually USE FOG, just mediocre documentation on how to install.

If you desire better documentation then make a post describing specifically what article could use improvement and what you feel it lacks. Our articles are improved when people point out issues with them and make suggestions. The @Developers and @Moderators all work on FOG in our free time because we want to create something that will help people. Simply saying that FOG has poor documentation does not help us further the development of FOG.

@x23piracy this has been patched in 0.11.10, which will be available in the next server RC/release.

@msi the log says Invalid Security Token Did you press Reset Encryption Data after re-installing the client like I mentioned in my prior post?

@Tom-Elliott

I am in agreement that the Client’s message should be “Running {name}” instead of “Installing {name}” as it is the most versatile.

@Asthea We currently do not have widget support, nor do we plan to for 1.3.0. What you describe would take a lot of work and put our v1.3.0 release even further away. (I do like the idea, but we don’t have the resources to devote to adding it).

Just an FYI, most software packages are already snapin compatible and don’t need to be made into self extracting archives.

For example, Java can be done by uploading the jre exe and setting “Snapin Arguments” to “/s”. Basically you want to find out the silent installation command line arguments for the software package and use that.

Just a heads up, calling recreate CA will cause all beta clients deployed to stop trusting your FOG server and will require a re-installation of the client / re-imaging.

Just a heads up, you installed the beta client.And the specific version you install won’t work with hostname changer. I’d either switch to the legacy client OR wait until I fix v0.8.0 of the beta.

@moses I would recommend using post-install scripts to modify the unattend xml, then just disable hostnamechanger all together.

Fixed in v0.8.1

Below are instructions to test my SELinux policy for FOG. This should allow your server to operate while SELinux is still enabled. If you encounter any issues while using the policy, please state exactly what you were doing when you encountered the issue.

To get the files you need, update your fogproject trunk (git pull or svn up).

Installation

yum install -y selinux-policy-devel gcc make
cd ../fogproject/SELinux
make -f /usr/share/selinux/devel/Makefile fog.pp
semodule -i fog.pp

Removal

semodule -r fog

Troubleshooting

If you get an error like the one below

make: /usr/share/selinux/devel/Makefile: No such file or directory
make: *** No rule to make target `/usr/share/selinux/devel/Makefile'.  Stop.

You should:

1. Ensure you installed SELinux development tools
2. Locate your SELinux Makefile. The installation command will look for it under /usr/share/selinux.

Go to the host on the web portal and click “Reset Encryption Data”.