Mender 2.4 on-premise released: New automation features

Hello everyone,

We want to let you know that we have released the on-premise production editions of Mender 2.4.0 and 2.3.1 packed with brand new feature improvements.

Learn more on this blog post.

As always, we appreciate your support and please continue giving us your great feedback.

Best regards,
Mender Team

Thanks for the update, the new features definitely appear to be very nice!

For those wondering about compatibility, the documentation mentions how the client/server and artefact API interact.

I’m trying ot upgrade from Mender 2.3.0 to 2.4.0. All works well, except that the deployments service stays unreachable. It doesn’t have an ip on the internal network, and the API gateway cannot reach it.
Is this a known thing? What did I goof up?

I already found out it has to do with my trying to put the storage stuff from 9000 onto a different domain and port 443.
Is that something that’s just impossible to do?

I forgot to mention: I have mender running on a ubuntu server, with nginx in front to ensure proper certificates.
When I tell storage-proxy to use port 443, ./run up -d shows that 443 is already in use (which makes sense, as that’s where nginx is running), putting it in another port, means the deployments service cannot access it (if i tell deployments to just access https://my-domain/)

My goal is to have client devices only access stuff on port 443 on my server.

Hello @mterwoord,

thank you for using Mender.
Does setting DEPLOYMENTS_AWS_URI: https://your-own-s3-hostname:443 work?

peter

P.S.
do you use the same hostname for both the server and s3 storage? (that will not work if the port is the same)

I’m using mender. and mender-storage..
I adjusted the DEPLOYMENTS_AWS_URI to ready https://mender-storage.:443

I’m using nginx as a reverse proxy. When I set the storage-proxy to use “443:443” as ports, that conflicts with nginx running on port 443. Leaving storage-proxy at 9000:9000 and DEPLOYMENTS_AWS_URI at 443, means the deployments container (for example) will try to access the storage-proxy on port 443, using the internal (docker) IP.

Somehow I feel I need to change the port the storage-proxy listens to in the docker container.