File Injection (possibly through Snapin management)
It would be extremely nice to be able to inject files from FOG. One particular instance this would be useful would be injecting a config file. FOG installs our Cisco Anyconnect client just fine, but we have a preset config file it uses. The script I wrote doesn’t seem to want to work copying a file from the server to the local machine without throwing a fit.
I could include it on the local image, but I’m trying to keep all the components modular from the base OS image so they can be installed when needed and on reimaging, updated.
It would be nice to have one day and maybe there’s a better way to try to do what I’m thinking.
@Wayne-Workman My point isn’t about people’s “mentalities” just rather the direct facts.
People who are working to create a postdownloadscript that would like logging to be included in some form should be thinking of these things. They’re ultimately in full control of the process, which would also include logging/reporting if that’s what they so need.
While you’re correct that snapins and snapinpacks have the “logging” built in, that’s not to say a postdownload script cannot. The idea of postdownload scripts is to give the person creating it FULL control. What you do with it is completely up to YOU. How you approach logging is up to you. What that script will do is up to, you guessed it, YOU.
Just because it’s not something others may be thinking about does not mean it’s a failure in the “system” itself.
@Tom-Elliott Not everyone is of the mentality to write their own. Snapins have viewable status via the web interface already and have logs on each host already. It’s not wrong to point out this difference, and it’s not wrong to choose snapins because of this difference.
@Tom-Elliott this is exactly what i do which is why i caused confusion when posting code regarding injecting drivers with “/fog” directory throwing ppl off lol. postdownloadscripts are only limited to your imagination, i honestly believe it’s very under-utilized. i even use it to update the snapin state to give a detailed progress of where it is at (using snapintaskstate plugin too) as i have one snapin script for all our builds, each snapin definition just has an argument set so the script knows what software to install, settings to set etc… essentially i only have to manage one image and one snapin otherwise if i had a snapin per software i’d be managing 100’s potentially 1000’s! although i guess this is where snapin packs comes in to play! i’d already got this setup before snapin packs where introduced. Can see the appeal to snapin packs and how useful they can be but rely on having the fog client and if you don’t use fog to manage existing systems can be the only downfall i guess.
@Wayne-Workman I don’t understand the “there are not integrated logs for postdownloadscripts”.
If you need them logged, you can write them. The whole basis of postdownload scripts is you can do what you need to. The only issue (which you can fix by modifying your exports file) is there isn’t a central place to store logs, though I don’t know that this would be needed. If you’re inserting files, you can create a log directly on the system using the postdownloadscripts.
@Wayne-Workman Yes I did. FOG gets better every day I swear. I got stuck on the CiscoVPN client (legacy), but that was my fault. Parsing problem for .msi
Yeah, that’s what’s really useful for me.
All of the users hate the word imaging here, so I’m trying to change that by doing a per department automated install for them so they can have all their apps back how they want them and their downtime is minimal.
Slowly but surely.
@THEMCV So, you were able to get snapinpacks to deploy and configure cisco anyconnect for you huh? Fast, isn’t it?
Not to discredit what Tom and Lee said, but there are not integrated logs for postdownloadscripts. With snapins and snapinpacks there are. And also you can see the queued item in the web interface and see if it’s running and if it disappears or not when it ought to be done.
@Wayne-Workman It’s not too bad how it is. Regardless of the name you really just need to read it a few times and then it clicks.
I’m going to update the wiki to give more examples - sometime next week on a week night. I’ll also try to re-write and simplify what’s already there. I probably didn’t choose the best example names (abc def ghi). I’ll use alpha bravo charlie delta instead.
Thank you all so much for your help. It works! And it works well! I have a lot of apps to do this with, but it’ll be worth it in the end.
Fully modular images by department with a tiny base image here I come.
If anyconnect is already installed, a postdownload script could be VERY simple to add, just parse searching for the folder, if it exists, place the config file and be done.
Of course this would be the route I personally would go only because I would absolutely know the program is present and existing on the systems that receive the file.
The snapin/snapinpack route would work, but what happens if there’s a problem with installing within windows? (Just my thoughts).
I genuinely like the collaboration on this thread though. It gives very useful information and shows how one can accomplish any number of things with potentially different approaches.
@Joe-Schmitt Even more universal, you can replace C: with %SystemDrive% so that if the drive letter of the windows partition is not C for some reason, it can still do it’s thing.
copy "%~dp0your.xml" "C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\Profile\your.xml"
copy "%~dp0your.xml" "%SystemDrive%\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\Profile\your.xml"
@Joe-Schmitt Your recommendations are consistent with other deployment tools too. That way the package writer doesn’t need to know the absolute path of the source files during deployment.
@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.
%~dp0returns 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"
@Wayne-Workman You are the absolute best. This looks perfect and totally doable for multiple packages.
Thanks so much! I’ll give this a whirl and let you know.
@THEMCV I would have the snapinpack both install the software and then place the file too. This way the two are together, and one is always coming before the other.
Where fog dumps the files - it was quite confusing to me until I understood it. The wiki article SnapinPacks “SnapinPacks are Compressed” section explains it very throughly.
So if you name the snapinpack in the FOG web interface
ciscoanyconnect, and the zip file does not contain yet another folder in it but just contains these three files:
- .xml file
- .bat file <-- more about this in a minute.
You’d upload the snapinpack to the web interface as a snapin pack (this is illustrated in the wiki). When it’s deployed, these files are moved from the FOG server to the host, and then extracted to this path:
C:\Program Files (x86)\FOG\tmp\ciscoanyconnect\your.bat
C:\Program Files (x86)\FOG\tmp\ciscoanyconnect\your.xml
C:\Program Files (x86)\FOG\tmp\ciscoanyconnect\installer.msior whatever it is
Now, from this point, after the copy finishes, the FOG Client initiates the .bat file (but it could initiate any executable, like a powershell script or a exe or .sh or whatever).
The .bat file must make all the correct calls to do everything necessary. For example, running a msi correctly in this situation might be:
msiexec.exe /i "C:\Program Files (x86)\FOG\tmp\ciscoanyconnect\installer.msi" /quiet
After this, and according to the info you gave below, the copy line would come last in the script, and may look something like this:
copy "C:\Program Files (x86)\FOG\tmp\ciscoanyconnect\your.xml" "C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\Profile\your.xml"
Note the quotes around the paths, thats because they has spaces in them.
Now, when you’re zipping this stuff up, and then uploading it to the web interface, you will need to specify that the SnapinPack is going to run a bat file, and then you need to put that bat file’s name in with the settings.
Watch the “very through” video if you have time, all this stuff is explained there:
@Wayne-Workman So we have our Anyconnect client that FOG installs with no issue. The problem I’m having is getting the file into the location from the server.
The file I need is on \\server\subfolder\FOG_VPN_Files and it’s an .XML file that needs to go into C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\Profile
I tried having a script mount \\server as a Z: drive, but the copying process proved unreliable and didn’t ever seem to work well. I don’t really want to be mapping drives if I don’t need to.
The snapinpack could work. Where does the FOG client drop the files to?
@Lee-Rowlett I’ll check into that snapcheck.php. These are fresh installs with no programs besides Office installed, so it could definitely work fine. The config files just need to be put in place and the vpnagent service needs to be restarted too.
The one idea I had was to just keep the config file on the image and have a script copy it over, but I’d like to be able to deploy and keep an updated version on the server for these sort of things if possible.
Without using any shares, this is possible with FOG SnapinPacks. Here’s the article on snapinpacks: https://wiki.fogproject.org/wiki/index.php?title=SnapinPacks
To summarize snapinpacks, you zip up the files you need along with an executable (like a script) and then upload that .zip file as a snapinpack. The snapin pack would then get deployed and the fog client would extract it and run the executable.
To give more specific help, I’d need more specific details. Like:
- What files?
- Where are they going?
your config copy scenario you could do with postscripts using snapcheck.php and the concept would be: if cisco anyconnect client snapin is queued to be installed on the pc, copy config" that way if you need to update config file, just copy new version to server and next time cisco anyconnect client is installed so will the new config.
however if you’re looking to use fog + fog client to update existing config files you’ll need to write a script/snapin
i use postscripts + setupcomplete.cmd for our builds solely on the basis we have another system that manages deployed machines and fog to build and the setupcomplete.cmd purely for the fact it runs interactively outside a profile as we have unattended builds remotely and that way can have a “progress” indication without having to have an admin profile potentially accessible…
but i highly highly recommend the FOG Client as the developer works hard on getting it to be awesome, which it is and fits the build for practically every environment!
@THEMCV I’m not the person to talk to about snapins, I don’t personally use them calling @Wayne-Workman But, I do understand the concepts. In that you can create a snapin that is a batch file and add in your config file. Your batch file would just copy the config file to the proper location then exit. If you used a snapin to install your application, have that snapin call a batch file that first installs your application and then copies the file and save the step of having to deploy a second snapin.
We use PDQ Deploy for this and not FOG snapins but the concept is the same.