Hello,
I am trying check my understanding before deployment.
1. how mender downloads the update. Is it done in parts or is it one single download? It looks like it is one single download.
For example,
If I have an update which is 300 MB in size and is midway downloading, If I power cycle the unit and I have the retry set to 0 the update fails
2. Can I change my certificate and hosted mender api via a artifact update
1. Do I have to include anything specific to perform an rollback. I think there are two conditions
a. Normal delta update on the root file system update. I see that if the download fails then we don’t perform the update
b. But in the scenario where I have created my own specific state scripts then its my responsibility to create a rollback script and include it in my artifact update in case the state scripts fails?
---
1. The client downloads the update in one single stream. However, if the connection is broken, the client should continue downloading the update from where it left off, if it is allowed to retry.
2. You can change your certificate (I’m not sure what changing the hosted API means), with a rootfs update (as long as the certificate is on one of the rootfs partitions. If it is not, it is possible to do something like a file update module, and have it replace it on the data-partition, although riskier, since a corruption or failure here will leave you in an undefined state.
3. I think you might be confusing State scripts with Update modules here. You can have state scripts which run in the ArtifactRollback state. But it is not required. This is entirely use-case dependent.
Rollbacks are different depending on what sort of an update you are doing. Since you mentioned deltas, I’m going to assume that this is a rootfs update. Which means that you don’t have to include anything special at all. The Mender client will perform the roll-back automatically, in case anything fails.
Does this make sense?
---
> [@oleorhagen](#):
>
> However, if the connection is broken, the client should continue downloading the update from where it left off, if it is allowed to retry
The connection broken in this case, would be, if I lost internet connection and I got it back after some time. Not the same as power loss. I would assume.
> [@oleorhagen](#):
>
> if it is allowed to retry.
This retry that you are referring to is different than the retry on [hosted.mender.io](http://hosted.mender.io)?
> [@oleorhagen](#):
>
> I’m not sure what changing the hosted API means
So right now I am setting two variable
`MENDER_SERVER_URL=https://hosted.mender.io` and `MENDER_TENNANT_TOKEN` So if in the future I need to change any of these variables to a some new value I can include them as new update
But I think I understand what you are trying to say for the certificate option. I have not looked into it. I will start looking into it
> [@oleorhagen](#):
>
> I think you might be confusing State scripts with Update modules here. You can have state scripts which run in the ArtifactRollback state. But it is not required. This is entirely use-case dependent.
I think I am. I am very bad at remembering proper terminologies. but you understood it spot on.
So this post is an example of what I am trying to achieve
> [@State-scripts documentation: how to use them without Yocto](https://hub.mender.io/t/state-scripts-documentation-how-to-use-them-without-yocto/744/18):
>
> The more I read about this more complicate it sounds So to give an example of what I am trying to achieve. Recently I found out that I had provide a patch to systemd so that I could change timezone in read only root file system. So the fix was in two areas. I had to update rootfs Add necessary file in persistent data section As shown below root@raspberrypi-cm3:/etc# ls -lrt | grep localtime lrwxrwxrwx 1 root root 22 Aug 19 11:56 localtime -\> /data/system/localtime root@raspberrypi…
In the above case. I had created a script which ran as a part of update module. Since this was a specific use case.
If the script fails in the second or third step, will the artifact automatically revert the changes performed or do I have to do something to take care of it?
---
> [@thesillywhat](#):
>
> The connection broken in this case, would be, if I lost internet connection and I got it back after some time. Not the same as power loss. I would assume.
In this case, the download should continue from where it was interrupted.
> [@thesillywhat](#):
>
> This retry that you are referring to is different than the retry on [hosted.mender.io](http://hosted.mender.io)?
Yes, I was talking about the Mender clients ablility to retry on connection errors. The `hosted.mender.io` retries will retry the entire deployment from the start.
> [@thesillywhat](#):
>
> `MENDER_SERVER_URL=https://hosted.mender.io` and `MENDER_TENNANT_TOKEN` So if in the future I need to change any of these variables to a some new value I can include them as new update
> But I think I understand what you are trying to say for the certificate option. I have not looked into it. I will start looking into it
Great 🙂, note that the client can have one ‘global’ configuration file on the `data` partition, and then override these with a local config on the `rootfs{a,b}` partitions.
> [@thesillywhat](#):
>
> In the above case. I had created a script which ran as a part of update module. Since this was a specific use case.
> If the script fails in the second or third step, will the artifact automatically revert the changes performed or do I have to do something to take care of it?
If I undestand you correctly:
Rollbacks are not performed automatically for changes you make using a state-script. The client only guarantees that the `RollBack` states will be run in the case of an error during the update. Hence it is your responsibility to have a `state-script` do the rollback if you have made a change to, like you did, `systemd` configuration.
---
Firstly I would like to thank everyone in this community for helping me out in releasing the product out so quickly. So thank you @drewmoseley @mirzak @oleorhagen @dellgreen @kacf
We have deployed 7 boards with mender. But now since I am including different projects. I would like some more help to understand.
1. How do people generally separate out mender delta releases for different projects. Is it by just specifying different version names?
2. We have a diagnostic screen as well in our UI something that lets the IT team know what URL I am using. Is it possible to send a curl request to `https://hosted.mender.io` and if yes what data will I receive.
Currently when I send a curl request I receive `moved permanently` as a response.
I know most of the people will be quick to point out just allow traffic on tcp port 443 and it will work. To them I say. I have already tried that and no one is buying that. So If I can send something to [hosted.mender.io](http://hosted.mender.io) and receive some sort of an acknowledgment saying that communication to [hosted.mender.io](http://hosted.mender.io) is indeed working I can sleep a little easy
---
So, The Client wants a Diagnostic screen where he can see if the websites are whitelisted or not.
So that he can tell the other IT team to white list it.
We do a curl to [google.com](http://google.com) to see if DNS is working or not and TCP setting are in place.
Since we are communicating with [mender.io](http://mender.io) . He wanted to have something similar to that. So that he can be assured that we are indeed able to communicate with mender server.
I thought the easiest way to do that, is to send a curl command to mender.
Am I able to explain this properly?
---
oh i see, i get you now.
Then yes a simple curl command that follows redirects and just pulls the headers from the server sounds like one way to do it.
curl -L -I “[https://hosted.mender.io](https://hosted.mender.io)”