sorry for long title, and need for some background:
am migrating from self-hosted 2.4 server to a paid hosted plan, a previous test I did for this part of the migration (configuring the device to use both servers, rejecting from the old server after the mender update, and accepting on the new server) was successful
mender-client is version 2.6 (I know it is bit old, but didn’t see any bugs in Mender client | Mender documentation that would be relevant, am working on updating to something newer, but am trying to start this migration before that is ready)
If this is a bug related to the versions being old I can work around it, since after a while the device appeared as pending in hosted mender, it would just require more work for the migration since I can’t rely on checking artifact name in self-hosted mender to know what devices need to be rejected and accepted.
some relevant error messages:
root@osname:/data/mender# mender send-inventory && journalctl -fu mender-client
...
Sep 12 06:43:23 osname mender[2253]: time="2024-09-12T06:43:23Z" level=info msg="Forced wake-up from sleep"
Sep 12 06:43:23 osname mender[2253]: time="2024-09-12T06:43:23Z" level=info msg="Forcing state machine to: inventory-update"
Sep 12 06:43:23 osname mender[2253]: time="2024-09-12T06:43:23Z" level=info msg="State transition: check-wait [Idle] -> inventory-update [Sync]"
Sep 12 06:43:26 osname mender[2253]: time="2024-09-12T06:43:26Z" level=warning msg="Server \"https://mender-internal.selfhosted.com\" failed to serve request \"/api/devices/v1/inventory/device/attributes\". Attempting \"https://eu.hosted.mender.io\""
Sep 12 06:43:26 osname mender[2253]: time="2024-09-12T06:43:26Z" level=info msg="Device unauthorized; attempting reauthorization"
Sep 12 06:43:28 osname mender[2253]: time="2024-09-12T06:43:28Z" level=info msg="successfully received new authorization data"
Sep 12 06:43:28 osname mender[2253]: time="2024-09-12T06:43:28Z" level=error msg="(request_id: ): Got unexpected HTTP status when submitting to inventory 401"
Sep 12 06:43:28 osname mender[2253]: time="2024-09-12T06:43:28Z" level=warning msg="Failed to refresh inventory: failed to submit inventory data: (request_id: ): Got unexpected HTTP status when submitting to inventory 401"
Sep 12 06:43:28 osname mender[2253]: time="2024-09-12T06:43:28Z" level=info msg="State transition: inventory-update [Sync] -> check-wait [Idle]"
Sep 12 06:43:28 osname mender[2253]: time="2024-09-12T06:43:28Z" level=info msg="Executing script: Idle_Enter_01_remove-deployment-flags"
Sep 12 06:43:28 osname osname-Idle-Enter-01-remove-deployment-flags[18234]: Enter idle state
Sep 12 06:43:28 osname mender[2253]: time="2024-09-12T06:43:28Z" level=info msg="Collected output (stderr) while running script /etc/mender/scripts/Idle_Enter_01_remove-deployment-flags\nEnter idle state\n\n---------- end of script output"
I wasn’t able to find any messages in the server logs about this, and I also couldn’t find any messages in the server logs when I run the same command on another device and it succeeds. Not sure if there is a specific container I should check or some setting I need to enable for more verbose logging or something.
root@arkkios:/data/mender# curl -X POST https://mender-internal.selfhosted.com/api/devices/v1/authentication/auth_requests -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'X-MEN-Signature: string' -d '{"id_data": "{\"os_device_id\":\"3f9e2b13-e836-42e6-ad22-012a39032053\"}", "pubkey": "-----BEGIN PUBLIC KEY-----\n...\n...\n...\n...\n...\n...\n...\n-----END PUBLIC KEY-----\n"}' {"error":"signature verification failed","request_id":"8fc3f545-f6cf-49c8-a00b-a30171d5645a"}
Here I was trying to see if I could curl the api endpoing giving 401 error to get more information, but I can’t get a token for some reason. Did verify that public key I used is the same as in the ui and can be generated from the private key on the device.
Also, for confirmation that these credentials are accepted in ui:
>>> a = requests.get("https://api.selfhosted.com/mender-api/api/management/v2/devauth/devices/32eaeadd-f342-4359-85c3-ca72ff75a414", headers=headers)
>>> pprint(a.json())
{'auth_sets': [{'id': '0a0d3183-74be-4749-9d6c-9e873dfd71bc',
'identity_data': {'os_device_id': '3f9e2b13-e836-42e6-ad22-012a39032053'},
'pubkey': '-----BEGIN PUBLIC KEY-----\n'
'...\n'
'...\n'
'...\n'
'...\n'
'...\n'
'...\n'
'...\n'
'...\n'
'...\n'
'-----END PUBLIC KEY-----\n',
'status': 'accepted',
'ts': '2024-09-10T12:01:15.857Z'}],
'created_ts': '2024-09-10T12:01:15.839Z',
'decommissioning': False,
'id': '32eaeadd-f342-4359-85c3-ca72ff75a414',
'identity_data': {'os_device_id': '3f9e2b13-e836-42e6-ad22-012a39032053'},
'status': 'accepted',
'updated_ts': '2024-09-12T05:41:44.691Z'}
This is for a custom board with yocto based os. Didn’t have the same problem the first time I tried this migration, but it is possible i’ve misconfigured something since then, though there shouldn’t be any significant changes. I don’t see any configuration other than the old server url that would be relevant here anyway.
