minion daemon fails to install packages when environment requires http proxy

[yannis666]

My environment requires access via http proxy.
I use RHEL 6.4 and run salt-minion as a service.
When I try to use state.sls to install packages, I get failures ("Error Downloading Packages" in log)

I have tried setting htt_proxy, https_proxy in ~root/.profile and also in /etc/environment (and re-starting the minion service) but that does not work.

I found prior issues on this:
#5937
#13786
but no indication of what the final resolution is, if any.

[yannis666]

I found a solution that worked. Added proxy to /etc/yum.conf
Maybe this needs to be added to salt-minion configuration?

[tjstansell]

You can also add it to a pkgrepo.managed entry if you want it to only apply to that repo. For instance:

yum.repos.test:
  pkgrepo.managed:
    - proxy: https://{{ proxy_host }}:{{ proxy_port }}/
    - baseurl: https://{{ my_repo_url }}/
    - gpgcheck: 0
    - enabled: 1

[basepi]

I think pkgrepo.managed is probably the right answer here. What do you mean this needs to be added to salt-minion configuration?

[yannis666]

@basepi what I meant is that I expected some parameter in the minion config to set the proxy.
That may not be a good idea, but I could not find any guidelines as to how to overcome the proxy issue when using pkg: install.
I had naively believed that the solution I used in my standard linux env (setting http_proxy in the environment) would work.
I think a low hanging fruit solution would be to add a note in the docs for salt.states.pkg mentioning how to best handle deployments using an http_proxy.

[basepi]

Ya, we wouldn't want to do it as part of the config. However, we could potentially add some sort of state or module to enable this configuration for you, and then you could add it to your workflow. I'm going to mark this as a feature.

[steverweber]

+1
2015.2
I would like /etc/environment vars loaded because of this pkg state and file.manage need to use proxy.
ubuntu 14.04 upstart.

[dove-young]

I don't think pkgrepo.managed is the right answer here.
http_proxy and https_proxy are used system wide and most applications use them as default. Set proxy in pkgrepo.managed makes proxy definitions spread everywhere in your infrastructure. And it did not resolve anything other than pkg installs.

why not load /etc/profile and use environment variables just like everything else does?

[The-Loeki]

I agree with @dove-young ; It's basically a function of the packaging manager. See also #18120

This is also closely related to #8177 and #23617

[andretost]

Looks like this problem has been open since March, is anyone doing anything about it? Running a salt-minion behind a web proxy should be very common and there has to be a simple way of doing it.
The bootstrap script has a parameter -H that claims to insert an HTTP proxy, is that flag not working, or just working for the salt master?

[basepi]

@andretost I think you're misunderstanding, this doesn't have to do with installing salt, but rather installing packages using salt. When salt calls out to yum, yum is not properly using the proxy. I think the solution is likely that we just need to add the ability to set the system-wide proxy so that yum will follow it.

[andretost]

Yes, I realize that, sorry if I sounded confused. :-) I wasn't referring to installing salt. In my concrete case, I am using archive.extracted with a source URL that is behind a proxy. And I set the proxy in /etc/environment. I have a state that runs apt-get in a cmd.run and that works fine (only if I call salt-minion-d, not when I do service salt-minion start). But archive.extracted does not, and posts I found suggest that it is file.managed causing my problem.

[basepi]

Interesting. Was the proxy configured when the minion was started? We may have to look into making sure the minion leverages those environment variables.

[andretost]

I have the proxy defined in /etc/environment before installing the minion. I use the bootstrap script to install the minion (including the -H option with the proxy), which also starts it.
I then do a 'pkill salt-minion' and found the following behavior:

• if I run 'service salt-minion start', it's not picking up the proxy.
• if I run 'http_proxy=... salt-minion -d', it uses the proxy.

Note, though, that I do all this from within an Openstack Heat template, which uses cloud-init to run the logic above. If I simply ssh into my VM and run 'salt-minion -d' from there, it properly picks up the proxy definition. So I take that cloud-init does not pick up stuff from /etc/environment.
In any case, it would be good if I could simply set the proxy as an option somewhere, for example, in the /etc/salt/minion file, so that it just works regardless how and when it gets started.
I hope this makes sense?

[basepi]

Yes, it would be useful to be able to just set it in the minion config. I'm just unsure of the best way to then inject that into the running environment for the minion. It will take some investigation.

[mrproper]

I've done a PR which has been merged which addresses some of these issues, basically you can define: proxy_host/proxy_port/proxy_username/proxy_password in the /etc/salt/minion config and the file.managed resources will use the proxy supplied

#29322

[ginkgo-brandeis]

Old thread. Working solution for my setup.

I've found that upstart does not support /etc/environment, so salt-minion gets started with no environment. If you modify the /etc/init/salt-minion.conf to do "exec su root -c salt-minion" then it starts salt-minion with the environment set

https://serverfault.com/questions/128605/have-upstart-read-environment-from-etc-environment-for-a-service

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.