Date   

cf deploy on openstack

Russell Blue
 

Hi,

I deploy cloud foundry openstack Pike. At the time of construction VMs and get error:

Updating instance api: api/215a8746-2867-415f-892b-f80be09f779c (0) (canary) (00:13:04)
L Error: Action Failed get_task: Task 058419ac-7dad-4183-65f0-5dc8a2c1ffba result: 1 of 7 pre-start scripts failed. Failed Jobs: cloud_controller_ng. Successful Jobs: cc_uploader, file_server, policy-server-internal, route_registrar, routing-api, consul_agent


Kind Regards


Metric Drains - A New Way for App Developers to Monitor their Containers #loggregator

Adam Hevenor
 

In service to our mission of providing all users of Cloud Foundry observability of their systems the Loggregator team is excited to offer a new feature for App Developers to use external monitoring tools for monitoring their applications without the need for FIrehose scope. This is accomplished by the use of User Provided Syslog Drains and a new CLI Plugin and we have called the new feature Metric Drains.  

Leveraging the user provided abstraction as well as the tcp based syslog:// protocol is a powerful tool for streaming data off the platform. We have plans to support more data and logs for streaming to app developers this way as well potentially other streaming formats. We'd love your feedback and ideas on either of these. 

A special thanks to several community members that originally suggested and voted for this feature on our github repo!

Requirements: 
This feature still requires opt in at this time. To utilize this feature you'll need cf-deployment 1.9+ and to set the scalablesyslog.adapter.metrics_to_syslog_enabled feature flag on the cf-syslog-drain deployment. 


Scheduler for PCF #service

shruthi s
 

Hi,
I have a spring boot application implementing a commandline runner and terminates after the process. The main class looks like:
@SpringBootApplication
public class MyClass implements CommandLineRunner{
    @Override
    public void run(String... strings) throws Exception {
if(strings[i].equals("A"){
  do processA();
}
else if(strings[i].equals("B"){
  do processB();
}
System.exit(0);
}
 
public static void main(String[] args) throws Exception{
            SpringApplication.run(CTFRetryNotification.class, args);
    }
}

I run this command: java -jar executable.jar arg0 arg1 -Dspring.profiles.active=dev. It workd fine when i run the command in terminal. 

I am now trying to push this executable jar to PCF as an application, bind it to the scheduler and then schedule a job with command which executes the jar.
I am using the below manifest file to push the app:
---
applications:
- name: my-app
  memory: 1024M
  host: my-app
  domain: my.pcf.domain
  health-check-type: process
  instances: 1
  timeout: 60
  path: executable.jar
  env:
    SPRING_PROFILES_ACTIVE: dev 
    JBP_CONFIG_JAVA_MAIN: '{java_main_class: com.abc.MyClass}'
    JBP_CONFIG_JAVA_MAIN: '{ arguments: "arg0 arg1" }'

Command to push:  cf push -f manifest.yml --no-route

The app starts but suddenly crashes with the following message: 
 [API/0] [OUT] Process has crashed with type: "web"
 [API/0] [OUT] App instance exited with guid 7bd4c9a8-a67e-471d-ad39-43623b6f29cd payload: {"instance"=>"d296990c-ead6-48e0-5308-3657", "index"=>0, "reason"=>"CRASHED", "exit_description"=>"Codependent step exited", "crash_count"=>2, "crash_timestamp"=>1518194091169216190, "version"=>"ed0bbd60-9e1c-4d95-97aa-b750446332d5"}

i am trying to figure out the command i can use to run the jar by using run-task command in cf cli but i cannot get it to work.
cf run-task my-app '$PWD/.java-buildpack/open_jdk_jre/bin/java -Dspring.profiles.active=dev -cp $PWD/. org.springframework.boot.loader.JarLauncher arg0 arg1'

This command fails " Incorrect Usage: unknown flag `c'"
I tried using double quotes around the command but it fails "out of memory".

Has anybody done something like this in PCF? What would be the command i can use to run the jar? Thanks in advance





Re: Should route services really need a route-app mapping?

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

Hi Shannon,

 

Thank you very much for getting back to us on the topic. Quite a few teams here at SAP will be happy to hear about the topic and I’ll make sure to pass your update on to them.

 

Thanks again,

Bernd

 

From: <cf-dev@...> on behalf of Shannon Coen <scoen@...>
Reply-To: "cf-dev@..." <cf-dev@...>
Date: Thursday, 8. February 2018 at 00:19
To: "cf-dev@..." <cf-dev@...>
Subject: Re: [cf-dev] Should route services really need a route-app mapping?

 

[Edited Message Follows]

Currently routes are only known to Gorouter when they are mapped to an app AND the app has running instances. If the app is stopped or crashing, Gorouter will return a 404 for the route. This is because routing configuration is passed through the Diego BBS. 

We've received requests for this several times in the past; see 
http://cf-dev.70369.x6.nabble.com/cf-dev-Brokered-route-services-only-receiving-traffic-for-routes-mapped-to-started-apps-td4699.html#a4742.

You may be happy to learn that we plan to support this use case in coming months. However, we will offer it through our integration with Istio Pilot and Envoy; we don't plan on offering it using Gorouter. One of the key differences between the current routing subsystem and our integration with Istio is that Istio will receive routes directly from Cloud Controller, while only backend IPs and ports will be obtained from Diego BBS. This will enable us to have the router (Envoy) be configured with a route that is associated with a route service but not an app. More on our initiative here: 
https://docs.google.com/document/d/1VldkvgWPUh13o5RCNjSvzoPFhbY9BtLqBDdk2k0z9fw/edit.


CF Summit Contributor Registration Time

Chip Childers <cchilders@...>
 

Hey all!

It's time again for contributors to get themselves registered for CF Summit North America in April! 

For those of you that have contributed to a CFF project (any repo in the cloudfoundry, cloudfoundry-incubator, cloudfoundry-attic or openservicebrokerapi GitHub orgs), we've got you covered with free registration. :)

CFNA18CONT

-chip
--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815


Calling all CF Users!

Chip Childers <cchilders@...>
 

Hey all,

Are you a CF user? If so, we want to hear from you! The CFF is running it's latest user survey to help us get to know the community better. Please take a few minutes to share your story here > https://www.surveymonkey.com/r/CFUserSurvey2018 

Thanks!

-chip
--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815


Re: Should route services really need a route-app mapping?

Shannon Coen
 
Edited

Currently routes are only known to Gorouter when they are mapped to an app AND the app has running instances. If the app is stopped or crashing, Gorouter will return a 404 for the route. This is because routing configuration is passed through the Diego BBS. 

We've received requests for this several times in the past; see http://cf-dev.70369.x6.nabble.com/cf-dev-Brokered-route-services-only-receiving-traffic-for-routes-mapped-to-started-apps-td4699.html#a4742.

You may be happy to learn that we plan to support this use case in coming months. However, we will offer it through our integration with Istio Pilot and Envoy; we don't plan on offering it using Gorouter. One of the key differences between the current routing subsystem and our integration with Istio is that Istio will receive routes directly from Cloud Controller, while only backend IPs and ports will be obtained from Diego BBS. This will enable us to have the router (Envoy) be configured with a route that is associated with a route service but not an app. More on our initiative here: https://docs.google.com/document/d/1VldkvgWPUh13o5RCNjSvzoPFhbY9BtLqBDdk2k0z9fw/edit.


Re: Change in CF Security RSS Feed

Matthew Kocher <mkocher@...>
 

Thanks Chip!

On Wed, Feb 7, 2018 at 11:03 AM, Chip Childers <cchilders@...> wrote:
Redirects should be in place now and the team is now aware of the importance. Thanks for pointing this out all!

On Wed, Feb 7, 2018 at 3:07 AM Lee Porte via Lists.Cloudfoundry.Org <lee.porte=digital.cabinet-office.gov.uk@lists.cloudfoundry.org> wrote:
I agree with Matthew.

A redirect should really have been put in place when the change was made. The changes broke our CVE alerting mechanism.

Lee

On 7 February 2018 at 00:51, Matthew Kocher <mkocher@...> wrote:
Can we put a redirect in place? Failing that, how about an update posted to the old feed before it goes dark?

Having the old feed go silent is bad form for something that people may be relying on for security updates.




On Tue, Feb 6, 2018 at 8:56 AM, Molly Crowther <mcrowther@...> wrote:
Hello all,

A few weeks ago, the foundation did some re-architecting of the CF blog to improve SEO and searchability. These updates changed the location of the Security RSS feed.

If you are using this feed, the new address is: https://www.cloudfoundry.org/foundryblog/security-advisory/feed/

Please let me know if you have any questions or concerns!

Thanks,
Molly Crowther
CFF Security Team



--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815



Re: Change in CF Security RSS Feed

Chip Childers <cchilders@...>
 

Redirects should be in place now and the team is now aware of the importance. Thanks for pointing this out all!


On Wed, Feb 7, 2018 at 3:07 AM Lee Porte via Lists.Cloudfoundry.Org <lee.porte=digital.cabinet-office.gov.uk@...> wrote:
I agree with Matthew.

A redirect should really have been put in place when the change was made. The changes broke our CVE alerting mechanism.

Lee

On 7 February 2018 at 00:51, Matthew Kocher <mkocher@...> wrote:
Can we put a redirect in place? Failing that, how about an update posted to the old feed before it goes dark?

Having the old feed go silent is bad form for something that people may be relying on for security updates.




On Tue, Feb 6, 2018 at 8:56 AM, Molly Crowther <mcrowther@...> wrote:
Hello all,

A few weeks ago, the foundation did some re-architecting of the CF blog to improve SEO and searchability. These updates changed the location of the Security RSS feed.

If you are using this feed, the new address is: https://www.cloudfoundry.org/foundryblog/security-advisory/feed/

Please let me know if you have any questions or concerns!

Thanks,
Molly Crowther
CFF Security Team



--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815


Re: Change in CF Security RSS Feed

Chip Childers <cchilders@...>
 

Completely agree. I'll forward to our web team and ask for a redirect (as well as a reminder that this feed is important to the ecosystem).


On Wed, Feb 7, 2018 at 3:07 AM Lee Porte via Lists.Cloudfoundry.Org <lee.porte=digital.cabinet-office.gov.uk@...> wrote:
I agree with Matthew.

A redirect should really have been put in place when the change was made. The changes broke our CVE alerting mechanism.

Lee

On 7 February 2018 at 00:51, Matthew Kocher <mkocher@...> wrote:
Can we put a redirect in place? Failing that, how about an update posted to the old feed before it goes dark?

Having the old feed go silent is bad form for something that people may be relying on for security updates.




On Tue, Feb 6, 2018 at 8:56 AM, Molly Crowther <mcrowther@...> wrote:
Hello all,

A few weeks ago, the foundation did some re-architecting of the CF blog to improve SEO and searchability. These updates changed the location of the Security RSS feed.

If you are using this feed, the new address is: https://www.cloudfoundry.org/foundryblog/security-advisory/feed/

Please let me know if you have any questions or concerns!

Thanks,
Molly Crowther
CFF Security Team



--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815


Re: Change in CF Security RSS Feed

Lee Porte
 

I agree with Matthew.

A redirect should really have been put in place when the change was made. The changes broke our CVE alerting mechanism.

Lee

On 7 February 2018 at 00:51, Matthew Kocher <mkocher@...> wrote:
Can we put a redirect in place? Failing that, how about an update posted to the old feed before it goes dark?

Having the old feed go silent is bad form for something that people may be relying on for security updates.




On Tue, Feb 6, 2018 at 8:56 AM, Molly Crowther <mcrowther@...> wrote:
Hello all,

A few weeks ago, the foundation did some re-architecting of the CF blog to improve SEO and searchability. These updates changed the location of the Security RSS feed.

If you are using this feed, the new address is: https://www.cloudfoundry.org/foundryblog/security-advisory/feed/

Please let me know if you have any questions or concerns!

Thanks,
Molly Crowther
CFF Security Team




CF UAA Localization #cf

Balakrishnan
 

Hi,
     Our project uses standalone UAA for User Authentication. There is a requirement of allowing Client  to create new users using API (/Users - POST) as per his/her locale. 

E.g. If Our Client  locale is in French, then username should allow all French character. 

However as per the current code it seems , it always expects the username in English as there are validation("[\\p{L}+0-9+\\-_.@'!]+") for valid user name . 

Is there any feature available in UAA to localize the instance ? or UAA will always accept Username/Password in English only ?

Thanks,
Balakrishnan


Re: Change in CF Security RSS Feed

Matthew Kocher <mkocher@...>
 

Can we put a redirect in place? Failing that, how about an update posted to the old feed before it goes dark?

Having the old feed go silent is bad form for something that people may be relying on for security updates.




On Tue, Feb 6, 2018 at 8:56 AM, Molly Crowther <mcrowther@...> wrote:
Hello all,

A few weeks ago, the foundation did some re-architecting of the CF blog to improve SEO and searchability. These updates changed the location of the Security RSS feed.

If you are using this feed, the new address is: https://www.cloudfoundry.org/foundryblog/security-advisory/feed/

Please let me know if you have any questions or concerns!

Thanks,
Molly Crowther
CFF Security Team



Change in CF Security RSS Feed

Molly Crowther
 

Hello all,

A few weeks ago, the foundation did some re-architecting of the CF blog to improve SEO and searchability. These updates changed the location of the Security RSS feed.

If you are using this feed, the new address is: https://www.cloudfoundry.org/foundryblog/security-advisory/feed/

Please let me know if you have any questions or concerns!

Thanks,
Molly Crowther
CFF Security Team


Service Brokers using plan_id in last operation requests

Matt McNeeney
 

There is a discussion taking place [1] in the Open Service Broker API group regarding the plan_id that is sent in requests to get the status of an asynchronous operation [2] such as a provision or an update (last_operation endpoint).

Given that an asynchronous update service instance request could change the plan that a service instance is using, we are unsure of what service brokers expect in this scenario; are they expecting to receive the old plan_id or the new plan_id?

If any service broker authors are using the plan_id field, please let me know so that we can guide that discussion and make sure we do not make a breaking change to the specification.

Thanks,
Matt




Re: What should happen to Service Instance Bindings when their Plan is updated?

landzhev@...
 

Hi Alex,

Our service broker implementation to a large extend ignores the planId. We store it as a piece of information, but we do not use it later on,

Best regards,
Nikolay

On Thursday, February 1, 2018, 6:11:48 AM GMT+2, Basavaraju, Jagadish <jagadish.basavaraju@...> wrote:


Our implementation of Service Broker [1] ignores Plan Id and Service Id input during the bind requests and the bindings are valid even post plan update.

 

Jagadish

[1] – Service Fabrik – https://github.com/cloudfoundry-incubator/service-fabrik-broker

          

From: <cf-dev@...> on behalf of Alex Ley <aley@...>
Reply-To: "cf-dev@..." <cf-dev@...>
Date: Wednesday, 31 January 2018 at 9:00 PM
To: "cf-dev@..." <cf-dev@...>
Subject: [cf-dev] What should happen to Service Instance Bindings when their Plan is updated?

 

For folks who build Service Brokers, I would like to get your input on this issue [1] in the OSBAPI spec project. 

 

Today the spec doesn't give any guidance on what should happen to bindings when a plan is updated. We are looking to add some clarification / set the expected behaviour.

 

Could you share the logic for your service brokers on the issue? Do you use the `plan_id` in the binding request? 

 


Setting Up DNS for Your Environment

Russell Blue
 

Hi,

I want deploy cf-deployment on pike openstack. how can setting up DNS for my environment ?

kind regards


Re: What should happen to Service Instance Bindings when their Plan is updated?

Sascha Matzke
 

Hi,

we have several service brokers (for "normal" backend services and quite a few route services) and we don't use PlanID (or ServiceID) in most of them.

There are exceptions (as always), but those brokers do not support plan updates.

Best,

Sascha


Re: What should happen to Service Instance Bindings when their Plan is updated?

Basavaraju, Jagadish
 

Our implementation of Service Broker [1] ignores Plan Id and Service Id input during the bind requests and the bindings are valid even post plan update.

 

Jagadish

[1] – Service Fabrik – https://github.com/cloudfoundry-incubator/service-fabrik-broker

          

From: <cf-dev@...> on behalf of Alex Ley <aley@...>
Reply-To: "cf-dev@..." <cf-dev@...>
Date: Wednesday, 31 January 2018 at 9:00 PM
To: "cf-dev@..." <cf-dev@...>
Subject: [cf-dev] What should happen to Service Instance Bindings when their Plan is updated?

 

For folks who build Service Brokers, I would like to get your input on this issue [1] in the OSBAPI spec project. 

 

Today the spec doesn't give any guidance on what should happen to bindings when a plan is updated. We are looking to add some clarification / set the expected behaviour.

 

Could you share the logic for your service brokers on the issue? Do you use the `plan_id` in the binding request? 

 


CVE-2018-1192: UAA SessionID present in Audit Event Logs

Molly Crowther <mcrowther@...>
 

Please see below for information on a high-severity UAA CVE.

Sree Tummidi can provide more details if you have questions.

Thanks,
Molly Crowther
CFF Security Team

CVE-2018-1192: UAA SessionID present in Audit Event Logs

Severity

High

Vendor

Cloud Foundry Foundation

Affected Cloud Foundry Products and Versions

  • All cf-release versions prior to v285
  • All cf-deployment versions prior to v1.7
  •  UAA
    • 4.5.x versions prior to 4.5.5
    • 4.8.x versions prior to 4.8.3
    • 4.7.x versions prior to 4.7.4
  • UAA-release
    • 45.7.x versions prior to 45.7
    • 52.7.x versions prior to 52.7
    • 53.3.x versions prior to 53.3

Description

Cloud Foundry UAA logs the SessionID in audit event logs. An attacker can use the SessionID to impersonate a logged-in user.

Mitigation

Users of affected versions should apply the following mitigations or upgrades:

  • Releases that have fixed this issue include:
    • cf-release: 285
    • cf-deployment: 1.7
    • UAA: 4.5.5, 4.8.3, 4.7.4
    • UAA-release: 45.7,52.7, 53.3

Credit

This issue was responsibly reported by the UAA team.

References

History

2018-01-31: Initial vulnerability report published.

1681 - 1700 of 9398