And this reflects as well my observation. My mender client is not able to connect to a mender server inside our company network (which is using HTTP proxy). The HTTP_PROXY setting seems to be ignored.
Question: Did I miss something or is the mender client not supporting HTTP proxy? Is it planned to be supported in the future?
I must admit I am not an expert on this area, but can’t you just use the “internal company IP” of the Mender server directly (instead of HTTP_PROXY)? Mender does require TLS for all communication for security reasons, is that supported with HTTP_PROXY or would HTTPS_PROXY be needed? If support for this requires plaintext communication it is unlikely we can prioritize this due to security requirements, unfortunately. But again I am not an expert.
We are looking at adding support for reverse proxy (with TLS termination and initiation) for potentially different reasons (e.g. to forward requests from device to hosted Mender when there are restrictive security policies in place), not sure if this would be relevant here.
Unfortunately I’m also not an expert on that topic. I just noticed that I get no connection to mender server inside our company network. Same is valid for any other services (such as apt-get, docker pull, pip install, …) as long as I don’t configure HTTP_PROXY and HTTPS_PROXY with our companies proxy.
Once I set HTTP_PROXY and HTTPS_PROXY (and configure all extra portions needed for the different tools which handles proxies differently), all services are running and are able to connect “to the internet”.
All except mender client.
That’s why I wondered if there is any additional setting needed to let mender client connecting to mender server via proxy.
I don’t think reverse proxy (used by servers) helps in this scenario. I’m looking for a forward proxy (used by clients).
This might have been fixed already, do you have the chance to test with Mender 2.2.0 or newer? There is also a Mender 2.3.0 beta right around the corner.
What is the best way to rev the mender-client to 2.2.0 or 2.3.0 to test the HTTP/HTTPS_PROXY env variables? Menderized sdimgs were created using using Mender-convert on raspbian and have client version 2.1.1 I currently have a number of pilot units running behind a proxy.
2.1.2 is the latest of the Mender client, though there is a beta, 2.2.0b1 (technically released already, but not announced, very soon though). Don’t be confused by Mender 2.3, this is the whole product line, but it’s not the same as the client version. There will be a 2.0.0 Beta release of mender-convert soon as well, so just give it a few days.
If by system proxy, you are referring to the internal golang http proxy implementation, then yes.
I saw you edited your post, and will refer to that now, as I noticed there was an s missing in your HTTP_PROXY. I’m pretty sure you need to set the HTTPS_PROXY variable, then this should work transparently.
@oleorhagen, yes, great observation, both HTTP and HTTPS proxys are being added to the environment during boot as part of the provisioning script.
After some review/testing here is some potentially useful data:
The proxy server is also the nameserver and in reviewing HTTP and DNS traffic hosted.mender.io resolves the 3 aws addresses 52.5.180.155, 34.205.112.193, 52.20.53.236
However, following the DNS lookup the proxy appears to be ignored with destinations being set to the aws servers?Src: 10.221.1.138 Dst: 52.5.180.155
Note I downloaded the latest vanilla raspbian build and used the mender-convert master and added HTTP HTTPS proxy address into /etc/environment for testing purposes.
@oleorhagen I hope this information is of use: Although, both env and my shell had the HTTP/HTTPS http/https proxy variables set correctly in my Golden Image and cURL as well as chromium browser would navigate the proxy correctly, Mender would not traverse it.
The current Raspbian Buster Lite download had changes in relation to proxies. There is a file created under sudoers.d/010_proxy with the following entries:
once the file was created on my GI build manually, mender client would check-in and download artifacts as expected.
All that being said I’m a novice, and you may have a better understanding of these changes were needed and why.
but have a second look at your environment setup for the systemd service file for the mender-client.
Good that it works now with the sudo environment (which mender needs). But the HTTPS_PROXY variable can also be set on a unit file basis through the ENVIRONMENT variable
Yes, I was not checking the active environment for mender-client. The HTTPS_PROXY is not added to the mender-client environment during the mender-convert process nor when the service launches. Also, to speed up testing i was launching the mender -daemon which does pull the current environment HTTPS_PROXY. The Squid Proxy server setup added a little more confusion as well. Simply put the HTTPS_PROXY needed to be manually added to the Environment of mender-client.service