Deploying config files

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.

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.

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.

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.

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.

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.

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.

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.

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.