Open niravart7383 opened 3 years ago
@niravart7383 Can you confirm that your iotedged version matches your edgeAgent. Run iotedge version
@niravart7383 Can you confirm that your iotedged version matches your edgeAgent. Run
iotedge version
Yes, it matches exactly
Hey @niravart7383, sorry for the delay. I can confirm that this is expected behavior. This is because restarting triggers the deprovisioning flow, which for DPS with TPM results in a new identity.
If you want to avoid this, you can set always_reprovision_on_startup
to false: https://github.com/Azure/iotedge/blob/d2c331d605a846911019364a31a7d098e1e2fc45/edgelet/iotedge/test-files/config/dps-tpm/old-config.yaml#L8
If you update to the LTS 1.1.x, the field is now AutoReprovisioningMode
, and can be set to Dynamic, AlwaysOnStartup, and OnErrorOnly.
Hi
I will check the same and let you know. Will it stop reprovisioning also during startup if the flag will be false? If it really stops reprovisioning then there may be a security threat as we are not reaching to DPS anymore during startup
Isn't it?
Hey @niravart7383, sorry for the delay. I can confirm that this is expected behavior. This is because restarting triggers the deprovisioning flow, which for DPS with TPM results in a new identity.
If you want to avoid this, you can set
always_reprovision_on_startup
to false:If you update to the LTS 1.1.x, the field is now
AutoReprovisioningMode
, and can be set to Dynamic, AlwaysOnStartup, and OnErrorOnly.
I have tested the same by setting flag always_reprovision_on_startup to true I have checked multiple times and everytime it recreates the container where we are losing our data and files.
I have attached two screenshots, where you can find the containerIds are different.
Hey @niravart7383, the always_reprovision_on_startup
needs to be set to false
. It is the re-provisioning that is causing the containers to be reset.
Sorry if the config file I linked above caused confusion, I simply linked to an example config in our repo that had the field.
In addition, if you are worried about losing data in a container, you can use volume mounting to store permanent files on the host filesystem: https://docs.docker.com/storage/volumes/
Hey @niravart7383, the
always_reprovision_on_startup
needs to be set tofalse
. It is the re-provisioning that is causing the containers to be reset.Sorry if the config file I linked above caused confusion, I simply linked to an example config in our repo that had the field.
I have checked with both, true/false the behavior is same.
In addition, if you are worried about losing data in a container, you can use volume mounting to store permanent files on the host filesystem: https://docs.docker.com/storage/volumes/
I agree !!
But why the behaviour is different, the same thing is not happening If I am not using TPM
This issue is being marked as stale because it has been open for 30 days with no activity.
Expected Behavior
Modules should be as it is after iotedge restart
Current Behavior
Module containers are getting recreated if iotedge service restarts
Steps to Reproduce
Provide a detailed set of steps to reproduce the bug.
Context (Environment)
OS: Windows IoT 1809 (LTSC)
Output of
iotedge check
Click here
``` √ config.yaml is well-formed - OK √ config.yaml has well-formed connection string - OK √ container engine is installed and functional - OK √ Windows host version is supported - OK √ config.yaml has correct hostname - OK √ config.yaml has correct URIs for daemon mgmt endpoint - OK ‼ latest security daemon - Warning Installed IoT Edge daemon has version 1.0.10.4 but 1.1.1 is the latest stable version available. Please see https://aka.ms/iotedge-update-runtime for update instructions. √ host time is close to real time - OK √ container time is close to host time - OK √ DNS server - OK √ production readiness: certificates - OK √ production readiness: container engine - OK ‼ production readiness: logs policy - Warning Container engine is not configured to rotate module logs which may cause it run out of disk space. Please see https://aka.ms/iotedge-prod-checklist-logs for best practices. You can ignore this warning if you are setting log policy per module in the Edge deployment. ‼ production readiness: Edge Agent's storage directory is persisted on the host filesystem - Warning The edgeAgent module is not configured to persist its C:\Windows\Temp\edgeAgent directory on the host filesystem. Data might be lost if the module is deleted or updated. Please see https://aka.ms/iotedge-storage-host for best practices. √ production readiness: Edge Hub's storage directory is persisted on the host filesystem - OK Connectivity checks ------------------- √ host can connect to and perform TLS handshake with DPS endpoint - OK √ host can connect to and perform TLS handshake with IoT Hub AMQP port - OK √ host can connect to and perform TLS handshake with IoT Hub HTTPS / WebSockets port - OK √ host can connect to and perform TLS handshake with IoT Hub MQTT port - OK √ container on the IoT Edge module network can connect to IoT Hub AMQP port - OK √ container on the IoT Edge module network can connect to IoT Hub HTTPS / WebSockets port - OK √ container on the IoT Edge module network can connect to IoT Hub MQTT port - OK 19 check(s) succeeded. ```Device Information
Runtime Versions
iotedge version
]:Note: when using Windows containers on Windows, run
docker -H npipe:////./pipe/iotedge_moby_engine version
insteadLogs
Additional Information
It is applicable to TPM auth with DPS only, It is working fine with SAS token authentication