So I recently made a change to our chef-client settings so that we specify
that our chef server, chef.trstone.com, is set as no_proxy. However, even
after setting that, one of our users is seeing this output:
38947 ==> default: [2015-04-16T21:52:14+00:00] DEBUG: Chef::HTTP
calling Chef::HTTP::ValidateContentLength#handle_request
38948 ==> default: [2015-04-16T21:52:14+00:00] DEBUG: Using
ashproxy.lan.flt:3128 for proxy
38949 ==> default: [2015-04-16T21:52:14+00:00] DEBUG: Initiating GET
to https://chef.trstone.com/organizations/homeslice/nodes/kburnett-vagrant
I am assuming that that log message simply indicates what was being
referenced via http_proxy and https_proxy. Is there a way to confirm that
chef-client is not using that proxy server to talk to the Chef server?
I mean, I’m pretty sure it’s working, by looking at the access.log on the
squid boxes, but being able to confirm it from the perspective of
chef-client itself would be a good thing.
Thanks.
–
~~ StormeRider ~~
“Every world needs its heroes […] They inspire us to be better than we
are. And they protect from the darkness that’s just around the corner.”
(from Smallville Season 6x1: “Zod”)
On why I hate the phrase “that’s so lame”… http://bit.ly/Ps3uSS