Script upload mechanism no longer working

[grahampugh]

Hi Shea, as mentioned on Slack, I've also got this problem. I've set JSS_MIGRATED to True but it is still "copying" the script to the distribution point:

JSSImporter: Script: Carbon Copy Cloner-postinstall.sh created.
JSSImporter: Copying /Users/Me/Library/AutoPkg/RecipeOverrides/Carbon Copy Cloner-postinstall.sh to all distribution points.
JSSImporter: Copying to jamfproserver
JSSImporter: Copied /Users/Me/Library/AutoPkg/RecipeOverrides/Carbon Copy Cloner-postinstall.sh

It cannot really be copying it, because I do not have a Scripts folder. Casper Admin shows the script as "missing" and there is an empty script object in the database. I'm using the default way of setting up the JSSImporter settings.

$ defaults read com.github.autopkg
{
    "API_PASSWORD" = blahblah;
    "API_USERNAME" = AutoPkg;
    "JSS_MIGRATED" = True;
    "JSS_REPOS" =     (
                {
            name = JPShare;
            password = "blahblahblah";
        }
    );
    "JSS_URL" = "https://jamfproserver/template";
}

On further investigation, it looks like the /dbfileupload API parameter is no longer valid. Scripts appear to be uploaded using the /scripts parameter, so they need to be "uploaded" (i.e. POST/PUT) in the same way as /computerextensionattributes...kind of inconvenient, since that means you have to embed the script in the XML template, but that wouldn't be too hard to wrap in a script.

Understandably, I can see it is not very feasible for you to refactor code using an API you no longer have access to. I'm not sure I have the Python skills to refactor python-jss to change this behaviour, but I'll try to have a look.

Of course things might change again with Jamf Pro 10 - for example there is a new field in Policies for "Self Service Display Name", allowing the policy name to be something only admins need to see (although this isn't in the API yet - feature request already in).

[sheagcraig]

Hey @grahampugh thanks for the update.

Do you know which version took away the dbfileupload endpoint?

I seem to remember that the JSS didn't have an official way of reporting its version to API clients, so it's indeed hard to work around this without either using a configuration toggle, or possibly a private API call that has the JSS version.

The actual code wouldn't be that hard, since as you point out it has already been done with computerextensionattributes.

Obviously, maintaining two versions of python-jss for before and after this change is crazy too!

[sheagcraig]

FWIW, this is how it should have been done long ago! I just need to know at which JSS version it should be supported, and whether I can even determine JSS version from the client side, or whether we need to add or update the configuration stuff for python-jss. This should also be added to python-jss, since that's where the real action happens.

[grahampugh]

I haven't been able to find out when this changed - nothing obvious in the Jamf documentation. I'll ask in the jss-api channel.

[sheagcraig]

Ready for testing! (See releases page beta).