Factory Reset

If a device has the option for a factory reset, is there a way to automatically have the device go back to the last deployed state?

  • Trevor

Hello Trevor, welcome to the Mender community.

There is currently no functionality that “automatically” triggers deployments based on certain conditions. Though this is a planed feature.

With the current state you can solve this by utilizing the server API’s, and basically poll the list of the devices, looking up devices that have “factory_reset=1” in e.g inventory (this is a value that you would need to add) and then you can create a deployment based on this lookup.

Mirza,

Trying to understand something here. Also for reset.

Obviously want to avoid being double charged for same device. On a reset we don’t retain a mender-agent.pem and generate a new one. Would this be treated as a new activation?

Cheers

1 Like

I have a similar question to @Upgradio 's. What are the possibilities of decommissioning/deactivating a device temporarily/permanently?

Yes, I believe this would be treated as a new device activation. The device identity has changed so there is no way to distinguish the two different cases.

Update:

My initial answer was misdealing and wrong.

We are counting devices which were active during the month but each active devices is always counted once (it’s safe to change auth set, rotate key etc)

Can you please clarify this question and what the use-case is.

Absolutely @mirzak

  1. The use-case is if a Mender Node is compromised in any case, either physically or via the network, how can the Mender Server deactivate/decommission the device so that it doesn’t allow any requests to be processed by the compromised mender client and also see the deactivated/decommissioned device in the GUI.

  2. Similarly, another use case can be when the deployed Mender Node needs to rotate/update its keys over a period of time. Can this be done remotely or manually?

@mirzak , I did find the solution the 1st use case. I didn’t look closely before. There are 2 ways that can be done.

  1. Using mender-GUI the Reject, dismiss or decommission the device action can be used which appears in the Device-Identity section, whenever a device information is expanded in the All Devices section.

  2. Using mender-cli, this API can be used to do the above same process remove-selected-device

I also found a way to even execute the 2nd use-case and that is to use Dismiss option from the above mentioned. Could you please explain what happens if each of the Reject, Dismiss or Decommision is executed on the mender client using the GUI or mender-cli?

  • Reject - Will invalidate the authorization of a specific authentication set and prevent that same set to be used again to authorize with the server. Essentially blocking the Mender client to connect to the server.

  • Dismiss - This will simply remove an authentication set associated with a device but it will not prevent the same authentication to be used for future authentication requests and the authetincation set would be in state “pending” if used again after Dismiss has been used

  • Decommission - This will simply remove the device and any associated authentication sets with a device but it will not prevent the same device to be used for future authentication requests and the authentication set would be in state “pending” if used again after Decommission has been used

1 Like

Thank you @mirzak. That was very informative.

So, in that case will it be possible to Reject a Device on the basis of a specific identity parameter or subset of identity parameters from the identity set. For example, Macid, serial-id, ipv4 or all three of them ?

So, in that case will it be possible to Reject a Device on the basis of a specific identity parameter or subset of identity parameters from the identity set. For example, Macid , serial-id , ipv4 or all three of them ?

Identity is a combination of identity parameters and the public key. An authorization set is a combination of these.

Then how can a device be rejected based on a specific identity parameter or N number of parameters?

Rejecting a device is generally an operator-initiated action so you just choose the device you are interested in and reject it.

It sounds like you are looking for a more programmatic approach which can certainly be done with the API. You can enumerate all the devices and the select the ones of interest based on your filtering criteria and the issue the API calls to reject them. We do not have a UI/automated way to handle this at present.

1 Like

@drewmoseley yes. I think that in near-future this kind of use will be required as Mender is likely the go-to service for seamless OTA for embedded devices.

The filtering approach you mentioned can be automated as well so that should pretty much do the job. Thank you!