Skip to main content
Jamf Nation, hosted by Jamf, is the largest Apple IT management community in the world. Dialog with your fellow IT professionals, gain insight about Apple device deployments, share best practices and bounce ideas off each other. Join the conversation.

Increase character limit for parameters to 65535

Currently if you try to enter a value longer than 255 characters in a parameter field in a policy's script payload, the JSS will automatically cut off everything beyond the 255th character. This used to be a limitation of MySQL prior to version 5.0.3, but it no longer is. You can store up to 65535 characters in a Text data type field as described in the MySQL 5.5 Storage Requirements document: https://dev.mysql.com/doc/refman/5.5/en/storage-requirements.html

I referenced MySQL v5.5. Because at the current time that's the minimum version the JSS 9.97 requires, although it recommends v5.6. http://docs.Jamf.com/9.97/casper-suite/administrator-guide/Requirements.html

Can you please increase character limit for parameters to 65535?

Comment
Order by:

Posted: by iJake

I am so curious as to what you are using parameters for that requires so much text. Nonetheless, if the db supports so should the field.

Like

Posted: by mm2270

I was thinking the same. I'm not opposed to Jamf making this change if the newer versions of MySQL support longer text fields. Just wondering what the use cases are for needing more than 255 characters for a parameter string. Not disputing that there are valid cases for it. I'm just curious about what they are.

Like

Posted: by bpavlov

@iJake It hasn't come up, but I have a script that uses comma separated values and I can see those going over 255 in some scenarios.

Also, Jamf doesn't necessarily need to go all the way up to 65535 if that will hinder performance, but at least something higher than the current 255 limit would be great. Perhaps 2^10 (1024) or 2^11 (2048) or 2^12 (4096)?

Like

Posted: by PeterClarke

Just checking that you understand this correctly..
Think of a Table of Values - like a spreadsheet..

The 'Parameters' are equivalent to the vertical columns in the table
The rows are just that - rows in the table. (each with up to 255 values)

So up to 255 parameters has NO restriction on the number of rows..
But does restrict the number of columns to a max of 255

I would have thought that that would be plenty..
Are you sure you are not accidentally mixing up 'number of parameters' with 'number of rows' ??

It's sometimes the case that some data table may need to be read - perhaps several thousand rows long..
but usually such tables have relatively few columns..

Like

Posted: by bpavlov

@PeterClarke It's been a while since I've taken a few database classes. But I'm not asking them to create 255 parameters (or rows) (although I'm fine with them adding more parameters and have requested that here ;) ). I'm asking them to increase the number of characters in each record (each parameter) can hold. Each record has a data type and along with those data types are size limits.

A simple exercise to show you what I'm talking about. Add the following string to a JSS script parameter:
0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789ThisIsTheEnd

Notice how the last portion "sTheEnd" gets cut off? Because there's a data type limit of 255 characters is being used. Well, I could be wrong on that last part, there may be another reason, I haven't taken a look at the JSS db.

Like

Posted: by marklamont

this caught us out, we tried using the script variables to pass a list of allowed patches to our custom patching script, once it reached the limit you couldn't even display the policy correctly let alone use it.

Like

Posted: by PeterClarke

Honestly I would have thought that this was a BAD Idea…

If I wanted to pass a lot of data, I would use a data file transfer, then use a script to read the data from that.
- That would provide a solution to 'marklamont' comment above…
- passing a 'data file', could have as much contents as you like…

I am wondering what the use case scenario is for this ?
- 'Monster sized Parameters' seems more like something you might use for 'hacking'…
Enabling this might expose additional security holes ? maybe ?

Right now if you need 'lots of data' - use a 'data file', then get your script to read from that.
- in that scenario, it would make sense to use one parameter - either name of data file, or path to data file (if not fixed path).
you might use a second parameter to control the read depth if the data file were segmented e.g. use parts: 1-3
although in such scenarios I would choose to write a different data file, and read the whole file.

Like

Posted: by bpavlov

@PeterClarke That's a horrible idea and completely backwards. I got a script already. I'm not trying to push data files to a client and then read that data off a script that I've created when that shouldn't be necessary.

The great thing about parameters are its flexibility. But it's currently has limitations that shouldn't necessarily be there. The use case for this can be anything that requires you to put in more characters in the parameter field than is currently supported. A full path, a list separate by commas, etc. Scripts that make use of JSS parameters mean that the scripts can be easily re-used and/or modified without actually having to update the script itself. Makes it a lot easier to share with other techs as well if they needed to use it. And yes, a lot needs to be scripted because Jamf Pro simply does not and will never cover all the gaps in macOS management.

Like