Date   

Using a TLS connection to the MySQL database #uaa

Shetty, Viraj S [CTR]
 

We have  a separate instance of UAA server interacting with the MySQL database running on cloud.gov. Recently, we have been advised to use a TLS connection to connect to the database. After doing some research, we found that the TLS certifciate is setup on the MySQL server. How do I make sure that the UAA server can connect to this MySQL server using TLS ? Is there any any configuration in uaa.yml that I can set ? 

Any help would be appreciated ! 

Thanks, 
Viraj 


Community help needed: CFCD version 2 Beta testing

Chip Childers
 

Hi all!

Many thanks to those that helped with the early functional testing of the new CFCD v2 exam! We've moved into beta testing now, and are looking for people that want to attempt the certification test for free. It's a bit easier than version 1, and set to launch right before summit. It's also a three year certification, vs version 1's 2 years.

Beta testing will be the full exam experience, but pass / fail will be determined after we have enough exam takers to set the "cut score" for passing and get the exam fully launched by September.

If interested, signup in this form -> https://forms.gle/JqRRaB6WA5DTkPa2A

You will need to sign up this week, and then we'll share instructions ASAP for you to register in the system to take the exam.

Chip Childers, CTO
Cloud Foundry Foundation


Re: CF Application Runtime PMC: UAA Project Lead Call for Nominations

Eric Malm <emalm@...>
 

Hi, everyone,

Pivotal is nominating Dan Beneke for the UAA Project Lead in the Application Runtime PMC.

Dan Beneke is a Senior Product Manager at Pivotal who has been working on identity topics within the UAA team for the past five months. Dan has held previous positions focused on enterprise technology transformation, and previously worked as a Product Manager within the financial sector for more than nine years.

Please send any other nominations directly to me or in reply to this message no later than 11:59 PM PDT on Monday, August 19, 2019.

Thanks,
Eric Malm

On Mon, Aug 5, 2019 at 2:56 PM Eric Malm <emalm@...> wrote:
Hi, everyone,

Chao Wang, the Project Lead for the UAA team within the Application Runtime PMC, has stepped down from the project, as he has recently left Pivotal. We thank him for his service.

The UAA team, based in San Francisco, now has an opening for its project lead. Project leads must be nominated by a Cloud Foundry Foundation member. Please send nominations directly to me or in reply to this message no later than 11:59 PM PDT on Monday, August 19, 2019.

Also, if you have any questions about the role or the nomination process, as described in the CFF governance documents (https://www.cloudfoundry.org/governance/cff_development_operations_policy/), please let me know.

Thanks,
Eric Malm, CF Application Runtime PMC Lead


CF Application Runtime PMC: UAA Project Lead Call for Nominations

Eric Malm <emalm@...>
 

Hi, everyone,

Chao Wang, the Project Lead for the UAA team within the Application Runtime PMC, has stepped down from the project, as he has recently left Pivotal. We thank him for his service.

The UAA team, based in San Francisco, now has an opening for its project lead. Project leads must be nominated by a Cloud Foundry Foundation member. Please send nominations directly to me or in reply to this message no later than 11:59 PM PDT on Monday, August 19, 2019.

Also, if you have any questions about the role or the nomination process, as described in the CFF governance documents (https://www.cloudfoundry.org/governance/cff_development_operations_policy/), please let me know.

Thanks,
Eric Malm, CF Application Runtime PMC Lead


CFF SIG Lifecycle

Marco Voelz
 

[cross-post for visibility on cf-bosh and cf-dev. Sorry for the spam if you're reading both lists. Future posts about this will be sent to cf-bosh only.]

 

Dear Friends of BOSH,

 

As the kubernetes community keeps growing and getting more traction and attention, we, the CF community, align more closely with the tools and community in the k8s ecosystem. Examples in the Runtime PMC are project Eirini and the ongoing efforts to leverage istio features for routing in CF, etc. Effectively, it seems that we're rebasing CF on top of a new abstraction, which is cool, because it allows us to do new cool things!

 

Within the BOSH PMC, there are also efforts towards installing CF on top of k8s, entirely without BOSH, called project Quarks. Especially when installing a complex and large distributed system like CF, issues with the current state of lifecycle management in the k8s ecosystem become apparent. Even more so if you're used to BOSH, which solves many issues for its users better than most other tools out there. Therefore, we're trying to bring some of the lessons we've learned by working on and with BOSH to the k8s ecosystem.

 

We have established a Lifecycle SIG and wrote down our ideas and opinions in the past few weeks [1]. While this document isn't done, we are at a point, we would like to open the discussion for everyone. If you're interested in participating in the conversation, please read the document and let us know what your think!

 

We appreciate your comments, thoughts, feedback and suggestions! You can reply on the cf-bosh mailing list or reach out in the ways described in the 'contact' section in the document.

 

Thanks and warm regards

Marco for the CFF SIG Lifecycle

 

[1] https://docs.google.com/document/d/1T1ZrwSV9aXWmF1tmUoMyo9M9EvWd07f-Uv5IO7nSmtY/edit#


routing-release 0.190.0

Aidan Obley
 

Hello cf-dev!

We have cut routing-release 0.190.0

Release Highlights

  • Jobs consuming the routing-api link do not fail when routing-api is not present details
  • Routing-API supports deletion of Router Groups details
  • Gorouter does not set the VCAP_ID stickyness cookie if provided by backend details
  • HTTP stop/start metrics emit all tags provided during route registration details
Regards,
The Networking Program


Announcement of planned deprecation of flag options (domains, hostname, route-path) on cf push on the v6 CLI

Abby Chau
 

Hi everyone,

The cf CLI team reached out to the Community back in December 2017 to gather feedback about domains and hostnames app manifest properties. Based on feedback, in cf CLI release v6.34.0, the team moved forward with deprecating domains and hostnames properties in the app manifest in favor of the routes attribute. 

At the time, the flag options to override the manifest properties were not deprecated. On `cf push` these include:
  • --hostname
  • --no-hostname
  • -d for domain
  • --route-path
This email announces planned deprecation of the above flag options on cf push on the v6 CLI, and to gather community feedback on our current approach on the v7 beta CLI for overriding routes using cf push. 

We welcome feedback in comments in this document, which also details:
  • the upcoming changes (the flags above will continue to work on v6 CLI but a deprecation notice will appear in the output)
  • a section calling for feedback for the v7 beta CLI (where we have removed these flag options).
Thanks and we hope to hear from you.

Best,

Abby Chau
cf CLI, Product Manager 






istio-release 1.3.0

Wa Gao
 

Hello cf-dev!

We have cut istio-release 1.3.0, here are the release highlights:

Release Highlights

- App developer can rely on the platform to provide client-side load balancing for app to app communication via container-to-container networking; requests will be evenly distributed across instances of applications mapped to the same internal route details
- App developer can rely on the platform to provide retries for app to app communication via container-to-container networking; the platform will retry requests three time if the response code is 5xx details
- Reliability and security improvement: Copilot consumes VIPs from CAPI to reduce the risk of misrouting details
- Bump istio to 1.2.0 in istio-release details
- Bump Envoy to 1.11.0 in istio-release details

No manifest changes 

Regards,
--

Wa Gao (Claire) | Senior Product Manager, Networking | Pivotal

Phone: 508-615-8644 | Email: wgao@...

 


Re: Upgrading to UAA 4.35.0 from UAA 4.30.0 stopped the UAA logging #uaa

Shetty, Viraj S [CTR]
 

I added a console setup and removed the file setup before compiling and it works. 

appender.console.type = Console
appender.console.name = STDOUT
appender.console.layout.type = PatternLayout
appender.console.layout.pattern = ${log_pattern}
 
rootLogger.level = INFO
rootLogger.appenderRef.stdout.ref = STDOUT
 
logger.cfIdentity.name = org.cloudfoundry.identity
logger.cfIdentity.level = debug
 


Re: Upgrading to UAA 4.35.0 from UAA 4.30.0 stopped the UAA logging #uaa

Chao Wang
 

+Joshua Casey who is the master of Log4j2 

On Tue, Jul 23, 2019 at 1:58 PM vshetty via Lists.Cloudfoundry.Org <vshetty=fdic.gov@...> wrote:

[Edited Message Follows]

Thanks Chaos. The doc says to create a custom env logging.config and point to log4j2 format file. Just like in the previous versions, why can we not get the logging by default ? 

Should I just create a custom log4j2.properties config file ? Is there an example of one that I can use ? The UAA war file does not contain a log4j2.properties otherwise i could have pointed to that. 

What is the best way to do this ? I am using the cloudfoundry environment, so I can't just push a log4j2.properties file. 

Thanks,
Viraj


Re: Upgrading to UAA 4.35.0 from UAA 4.30.0 stopped the UAA logging #uaa

Shetty, Viraj S [CTR]
 
Edited

Thanks Chaos. The doc says to create a custom env logging.config and point to log4j2 format file. Just like in the previous versions, why can we not get the logging by default ? 

Should I just create a custom log4j2.properties config file ? Is there an example of one that I can use ? The UAA war file does not contain a log4j2.properties otherwise i could have pointed to that. 

What is the best way to do this ? I am using the cloudfoundry environment, so I can't just push a log4j2.properties file. 

Thanks,
Viraj


CF-Deployment v10.0 release pulled due to a backward incompatible issue with UAA 73.4.0 #cf

Saikiran Yerram
 

Please use the next version of CF-Deployment as we have identified an issue with UAA version 73.4.0 due to a backward incompatibility issue in upgrading to Spring Security 5 on 07-19-2019. The next release of UAA would fix this issue.


Re: Upgrading to UAA 4.35.0 from UAA 4.30.0 stopped the UAA logging #uaa

Chao Wang
 

Hi Viraj,

Please check the release notes of UAA 4.31.0 which shared the changes you need to make, there are also additional comments from the tracker story if you need more details. 

Thanks,
Chao



On Mon, Jul 22, 2019 at 11:46 AM vshetty via Lists.Cloudfoundry.Org <vshetty=fdic.gov@...> wrote:
When I was using UAA 4.30.0, UAA used to log a lot of messages which was fine. However, I recently upgraded the UAA to 4.35.0 and the logging stopped working. I deploy UAA by getting the source from github link below, compiled it and then deployed using cloudfoundry push command

https://github.com/cloudfoundry/uaa/releases/tag/4.35.0

I understand that there was a change made to logging in 4.31.0 -  Upgrade to Log4j2 logging framework 

What do I need to do to get logging back ? Do I need to create a log4j2 file ? If so, where do I need to save it. 

Any help is appreciated. 

Thanks,
Viraj 


Upgrading to UAA 4.35.0 from UAA 4.30.0 stopped the UAA logging #uaa

Shetty, Viraj S [CTR]
 

When I was using UAA 4.30.0, UAA used to log a lot of messages which was fine. However, I recently upgraded the UAA to 4.35.0 and the logging stopped working. I deploy UAA by getting the source from github link below, compiled it and then deployed using cloudfoundry push command

https://github.com/cloudfoundry/uaa/releases/tag/4.35.0

I understand that there was a change made to logging in 4.31.0 -  Upgrade to Log4j2 logging framework 

What do I need to do to get logging back ? Do I need to create a log4j2 file ? If so, where do I need to save it. 

Any help is appreciated. 

Thanks,
Viraj 


Re: Running UAA on Kubernetes behind TLS-enabled ingress controller #uaa

Filip Hanik
 

hi Enrique,

The port number will not be forced if 
  the appropriate proxy headers are set 
*AND* 
  the request comes from a trusted IP (Tomcat's RemoteIpValve)

ie, the HttpServletRequest.getScheme does not return https because the web server (ie Apache Tomcat) does not trust the source of the request, so the headers are ignored.

I'm not sure why that filter is even in the UAA. The code of the filter basically states

_Apache Tomcat doesn't trust the X-Forwarded-Proto header, so our code will do so instead and override the behavior_

So that code should not exist, as it indicates a workaround for a misconfigured system.

You need to configure your RemoteIpValve correctly, if you are using Apache Tomcat
and then your problem will go away




[Operators SIG Meeting] Call for Content - July 24

Gowrisankar M
 

Dear Cloud Foundry Community,

Please let me or Karthik know, if you’d like to bring any specific topics for discussion for the next sig meeting on Wednesday, June 24th at 08:00 US Pacific | 11:00 US Eastern | 20:30 Indian Standard Time.

Please add the calendar appt from here: https://www.cloudfoundry.org/community-calendar.

BRs, Gowrisankar


CF-Deployment v10.0 is now live #cf

Saikiran Yerram
 

Happy Friday everyone,

CF-deployment v10.0 is now live. Please refer to the release notes for breaking changes: https://github.com/cloudfoundry/cf-deployment/releases/tag/v10.0.0


Let me know if you have any questions,


Re: Running UAA on Kubernetes behind TLS-enabled ingress controller #uaa

Enrique Cano
 

Thank you, Filip.

We are not using uaa-release, and we can control the protocol (https). Our issue is that the port number is forced to be 443 when we don't want that to happen.

Regards

Enrique


Re: CF Application Runtime PMC: Loggregator Project Lead Call for Nominations

Eric Malm <emalm@...>
 

Hi, everyone,

Pivotal is nominating Allen Duet for the Loggregator Project Lead in the Application Runtime PMC.

Allen is a Director of Product Management at Pivotal where he oversees Cloud Foundry products related to Observability and Automation. Allen joined Pivotal and Cloud Foundry in December 2015.

Prior to joining Pivotal, Allen was Chief Technology Officer at Swiftpage ACT!, a software company focused on CRM and email marketing products for businesses. Allen is located in Denver and enjoys hiking, skiing, and a variety of outdoor activities.

Please send any other nominations directly to me or in reply to this message no later than 11:59 PM PDT on Monday, May 20, 2019.

Thanks,
Eric Malm

On Thu, Jul 18, 2019 at 4:57 PM Eric Malm <emalm@...> wrote:
Hi, everyone,

Fred Krone, the lead for the Loggregator project within the Application Runtime PMC, is stepping down from the project, as he has recently left Pivotal. We thank him for his  service.

The Loggregator team, located in Denver, now has an opening for its project lead. Project leads must be nominated by a Cloud Foundry Foundation member. Please send nominations directly to me or in reply to this message no later than 11:59 PM PDT on Friday, Aug 2, 2019.

Also, if you have any questions about the role or the nomination process, as described in the CFF governance documents (https://www.cloudfoundry.org/governance/cff_development_operations_policy/), please let me know.

Thanks,
Eric Malm, CF Application Runtime PMC Lead


CF Application Runtime PMC: Loggregator Project Lead Call for Nominations

Eric Malm <emalm@...>
 

Hi, everyone,

Fred Krone, the lead for the Loggregator project within the Application Runtime PMC, is stepping down from the project, as he has recently left Pivotal. We thank him for his  service.

The Loggregator team, located in Denver, now has an opening for its project lead. Project leads must be nominated by a Cloud Foundry Foundation member. Please send nominations directly to me or in reply to this message no later than 11:59 PM PDT on Friday, Aug 2, 2019.

Also, if you have any questions about the role or the nomination process, as described in the CFF governance documents (https://www.cloudfoundry.org/governance/cff_development_operations_policy/), please let me know.

Thanks,
Eric Malm, CF Application Runtime PMC Lead