Best posts made by Joe Schmitt

Snapins just let you run any file remotely. When you go to create / edit a snapin you will see several fields.
A snapin gets executed in this format:

{Snapin Run With} {Snapin Run With Arguments} {Snapin File} {Snapin Arguments}

The best way to understand this is with a couple of examples.

EXE

Let’s say you have an exe you want to run on a computer, and you normally run it like this:

MyFile.exe /foo /bar

Then you would upload MyFile.exe, set Snapin Arguments to /foo /bar and that’s it.

If you have an exe that is an installation (e.g. vlc), you will need to provide the silent installation parameters in the Snapin Arguments box.

MSI

Let’s say you want to deploy an MSI. To install an msi from the command prompt you would run

msiexec /quiet /i MyFile.msi

So to make that a snapin, upload your MSI, set Snapin Run With to msiexec and Snapin Run With Argument to /quiet /i

Batch script

Let’s say you want to deploy an batch script. To run a .bat / .cmd from the command prompt you would run

MyFile.bat

So to make that a snapin, upload your script, and that’s it.

Hopefully this helps, but if you have any more questions let me know.

@THEMCV , @Wayne-Workman one note about that batch script (or any script for that matter). I would avoid hard coding the path of the files as it can change based on your machine’s architecture. Instead use your scripting language’s command to get its directory.

For batch %~dp0 returns the script’s directory (including the last \). So to re-write wayne’s examples the commands would be:

msiexec.exe /i "%~dp0installer.msi" /quiet

copy "%~dp0your.xml" "C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\Profile\your.xml"

@george1421 the FOG client should never be set to run a domain user. The client’s security model relies on the assumption of running as SYSTEM/root. In addition if the client runs a domain user then it will not be able to rename, join, or leave a domain. Since when the client needs to temporary leave remove a machine from the domain, the client would loose all privileges.

Ultimately the client may or may not work as non-SYSTEM users, but its not something we recommend or will officially support.

For valuable snapins, I would probably start with basic cmd scripts, and then play around with silently installing some exes / msis. (For an exe installer the silent parameter is usually /s or /S).

I may be a tad bias when it comes to this, but I would recommend trying out our development builds on another vm / server. You’ll find imaging speeds are significantly faster, and there are some added security benefits. You should also check out the new beta client (my baby) which works with our development builds. It’s far more responsive than the 1.2.0 client, has quite a few security patches, and is more … ‘professional’ in areas, such as shutdown prompts and such.
(See https://wiki.fogproject.org/wiki/index.php/Upgrade_to_trunk)

https://news.fogproject.org/fog-client-v0-11-12-released

Yup. You can thank @tom-s for the name.

https://news.fogproject.org/fog-1-5-0-officially-released-and-fog-client-0-11-15-officially-released/

@Wayne-Workman no such complications are needed. When I have free time, I simply need to find the appropriate registry values to check if the license key is armed or not (no language dependencies)

@george1421 @Sebastian-Roth this is a very good conversation to be having. FOG 2.0 was looking at system uuids to identify computers, but for the reasons you stated, that wouldn’t work very well. Thinking out-loud here, maybe these points are worth considering:

• There is no 1 single we can rely on as you showed in your original post, and some derived value based on client information may be the best route to go.
• A static key derived from values may not be the best idea. Instead it should be a weighted component comprised of several fields. For example, one could think about it like so:
  • UUID: .4
  • Primary MAC: .2
  • Motherboard asset #: .2
  • Hard drive asset #: .1
  • Ram/CPU information :.1

For each field that matches, a score gets increment by that amount; the host with the highest score, and above some threshold, gets selected/matched (essentially a fuzzy search). This provides some tolerance against machine’s hardware being upgraded, or portable network adapters being used. Obviously the fields I picked were completely arbitrary and some testing may need to go into it to pick the best identifiers.

@johnomaz ,the next version should automatically remove the legacy client:
https://github.com/FOGProject/fog-client/issues/31

Starting on September 7th 2016 auto updating of the new client stopped functioning properly. There was a bug in the installer validation code which made the client believe our signed installers were not authentic, that is someone forged them. We have since developed an in-place hotfix ready for immediate use that does not require a server upgrade. You are only affected if you use trunk or a 1.3.0 release candidate.

HOW TO GET THE HOTFIX
To patch your server and resume normal auto updating functionality please simply re-run the fog server installer (installfog.sh). You do not need to upgrade your server version, simply re-run the installer. No other actions are required.

@Darrin-Enerson Now that I have some free time, here’s my 2 cents.

Snapin Notification Message

The notification message just says the snapin has finished. While I could certainly add a lookup table of all of the common return codes, why? Return codes are not global, the return codes for msiexec vs the return codes for bash/batch are completely different. Furthermore that message is showed to logged in users. In the fog.log the actual return code is logged and its also sent to the server.

Msiexec Detection

Snapins don’t just run msiexec, or even install software for that matter. The concept of snapins is to allow remote file execution, nothing more. Now a large percentage of our user bases uses that system to install software. But it’s not a software management system and isn’t intended to be one. It also targets Linux, OSX and Windows. If we were to have msiexec detection it would also demand apt-get, yum, dnf, pacman, and every other possible single-lock software system? In addition, having some halting mechanism introduces a way for a random user to render the client useless. Let’s say you have some mischief user wanting to screw up your client for some malicious reason. They could simple make an exe named msiexec and run it. Then when the client is instructed to run a snapin, the whole client becomes effectively disabled. I could certainly write prevention code for this, such as doing analysis on the detected msiexec process, but as you can see it introduces much more complexity.

TL;DR

Snapins don’t just run msiexec, or even install software for that matter. The concept of snapins is to allow remote file execution, nothing more.

@Wayne-Workman thanks for reporting, the issue has been fixed. It was caused by the anti-spam plugin being stale.

@Tony-Ayre just wanted to acknowledge that this is definitely a limitation of FOG backend that we were handed when @Tom-Elliott picked up this project. Our current rewrite addresses this problem (and most scaling problems), but it’ll be a quite a bit before FOG 2.0 is ready.

@x23piracy @fry_p Basically I finally had the time to rework how domain joining / renaming happened to only require 1 reboot to apply all the changes.

@zacadams there is no native option, but it can still be done easily using SnapinPacks. Basically SnapinPacks let you “bundle” multiple files together.

Lets say you wanted to save a file FileToSave.exe. You’d create a pack that looked like:

--> copy.bat
--> FileToSave.exe

copy.bat would be the script you tell FOG to run, and it’d simply copy the FileToSave.exe, which is in the same directory, to wherever you want on the machine.

wiki: https://wiki.fogproject.org/wiki/index.php?title=SnapinPacks

Note: You can use %~dp0 in batch scripts to get the script’s directory. This way you can avoid hard-coding paths.

@Amh PXE is definitely an insecure protocol, unfortunately it also so happens to be the standard every machine has. I am working on a new system for Windows machines to boot to FOG without PXE along with secure boot compatibility, but they won’t be available until FOG 2.0.

The best approach to remain secure is to have some network monitoring software keep an eye out for rouge dhcp/dhcp proxy servers.

@Vinay https://wiki.fogproject.org/wiki/index.php?title=FOG_Client has everything you need;
for ubuntu: https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#Debian_8.2B.2C_Ubuntu_13.10.2B.2C_and_derivatives

The client will not manage domain bindings for linux. You can use a bash script Snapin for that though.

The fact that you had to manually start it is a problem. Pinging @Tom-S for this conversation (I’ll be busy for the next several hours). As for the “Users are still logged in”, that is a checkbox in the web portal under a host/group

Specifically the “Host changes every cycle”. If disabled, it will wait for users to log off first. @Tom-Elliott perhaps we could name it something like “Wait until users are logged off” and invert it, or have some (?) hover next ot it?

This is a client issue. Long story short: you have your fog.log in the program files directory, and the client tells update helper where to log, but isn’t wrapping it in quotes. So the log file is now C:\program during updates. I won’t be able to patch it for a couple of days. But to remove it, use a snapin.

Make a batch script del the file if it exists and deploy that snapin to all hosts. It will run as SYSTEM and have the needed privilages.