Update jq on the VA (-R - read raw strings, not JSON texts)

Dear SailPoint IDN team,

The jq tool installed on the VA is not behaving properly (when using the -R flag). I am not sure which version it is (jq -h reports version jq_version).

Expected ({"x":3} is parsed properly, as on my laptop/WSL, jq version 1.6):


Current (on the VA):

I need the jq tool to process the ccg.log (which doesn’t contain only JSON objects).

Best regards,
Andrei

Hi @adamian,

Please be sure you have submitted an official support ticket with our support team. This forum is a great place to gain consensus from your peers though, and learn about potential workarounds or solutions from the community in the interim.

Hi Andrei,

We do have a custom build of JQ on the VA we need for our own scripts. It’s based on an older version of JQ that may have these issues. You can easily add the latest release to the VA as follows:

wget -O ~/jq https://github.com/jqlang/jq/releases/download/jq-1.7.1/jq-linux-amd64
chmod +x ~/jq

This version won’t be part of PATH, but you can invoke it via ~/jq for your own needs.

1 Like

Hi Alex,

Yes, I’ll have to do that. We’ll also have to add the path (~, or ~/bin) to PATH in .bash_rc or .bash_profile as I don’t want to remember on which machine I can use the jq and on which not (~/jq).

One issue is that this change has to be performed on every VA, and if the jq is not updated, the error is not always visible, and you just miss logs when processing the ccg.log, so it would be nice to update the jq on all VAs.

It would also be nice to only write JSONs to ccg.log.

Best regards,
Andrei

For completion before this thread is closed, this is what I’ve received from support (in addition to a reference to Alex’s answer):

JQ tool is something that we do not own and support.

I do not recommend you modify the PATH to prefer the updated JQ over the ones pre-packaged. That is not something we support or test and will not be able to help if it breaks your VAs.

Hi @alex_derzhi , so how old is the jq that is provided by you?
And when can one expect to have an updated version?

That is not something we support or test and will not be able to help if it breaks your VAs.

What SailPoint processes run on the VA as the user sailpoint (as the path would be modified for this user, not for root)?
Taking it to the extreme, which files are we allowed to create/modify in the /home/sailpoint directory that you support and test? May one copy a log file under under another name? What about creating a folder bin and adding a binary named jq there?

I can’t speak to specifics, but this is more a case of we can’t support what we don’t test. It’s likely not going to cause issues as jq should be backwards compatible, but none-the-less we have to have this position on supportability. Adding a bin folder is fine, I think. My recommendation is to use it’s explicit path in your scripts so that you are sure you are using the downloaded version and not our included one.

As far as other files, if you rename a log file, it will keep getting written to until rotated. Renaming other files such as .env files can break the VA and prevent containers from starting. I would be careful with that. At this point, I suggest you open a Support request with more info of what you are trying to accomplish, and they will help and escalate to me if needed.