Sourcing a script library file

[thebrucecarter]

This may seem like a naive question (and probably is) but how do I do the equivalent of sourcing a bash script library from within Jamf Pro? I have a file with a few common routines that several of our scripts use, and it would be nice to keep that structure intact instead of duplicating code all over the place. Do I just package the library up and drop it someplace (right now it resides in /usr/local/bin/ND/ on our systems) and then just source it like normal from the scripts that are executed by Jamf Pro policies? I'm new at the scripting part of Jamf (although I've been doing bash scripts for a while now) and I'm not sure what the best practice here is.

[tlarkin]

You will need to deploy your code locally, or have something curl it down from jamf (which is doable but also a bit of a rube goldberg workflow with pure jamf). The big thing there is how do you version control it, and deploy your local code base. I had a feature request for local code base, but I am not seeing it on my public jamf nation profile. So, I probably filed that FR when worked at jamf and it is internal. I can ask some jamf people if they can convert it (if it still exists) and make it public.

How you do this is simple from a code perspective:

bash example

#!/bin/bash

# source file to pull in functions
source /usr/local/tlark/codebase/mycode.sh

Python you would import a module, Ruby you would import a Gem, etc, etc

That is it, once that is sourced the shell will read that entire script into memory and you can use it. I did a presentation on this at a Macbrained event back in like 2013 or something with examples of how to reuse bash code. I do not think it was filmed, but if I can find the slide deck I can share (that is a huge maybe if I still have it).

So, how do you keep machines up to date with with your most recent code base? Well you can do what I like to call ghetto version control and it is not too pretty. Basically the idea is that you will actually have two scripts stored in your JSS database. One will be the actual code base, the other one will contain a single string of the version. You will have to manually version it. Then anytime your code kicks off it can grab the dummy script and the only output you get from the file is a version string. If it doesn't match the local version you run a policy that installs it or what not. It is doable but not really great by any means.

You could scrape a version variable from your code base as an Extension Attribute, and use that to logically scope versions. Then just make a smart group that is out of date (less than current version) and make an ongoing policy that deploys the new code.

You could just package it up and deploy it, but with our version control how do you ensure that every device in your fleet is actually running the proper version of your code base? So, you would always be running a risk of some Macs running an older version of your code, or code with bugs in it. Ideally, there should be some discussion around CI/CD for this type of work, with version controls and deployment methods.

These things are a bit out of scope for jamf as a product, so there would probably be paths with other tools to deploy the code. Configuration Management and state management tools, so I am mainly commenting on your post, because I too share a lot of interest in these ideas and there is no good way for jamf to do it out of the box, and would require some decent integration into a CI/CD stack.