standalone mender update on RPI3 from remote Mender server

[Ahmed abdelhalim]

Hi all,

I am using mender 1.4 on RPI3 and I already built it with yocto (rocko branch). My situation is that the rpi boots up and it starts mender client as daemon using the systemd service "mender.service". After that I upload the artifact on the mender server, then I update(deploy the artifact) from the server to the pi. This works perfectly. 

I stop the service "mender.service" and I try to update the rpi remotly but from the pi's side. This does't work. This is the command that I use on the rpi-->

mender -log-level info -rootfs https://<my IP address>:8000/release-3.6.2.mender  

The is the output from executing the last command:

INFO[0000] Performing remote update from: [https://<my IP address>:8000/release-3.6.2.mender].  module=rootfs

ERRO[0130] Can not fetch update image: Get https://<my IP address>:8000/release-3.6.2.mender: dial tcp <my IP address>:8000: getsockopt: connection timed out  module=client_update

ERRO[0130] rootfs: error while updating image from command line: update fetch request failed: Get https://<my IP address>:8000/release-3.6.2.mender: dial tcp <my IP address>:8000: getsockopt: connection timed out  module=main

if I change the port number to 443 which is actually the port number which I am use in "/etc/mender/mender.config" file in "ServerURL" attribute, then I get different response -->

This is the command--> 

mender -log-level info -rootfs https://<my IP address>:443/release-3.6.2.mender

 This is the response-->

INFO[0000] Performing remote update from: [https://<my IP address>:443/release-3.6.2.mender].  module=rootfs

ERRO[0000] Can not fetch update image: Get https:<my IP address>:443/release-3.6.2.mender: x509: certificate signed by unknown authority  module=client_update

ERRO[0000] rootfs: error while updating image from command line: update fetch request failed: Get https://<my IP address>:443/release-3.6.2.mender: x509: certificate signed by unknown authority  module=main

I am sure there is no problem with the certificate that I am using and no issues with the internet connection. The same internet connection and certificate I used when deploying from server to the pi and it worked. 

Please what could be the reason for the last 2 messages, which port 8000 or 443 is correct? 

Thanks

Ahmed

kind regards

[Drew Moseley]

Hi Ahmed,

The Mender server uses a storage proxy and does not provide the Mender artifacts directly. The default setup uses Minio and generates the URL for the artifact dynamically.  You should be able to see the URL that is generated in the logs from a successful managed update. I believe it uses port 9000 as default.

That said, I'm not sure you can rely on that as a persistent way to access the artifacts.  Since they are generated, with a timeout, the URLs will not always be valid. I suspect you will be better off using a separate file server for this.

Drew
---
Drew Moseley | Technical Solutions Architect | (+1) 480-797-0552 | https://mender.io

Northern.tech AS | @northerntechHQ | @drewmoseley

[Ahmed abdelhalim]

Hi Drew,

thanks for your reply. I tested port 9000 as you mentioned but still no hope and it does show the unauthorized certificate. The issue is that it is clearly mentioned in the Mender documentation page "version 1" ( "Deploy the new artifact to device" section) that it is possible to draw the artifacts from the client side. I know that Documentation 1 is quite old but I hoped that such feature are still supported even for the new versions.

That said, I'm not sure you can rely on that as a persistent way to access the artifacts.  Since they are generated, with a timeout, the URLs will not always be valid. I suspect you will be better off using a separate file server for this.

you mean it is not possible to access artifacts from outside the server and the only way is that I have to generate the artifact download link through the web GUI ?

Thanks 

kind regards

Ahmed 

[Mirza Krak]

On Sat, Sep 1, 2018 at 9:01 PM, Ahmed abdelhalim <ahmedabde...@gmail.com> wrote:

Hi Drew,

thanks for your reply. I tested port 9000 as you mentioned but still no hope and it does show the unauthorized certificate. The issue is that it is clearly mentioned in the Mender documentation page "version 1" ( "Deploy the new artifact to device" section) that it is possible to draw the artifacts from the client side. I know that Documentation 1 is quite old but I hoped that such feature are still supported even for the new versions.

It is definitely possible to initiate downloads from the client using "mender -rootfs <file or http/https URL>". 

That said, I'm not sure you can rely on that as a persistent way to access the artifacts.  Since they are generated, with a timeout, the URLs will not always be valid. I suspect you will be better off using a separate file server for this.

you mean it is not possible to access artifacts from outside the server and the only way is that I have to generate the artifact download link through the web GUI ?

You need some way of generating artifact links, these are actually not stored on the Mender server but instead this is a third-party service. This is configurable but by default Minio [1] is used, and this is where the artifacts reside. When deploying updates in "managed" mode the Mender server will use the Minio API to generate download links and provides these to the Mender client, these links typically have an expiry time, means that they are only valid a short period of time.

Now if you want to download the artifacts from the same location as the Mender server you need to use the Minio API to get the links or host your artifacts at a different location, as Drew suggested a simple file-server might be enough for this. 

[1]. https://www.minio.io/

-- 

Mirza Krak | Embedded Solutions Architect | https://mender.io

[Vladimir Bashkirtsev]

That documentation clearly says "standalone deployments with the Mender client, where no Mender server is used". Then it explains that you must start standalone webserver serving your artifact and use it as the source for mender client. Calls on port 443 to Mender server are inappropriate in this  case and calls on port 9000 to Minio are also inappropriate as it is not a 'normal' webserver.

Just upload your artifact to any http webserver and use its URL as -rootfs parameter. 

--
You received this message because you are subscribed to the Google Groups "Mender List mender.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mender+un...@lists.mender.io.
To post to this group, send email to men...@lists.mender.io.
Visit this group at https://groups.google.com/a/lists.mender.io/group/mender/.

[Ahmed abdelhalim]

Thanks Mirza and Vladimir for your clarifications, then I will try to upload my artifacts to ftb server and use its URL to call using "mender -rootfs URL" and get back with results. Thanks all again for your help.

[Mirza Krak]

On Sun, Sep 2, 2018 at 2:30 PM, Ahmed abdelhalim <ahmedabde...@gmail.com> wrote:

Thanks Mirza and Vladimir for your clarifications, then I will try to upload my artifacts to ftb server and use its URL to call using "mender -rootfs URL" and get back with results. Thanks all again for your help.

Also wanted to point out that you can generate valid download links using the Mender API, specifically this one [1]. Also check this section [2] on how to use the APIs

[1]. https://docs.mender.io/1.5/apis/management-apis/deployments#artifacts-id-download-get

[2]. https://docs.mender.io/1.5/server-integration/using-the-apis

-- 

[Ahmed abdelhalim]

Thank you very much Mirza. I actually just discovered that very few hours ago and I was testing this way either. It is more a professional way and better than using FTP/http file servers to upload the mender artifacts and download them on the RPI. I have just very small issue.

I used the API's, logged to the Mender server and I obtained the JWT. Now I used it to obtain the dynamic link for downloading the artifact and I obtained something like this from the Mender server:

{"uri":"https://my-Mender-Server-URI:9000/mender-artifact-storage/d5ab385b-782f-4fc1-839b-44f875ca1e50?X-Amz-Algorithm=AWS4-HMAC-SHA256\u0026X-Amz-Credential=mender-deployments%2F20180903%2Fus-east-1%2Fs3%2Faws4_request\u0026X-Amz-Date=20180903T100449Z\u0026X-Amz-Expires=900\u0026X-Amz-SignedHeaders=host\u0026response-content-type=application%2Fvnd.mender-artifact\u0026X-Amz-Signature=e43087c56d9efd8dcbbbd23d0143ccb8426a57a55032bb144cee78f84702c40c","expire":"2018-09-03T10:19:49.82647177Z"}

I stopped the mender.service on the RPI and performed the mender command with the supplied URI from the Mender server:

mender -log-level info -rootfs https://my-Mender-Server-URI:9000/mender-artifact-storage/d5ab385b-782f-4fc1-839b-44f875ca1e50?X-Amz-Algorithm=AWS4-HMAC-SHA256\u0026X-Amz-Credential=mender-deployments%2F20180903%2Fus-east-1%2Fs3%2Faws4_request\u0026X-Amz-Date=20180903T100449Z\u0026X-Amz-Expires=900\u0026X-Amz-SignedHeaders=host\u0026response-content-type=application%2Fvnd.mender-artifact\u0026X-Amz-Signature=e43087c56d9efd8dcbbbd23d0143ccb8426a57a55032bb144cee78f84702c40c

However I still get the certifcate problem: This is exaclty the response --> 

INFO[0000] Performing remote update from: [https://my-Mender-Server-URI:9000/mender-artifact-storage/d5ab385b-782f-4fc1-839b-44f875ca1e50?X-Amz-Algorithm=AWS4-HMAC-SHA256u0026X-Amz-Credential=mender-deployments%2F20180903%2Fus-east-1%2Fs3%2Faws4_requestu0026X-Amz-Date=20180903T095842Zu0026X-Amz-Expires=900u0026X-Amz-SignedHeaders=hostu0026response-content-type=application%2Fvnd.mender-artifactu0026X-Amz-Signature=59a2022b30a6f38eb5b9672faf128de3e6db99b411710361924526a3ba0baa37].  module=rootfs

ERRO[0000] Can not fetch update image: Get https://my-Mender-Server-URI:9000/mender-artifact-storage/d5ab385b-782f-4fc1-839b-44f875ca1e50?X-Amz-Algorithm=AWS4-HMAC-SHA256u0026X-Amz-Credential=mender-deployments%2F20180903%2Fus-east-1%2Fs3%2Faws4_requestu0026X-Amz-Date=20180903T095842Zu0026X-Amz-Expires=900u0026X-Amz-SignedHeaders=hostu0026response-content-type=application%2Fvnd.mender-artifactu0026X-Amz-Signature=59a2022b30a6f38eb5b9672faf128de3e6db99b411710361924526a3ba0baa37: x509: certificate signed by unknown authority  module=client_update

ERRO[0000] rootfs: error while updating image from command line: update fetch request failed: Get https://my-Mender-Server-URI:9000/mender-artifact-storage/d5ab385b-782f-4fc1-839b-44f875ca1e50?X-Amz-Algorithm=AWS4-HMAC-SHA256u0026X-Amz-Credential=mender-deployments%2F20180903%2Fus-east-1%2Fs3%2Faws4_requestu0026X-Amz-Date=20180903T095842Zu0026X-Amz-Expires=900u0026X-Amz-SignedHeaders=hostu0026response-content-type=application%2Fvnd.mender-artifactu0026X-Amz-Signature=59a2022b30a6f38eb5b9672faf128de3e6db99b411710361924526a3ba0baa37: x509: certificate signed by unknown authority  module=main

Have you any ideas please what is the reason?

Thanks

Kind regards

Ahmed 

[Mirza Krak]

On Mon, Sep 3, 2018 at 12:11 PM, Ahmed abdelhalim <ahmedabde...@gmail.com> wrote:

Thank you very much Mirza. I actually just discovered that very few hours ago and I was testing this way either. It is more a professional way and better than using FTP/http file servers to upload the mender artifacts and download them on the RPI. I have just very small issue.

I used the API's, logged to the Mender server and I obtained the JWT. Now I used it to obtain the dynamic link for downloading the artifact and I obtained something like this from the Mender server:

{"uri":"https://my-Mender-Server-URI:9000/mender-artifact-storage/d5ab385b-782f-4fc1-839b-44f875ca1e50?X-Amz-Algorithm=AWS4-HMAC-SHA256\u0026X-Amz-Credential=mender-deployments%2F20180903%2Fus-east-1%2Fs3%2Faws4_request\u0026X-Amz-Date=20180903T100449Z\u0026X-Amz-Expires=900\u0026X-Amz-SignedHeaders=host\u0026response-content-type=application%2Fvnd.mender-artifact\u0026X-Amz-Signature=e43087c56d9efd8dcbbbd23d0143ccb8426a57a55032bb144cee78f84702c40c","expire":"2018-09-03T10:19:49.82647177Z"}

I stopped the mender.service on the RPI and performed the mender command with the supplied URI from the Mender server:

mender -log-level info -rootfs https://my-Mender-Server-URI:9000/mender-artifact-storage/d5ab385b-782f-4fc1-839b-44f875ca1e50?X-Amz-Algorithm=AWS4-HMAC-SHA256\u0026X-Amz-Credential=mender-deployments%2F20180903%2Fus-east-1%2Fs3%2Faws4_request\u0026X-Amz-Date=20180903T100449Z\u0026X-Amz-Expires=900\u0026X-Amz-SignedHeaders=host\u0026response-content-type=application%2Fvnd.mender-artifact\u0026X-Amz-Signature=e43087c56d9efd8dcbbbd23d0143ccb8426a57a55032bb144cee78f84702c40c

However I still get the certifcate problem: This is exaclty the response --> 

INFO[0000] Performing remote update from: [https://my-Mender-Server-URI:9000/mender-artifact-storage/d5ab385b-782f-4fc1-839b-44f875ca1e50?X-Amz-Algorithm=AWS4-HMAC-SHA256u0026X-Amz-Credential=mender-deployments%2F20180903%2Fus-east-1%2Fs3%2Faws4_requestu0026X-Amz-Date=20180903T095842Zu0026X-Amz-Expires=900u0026X-Amz-SignedHeaders=hostu0026response-content-type=application%2Fvnd.mender-artifactu0026X-Amz-Signature=59a2022b30a6f38eb5b9672faf128de3e6db99b411710361924526a3ba0baa37].  module=rootfs

ERRO[0000] Can not fetch update image: Get https://my-Mender-Server-URI:9000/mender-artifact-storage/d5ab385b-782f-4fc1-839b-44f875ca1e50?X-Amz-Algorithm=AWS4-HMAC-SHA256u0026X-Amz-Credential=mender-deployments%2F20180903%2Fus-east-1%2Fs3%2Faws4_requestu0026X-Amz-Date=20180903T095842Zu0026X-Amz-Expires=900u0026X-Amz-SignedHeaders=hostu0026response-content-type=application%2Fvnd.mender-artifactu0026X-Amz-Signature=59a2022b30a6f38eb5b9672faf128de3e6db99b411710361924526a3ba0baa37: x509: certificate signed by unknown authority  module=client_update

ERRO[0000] rootfs: error while updating image from command line: update fetch request failed: Get https://my-Mender-Server-URI:9000/mender-artifact-storage/d5ab385b-782f-4fc1-839b-44f875ca1e50?X-Amz-Algorithm=AWS4-HMAC-SHA256u0026X-Amz-Credential=mender-deployments%2F20180903%2Fus-east-1%2Fs3%2Faws4_requestu0026X-Amz-Date=20180903T095842Zu0026X-Amz-Expires=900u0026X-Amz-SignedHeaders=hostu0026response-content-type=application%2Fvnd.mender-artifactu0026X-Amz-Signature=59a2022b30a6f38eb5b9672faf128de3e6db99b411710361924526a3ba0baa37: x509: certificate signed by unknown authority  module=main

Have you any ideas please what is the reason?

Hmm interesting.

I am assuming that you are using self-signed certificates and this might be what is causing this problem as it does not seem that the "/etc/mender/server.crt" is loaded when running "mender -rootfs" but it is when running "mender -daemon". Will need to look in to this a bit more.

You could try appending the "server.crt" content to "/etc/ssl/certs/ca-certificates.crt" to see if that "fixes" your problem.

-- 

[Mirza Krak]

Or the proper way is probably copy "server.crt" to /etc/ssl/certs and then run:

    $ update-ca-certificates

-- 

[Ahmed abdelhalim]

Hi Mirza,

I updated the server.crt to /etc/ssl/certs as you pointed. Now when I perform the command after obtaining new download link:

mender -log-level info -rootfs https://<my-mender-server>:9000/mender-artifact-storage/481b8457-01ae-4496-87a0-3585be56e3db?X-Amz-Algorithm=AWS4-HMAC-SHA256\u0026X-Amz-Credential=mender-deployments%2F20180903%2Fus-east-1%2Fs3%2Faws4_request\u0026X-Amz-Date=20180903T135503Z\u0026X-Amz-Expires=900\u0026X-Amz-SignedHeaders=host\u0026response-content-type=application%2Fvnd.mender-artifact\u0026X-Amz-Signature=9b0d63bddfdb4db8ba6a4a2e84bd371a308b0aa1ecbaa48175ae0b7cd61fee75

This is the new response:

INFO[0000] Performing remote update from: [https://<my-mender-server>:9000/mender-artifact-storage/481b8457-01ae-4496-87a0-3585be56e3db?X-Amz-Algorithm=AWS4-HMAC-SHA256u0026X-Amz-Credential=mender-deployments%2F20180903%2Fus-east-1%2Fs3%2Faws4_requestu0026X-Amz-Date=20180903T135503Zu0026X-Amz-Expires=900u0026X-Amz-SignedHeaders=hostu0026response-content-type=application%2Fvnd.mender-artifactu0026X-Amz-Signature=9b0d63bddfdb4db8ba6a4a2e84bd371a308b0aa1ecbaa48175ae0b7cd61fee75].  module=rootfs

ERRO[0000] Error fetching shcheduled update info: code (403)  module=client_update

ERRO[0000] rootfs: error while updating image from command line: Error receiving scheduled update information.  module=main

I noticed that even if the timezone of the virtual machine which mender server is working on different than ETC/UTC, mender server always chooses this time zone and I see this from the server logging. However I changed the RPI timezone to ETC/UTC to avoid any mismatch between the server and the PI but still no chance ? 

Thanks

Kind regards

Ahmed

[Ahmed abdelhalim]

Hmm interesting.

I am assuming that you are using self-signed certificates and this might be what is causing this problem as it does not seem that the "/etc/mender/server.crt" is loaded when running "mender -rootfs" but it is when running "mender -daemon". Will need to look in to this a bit more.

You could try appending the "server.crt" content to "/etc/ssl/certs/ca-certificates.crt" to see if that "fixes" your problem.

I tried the following complete command of mender to make sure it loads everything:

mender -data="/data/mender/" -debug -config="/etc/mender/mender.conf" -trusted-certs="/etc/mender/server.crt" -rootfs https://<my mender URL>.com:9000/mender-artifact-storage/481b8457-01ae-4496-87a0-3585be56e3db?X-Amz-Algorithm=AWS4-HMAC-SHA256\u0026X-Amz-Credential=mender-deployments%2F20180903%2Fus-east-1%2Fs3%2Faws4_request\u0026X-Amz-Date=20180903T144003Z\u0026X-Amz-Expires=900\u0026X-Amz-SignedHeaders=host\u0026response-content-type=application%2Fvnd.mender-artifact\u0026X-Amz-Signature=e8978077e74e2075dd3ed35f2608ece54766151e6778eb33189cc9e916949ce7


 

This is output logs:

DEBU[0000] Reading Mender configuration from file /etc/mender/mender.conf  module=config

DEBU[0000] Read data from device manifest file: device_type=raspberrypi3  module=mender

DEBU[0000] Found needed line: device_type=raspberrypi3   module=mender

DEBU[0000] Current manifest data: raspberrypi3           module=mender

DEBU[0000] Starting device update.                       module=rootfs

INFO[0000] Performing remote update from: [https://<my mender URL>:9000/mender-artifact-storage/481b8457-01ae-4496-87a0-3585be56e3db?X-Amz-Algorithm=AWS4-HMAC-SHA256u0026X-Amz-Credential=mender-deployments%2F20180903%2Fus-east-1%2Fs3%2Faws4_requestu0026X-Amz-Date=20180903T144003Zu0026X-Amz-Expires=900u0026X-Amz-SignedHeaders=hostu0026response-content-type=application%2Fvnd.mender-artifactu0026X-Amz-Signature=e8978077e74e2075dd3ed35f2608ece54766151e6778eb33189cc9e916949ce7].  module=rootfs

INFO[0000] API Gateway certificate (in PEM format):

-----BEGIN CERTIFICATE-----

MIIBtDCCAVugAwIBAgIJALPPh4OBT2sDMAoGCCqGSM49BAMCMDcxNTAzBgNVBAMM

LGJkdXBkYXRlc2VydmVyLndlc3RldXJvcGUuY2xvdWRhcHAuYXp1cmUuY29tMB4X

DTE4MDIwODA5NTYxOVoXDTI4MDIwNjA5NTYxOVowNzE1MDMGA1UEAwwsYmR1cGRh

dGVzZXJ2ZXIud2VzdGV1cm9wZS5jbG91ZGFwcC5henVyZS5jb20wWTATBgcqhkjO

PQIBBggqhkjOPQMBBwNCAASpQ6Dim3xJbWEsSobN2ikPZBfdJqFesgLcyFQ/Uwim

NpJRD0na7FocnDaeft8VTJqB+JR2k9/Y9ThYwIIABq16o1AwTjAdBgNVHQ4EFgQU

hb0YvKvQu4uP2EiFSk4WhasWY/AwHwYDVR0jBBgwFoAUhb0YvKvQu4uP2EiFSk4W

hasWY/AwDAYDVR0TBAUwAwEB/zAKBggqhkjOPQQDAgNHADBEAiAGk8BndimdeH6U

q2DNu8L6I6Lz3WN5F0YAldDWY04gNQIgYXPctXXn3cOqA80L7OtboQhsCsGajwKF

BvaMQ2asYp0=

-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----

MIIBtjCCAVugAwIBAgIJAJJi0SGV0B7AMAoGCCqGSM49BAMCMDcxNTAzBgNVBAMM

LGJkdXBkYXRlc2VydmVyLndlc3RldXJvcGUuY2xvdWRhcHAuYXp1cmUuY29tMB4X

DTE4MDIwODA5NTYxOVoXDTI4MDIwNjA5NTYxOVowNzE1MDMGA1UEAwwsYmR1cGRh

dGVzZXJ2ZXIud2VzdGV1cm9wZS5jbG91ZGFwcC5henVyZS5jb20wWTATBgcqhkjO

PQIBBggqhkjOPQMBBwNCAAQl25RowX49fKIFaOrqvTmDTvX20+ZjGgkPYF9rRwxe

IF+eG+DE/u3fSZ4j24T6sMC5gL1pCwHMoy5BOfL6pr8Bo1AwTjAdBgNVHQ4EFgQU

Hvrwhz2A7JLr2bMJ9PrUPRFCj2EwHwYDVR0jBBgwFoAUHvrwhz2A7JLr2bMJ9PrU

PRFCj2EwDAYDVR0TBAUwAwEB/zAKBggqhkjOPQQDAgNJADBGAiEA1peBiC+EpxfC

pfck1AZ10AT54pno26lfPsehDJvO08gCIQC2kFqf0z9BsEz5oQa6igklCKuS7shx

r00D3U+YKzV2xQ==

-----END CERTIFICATE-----

  module=client

INFO[0000] Issuer: [], Valid from: 2018-02-08 09:56:19 +0000 UTC, Valid to: 2028-02-06 09:56:19 +0000 UTC  module=client

DEBU[0000] Client initialized. Start downloading image.  module=rootfs

DEBU[0000] Received fetch update response &{403 Forbidden 403 HTTP/1.1 1 1 map[Vary:[Origin] X-Amz-Request-Id:[IVYJFA42HYZ3HIVG] Server:[openresty/1.11.2.2] Content-Type:[text/xml; charset=utf-8] Connection:[keep-alive] Date:[Mon, 03 Sep 2018 14:40:31 GMT] Accept-Ranges:[bytes]] 0x12530b00 -1 [chunked] false false map[] 0x12370300 0x126a3440}+  module=client_update

ERRO[0000] Error fetching shcheduled update info: code (403)  module=client_update

DEBU[0000] Image downloaded: -1 [<nil>] [Error receiving scheduled update information.]  module=rootfs

ERRO[0000] rootfs: error while updating image from command line: Error receiving scheduled update information.  module=main

This error 403 forbidden, may be it tells that the server does not allow the client to draw the artifact? I am using Mender server 1.3.

Thanks again

Ahmed

[Ahmed abdelhalim]

I have found the problem. It is something actually very strange.

When I request the download link using the API, then the created download link looks like this --> 

https://<My Mender IP Server>:9000/mender-artifact-storage/5f2b9a1c-1e22-4746-ae33-13bfa52bd2f4?X-Amz-Algoender-deployments%2F20180904%2Fus-east-1%2Fs3%2Faws4_request\u0026X-Amz-Date=20180904T092647Z\u0026X-Amz-Expires=900\u0026X-Amz-SignedHeaders=host\u0026response-content-type=application%2Fvnd.mender-artifact\u0026X-Amz-Signature=440e2b9d97b6d3703eb6930f53c21fd54c5cb5583334a90a0af4c56315e3ae96

When I compared between this link and that other link sent to the mender client in daemon mode, I found that the difference is in a letter '&' which is not interpreted and instead it is sent from the mender server as \u0026. This is exactly repeated over all in the link sent to me using the APi. (In blue marker above). Once replaced to & , now I can download the artifact even in my chrome browser.

Thanks 

Kind regards

Ahmed

[Mirza Krak]

Thanks for investigating this and for the detailed raport.

I will forward this to our back-end team. Will keep you updated :).

--
Mirza Krak | Embedded Solutions Architect | https://mender.io

Northern.tech AS | @northerntechHQ

[Mirza Krak]

Or even better, could you create a bug report here,
https://tracker.mender.io/projects/MEN.

As you have all the information and the steps to re-reproduce this.

[Mirza Krak]

On Tue, Sep 4, 2018 at 12:26 PM, Ahmed abdelhalim
<ahmedabde...@gmail.com> wrote:

> I have found the problem. It is something actually very strange.
>
> When I request the download link using the API, then the created download
> link looks like this -->
>
> https://<My Mender IP
> Server>:9000/mender-artifact-storage/5f2b9a1c-1e22-4746-ae33-13bfa52bd2f4?X-Amz-Algoender-deployments%2F20180904%2Fus-east-1%2Fs3%2Faws4_request\u0026X-Amz-Date=20180904T092647Z\u0026X-Amz-Expires=900\u0026X-Amz-SignedHeaders=host\u0026response-content-type=application%2Fvnd.mender-artifact\u0026X-Amz-Signature=440e2b9d97b6d3703eb6930f53c21fd54c5cb5583334a90a0af4c56315e3ae96

Actually what seems to be going on here is that you might have skipped
running a JSON decode on the API response, could that be the case? You
can typically use "jq" for this.

[Mirza Krak]

On Tue, Sep 4, 2018 at 2:39 PM, Mirza Krak <mirza...@northern.tech> wrote:
> On Tue, Sep 4, 2018 at 12:26 PM, Ahmed abdelhalim
> <ahmedabde...@gmail.com> wrote:
>> I have found the problem. It is something actually very strange.
>>
>> When I request the download link using the API, then the created download
>> link looks like this -->
>>
>> https://<My Mender IP
>> Server>:9000/mender-artifact-storage/5f2b9a1c-1e22-4746-ae33-13bfa52bd2f4?X-Amz-Algoender-deployments%2F20180904%2Fus-east-1%2Fs3%2Faws4_request\u0026X-Amz-Date=20180904T092647Z\u0026X-Amz-Expires=900\u0026X-Amz-SignedHeaders=host\u0026response-content-type=application%2Fvnd.mender-artifact\u0026X-Amz-Signature=440e2b9d97b6d3703eb6930f53c21fd54c5cb5583334a90a0af4c56315e3ae96
>
> Actually what seems to be going on here is that you might have skipped
> running a JSON decode on the API response, could that be the case? You
> can typically use "jq" for this.

Yepp, verified this. The following:

curl -H "Authorization: Bearer $JWT"
$MENDER_SERVER_URI/api/management/v1/deployments/artifacts/{id}/download
| jq

produces a valid link.

[Ahmed abdelhalim]

Hi Mirza,

i created this bug with this ID MEN-2082 . 

Thanks

Kind regards

Ahmed

[Ahmed abdelhalim]

Hi Mirza,

I didn't actually use the json decode. That was the problem then. Many Thanks again.

Kind regards

Ahmed