Automate FOG Client Install

[Joe Schmitt]

https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#FOG_Client_0.10.0.2B_Installation_Options

[Wayne Workman]

And in addition to what others have said, the FOG Client updates itself automatically when a newer copy of the FOG Client is available on your fog server, meaning that it won’t update unless you update your server. Joe posted a link to a specific point in the FOG Client article, but you might want to look over the entire article to just get your feet wet with FOG Client knowledge.

[dholtz-docbox]

In short, I was looking to capture a configuration file and supply it to the installer, similarly to how the .fogsettings file can be supplied to the servers installfog.sh script, when the -y command is passed to it, for automation. It has a settings file in /opt/fog-service, so I wasn’t sure if I could use it the same way.

I am not too concerned about getting the latest installer, as every client just does a wget on the FOG server for whatever version of the installer it has. It’s actually preferred that nothing automatically updates itself, unless it can do so independently of needing to update the other FOG services. I imagine the concerns here are obvious, if justified.

At the end of the day, I have Puppet automating the server’s installation as needed. It would be nice to have Puppet automate the client’s installation too. Which doesn’t seem possible the way I thought. What would the preferred Linux way of handling this? Can I do something similar with Mono?

And to your point, ultimately, it’s not huge. This will just aid in fresh installations more than anything, but it’s a process I would like to get out of the developers hands if possible. For the first pass, I can just manually do this and capture the image.

-Dustin

[Joe Schmitt]

@dholtz-docbox a few things:

1. I was looking to capture a configuration file and supply it to the installer, the client uses a file called settings.json to store its configuration. But with that said, it is always preferred to use the installer switches I mentioned so that the client can perform any needed schema updates and security patches.

2. It’s actually preferred that nothing automatically updates itself, unless it can do so independently of needing to update the other FOG services. I imagine the concerns here are obvious, if justified. To be blunt this does not make sense. The client is, by definition, dependent on the server. That is, if you perform a server upgrade, the server’s API may very well change and thus the client must update itself to match the new API.

3. It would be nice to have Puppet automate the client’s installation too. Which doesn’t seem possible the way I thought. Again, if you really wanted to the client is completely capable of being mass-deployed by a solution such as puppet. The smart installer has switches just like the MSI. But with that said should you disable the client’s auto updating feature and implement your own? No, absolutely not.

What updating actually does and why do we recommend using the built in updater?
The client is a single set of binaries that dynamically adapt themselves to run on any os. The client is possible due to a framework I created called Zazzles. It takes the complexities and niches of every OS and abstracts them away, providing 1 single clean API to do OS-specific tasks and also not break that OS’s security model. This means there’s a lot of complexity behind it and lot more going on than what may first appear.

The client isn’t just one process. Its a group of processes working together. You have your daemon, (what runs as SYSTEM/root), your user agents (a process spawned for each user), and other processes. They must all work in unison. Due to the complexities behind how the services runs as this cluster of processes, performing a clean updating while it’s running is something very difficult as you must coordinate all the processes to work together if you wish to avoid a reboot for a functional service. This complexity can only be overcome on any OS if Zazzles is in charge of handling the update, which it is.

You also have to worry about the security model of the client. Manual uninstalling and re-installing an installation will cause computer’s security token to get erased (this is for security reasons). The token persists through client upgrades if the client is also the one performing the upgrade.

There are many complexities to the client’s update process, and that’s why the client handles it on its own. Sure, if the client was windows only we could make it a lot simpler. But it’s not. It has to target every OS possible. Again I must ask the question. Why disregard the built in auto-updater of the client and build your own? It’s extra work for seemingly no real benefit.

[Wayne Workman]

@Joe-Schmitt said in Automate FOG Client Install:

Why disregard the built in auto-updater of the client and build your own? It’s extra work for seemingly no real benefit.

No, for negative benefit. The host’s security token being reset is not good, and completely throwing out the security model that the update process uses is not wise - as the installer authenticates the signature of any update that it would handle on it’s own.

[dholtz-docbox]

@Joe-Schmitt

Regarding point #2, I believe we are misunderstanding each other, but we are saying the same thing. What alarmed me was Wayne’s statement that the FOG Client automatically updates itself; what I missed was the one word he had in bold, where it only applies based on my server. Whoopsie…

Yes, the config.json was what I wanted the installed to use, but it ignores the file from what I can see. I am also not sure what these switches are. Is it something handled by mono, or is it just another name for a command parameter? I don’t mind passing this information along, I just didn’t think I could - so I was looking to do something similar to your other installation process.

-Dustin

[Joe Schmitt]

@dholtz-docbox I’m not sure if the smart installer switches are in the wiki yet (pinging @Wayne-Workman). The list is here:

https://news.fogproject.org/fog-client-v0-11-0-released-2/ See the SmartInstaller Switches section.

[dholtz-docbox]

PS > I might have said the wrong word, but I have no desire to overwrite any functionality in how the FOG Client does its business - why would I. I just want to make sure machines run through this process have the client installed with no manual intervention, and right now it appeared to me that the only way I could go through installing this was manually.

[Joe Schmitt]

@dholtz-docbox example usage of the switches I post a link to just now:

mono SmartInstaller.exe --server=my-fog-server --tray

[dholtz-docbox]

@Joe-Schmitt : Awesome! Thanks for linking that; it sounds like it’s all I need, if I am following everything. Let me give it a better read though.

-Dustin

[dholtz-docbox]

@Joe-Schmitt : Yeah, I was glad to see that switch was just another word for what I know as command parameters. Is “switch” the preferred verbiage here, for my own knowledge? I am but a fledgling still in the world of… everything you guys do, I guess, heh. So much more to learn…

-Dustin

[Joe Schmitt]

@dholtz-docbox switch and command parameters are just different words for the same thing. It doesn’t really matter which one you use. Some places call them switches, others installation arguments, others commands parameters.

[Wayne Workman]

There now: https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#FOG_Client_0.10.0.2B_Installation_Options

[dholtz-docbox]

Just to clarify on one piece real quick, for the options that specify to include something, like tray, do they default to “no” when using switches? I know tray isn’t used in Linux, unless that changed, so it’s moot. I was just curious since they didn’t specify defaults, if they defaulted to disabled/false/no.

Edit> I see when using MSI switches, it specifies the default and allows you to set tray and other binary settings, but does not provide a method for specifying on/off for tray and others in Linux. Is this just because they aren’t used, so it doesn’t matter one-way-or-another?

[Joe Schmitt]

@dholtz-docbox the tray defaults to off. Even if you use the -t switch, the tray still wouldn’t run on linux. All that does is tell the installer to enable the tray in the settings file. Once the client runs, it sees that it should run the tray, but it’s not compatibility with linux so it ignores the instruction. It’s one of the limitations for linux listed on the wiki.

[dholtz-docbox]

@Joe-Schmitt : Okay, that’s what I thought, regarding tray. I wasn’t sure for the other setting, https I presume. Does it default to “0” as well, unless specified via. its switch?

[Joe Schmitt]

@dholtz-docbox yes. If i switch it set, it uses that option. Otherwise it doesn’t.

[dholtz-docbox]

Awesome. Thanks for clarifying everything; sorry for being so explicit, I am multitasking a lot while trying to finalize this for our next release coming up, and it’s easier to ask some questions than trial-by-fire it myself at this moment.

-Dustin

[george1421]

@Joe-Schmitt Just to add a little more detail here.

As I posted before. I have MDT build my reference image using the lite touch process. Once the process is kicked off I don’t touch the reference image until its time for sysprep. I have the fog client installed via an application in MDT. This is the command I use to install the FOG Client.

@Echo Off
start /wait msiexec.exe /i FOGService.msi /quiet USETRAY="0" WEBADDRESS="192.168.1.53"
net stop "FogService"
sc config "FogService" start= disabled