[PUP-10106] no_proxy does not exclude hosts whose FQDN matches based on suffix Created: 2019/10/19  Updated: 2019/11/15  Resolved: 2019/11/12

Status: Resolved
Project: Puppet
Component/s: None
Affects Version/s: PUP 5.5.17
Fix Version/s: PUP 5.5.18, PUP 6.4.5, PUP 6.11.0

Type: Bug Priority: Normal
Reporter: Tom Parker Assignee: Josh Cooper
Resolution: Fixed Votes: 1
Labels: resolved-issue-added
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Template: PUP Bug Template
Agent OS: CentOS 7
Master OS: CentOS 7
Epic Link: Agent HTTP
Team: Coremunity
Sprint: Platform Core KANBAN
Method Found: Needs Assessment
Release Notes: Bug Fix
Release Notes Summary: Puppet will bypass the http proxy if the `no_proxy` environment variable or puppet setting is a suffix of the destination server FQDN. Previously puppet would only bypass the proxy if `no_proxy` had a leading wildcard (*.example.com) or dot (.example.com).
QA Risk Assessment: Needs Assessment

 Description   

Puppet Version: 5.5.17
Puppet Server Version: 5.3.10
OS Name/Version: CentOS 7

Original Summary Since update to puppet 5.5.17 puppetdb forge module cannot connect to puppetdb

Since the update to puppet agent 5.5.17 the puppetdb forge module is using the configured proxy server and ignoring the no_proxy setting when trying to validate the connection to puppetdb.  This worked properly on 5.5.16. 

My environment proxy settings are:

http_proxy=http://ottinstall.ls.cbn:3128
ftp_proxy=http://ottinstall.ls.cbn:3128
https_proxy=http://ottinstall.ls.cbn:3128
no_proxy=ls.cbn, localhost, puppet, 127.0.0.1

My puppetdb server is: https://glycon.ls.cbn:8081

Desired Behavior: 

Respect the no_proxy value ls.cbn and not proxy connections to https://glycon.ls.cbn:8018

Actual Behavior:

opening connection to ottinstall.ls.cbn:3128...
opened
<- "CONNECT glycon.ls.cbn:8081 HTTP/1.1\r\nHost: glycon.ls.cbn:8081\r\n\r\n"
-> "HTTP/1.1 403 Forbidden\r\n"
-> "Server: squid/3.5.20\r\n"
-> "Mime-Version: 1.0\r\n"
-> "Date: Sat, 19 Oct 2019 18:46:40 GMT\r\n"
-> "Content-Type: text/html;charset=utf-8\r\n"
-> "Content-Length: 3448\r\n"
-> "X-Squid-Error: ERR_ACCESS_DENIED 0\r\n"
-> "Vary: Accept-Language\r\n"
-> "Content-Language: en\r\n"
-> "X-Cache: MISS from ottinstall.ls.cbn\r\n"
-> "X-Cache-Lookup: NONE from ottinstall.ls.cbn:80\r\n"
-> "Via: 1.1 ottinstall.ls.cbn (squid/3.5.20)\r\n"
-> "Connection: keep-alive\r\n"
-> "\r\n"
Conn close because of connect error 403 "Forbidden"
Notice: Unable to connect to puppetdb server (https://glycon.ls.cbn:8081): 403 "Forbidden"



 Comments   
Comment by Tom Parker [ 2019/10/19 ]

Further testing shows that the issue is in the handling of no_proxy for a domain match. 

NO_PROXY="ls.cbn, localhost, puppet, 127.0.0.1" fails.

NO_PROXY="glycon.ls.cbn, ls.cbn, localhost, puppet, 127.0.0.1" works.  

As far as I know this is incorrect behaviour as ls.cbn should match *.ls.cbn 

Comment by Josh Cooper [ 2019/10/21 ]

Thanks Tom Parker. This is indeed a behavior change from 5.5.16 as puppet and ruby interpret the no_proxy environment variable differently. Unfortunately there isn't a specification, which makes this more confusing.

In order to exclude hosts in a domain, I'd recommend prefixing the domain with a dot, as in no_proxy=.ls.cbn, localhost, puppet, 127.0.0.1. That syntax should work universally for puppet, curl and ruby 2.4.0 and up

Using the parent domain ls.cbn works for ruby, but not puppet. Other applications may have issues like https://github.com/httplib2/httplib2/pull/95

Using the wildcard *.ls.cbn works for puppet, but not ruby nor curl, so is not recommended.

I'm going to keep this issue open, as it looks like there are some unexpected differences between specifying no_proxy as a puppet setting vs environment variable:

RUBY to http://www.google.com
ENV['no_proxy']
*                => http://proxy.example.com
*.google.com     => http://proxy.example.com
.google.com      => direct
www.google.com   => direct
google.com       => direct
.com             => direct
 
PUPPET to http://www.google.com
ENV['no_proxy']
*                => proxy.example.com
*.google.com     => proxy.example.com
.google.com      => direct
www.google.com   => direct
google.com       => proxy.example.com
.com             => direct
 
PUPPET to http://www.google.com
Puppet[:no_proxy]
*                => direct
*.google.com     => direct
.google.com      => direct
www.google.com   => direct
google.com       => http://proxy.example.com
.com             => direct

Comment by Josh Cooper [ 2019/10/21 ]

Also looks like 6.9.0 and up behave differently than earlier versions when setting no_proxy as an environment variable due to PUP-9990

PUPPET to http://www.google.com
ENV['no_proxy']
*                => direct
*.google.com     => direct
.google.com      => direct
www.google.com   => direct
google.com       => proxy.example.com
.com             => direct

Comment by Tom Parker [ 2019/10/23 ]

Thanks Josh Cooper

 

I will have to do some experiments to see how other applications on my system behave with .ls.cbn vs ls.cbn including python and older versions of ruby.   For everything so far with the exception of puppet/ruby the ls.cbn has always matched.

I appreciate you keeping this ticket open.  The behaviour is indeed odd between ENV[no_proxy] and puppet.conf no_proxy although the .domain seems to be pretty consistent across the various environments and applications.

Comment by Josh Cooper [ 2019/11/09 ]

Merged to 5.5.x in https://github.com/puppetlabs/puppet/commit/38001424b9590bdf40167e50afcda3051a88bed1

Comment by Melissa Stone [ 2019/11/12 ]

This has passed CI as a part of puppet-agent 5.5.17.71.gb6ebce3, 6.4.4.153.g20aeaaf, and 6.10.1.242.gc2f3a9f

Generated at Fri Jul 03 20:38:21 PDT 2020 using Jira 8.5.2#805002-sha1:a66f9354b9e12ac788984e5d84669c903a370049.