Date   

Re: Looking for users with user cases for HTTP/2

Carlo Alberto Ferraris
 

Shannon,
great to hear things are starting to move.

  • Do you have workloads that currently leverage HTTP/2, or for which you would like to leverage H2?
  • What problem does HTTP/2 solve for you?
  • Are you using TCP routing to run apps on PAS that leverage H2?
  • If TCP Routing is not a viable solution, why?
From https://github.com/cloudfoundry/gorouter/issues/195#issuecomment-345648001:
gRPC support is one of the most commonly requested features even from our customers. Sure, they can use TCP routing but then they lose a whole lot of the gorouter out-of-the-box experience (path/hostname routing, logging, TLS termination, ...)
We haven't rolled out TCP routing yet precisely because we don't want to push users looking for H2 in the direction of having to reimplement the same functionalities over and over. This is something that the platform should definitely do on their behalf.

  • Do these apps require access to the certificate of the originating client (mutual auth), or is one-way TLS sufficient?
one-way would be sufficient in our case

  • Is HTTP/2 without TLS viable for any use cases?
Currently, we do TLS termination before the gorouter. I can think of a single reason we may want to move away from this approach, and that is if gorouter was *required* to terminate TLS (e.g. in case of user-provided TLS certificates we discussed in Basel)

I'm available for any further discussion, here or on slack.

Carlo


Re: Announcing TLS from Gorouter to app containers: Delivering three important outcomes

Krannich, Bernd <bernd.krannich@...>
 

Same here! Congrats from the SAP side of the house to the teams for getting this in!

 

Regards,

Bernd

 

From: <cf-dev@...> on behalf of Dieu Cao <dcao@...>
Reply-To: "cf-dev@..." <cf-dev@...>
Date: Saturday, 17. February 2018 at 05:44
To: "cf-dev@..." <cf-dev@...>
Subject: Re: [cf-dev] Announcing TLS from Gorouter to app containers: Delivering three important outcomes

 

Extremely excited to see this great milestone reached! Congrats to the Routing and Diego teams!

 

Dieu

 

On Feb 16, 2018 7:47 PM, "Dr Nic Williams" <drnicwilliams@...> wrote:

Congrats on the work!

 


From: cf-dev@... <cf-dev@...> on behalf of David Sabeti <dsabeti@...>
Sent: Friday, February 16, 2018 10:08:40 PM
To:
cf-dev@...
Subject: Re: [cf-dev] Announcing TLS from Gorouter to app containers: Delivering three important outcomes

 

Congrats! Let me know if/when you want route integrity enabled by default in cf-deployment.

On Fri, Feb 16, 2018 at 6:08 PM Shannon Coen <scoen@...> wrote:

On behalf of Eric Malm, the CF Diego team, and the CF Routing team, I am thrilled to announce three exciting improvements to Cloud Foundry, rolled up in one big shiny feature, available now using this operations file with cf-deployment 1.15.0. If these sound valuable to you, please give it a try and send us your feedback.

 

  1. Increased security: Gorouter will encrypt traffic to application containers via TLS.
  2. Increased resiliency: Gorouter will ignore the TTL of app routes, keeping your apps available during failures in the routing control plane.
  3. Increased guarantees against misrouting: Gorouter will use the certificate presented in the TLS handshake to validate the identity of application instances before forwarding HTTP requests. Optimizing for availability increases the risk of misrouting, as a healthy Diego will continue recreating containers to keep your apps running and the probability of port reuse is statistically significant.

 

All this without any additional burden on application developers. Cloud Foundry will automatically generate the necessary certificates for each container, rotate them periodically, and use them to transparently terminate TLS for traffic from Gorouter. This effort represents our first integration with Envoy, a feature-rich proxy developed at Lyft and recently contributed to the CNCF, laying a foundation for future Istio-driven polyglot service-mesh features in Cloud Foundry. When the feature is enabled, Cloud Foundry runs an Envoy proxy in each application container for terminating TLS and increases container resource quotas to avoid any impact to the application.

 

We're currently rolling this feature out on Pivotal Web Services, where we'll watch how the system performs for a bit before making this configuration the default in cf-deployment, eliminating the need for an operations file.



For details and configuration instructions, please see our documentation:



The original proposal for the feature can be found here.


In addition to replying to this announcement, feedback can be provided in the Cloud Foundry team Slack channels #diego and #routing.



Best,


Shannon Coen

Product Manager, Cloud Foundry

Pivotal, Inc.


Re: bosh cf login on openstack

Russell Blue
 

Hi,

I deployed octavia load balancer on openstack and created Cloud Foundry vms.  How to configure the dns to resolve all *.pcontroler to  a routing layer? I dont have dns server.

when I 'cf login' get error:

 cf login --skip-ssl-validation

API endpoint> api.pcontroller   
FAILED
Error performing request: Get https://api.pcontoller/v2/info: dial tcp: lookup api.pcontoller on 192.168.55.1:53: no such host
TIP: If you are behind a firewall and require an HTTP proxy, verify the https_proxy environment variable is correctly set. Else, check your network connection.


On Tue, Jan 30, 2018 at 09:31 pm, Yitao Jiang wrote:
ssuming your ​domain for management is pcontroller
You need to configure the dns to resolve all *.pcontrole


cf deploy on openstack

Russell Blue
 

Hi

I get error:

Task 14684 | 13:46:15 | Updating instance api: api/da650517-d65a-4553-8a26-9814566c92b0 (0) (canary) (00:16:19)
L Error: Action Failed get_task: Task a207b0ae-0a61-4adb-429d-9be7aa0567d5 result: 1 of 7 pre-start scripts failed. Failed Jobs: cloud_controller_ng. Successful Jobs: cc_uploader, file_server, policy-server-internal, routing-api, route_registrar, consul_agent

Then I ssh api vm:

bosh -e bosh-1 -d cf ssh api --gw-user jumpbox --gw-host 172.101.23.10 --gw-private-key jumpbox.key

api/da650517-d65a-4553-8a26-9814566c92b0:~$ sudo vim /var/vcap/sys/log/cloud_controller_ng/pre-start.stdout.log

[2018-02-14 13:33:30+0000] bosh dns is-system-resolver script not present, using consul
[2018-02-14 13:33:31+0000] Running migrations
[2018-02-14 13:33:31+0000] Running migration try number 1 of 3
[2018-02-14 13:33:32+0000] `/` is not writable.
[2018-02-14 13:33:32+0000] Bundler will use `/tmp/bundler/home/unknown' as your home directory temporarily.
[2018-02-14 13:46:03+0000] `/` is not writable.
[2018-02-14 13:46:03+0000] Bundler will use `/tmp/bundler/home/unknown' as your home directory temporarily.
[2018-02-14 13:46:15+0000] DB seeding failed


Please help me,


Re: Announcing TLS from Gorouter to app containers: Delivering three important outcomes

Dieu Cao <dcao@...>
 

Extremely excited to see this great milestone reached! Congrats to the Routing and Diego teams!

Dieu

On Feb 16, 2018 7:47 PM, "Dr Nic Williams" <drnicwilliams@...> wrote:
Congrats on the work!


From: cf-dev@... <cf-dev@...> on behalf of David Sabeti <dsabeti@...>
Sent: Friday, February 16, 2018 10:08:40 PM
To: cf-dev@...
Subject: Re: [cf-dev] Announcing TLS from Gorouter to app containers: Delivering three important outcomes
 
Congrats! Let me know if/when you want route integrity enabled by default in cf-deployment.

On Fri, Feb 16, 2018 at 6:08 PM Shannon Coen <scoen@...> wrote:

On behalf of Eric Malm, the CF Diego team, and the CF Routing team, I am thrilled to announce three exciting improvements to Cloud Foundry, rolled up in one big shiny feature, available now using this operations file with cf-deployment 1.15.0. If these sound valuable to you, please give it a try and send us your feedback.


  1. Increased security: Gorouter will encrypt traffic to application containers via TLS.

  2. Increased resiliency: Gorouter will ignore the TTL of app routes, keeping your apps available during failures in the routing control plane.

  3. Increased guarantees against misrouting: Gorouter will use the certificate presented in the TLS handshake to validate the identity of application instances before forwarding HTTP requests. Optimizing for availability increases the risk of misrouting, as a healthy Diego will continue recreating containers to keep your apps running and the probability of port reuse is statistically significant.


All this without any additional burden on application developers. Cloud Foundry will automatically generate the necessary certificates for each container, rotate them periodically, and use them to transparently terminate TLS for traffic from Gorouter. This effort represents our first integration with Envoy, a feature-rich proxy developed at Lyft and recently contributed to the CNCF, laying a foundation for future Istio-driven polyglot service-mesh features in Cloud Foundry. When the feature is enabled, Cloud Foundry runs an Envoy proxy in each application container for terminating TLS and increases container resource quotas to avoid any impact to the application.


We're currently rolling this feature out on Pivotal Web Services, where we'll watch how the system performs for a bit before making this configuration the default in cf-deployment, eliminating the need for an operations file.


For details and configuration instructions, please see our documentation:


The original proposal for the feature can be found here.

In addition to replying to this announcement, feedback can be provided in the Cloud Foundry team Slack channels #diego and #routing.

Best,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.


Re: Announcing TLS from Gorouter to app containers: Delivering three important outcomes

Dr Nic Williams <drnicwilliams@...>
 

Congrats on the work!


From: cf-dev@... <cf-dev@...> on behalf of David Sabeti <dsabeti@...>
Sent: Friday, February 16, 2018 10:08:40 PM
To: cf-dev@...
Subject: Re: [cf-dev] Announcing TLS from Gorouter to app containers: Delivering three important outcomes
 
Congrats! Let me know if/when you want route integrity enabled by default in cf-deployment.

On Fri, Feb 16, 2018 at 6:08 PM Shannon Coen <scoen@...> wrote:

On behalf of Eric Malm, the CF Diego team, and the CF Routing team, I am thrilled to announce three exciting improvements to Cloud Foundry, rolled up in one big shiny feature, available now using this operations file with cf-deployment 1.15.0. If these sound valuable to you, please give it a try and send us your feedback.


  1. Increased security: Gorouter will encrypt traffic to application containers via TLS.

  2. Increased resiliency: Gorouter will ignore the TTL of app routes, keeping your apps available during failures in the routing control plane.

  3. Increased guarantees against misrouting: Gorouter will use the certificate presented in the TLS handshake to validate the identity of application instances before forwarding HTTP requests. Optimizing for availability increases the risk of misrouting, as a healthy Diego will continue recreating containers to keep your apps running and the probability of port reuse is statistically significant.


All this without any additional burden on application developers. Cloud Foundry will automatically generate the necessary certificates for each container, rotate them periodically, and use them to transparently terminate TLS for traffic from Gorouter. This effort represents our first integration with Envoy, a feature-rich proxy developed at Lyft and recently contributed to the CNCF, laying a foundation for future Istio-driven polyglot service-mesh features in Cloud Foundry. When the feature is enabled, Cloud Foundry runs an Envoy proxy in each application container for terminating TLS and increases container resource quotas to avoid any impact to the application.


We're currently rolling this feature out on Pivotal Web Services, where we'll watch how the system performs for a bit before making this configuration the default in cf-deployment, eliminating the need for an operations file.


For details and configuration instructions, please see our documentation:


The original proposal for the feature can be found here.

In addition to replying to this announcement, feedback can be provided in the Cloud Foundry team Slack channels #diego and #routing.

Best,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.


Re: Announcing TLS from Gorouter to app containers: Delivering three important outcomes

David Sabeti
 

Congrats! Let me know if/when you want route integrity enabled by default in cf-deployment.


On Fri, Feb 16, 2018 at 6:08 PM Shannon Coen <scoen@...> wrote:

On behalf of Eric Malm, the CF Diego team, and the CF Routing team, I am thrilled to announce three exciting improvements to Cloud Foundry, rolled up in one big shiny feature, available now using this operations file with cf-deployment 1.15.0. If these sound valuable to you, please give it a try and send us your feedback.


  1. Increased security: Gorouter will encrypt traffic to application containers via TLS.

  2. Increased resiliency: Gorouter will ignore the TTL of app routes, keeping your apps available during failures in the routing control plane.

  3. Increased guarantees against misrouting: Gorouter will use the certificate presented in the TLS handshake to validate the identity of application instances before forwarding HTTP requests. Optimizing for availability increases the risk of misrouting, as a healthy Diego will continue recreating containers to keep your apps running and the probability of port reuse is statistically significant.


All this without any additional burden on application developers. Cloud Foundry will automatically generate the necessary certificates for each container, rotate them periodically, and use them to transparently terminate TLS for traffic from Gorouter. This effort represents our first integration with Envoy, a feature-rich proxy developed at Lyft and recently contributed to the CNCF, laying a foundation for future Istio-driven polyglot service-mesh features in Cloud Foundry. When the feature is enabled, Cloud Foundry runs an Envoy proxy in each application container for terminating TLS and increases container resource quotas to avoid any impact to the application.


We're currently rolling this feature out on Pivotal Web Services, where we'll watch how the system performs for a bit before making this configuration the default in cf-deployment, eliminating the need for an operations file.


For details and configuration instructions, please see our documentation:


The original proposal for the feature can be found here.

In addition to replying to this announcement, feedback can be provided in the Cloud Foundry team Slack channels #diego and #routing.

Best,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.


Re: Announcing TLS from Gorouter to app containers: Delivering three important outcomes

Onsi Fakhouri <ofakhouri@...>
 

Bravo!  Such a beautifully integrated solution!

On Feb 16, 2018, at 7:12 PM, Amit Kumar Gupta <agupta@...> wrote:

Wow, that's a beautiful set of improvements, and all rolled into one to boot!  Congrats routing and diego teams!  Looking forward to seeing the real-world data from PWS.

Cheers,
Amit

On Fri, Feb 16, 2018 at 6:07 PM, Shannon Coen <scoen@...> wrote:

On behalf of Eric Malm, the CF Diego team, and the CF Routing team, I am thrilled to announce three exciting improvements to Cloud Foundry, rolled up in one big shiny feature, available now using this operations file with cf-deployment 1.15.0. If these sound valuable to you, please give it a try and send us your feedback.


  1. Increased security: Gorouter will encrypt traffic to application containers via TLS.

  2. Increased resiliency: Gorouter will ignore the TTL of app routes, keeping your apps available during failures in the routing control plane.

  3. Increased guarantees against misrouting: Gorouter will use the certificate presented in the TLS handshake to validate the identity of application instances before forwarding HTTP requests. Optimizing for availability increases the risk of misrouting, as a healthy Diego will continue recreating containers to keep your apps running and the probability of port reuse is statistically significant.


All this without any additional burden on application developers. Cloud Foundry will automatically generate the necessary certificates for each container, rotate them periodically, and use them to transparently terminate TLS for traffic from Gorouter. This effort represents our first integration with Envoy, a feature-rich proxy developed at Lyft and recently contributed to the CNCF, laying a foundation for future Istio-driven polyglot service-mesh features in Cloud Foundry. When the feature is enabled, Cloud Foundry runs an Envoy proxy in each application container for terminating TLS and increases container resource quotas to avoid any impact to the application.


We're currently rolling this feature out on Pivotal Web Services, where we'll watch how the system performs for a bit before making this configuration the default in cf-deployment, eliminating the need for an operations file.


For details and configuration instructions, please see our documentation:


The original proposal for the feature can be found here.

In addition to replying to this announcement, feedback can be provided in the Cloud Foundry team Slack channels #diego and #routing.

Best,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.



Re: Announcing TLS from Gorouter to app containers: Delivering three important outcomes

Amit Kumar Gupta
 

Wow, that's a beautiful set of improvements, and all rolled into one to boot!  Congrats routing and diego teams!  Looking forward to seeing the real-world data from PWS.

Cheers,
Amit

On Fri, Feb 16, 2018 at 6:07 PM, Shannon Coen <scoen@...> wrote:

On behalf of Eric Malm, the CF Diego team, and the CF Routing team, I am thrilled to announce three exciting improvements to Cloud Foundry, rolled up in one big shiny feature, available now using this operations file with cf-deployment 1.15.0. If these sound valuable to you, please give it a try and send us your feedback.


  1. Increased security: Gorouter will encrypt traffic to application containers via TLS.

  2. Increased resiliency: Gorouter will ignore the TTL of app routes, keeping your apps available during failures in the routing control plane.

  3. Increased guarantees against misrouting: Gorouter will use the certificate presented in the TLS handshake to validate the identity of application instances before forwarding HTTP requests. Optimizing for availability increases the risk of misrouting, as a healthy Diego will continue recreating containers to keep your apps running and the probability of port reuse is statistically significant.


All this without any additional burden on application developers. Cloud Foundry will automatically generate the necessary certificates for each container, rotate them periodically, and use them to transparently terminate TLS for traffic from Gorouter. This effort represents our first integration with Envoy, a feature-rich proxy developed at Lyft and recently contributed to the CNCF, laying a foundation for future Istio-driven polyglot service-mesh features in Cloud Foundry. When the feature is enabled, Cloud Foundry runs an Envoy proxy in each application container for terminating TLS and increases container resource quotas to avoid any impact to the application.


We're currently rolling this feature out on Pivotal Web Services, where we'll watch how the system performs for a bit before making this configuration the default in cf-deployment, eliminating the need for an operations file.


For details and configuration instructions, please see our documentation:


The original proposal for the feature can be found here.

In addition to replying to this announcement, feedback can be provided in the Cloud Foundry team Slack channels #diego and #routing.

Best,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.



Announcing TLS from Gorouter to app containers: Delivering three important outcomes

Shannon Coen
 

On behalf of Eric Malm, the CF Diego team, and the CF Routing team, I am thrilled to announce three exciting improvements to Cloud Foundry, rolled up in one big shiny feature, available now using this operations file with cf-deployment 1.15.0. If these sound valuable to you, please give it a try and send us your feedback.


  1. Increased security: Gorouter will encrypt traffic to application containers via TLS.

  2. Increased resiliency: Gorouter will ignore the TTL of app routes, keeping your apps available during failures in the routing control plane.

  3. Increased guarantees against misrouting: Gorouter will use the certificate presented in the TLS handshake to validate the identity of application instances before forwarding HTTP requests. Optimizing for availability increases the risk of misrouting, as a healthy Diego will continue recreating containers to keep your apps running and the probability of port reuse is statistically significant.


All this without any additional burden on application developers. Cloud Foundry will automatically generate the necessary certificates for each container, rotate them periodically, and use them to transparently terminate TLS for traffic from Gorouter. This effort represents our first integration with Envoy, a feature-rich proxy developed at Lyft and recently contributed to the CNCF, laying a foundation for future Istio-driven polyglot service-mesh features in Cloud Foundry. When the feature is enabled, Cloud Foundry runs an Envoy proxy in each application container for terminating TLS and increases container resource quotas to avoid any impact to the application.


We're currently rolling this feature out on Pivotal Web Services, where we'll watch how the system performs for a bit before making this configuration the default in cf-deployment, eliminating the need for an operations file.


For details and configuration instructions, please see our documentation:


The original proposal for the feature can be found here.

In addition to replying to this announcement, feedback can be provided in the Cloud Foundry team Slack channels #diego and #routing.

Best,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.


Re: HTTP error code when route not found

Mike Youngstrom
 

Here is a thread from the past that might help: https://lists.cloudfoundry.org/g/cf-dev/message/4503

Mike

On Fri, Feb 16, 2018 at 3:50 AM, John Mcteague <john@...> wrote:
When a route is not found by the gorouter, clients receive a http 404, which can be confusing for some downstream clients as its hard to distinguish between the resource in my app is not found vs the entire app is not found.

502 bad gateway is used in CF when the route is known but it is temporarily unable to reach the app backend.

Is there any thought on changing the error the gorouter returns in this scenario to help provide clients more meaningful information.Checking the X-cf-routererror header (which returns unknown_route) is not desirable as this starts to bake in CF specific behaviours into applications.

Thanks,
John



Noisy Neighbor Nozzle CLI - Quickly Determine High Volume Log Producers #loggregator

Adam Hevenor
 

Nearly all log reliability problems on CF can be attributed to two main factors. Improper scaling or "noisy neighbor" applications. For the former you can install logmon, check the scaling recommendations published by Pivotal and learn about our capacity planning methodology in our whitepaper.  For the latter Operators have had to rely on their own solutions until now. The Noisy Neighbor Nozzle is a set of nozzle applications and a CLI Plugin that make it easy to identify applications that are logging excessively (after some time playing with it we built in a color threshold at 1,000,000 logs per minute). We worked with several customers as part of Pivotal's early access program to make this nozzle easy to deploy and quickly utilize from the Command Line. We also have included an example "accumulator" that will send the results to datadog and allow operators to operationalize their monitoring of these events. One more thing...it's backwards compatible to nearly all versions of Cloud Foundry since it uses a simple methodology of counting logs through the Firehose.  



To learn more about how this helps Operators check out my post on Rapid Troubleshooting of the Cloud Foundry Logging System on Medium


HTTP error code when route not found

John Mcteague <john@...>
 

When a route is not found by the gorouter, clients receive a http 404, which can be confusing for some downstream clients as its hard to distinguish between the resource in my app is not found vs the entire app is not found.

502 bad gateway is used in CF when the route is known but it is temporarily unable to reach the app backend.

Is there any thought on changing the error the gorouter returns in this scenario to help provide clients more meaningful information.Checking the X-cf-routererror header (which returns unknown_route) is not desirable as this starts to bake in CF specific behaviours into applications.

Thanks,
John


Re: Tomcat Internal Proxies with Load Balancer #cf

Jon Martin
 

Dan,
Yes, the approach outlined in my initial post works fine with server.tomcat.internal-proxies and an embedded Tomcat.

Ben,
I'll run what you said regarding network configuration by some folks on my end.  My concern with using external Tomcat config is the additional maintenance (web servers) and complexity for development teams (required env vars).


Re: Tomcat Internal Proxies with Load Balancer #cf

Daniel Mikusa
 

On Thu, Feb 15, 2018 at 11:58 AM, Matthias Winzeler <matthias.winzeler@...> wrote:
Hi Jon

We're facing a similar issue for which we have a PR created: https://github.com/cloudfoundry/java-buildpack/pull/546 

From some informal discussions with the the buildpack maintainers, it seems like this is not gonna be merged, because they don't want to support some specific tomcat conf parameters.
We were pointed to providing a custom Tomcat external configuration (as per https://github.com/cloudfoundry/java-buildpack/blob/master/docs/container-tomcat.md#external-tomcat-configuration) that could also be set as standard env group (and thus be operator-friendly), but it looks like we can not ship one external config that works for both Tomcat 7 and Tomcat 8.

Be aware that this would only solve the issue for standalone Tomcat. If your apps use it in the embedded form, they still have to write custom Spring config for it. 

You can configure that in all the ways supported by Spring Boot (i.e. env variable, system propertie, application.properties, etc...).  Env variables work nice if you have lots of Spring Boot apps, as you can set it in a running environment variable group so it'll go across all your apps.

Hope that helps!

Dan

 
This is probably also true for other app runtimes; I know at least of .NET core which also defines 'KnownProxies.

-Matthias

2018-02-15 17:15 GMT+01:00 Jon Martin <martindesignonline@...>:
We are in the process of standing up several PCF foundations in multiple locations.  Each foundation is fronted by a dedicated load balancer.  For Java application's we were noticing that httpRequest.getScheme() and httpRequest.getServerPort() where returning "http" and "80" respectively even though the load balancer forces the use of "https" and "443".

This led us to Tomcat's remoteIpValve documentation:
https://tomcat.apache.org/tomcat-8.5-doc/api/org/apache/catalina/valves/RemoteIpValve.html

In the Java Buildpack, adding an internalProxies attribute to Tomcat's RemoteIpValve with a regex that matched the ERT subnet of the foundation solved the problem.  A similar approach can be used for embedded Tomcat:
https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#howto-customize-tomcat-behind-a-proxy-server 

The problems we're trying to solve are:

  1. The ERT subnet regex will be different for each foundation
  2. We don't want to maintain multiple Java buildpacks for each foundation to support a single property value in Tomcat's server.xml
  3. The solution needs to solve for both standalone and embedded Tomcat's
We're trying to implement a solution with minimal maintenance and complexity for operators and developers.  That said, we're thinking we could configure an environment variable group with the ERT subnet regex for each foundation. 

  • For embedded Tomcat the environment variable group would be referenced in the application.  For example: server.tomcat.internal-proxies=${ERT_SUBNET}
  • For standalone Tomcat the environment variable group would be referenced in server.xml. e.g. internalProxies="${ERT_SUBNET}
The two questions I have are:
  1. Would we need to set an environment variable group or is the ERT subnet available in some form already at runtime.
  2. Would the Java Buildpack need to be updated to support standalone Tomcat.
  3. I'm assuming other companies have run into this, is there a standard supported means to solve this already?




--



Re: Tomcat Internal Proxies with Load Balancer #cf

Ben Hale <bhale@...>
 

From some informal discussions with the the buildpack maintainers, it seems like this is not gonna be merged, because they don't want to support some specific tomcat conf parameters.
We were pointed to providing a custom Tomcat external configuration (as per https://github.com/cloudfoundry/java-buildpack/blob/master/docs/container-tomcat.md#external-tomcat-configuration) that could also be set as standard env group (and thus be operator-friendly), but it looks like we can not ship one external config that works for both Tomcat 7 and Tomcat 8.
At this time I'm not planning on adding support for configuring the internalProxies explicitly both because it sets a precedent that I'm not comfortable with, and that it hasn't shown to be a big issue so far. In nearly every single installation of CF, the incoming request from either the `gorouter` or some other replacement for it comes via a Class A, B, or C private IP address. Even in cases where the router has a public IP address (like an F5 at the network edge), that router has a **second** private IP address for communicating back to the CF application instances. In this case, Tomcat's standard configuration works well. Needing to configure this value is only required in systems where the edge router communicates back to the application instances using a public (non-Class A, B, or C) IP address.

This is not to say that your networks are not configured in such a way that the application instances are called from public IP addresses, but rather that it's a rare enough occurrence that I don't feel the need to promote it to a top-level configuration item rather than using existing configuration strategies. I'm open to being convinced otherwise by issues/upvotes in GitHub.


-Ben Hale
Cloud Foundry Java Experience


Re: Tomcat Internal Proxies with Load Balancer #cf

Matthias Winzeler
 

Hi Jon

We're facing a similar issue for which we have a PR created: https://github.com/cloudfoundry/java-buildpack/pull/546 

From some informal discussions with the the buildpack maintainers, it seems like this is not gonna be merged, because they don't want to support some specific tomcat conf parameters.
We were pointed to providing a custom Tomcat external configuration (as per https://github.com/cloudfoundry/java-buildpack/blob/master/docs/container-tomcat.md#external-tomcat-configuration) that could also be set as standard env group (and thus be operator-friendly), but it looks like we can not ship one external config that works for both Tomcat 7 and Tomcat 8.

Be aware that this would only solve the issue for standalone Tomcat. If your apps use it in the embedded form, they still have to write custom Spring config for it. 
This is probably also true for other app runtimes; I know at least of .NET core which also defines 'KnownProxies.

-Matthias

2018-02-15 17:15 GMT+01:00 Jon Martin <martindesignonline@...>:

We are in the process of standing up several PCF foundations in multiple locations.  Each foundation is fronted by a dedicated load balancer.  For Java application's we were noticing that httpRequest.getScheme() and httpRequest.getServerPort() where returning "http" and "80" respectively even though the load balancer forces the use of "https" and "443".

This led us to Tomcat's remoteIpValve documentation:
https://tomcat.apache.org/tomcat-8.5-doc/api/org/apache/catalina/valves/RemoteIpValve.html

In the Java Buildpack, adding an internalProxies attribute to Tomcat's RemoteIpValve with a regex that matched the ERT subnet of the foundation solved the problem.  A similar approach can be used for embedded Tomcat:
https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#howto-customize-tomcat-behind-a-proxy-server 

The problems we're trying to solve are:

  1. The ERT subnet regex will be different for each foundation
  2. We don't want to maintain multiple Java buildpacks for each foundation to support a single property value in Tomcat's server.xml
  3. The solution needs to solve for both standalone and embedded Tomcat's
We're trying to implement a solution with minimal maintenance and complexity for operators and developers.  That said, we're thinking we could configure an environment variable group with the ERT subnet regex for each foundation. 

  • For embedded Tomcat the environment variable group would be referenced in the application.  For example: server.tomcat.internal-proxies=${ERT_SUBNET}
  • For standalone Tomcat the environment variable group would be referenced in server.xml. e.g. internalProxies="${ERT_SUBNET}
The two questions I have are:
  1. Would we need to set an environment variable group or is the ERT subnet available in some form already at runtime.
  2. Would the Java Buildpack need to be updated to support standalone Tomcat.
  3. I'm assuming other companies have run into this, is there a standard supported means to solve this already?




--
Matthias Winzeler
Mattenenge 8
3011 Bern
mailto: matthias.winzeler@...


Tomcat Internal Proxies with Load Balancer #cf

Jon Martin
 
Edited

We are in the process of standing up several PCF foundations in multiple locations.  Each foundation is fronted by a dedicated load balancer.  For Java application's we were noticing that httpRequest.getScheme() and httpRequest.getServerPort() where returning "http" and "80" respectively even though the load balancer forces the use of "https" and "443".

This led us to Tomcat's remoteIpValve documentation:
https://tomcat.apache.org/tomcat-8.5-doc/api/org/apache/catalina/valves/RemoteIpValve.html

In the Java Buildpack, adding an internalProxies attribute to Tomcat's RemoteIpValve with a regex that matched the ERT subnet of the foundation solved the problem.  A similar approach can be used for embedded Tomcat:
https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#howto-customize-tomcat-behind-a-proxy-server 

The problems we're trying to solve are:

  1. The ERT subnet regex will be different for each foundation
  2. We don't want to maintain multiple Java buildpacks for each foundation to support a single property value in Tomcat's server.xml
  3. The solution needs to solve for both standalone and embedded Tomcat's
We're trying to implement a solution with minimal maintenance and complexity for operators and developers.  That said, we're thinking we could configure an environment variable group with the ERT subnet regex for each foundation. 

  • For embedded Tomcat the environment variable group would be referenced in the application.  For example: server.tomcat.internal-proxies=${ERT_SUBNET}
  • For standalone Tomcat the environment variable group would be referenced in server.xml. e.g. internalProxies="${ERT_SUBNET}
The questions I have are:
  1. Would we need to set an environment variable group or is the ERT subnet available in some form already at runtime.
  2. Would the Java Buildpack need to be updated to support standalone Tomcat.
  3. I'm assuming other companies have run into this, is there a standard supported means to solve this already?


How to rotate the CA certificate of the service_cf_internal_ca

Steffen Uhlig
 

Hi,

has anyone successfully rotated the CA certificate of the service_cf_internal_ca in a cf-deployment? Are there instructions more detailed than those for consul?

We are using cf-deployment at v1.14.0 and put an additional CA certificate (generated with bosh) on top of the existing CA cert. The deployment runs fine, but smoke tests fail with:

Stager is unavailable: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed

More details can be found in this bits-service story.

Any help or pointers are appreciated.

Regards

Steffen


Invoking a cloud foundry API having Basic authentication using Autosys HTTP job

shruthi s
 

Hi,
I have spring boot REST API having Basic authentication hosted in cloud foundry. I am using Autosys HTTP job to call the API periodically and it is not working. The Autosys job is sending in credentials but the logs in PCF app shows null. 
Has anybody tried anything like this ? Any suggestions or ideas will be helpful 

1681 - 1700 of 9425