Troubles with Management API

General Discussions
1

Hello,

I am facing some troubles while using the management API.

When I am getting a list of devices using the GET “/api/management/v1/inventory/devices” URL by specifying attributes it works properly instead when I am doing it specifying a MAC address.

For instance:

  • GET /devices?hostname=myhostname" works properly
  • GET /devices?mac=01%3A72%3A47%3A11%3Af0%3A0f does not return any device while it actually exists (the URL is properly encoded)

Do you have any idea of what is wrong? Does the API support the encoded double dots of the MAC address?

Regards,

2

The actual key name is going to be something like mac_eth0. You’ll need to know how your kernel enumerates the devices to filter directly. There was a bug where even using the proper mac_* name would not return anything. That is fixed in hosted but has not yet been release in an on-prem version.

3

Thanks. I know how my kernel enumerates the MAC addresses, what I wrote above was only an example, in my real case I use mac_eth0= to retrieve the device ID from the server.

So you confirm that it is not possible to get a device from the server by requesting it using “mac_something” from the current version?

4

Yes. The next release should have the bug fix.

5

@drewmoseley Was this encoding issue fixed in 1.7.1?

6

Hello @SuicidalLabRat. Welcome to Mender Hub.
It does not appear so. I verified that it is functional in 2.0.1.

7

sigh We just finished a three week change control to upgrade to 1.7.1 for this fix. :confused:

Thanks for the prompt response Drew!

8

…a couple follow up questions

  1. In server 2.0.1, is only api/…/v2 fixed, or does the v1 api also include the fix?
  2. Is server 2.0.1 fully backwards compatible with v1.7 clients. i.e. if I have 48,000 clients in the field, am I going to orphan them be deploying this fix via upgrading our server(s) from 1.7.1 -> 2.0.1?

Thanks!

9

The server is definitely backwards compatible. I tested the v1 api and it did include the fix.
@michaelatmender may know more about the specific fix in case there is a solution that can be appled on the 1.7 branch.

10

There are no further 1.7 releases planned. It’s probably possible to “cherry-pick” this fix to 1.7.x yourself but I would not recommend that (it has not been tested).

So indeed I’d suggest upgrading to 2.0.1 – or (if you’re tired of upgrading) Hosted Mender :wink:

11

If you need only this fix specifically, you can try upgrading only the inventory micro service. Mender 1.7.1 is using inventory 1.5.0, and Mender 2.0.1 is using inventory 1.6.0, so just make that update in the docker-compose.yml file in integration and restart. Like this:

diff --git a/docker-compose.yml b/docker-compose.yml
index 1ade855..7a9a32d 100644
--- a/docker-compose.yml
+++ b/docker-compose.yml
@@ -63,7 +63,7 @@ services:
     # mender-inventory
     #
     mender-inventory:
-        image: mendersoftware/inventory:1.5.0
+        image: mendersoftware/inventory:1.6.0
         extends:
             file: common.yml
             service: mender-base

I can’t guarantee that this will solve the problem, but worth a shot without a full upgrade.

12

Awesome. Thanks for the updates guys, much appreciated!