Upstream metadata expiry breaks lockboxes?

Hello, thanks for the continued feedback on our new api!

I am a little confused what is being asked for here though. Curl doesn’t usually propagate non-200 http errors as a non-zero exit-status, which seems what you are trying to accomplish. I wouldve expected this to fail for old API as well?

For some of our internal toradex scripts we do something similar to solutions discussed here: stdout - Can I make cURL fail with an exitCode different than 0 if the HTTP status code is not 200? - Super User

For example, the OTA provisioning script does this:

function RegisterDevice() {

  echo "== Registering device (deviceID: ${DEVICE_ID}) in system, and downloading credentials."
  cd "$(mktemp -d)" || exit 1
  http_code=$(curl -s -w '%{http_code}' --max-time 30 -X POST -H "Authorization: Bearer $PROVISIONING_TOKEN" "$AUTOPROV_URL" -d "{\"device_id\": \"${DEVICE_ID}\", \"device_name\": \"${DEVICE_NAME}\"}" -o device.zip)

  if [[ ! $http_code -eq 200 ]]; then
    # if we failed, device.zip will be a text file with the errors
    echo -e "${RED}"
    echo "Failed to download token :("
    echo "HTTP ERROR ${http_code}"
    cat device.zip
    echo -e "${NC}"
    exit 1
  fi
}

Now, that being said, it’s possible i completely misunderstood your question… Our API endpoints should be responding with the proper HTTP errors (like 404 for that non-existent-endpoint, etc), if they aren’t it would be considered a bug.

Thanks for the follow-up. Sounds like I’ll have to look into this more; I was basing my comments of our prior script(s) which (it sounds like incorrectly) made that behavioural assumption. My mistake if it’s a PEBKAC error.

Ah, based on your link it appears we lost the -f argument which is satisfactory for our particular use case.

Glad we were able to help clarify.

1 Like

Hi @jeremias.tx ,

Unfortunately I need to resurrect the original issue in a different form, as we are now encountering lockboxes that again refuse to install - this time though due to the root metadata being expired. Inspection of the JSON shows the expiry of the root files isn’t being bumped out when the lockbox is created; we ended up with a lockbox built on July 10th (with an expiry of 1 year) that no longer works because the root metadata expired on August 25th of this year. Even in lockboxes built after that date, the root metadata is only ever extended by a year and not to the expiry date of the lockbox itself.

What can we do to mitigate this issue?

Regar

Hi @bw908,

We’re currently looking into this. Just to ask some clarifying questions about your situation.

First of all, when you’re talking about Lockbox creation/built could you specific what exact actions that means?

For example is “creation” defining the Lockbox on the web UI and “building” is when you download the files with TorizonCore Builder? Or do you mean something else?

Another question the team had is. Are you seeing this with completely new Lockboxes that you are defining in the web UI, or are you seeing this with old Lockboxes that you are updating, or are you seeing it with both?

Best Regards,
Jeremias

Apologies for the confusion. In our case I am using those (define/build) interchangeably, in our CI setup, we both define the lockbox (via API v2 call) and then build it in the same process.

We see this both on rebuilt lockboxes (where we bump the new expiry via the API and then rebuild it) as well as newly created ones, e.g. a new customer-facing software version which did not have a lockbox before.

Best,
~BW908

Thank you for the clarification. This was already brought to the attention of our cloud team. They’ll investigate and see if something strange is going on with regards to the expiry not being appropriately bumped for the metadata.

I’ll give an update once something is available to share.

Best Regards,
Jeremias

1 Like