I’m just looking through chef-client 3.0.0 and its proxy support - one of
the outstanding local patches I had was for https_proxy and no_proxy
support which the config stuff looks like it addresses (and is documented
in the README for those).
The bit I can’t spot is if there’s any support for https_proxy and no_proxy
environment variables so gems work correctly - client.rb.erb addresses the
http_proxy one but not the other two.
The bit I can't spot is if there's any support for https_proxy and
no_proxy environment variables so gems work correctly - client.rb.erb
addresses the http_proxy one but not the other two.
I believe you are correct and that we don't currently set the
environment variables for these items. I don't see an open bug for this
issue in JIRA: http://tickets.opscode.com/browse/COOK but it does seem
like a reasonable addition to the cookbook.
One nice new feature, however, that will let you add this to your config
easily without modifying the chef-client cookbook directly is the
addition of an /etc/chef/client.d/ directory. See the "Configuration
Includes" section of the README for details.
The bit I can't spot is if there's any support for https_proxy and
no_proxy environment variables so gems work correctly - client.rb.erb
addresses the http_proxy one but not the other two.
I believe you are correct and that we don't currently set the
environment variables for these items. I don't see an open bug for this
issue in JIRA: http://tickets.opscode.com/browse/COOK but it does seem
like a reasonable addition to the cookbook.
Thanks for the confirmation. I'll get a ticket opened and code up a pull
request.
One nice new feature, however, that will let you add this to your config
easily without modifying the chef-client cookbook directly is the
addition of an /etc/chef/client.d/ directory. See the "Configuration
Includes" section of the README for details.
Yeah I saw that, though I wasn't sure if that was just for config items or
if you could inject arbitrary assignments. Actually now I stop and think
about it there's no real difference is there.
The bit I can't spot is if there's any support for https_proxy and
no_proxy environment variables so gems work correctly - client.rb.erb
addresses the http_proxy one but not the other two.
I believe you are correct and that we don't currently set the
environment variables for these items. I don't see an open bug for this
issue in JIRA: http://tickets.opscode.com/browse/COOK but it does seem
like a reasonable addition to the cookbook.
Thanks for the confirmation. I'll get a ticket opened and code up a pull request.
One nice new feature, however, that will let you add this to your config
easily without modifying the chef-client cookbook directly is the
addition of an /etc/chef/client.d/ directory. See the "Configuration
Includes" section of the README for details.
Yeah I saw that, though I wasn't sure if that was just for config items or if you could inject arbitrary assignments. Actually now I stop and think about it there's no real difference is there.
The bit I can't spot is if there's any support for https_proxy and
no_proxy environment variables so gems work correctly - client.rb.erb
addresses the http_proxy one but not the other two.
I believe you are correct and that we don't currently set the
environment variables for these items. I don't see an open bug for this
issue in JIRA: http://tickets.opscode.com/browse/COOK but it does seem
like a reasonable addition to the cookbook.
Thanks for the confirmation. I'll get a ticket opened and code up a
pull request.
One nice new feature, however, that will let you add this to your config
easily without modifying the chef-client cookbook directly is the
addition of an /etc/chef/client.d/ directory. See the "Configuration
Includes" section of the README for details.
Yeah I saw that, though I wasn't sure if that was just for config
items or if you could inject arbitrary assignments. Actually now I
stop and think about it there's no real difference is there.
That covers http_proxy, but not https_proxy or no_proxy.
Ah indeed.
Dropping off a file in the client.d is the right thing here, IMO.
Personally I'd rather have first class support - proxy configuration
is a pain which those of us who have it inflicted on us spend hours
tracking down all the places you need to configure it, having one less
place to ensure it gets injected because it arrives our of the box
would be benefit to me. If nothing else the lack of consistency
between http and https seems wrong.
I've most of a patch but I'm just struggling to ensure it's adequately
tested - your ChefSpec blog post was a big help though!