Bug 1266989 - Redirect issues due to changing to 172.16.x.x network
Redirect issues due to changing to 172.16.x.x network
Product: OpenShift Online
Classification: Red Hat
Component: Image (Show other bugs)
Unspecified Unspecified
unspecified Severity low
: ---
: ---
Assigned To: Timothy Williams
DeShuai Ma
Depends On:
  Show dependency treegraph
Reported: 2015-09-28 14:26 EDT by Ryan Howe
Modified: 2015-12-18 15:08 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-12-18 15:08:08 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 749733 None None None Never

  None (edit)
Description Ryan Howe 2015-09-28 14:26:41 EDT
Description of problem:

This issue is related to our VPC migration in early August.  This migration moved us from a 10.x.x.x network to a 172.16.x.x network.  According to the RemoteIPValve documentation for the internalProxies at https://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/catalina/valves/RemoteIpValve.html :

"By default, 10/8, 192.168/16, 169.254/16 and 127/8 are allowed ; 172.16/12 has not been enabled by default because it is complex to describe with regular expressions"

The solution is to define the Valve in context.xml slightly differently from what the knowledgebase article describes.  The following should work:

    <Valve className="org.apache.catalina.valves.RemoteIpValve"
            internalProxies="169\.254\.\d{1,3}\.\d{1,3}|127\.\d{1,3}\.\d{1,3}\.\d{1,3}|172.16.\d{1,2}.\d{1,3}" />

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:

# rhc app create jbossews-2.0 -a work -s
# rhc cartridge scale jbossews-2.0 --min 2 --max 2 -a work

Follow previous instructions  

-git add commit push
-in private window test  the results are weird because everything works but then if you try again with a private window it doesn't

- curl to local gear passes

Actual results:

- Redirect error 

Expected results:

- Work like it did in the past. 

Additional info:

Since we have moved from a 10.x.x.x network to a 172.16.x.x network, should we update the online docs or provide an announcement?
Comment 2 Timothy Williams 2015-12-18 15:08:08 EST
We do not plan on changing the cartridge. This is due to the change allowing all addresses rather than just the addresses. Instead, we've made the article that describes the workaround public to all users. This should allow users who may still be hitting this issue to find a workaround:


Closing this.

Note You need to log in before you can comment on or make changes to this bug.