Preauthorization on mender devauth 1.6.0

Hi!

I am using old version of Mender Server, which is self hosted. I can’t see the version information, but I am sure that devauth docker container is version 1.6.0. I think the steps mentioned here are not valid.

Here are the output from the commands I ran:

curl -H "Authorization: Bearer $JWT" -H "Content-Type: application/json" -X POST -d "{ \"identity_data\" : $DEVICE_IDENTITY_JSON_OBJECT_STRING, \"pubkey\" : \"$DEVICE_PUBLIC_KEY\" }" $MENDER_SERVER_URI/api/management/v1/devauth/devices -k

{"error":"failed to decode preauth request: device_id: non zero value required;auth_set_id: non zero value required;id_data: non zero value required","request_id":"3bddad18-9b34-4729-b496-724139a93e29"}

When I use:

curl -H "Authorization: Bearer $JWT" -H "Content-Type: application/json" -X GET $MENDER_SERVER_URI/api/management/v1/devauth/devices -k | jq .

I get devices in this particular format, which deviates from https://docs.mender.io/1.6/apis/management-apis/device-admission#example-http-response-1

  {
    "id": "",
    "id_data": "{\"mac\":\"\"}",
    "decommissioning": false,
    "created_ts": "",
    "updated_ts": "",
    "auth_sets": [
      {
        "id": "",
        "id_data": "{\"mac\":\"\"}",
        "pubkey": "-----BEGIN PUBLIC KEY-----\n-----END PUBLIC KEY-----\n",
        "ts": "2019-09-05T16:35:15.057Z",
        "status": "rejected"
      }
    ]
  }

After that, I deleted a device using ${id} property - as mentioned here.

This is what mender client shows on the device:

Sep 10 00:54:39 dev_x mender[499]: time="2020-09-10T00:54:39Z" level=error msg="authorize failed: transient error: authorization request failed: (request_id: ): authentication request rejected server error message: dev auth: unauthorized" module=state
Sep 10 00:54:39 dev_x mender[499]: time="2020-09-10T00:54:39Z" level=info msg="State transition: authorize [Sync] -> authorize-wait [Idle]" module=mender

Now, when I check for that particular device I see this message (which is expected):

curl -H "Authorization: Bearer $JWT" -H "Content-Type: application/json" -X GET $MENDER_SERVER_URI/api/management/v1/devauth/devices/$ID -k | jq .
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100    80  100    80    0     0    316      0 --:--:-- --:--:-- --:--:--   316
{
  "error": "device not found",
  "request_id": "eca9936c-9f69-4bbd-a7a4-2f280b580226"
}

For preauthorizing, I would assume that I will have to do Submit a preauthorized device authentication data set which returns -

curl -H "Authorization: Bearer $JWT" -H "Content-Type: application/json" -X POST -d "{ \"device_identity\" : $DEVICE_IDENTITY_JSON_OBJECT_STRING, \"key\" : \"$DEVICE_PUBLIC_KEY\" }" $MENDER_SERVER_URI/api/management/v1/devauth/devices -k
{"error":"failed to decode preauth request: device_id: non zero value required;auth_set_id: non zero value required;id_data: non zero value required;pubkey: non zero value required","request_id":"a7e44d9a-86ee-44e7-8e7f-437eb11dc6d0"}

When I try to preauthorize from the UI, the UI gives error saying - A preauthorization with a matching identity data set already exists

Using Update the admission status of a selected device gives -

curl -X PUT -H 'Accept: application/json' -H 'Content-Type: application/json' -H "Authorization: Bearer $JWT" $MENDER_SERVER_URI/api/management/v1/devauth/devices/$ID/status -k --data '{"status":"accepted"}'
{"error":"Resource not found"

I am unsure about how to preauthorize after encountering the above mentioned response. I would love some help with preauthorization, and clarification on documentation.

1 Like

deviceauth = 1.6.0 should be Mender 1.6.0 as well. Unfortunately 1.6 is an ancient version so the incentive to debug this is not high.

Maybe @peter or @tranchitella can provide some insights still.

@atharvanan1 I’m sorry, but this version is very old, and debugging it via Mender hub comments is not really practical. I know this is not the answer you are happy to receive, but you should really upgrade to a newer version.

Thank you @mirzak and @tranchitella. You are right this is not the answer we were looking for but we understand and agree we need to get the environment upgraded.

When I look at the upgrading instructions for 1.6 one of the first steps is cleaning up the devauth database, however the link to the corresponding mender server troubleshooting page is broken. I fear upgrading from a version this old is likely to also have issues and would appreciate any suggestions about how to approach this.

We are inheriting this setup and would like to move to hosted mender instead to avoid problems like this going forward. I see a recent thread here discussing the multi step update required for devices. If I understand correctly, the idea is to re-authorize (or pre-authorize) devices on the hosted server as opposed to any kind of database migration. Is that correct?

You should actually be looking at Upgrading | Mender documentation, since you are already at version 1.6. There the links seem to be correct.

Also we only test one upgrade path, so to have the least resistant the recommended would be to do:

1.6 -> 1.7 -> 1.8 -> 2.0 -> 2.1 -> 2.2 -> 2.3 -> 2.4 ...

Almost not worth to do this, and the better alternatives are probably:

  • Setup a new server based on 2.4 and migrate devices there.
  • Migrate to https://hosted.mender.io (which you are considering already)

If I understand correctly, the idea is to re-authorize (or pre-authorize) devices on the hosted server as opposed to any kind of database migration. Is that correct?

That is correct. I hope that we can streamline the migration between server some day, but for now the focus has been to have the possibility on the client to switch servers. So you would generally start with a fresh server environment and just pre-authorize the devices.

I believe that we can also help out with migrating data (if required) on a case-by-case base, but there probably needs to be a commercial incentive for this as it would be manual labor.

2 Likes