Chef-client 3.0.0 and proxies

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.

Is it somewhere and I’m just not spotting it?


Alex Kiernan

Hi,

On 6/12/13 2:51 AM, Alex Kiernan wrote:

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.

Sincerely,

Steven

Steven Danna
Systems Engineer, Opscode, Inc
GPG Key: http://stevendanna.github.com/downloads/code/public.key

On 13 Jun 2013 07:38, "Steven Danna" steve@opscode.com wrote:

Hi,

On 6/12/13 2:51 AM, Alex Kiernan wrote:

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.

Doesn't this unless block have it covered?

--
Joshua Timberman

On Thursday, June 13, 2013 at 1:55, Alex Kiernan wrote:

On 13 Jun 2013 07:38, "Steven Danna" <steve@opscode.com (mailto:steve@opscode.com)> wrote:

Hi,

On 6/12/13 2:51 AM, Alex Kiernan wrote:

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.

On 6/13/13 7:06 AM, Joshua Timberman wrote:

Doesn't this unless block have it covered?
chef-client/templates/default/client.rb.erb at main · chef-boneyard/chef-client · GitHub

That covers http_proxy, but not https_proxy or no_proxy.

--
Joshua Timberman

On Thursday, June 13, 2013 at 1:55, Alex Kiernan wrote:

On 13 Jun 2013 07:38, "Steven Danna" <steve@opscode.com
mailto:steve@opscode.com> wrote:

Hi,

On 6/12/13 2:51 AM, Alex Kiernan wrote:

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.

--
Steven Danna
Systems Engineer, Opscode, Inc
GPG Key: http://stevendanna.github.com/downloads/code/public.key

On Jun 13, 2013, at 9:07 AM, Steven Danna steve@opscode.com wrote:

On 6/13/13 7:06 AM, Joshua Timberman wrote:

Doesn't this unless block have it covered?
chef-client/templates/default/client.rb.erb at main · chef-boneyard/chef-client · GitHub

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.

On Fri, Jun 14, 2013 at 5:38 PM, Joshua Timberman joshua@opscode.com wrote:

On Jun 13, 2013, at 9:07 AM, Steven Danna steve@opscode.com wrote:

On 6/13/13 7:06 AM, Joshua Timberman wrote:

Doesn't this unless block have it covered?
chef-client/templates/default/client.rb.erb at main · chef-boneyard/chef-client · GitHub

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!

--
Alex Kiernan