Provision ADU as Module Identity about iot-hub-device-update HOT 3 CLOSED

Hey Sara,

Sorry for the late response. I'll reply in order to what I see. If you have additional questions, please let me know.

No Module Identity, and instead ADU reports to device twin.

Interesting. This sometimes happens when the principal file for DU doesn't have the right settings associated with the client. The default for most tomls is to have the device provisioned with a device-id (eg top level, updates the DeviceTwin of the device not the module). Within your toml you should see the idtype field set to ["module"].

If it's not set or is set to device, then the IoT Identity Service will provision the agent as a device instead of a module.

You can read more about the configurations, settings, and options available in the IoT Identity Service here.

If you're setting the idtype already than could you post a snapshot of your principal file? We can look through it and see what we're doing wrong.

Also, I've encountered problems in the ADU logs, like 'Failed to pass connection string to DO'. However, communication between ADU and device twin seems to work as expected, and also Edge deployments and telemetry.

Unless you're using MCC then this error message doesn't apply. Within the two agents we need to share the connection strings to allow the Microsoft Connected Cache to properly pull data from its gateway. The error message could be better. We're looking into that as well.

I assume step 3 Install the Device Update package update agent. is only needed if I will use APT updates with ADU.

In our instructions this means to install the debian package built by our client. We suggest that because we take care of a lot of the setup in our debian/postinst script. It's not just for APT but installs the actual agent.

IoT Edge doesn't need to have a module deployment for the ADU Module Identity to show up.

You are correct. It should just show up as whatever you've named the device in your principal toml file. To see what the name should be look for name in the principal.

Only device connection string is relevant, even though a module identity can have its own connection string.

Indeed. The device connection string gives IotEdge access to the device so it can manage provisioning the module identity. Alternatively, you can create these manually on the IotHub, but you do not need to.

I should not enter the device connection string with AducIotAgent ' as I run ADU as a daemon. Neither do I need to add the connection string to /adu/adu-conf.txt

I think I understand this question as "I should not run /usr/bin/AducIotAgent while the systemd DeviceUpdate daemon is running". If that is correct, then yes that part is right. It'll mess with the flow from the two agents, and they could end up touching the same files.

I'm confused by "Neither do I need to add the connection string to /adu/adu-conf.txt". I think what you mean is that you don't need to include the connection string because the IoT Identity Service is handling the actual provisioning and creation of the connection string. If that is correct, then yes.

Please let me know if I misinterpreted either of these.

Also, what has to be done on the device, referring to this: If you are migrating from a device level agent to adding the agent as a Module identity on the device, remove the older agent that was communicating over the Device Twin Uninstall ADU and install it again, or something else/more, e.g. how is the device twin data cleared?

This is referring to the service side (IotHub/ADU Instance rather) Device not a client-side Device. If you have an IotEdge device that was already running deployments switching immediately to using the IoT Identity Service to provision your device can cause issues with the workflow. For instance, if the device was in the middle of a deployment you would run into errors once it did the re-boot and provisioned itself as a module-id. You shouldn't have to do anything to the agent.

Additional Questions

• Which version of the agent are you using? That has implications for the way you handle the adu-conf.txt and what goes into it. If you're still having issues we can look at the agent version to check and see how things are configured.

Another quick note. If you want to cheat and see what the adu debian file does to setup the device for IoT Identity Service provisioning you can always go look at the packages/debian/postinst script. There's a section in there that includes the default values, permission settings, and other random things that the APT package handles for you. It might be a good sanity test to compare against your current workflow if you're still having issues.

I hope that answered some of your questions. If you're still having issues feel free to post your principal file (by default this the adu.toml file but the name doesn't matter. The uid does.) and let me know which version of the agent you're using. From there we'll be able to get a solution.

Thanks,

Nic Hemstreet

Software Engineer, Device Update for IotHub

from iot-hub-device-update.

Hello Nic, hello Sara,

is there any update on this issue?

I experience a similar problem with the current release 0.8.0 of the DU agent. I also followed the guide mentioned by Sara (Device Update Agent Provisioning). I'm using a Ubuntu VM as the IoT device.

When I run the update agent manually by myself with sudo /usr/bin/AducIotAgent, it will connect to the Device Identity (Device Twin), see du-agent.manually.edge.log and du-agent.manually.log.

When I run the update-agent as an Ubuntu service, it will fail with the error [E] Failed to set DO connection string in Nested Edge scenario, result: 0 [StartupAgent], see du-agent.service.edge.log and du-agent.service.log. Other log-files in /var/log/adu are not created. The Module Identity is provisioned by the Identity Service but the ModuleTwin is actually empty (no properties set).

Furthermore, Ubuntu tries to restart the service again and again:

martin@vm:~$ sudo systemctl start adu-agent
martin@vm:~$ sudo systemctl status adu-agent
● adu-agent.service - Device Update Agent daemon.
   Loaded: loaded (/usr/lib/systemd/system/adu-agent.service; enabled; vendor preset: enabled)
   Active: activating (auto-restart) since Wed 2022-02-16 10:10:46 UTC; 4s ago
  Process: 6404 ExecStart=/usr/bin/AducIotAgent -l 0 -e (code=exited, status=0/SUCCESS)
 Main PID: 6404 (code=exited, status=0/SUCCESS)
martin@vm:~$

I have tried both:

• connecting as an IoT-Edge Enabled device
  • configuration created with sudo iotedge config mp --force -c "<connection-string>"
  • created config file (renamed from config.toml for upload): config.edge.toml.txt
  • see above log-files with infix "edge"
• connecting as non IoT-Edge Linux device
  • configuration created with sudo aziotctl config mp --force -c "<connection-string>"
  • created config file (renamed from config.toml for upload): config.toml.txt
  • see above log-files without infix "edge"

My /etc/adu/du-config.log:

{
  "schemaVersion": "1.0",
  "aduShellTrustedUsers": [
    "adu",
    "do"
  ],
  "manufacturer": "Contoso",
  "model": "Video2",
  "agents": [
    {
      "name": "IoTHubDeviceUpdate",
      "runas": "adu",
      "connectionSource": {
        "connectionType": "AIS",
        "connectionData": ""
      },
      "manufacturer": "Contoso",
      "model": "Video2"
    }
  ]
}

EDIT: And this is the content of /etc/aziot/identityd/config.d/adu.toml (uid is correct):

[[principal]]
 name="IoTHubDeviceUpdate"
 idtype=["module"]
 uid= 111

It would be very nice, if we could get this working. I can also provide more details if needed.

Martin

from iot-hub-device-update.

Closing this as it is a stale issue. Please feel free to open a new issue if you are having issues with the latest agent.

from iot-hub-device-update.