This website uses Cookies. Click Accept to agree to our website's cookie use as described in our Privacy Policy. Click Preferences to customize your cookie settings.
Sign in with your Check Point UserCenter/PartnerMap account to access more great content and get a chance to win some Apple AirPods! If you don't have an account, create one now for free!
FW1 build number: This is Check Point Security Management Server R81.20 - Build 440 This is Check Point's software version R81.20 - Build 703
I've recently come across something I assume is a bug or at least a limitation of the API run-script call.
My use case is invoking a script that uploads log files ( *.log and *.adtlog ) from an MDS running R81.20 to a remote server using the rsync command. This can easily require a very long time, since daily we will need to upload several GB of data from several firewalls.
This server is a fresh install used only for testing.
I wrote two scripts, the first talks to the MDS API, the second is uploaded to the server and run using the run-script endpoint.
the relevant snippets from the first script are:
function do_login {
echo login to server
SID=$(https ${HTTPS_OPTS} POST ${checkpoint_host}/web_api/login user="$username" password="$password" session-timeout:=3600 | jq '.sid' -r)
https --offline ${HTTPS_OPTS_WITH_SESSION} ${checkpoint_host} X-chkp-sid:"$SID" Content-Type:application/json Accept:application/json
}
This is simple login logic with a session timeout of one hour, the SID is then set to the variable $HTTPS_OPTS_WITH_SESSION, which is used throughout the rest of the script.
function do_run_script () {
TASKID=$(https ${HTTPS_OPTS_WITH_SESSION} \
POST ${checkpoint_host}/web_api/run-script \
script-name=checkpoint-log-backup \
targets="$checkpoint_object_name" \
script=@${script_file} \
timeout:=3600 \
args="some_secret '$RSYNCD_ARGS_BASE64'" | \
tee script-log | \
jq --raw-output '.tasks[0]["task-id"]'
)
echo "created task: $TASKID"
while true; do
https ${HTTPS_OPTS_WITH_SESSION} POST ${checkpoint_host}/web_api/show-task \
task-id="$TASKID" details-level=full | \
jq '.tasks[0]' > out.json
status=$(cat out.json | jq --raw-output '.status')
progress=$(cat out.json | jq --raw-output '.["progress-percentage"]')
echo "$status... ${progress}%"
if [[ "$status" == "in progress" ]]; then
https ${HTTPS_OPTS_WITH_SESSION} POST ${checkpoint_host}/web_api/keepalive &> /dev/null
sleep 3
else
cat out.json | jq --from-file show_task_log.jq --raw-output
break
fi
done
}
This creates the task, takes the task_id, and then loops while the task is in progress. The timeout is set to 3600 seconds, and the API accepts it as such, however this always fails with a timeout status if the uploaded script takes more than 5 minutes to run.
This is the output of the trial runs:
$ time bash test.sh
...snipped
created task: 823d93fd-f643-4c62-b018-dd6d3fc80c07
in progress... 10%
...snipped
in progress... 10%
failed... 100%
STDOUT
Operation timed out
END STDOUT
STDERR
END STDERR
logout from server
real 5m5.171s
user 0m36.334s
sys 0m3.925s
Notice how the progress is always set to 10%. I assume that the API is calculating the progress using the timeout of 3600.
However when the 5 minute mark is reached, the status is set to timeout, even though the script continues to run in the server.
In fact I found that the upload always completes, regardless of the time it takes. This suggests that something in the API code is ignoring the timeout setting and eagerly marking the process as timed-out, but not killing it...
I've confirmed this also happens with the mgmt_cli:
Hi @Hugo_vd_Kooij, thanks for taking the time to respond,
I understand your suggestion and I also considered ansible for this, however I wanted to try the leanest possible approach first.
Usage of the API alone fits our environment perfectly, since the jobs would be triggered from our CI/CD platform, which is already tightly integrated with our daily workflows (our single pane of glass).
This would also require only HTTPS access to the boxes, whereas with ansible we will need SSH.
With ansible we would need to provision and manage more than what I currently think is reasonable for such a simple task.
The API docs clearly state a timeout script and I assume the sort of behaviour I encountered is unexpected, and this is why I posted this.
