Deploying config files

[psmeltzer]

We've been running casper for 6 months or so and we're moving past basic MDM and machine imaging to more advanced use of scripts and packages to upgrade and reconfigure machines.

These forums have been great for most of my questions but there's one I really haven't found a good answer to.

We're a game developer with Web and C++ devs working on macs and one of our major software deployments is GIT clients and development environments. All of these tools require basic configuration and I'm trying to move from having users do this to dropping config files in with the packages from self service but I haven't found a method I really like.

2 Situations as I see it
A config file needed by a PKG when it runs. Such as kaspersky antivirus which has a dmg, a config file and a.sh script to chain it all together properly. For this I end up making 2 packages 1 to put the config file and script in /user/shared then the preflight script in the cached casper install policy to copy it to the install cache before the dmg is processed. It works but it makes updates and the policy list untidy with 2 policies for every install.

The other situation is deploying user config like git or .bash_profile files. Our team leads would like people to be able to go to self service and click a "package" that adds default config files into ~/ and paths bellow it which they can then customise and if they break it go back to self service and overwrite later.

In both cases what I think would be ideal is to be able to have these kinds of text files exist in the distribution point and copy them with either a script entry in self service or the preflight script in a pkg deployment policy. Each task could be a single policy and scripts and configs could be easily updated and version controlled.

Is this possible?

If not how do you guys do this. I guess it extends to license files as well.

[mm2270 · Accepted solution]

Well, that may have just been me reading between the lines in a way that was not accurate. Understood now on what you're looking for here.

Honestly, other than repacking these config files and pushing them over and over, the only other option might be to house them in a http/s sharepoint that is accessible to all clients, perhaps a separate folder on your JSS distribution point, and script copying them down by doing a curl command. That should be possible to do, but keep in mind that keeping these files in plain text accessible by any client over an http/s share is somewhat insecure. We locked down our DPs with ACLs and permissions, so that users could not discover the direct path to the Packages directory and download whatever they wanted outside of Self Service. Just something to keep in mind if you decide to look into the curl route, I don't know how sensitive any of the config files you're referring to would be, so that will be for you to judge for yourself.

Also, how often do you anticipate some of these files being changed? It may not be worth the effort if its only changed infrequently. I'm guessing the changes may be more frequent however, otherwise you probably wouldn't be asking the question.

[nessts]

Maybe I am not understanding what you are wanting to do, but lets just take something simple like Junos Pulse VPN client. I take the Package from the vendor and I add that to the JSS, then I package the configuration file and a script that will run the appropriate command to import the configuration as a postinstall in that package. When you upload Pulse you give it a priority of 10 and the configuration package a priority of 11, you add both packages to the policy, and they install in the proper order.

For your .bashrc example, create the files and directory structure the way you want it to look, put them into composer, make a DMG, check the FEU box and be done with it.

Again sounds like you have the right idea but maybe not the proper understanding of how packaging works. Once you figure that out, this should all make sense. It is a UNIX OS, you can automate and do just about anything you want.

[psmeltzer]

Over the last 6 months since we implemented the JSS I've learnt so much about how OSX is similar but yet different to debian which is where my nix skills are strongest. Currently I'm using the system you describe. Most utilities are deployed as 2 packages with policy level preflight and or postflight scripts.

It works but I feel it's untidy as it increases the maintenance complexity when you wither just want to update the product or just want to alter the config. Some of my packages like Java JDKs and JREs are now 6+ scripts and 4 packages in order to perform clean version migrations.

The other case was for apps like Kaspersky Endpoint. It has a pkg a config file and a shell script. You end up having to package the supporting files and combine them with a caching install of the vendor policy and put it all together with a postflight script based on the old CS6 Adobe examples.

It seems to me like it would be cleaner if instead of packing config files and postflight scripts into .pkg files etc they could all be in the JSS database where they could be versioned and edited easily without repackaging and just pulled down onto the client with the vendor package run and then cleaned up. I've experimented a bit with using a preflight script on the policy which uses curl to pull the script and config file off the JDS but I can't get it to work and in my current implementation with static URLs it make scripts distribution point specific which trips up our desktop guys.

What I was wondering if anyone had solved this. Maybe with a separate script / config file repo which a standard preflight script could pull from.

[nessts]

Hard to say, it sounds to me like you are over complicating things at least in my head, but its hard to know without seeing what you are doing specifically. I put the majority of my scripts into the pkg files and run them via launch daemons and I do not use the JSS script stuff for much other than self service stuff to fix things, spotlight reset, timeserver reset, rebind to AD, etc for the users and almost never in conjunction with a package install.

[mm2270]

It seems to me like it would be cleaner if instead of packing config files and postflight scripts into .pkg files etc they could all be in the JSS database where they could be versioned and edited easily without repackaging and just pulled down onto the client with the vendor package run and then cleaned up.

Uhm, why not just use the built in MDM capabilities for this then? What you described is exactly how that works once its set up. You set up APNS and push Config Profiles from the JSS.
I guess I'm not understanding why its necessary to package and install each config profile manually. This is exactly what Apple's MDM framework is for.

[nessts]

well MDM does not work for .bashrc files or non plist types of things and could possibly not work at all with 3rd party software. Heck it only mostly works with the stuff Apple supports.

[mm2270]

Well, seems like we may have a confusion of terms here then. Throughout the posts above I'm seeing "config profiles" mentioned, but it sounds like we're really talking about plists or other configuration "settings"? Is that it? That's a different story if so, and these are not actually "config profiles" And yes, true, these aren't something you'd deploy via MDM.

[psmeltzer]

In my description I used "config" and "policy". I was careful about the terminology as "configuration profiles" is very definitely apple MDM in JSS.

Apple MDM is unsuitable for the examples I'm thinking of here as they aren't plists. They are config files which are a plain text or XML text file which may or may not have a file extension but that is largely irrelevant.

Some of these like a ~.bash_profile can be deployed with DMG and FEU but then to alter them you need a repository of the originals which you then edit and repack to dmg and replace in the policies. You then either decide to replace them across the board or make them available in self service for users to opt into if they want the new version. It seems like being able to have the policy just copy that script directly from the repo would be cleaner.

The other case are config files that are a partner to the pkg install itself, the pkg expects the file to exist in the same folder it is in when it is run so that it can read it and use the contents when it creates the LaunchAgents and LaunchDaemons plist files. These are mostly security and management agents like Kaspersky antivirus or Endpoint Protector 4 which we use to control USB access across the Enterprise.

[mm2270 · Accepted solution]

Well, that may have just been me reading between the lines in a way that was not accurate. Understood now on what you're looking for here.

Honestly, other than repacking these config files and pushing them over and over, the only other option might be to house them in a http/s sharepoint that is accessible to all clients, perhaps a separate folder on your JSS distribution point, and script copying them down by doing a curl command. That should be possible to do, but keep in mind that keeping these files in plain text accessible by any client over an http/s share is somewhat insecure. We locked down our DPs with ACLs and permissions, so that users could not discover the direct path to the Packages directory and download whatever they wanted outside of Self Service. Just something to keep in mind if you decide to look into the curl route, I don't know how sensitive any of the config files you're referring to would be, so that will be for you to judge for yourself.

Also, how often do you anticipate some of these files being changed? It may not be worth the effort if its only changed infrequently. I'm guessing the changes may be more frequent however, otherwise you probably wouldn't be asking the question.

[alexjdale · Accepted solution]

Whenever I have a pkg installer that needs config files to be in the same folder during installation, I repackage the whole thing. Put the pkg and the config files into a temp folder, then have a postflight script that runs the installer command to install that pkg. Works great. I just repackaged SEP 12.1.6 via that method.

If I ever need text files in a specific location, I just use a script and echo that file out. If the config file is all text, you could put that into a JSS script and change it very easily. You can echo out a plist for a launchdaemon to /tmp and load it for one-time use, a configuration profile with variable substitution followed by a profiles installation, another script, etc. You can do some pretty cool stuff with just a script if you get creative.

[psmeltzer]

When I started this I was anticipating someone knew how to add distribution point awareness to a bash script and I'd just put files in there through casper admin and then curl them out with a preflight script.

But running an https repo with ACLs is probably the best way for exactly the reasons outline.

I think I'll try some examples of echoing the files out of preflight scripts tho certainly for EP4 and Kaspersky that might very well be the ideal way to keep everything in one place.