But when started someone out there was guiding me in the wrong direction
new to this but after seeing the results now I know which direction to take
I've had some downtime do to illness with my family members and water
damage to my equipment but even tonight while trying to do something
someone we'll message me they were guided me in the wrong direction I will
focus on the task at hand like stylus I want make something good

On Jul 23, 2017 6:38 AM, "Jenny Hilton [via CF Dev]" <
ml+s70369n7245h87(a)n6.nabble.com> wrote:

Ping :- )


------------------------------
If you reply to this email, your message will be added to the discussion
below:
http://cf-dev.70369.x6.nabble.com/cf-dev-Manage-Cloud-
foundry-Org-space-tp7229p7245.html
To start a new topic under CF Dev, email ml+s70369n1h23(a)n6.nabble.com
To unsubscribe from CF Dev, click here
<http://cf-dev.70369.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=1&code=dG9tbXlvc2hpZWxkczcxQGdtYWlsLmNvbXwxfDYzNTk2MjAwOA==>
.
NAML
<http://cf-dev.70369.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>

--
View this message in context: http://cf-dev.70369.x6.nabble.com/Re-cf-dev-Re-Manage-Cloud-foundry-Org-space-tp7246.html
Sent from the CF Dev mailing list archive at Nabble.com.

Ping :- )

Sorry been out of commission water damage on my other phone just glad to be
back
On Jul 18, 2017 7:40 PM, "Mike Youngstrom [via CF Dev]" <
ml+s70369n7221h43(a)n6.nabble.com> wrote:

This sounds like a great solution to a very old nagging problem. I'm
excited to see this issue moving forward. I assume that if the mTLS
handshake fails then the router will try the next instance in the table as
if the TCP connection had failed?

Mike

On Tue, Jul 18, 2017 at 5:25 PM, Shannon Coen <[hidden email]
<http:///user/SendEmail.jtp?type=node&node=7221&i=0>> wrote:

After weeks of exploration by the Routing, Networking, and Diego teams, we
have a solution in mind and will begin implementation shortly.

TL;DR
We plan to install a proxy in every container to terminate mTLS for
requests
from Gorouter, enabling validation of application identity and
optimization
for availability over consistency. The solution will be transparent to
application developers.

Our proposal has been updated with details on this solution, and we
welcome
your comments:
https://docs.google.com/document/d/1zkPVGNnBX18rWdOpinIEtRxt
e3kwpVhIyS9_WM3ITqM/edit?usp=sharing





--
View this message in context: http://cf-dev.70369.x6.nabble.
com/cf-dev-Increasing-Routing-availability-in-the-event-of-f
ailure-with-route-registration-tp6703p7220.html
Sent from the CF Dev mailing list archive at Nabble.com.

------------------------------
If you reply to this email, your message will be added to the discussion
below:
http://cf-dev.70369.x6.nabble.com/cf-dev-Increasing-Routing-
availability-in-the-event-of-failure-with-route-
registration-tp6703p7221.html
To start a new topic under CF Dev, email ml+s70369n1h23(a)n6.nabble.com
To unsubscribe from CF Dev, click here
<http://cf-dev.70369.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=1&code=dG9tbXlvc2hpZWxkczcxQGdtYWlsLmNvbXwxfDYzNTk2MjAwOA==>
.
NAML
<http://cf-dev.70369.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>

--
View this message in context: http://cf-dev.70369.x6.nabble.com/Re-cf-dev-Re-Re-Increasing-Routing-availability-in-the-event-of-failure-with-route-registration-tp7244.html
Sent from the CF Dev mailing list archive at Nabble.com.

Hey All -

We are holding a Cloud Foundry meetup at Pivotal in San Francisco on
Tuesday, July 25. This session will focus on how to use CredHub in your
environment to manage platform and service credentials. Further details in
the invite linked below.

https://www.meetup.com/Cloud-Foundry-Users-San-Francisco-Bay-Area/events/241697978/

Hope to see you there.
-Dan

Hi Colleages,

Can somebody tell me cf api which is avaialble to findout duplicated users
in uaadb.

BRs, Gowrisankar

I recognized why token log logged twice .
it was just log4j configuration problem
Thanks.

Thanks Filip for the information for UAA DB. Any idea on Cloud controller
DB (postgresSQL) design ? documetation ?

Thanks Ben Hale for replying

I still have a question about 401 error occurred sometimes

as Ben Hale said, i set the logger and i see the log when 401 error occurs
as you can see, it seems that token is issued
2017-07-21 11:08:10,751 DEBUG [cloudfoundry-client.token] (AbstractUaaTokenProvider.java:151) - Access Token Issued At: 2017-07-21T02:08:14 UTC
2017-07-21 11:08:10,751 DEBUG [cloudfoundry-client.token] (AbstractUaaTokenProvider.java:151) - Access Token Issued At: 2017-07-21T02:08:14 UTC
2017-07-21 11:08:10,751 DEBUG [cloudfoundry-client.token] (AbstractUaaTokenProvider.java:152) - Access Token Expires At: 2017-07-21T02:18:14 UTC
2017-07-21 11:08:10,751 DEBUG [cloudfoundry-client.token] (AbstractUaaTokenProvider.java:152) - Access Token Expires At: 2017-07-21T02:18:14 UTC
reactor.ipc.netty.http.client.HttpClientException: HTTP request failed with code: 401.
Failing URI: /firehose/cf-nozzle

but i received error 401
I don't why error is occurred
and my token log is logged twice
i configured TokenProvider and DopplerClient below
doppler client has @Bean annotation and TokenProvider has no @Bean annotation

public TokenProvider tokenProvider(String password, String username) {
return PasswordGrantTokenProvider.builder()
.password(password)
.username(username)
.build();
}
@Bean
public DopplerClient dopplerClient(NozzleProperties properties) {
return ReactorDopplerClient.builder()
.connectionContext(connectionContext(properties.getApiHost(), properties.isSkipSslValidation()))
.tokenProvider(tokenProvider(properties.getPassword(), properties.getUsername()))
.build();
}
is it wrong?
may these configuration can make token log twice??

Thanks
------
the full log is below

2017-07-21 11:08:10,268 DEBUG [cloudfoundry-client.token] (AbstractUaaTokenProvider.java:264) - Negotiating using token provider
2017-07-21 11:08:10,268 DEBUG [cloudfoundry-client.token] (AbstractUaaTokenProvider.java:264) - Negotiating using token provider
2017-07-21 11:08:10,704 DEBUG [cloudfoundry-client.token] (AbstractUaaTokenProvider.java:193) - Refresh Token: a93d6589d929470880b8e6f8878dea1a-r
2017-07-21 11:08:10,704 DEBUG [cloudfoundry-client.token] (AbstractUaaTokenProvider.java:193) - Refresh Token: a93d6589d929470880b8e6f8878dea1a-r
2017-07-21 11:08:10,725 DEBUG [cloudfoundry-client.token] (AbstractUaaTokenProvider.java:147) - Access Token: eyJhbGciOiJSUzI1NiIsImtpZCI6ImxlZ2FjeS10b2tlbi1rZXkiLCJ0eXAiOiJKV1QifQ.eyJqdGkiOiI1ZjE3Y2YwY2ViZWQ0OTE2YTFjZjA5OTYwZDg2OTdjMCIsInN1YiI6IjI2OGM3MGZhLTExYmUtNGIxNS04ZDgyLTdkM2UxYzA1NDI1ZSIsInNjb3BlIjpbImNsb3VkX2NvbnRyb2xsZXIuYWRtaW4iLCJyb3V0aW5nLnJvdXRlcl9ncm91cHMucmVhZCIsImNsb3VkX2NvbnRyb2xsZXIud3JpdGUiLCJkb3BwbGVyLmZpcmVob3NlIiwib3BlbmlkIiwicm91dGluZy5yb3V0ZXJfZ3JvdXBzLndyaXRlIiwic2NpbS5yZWFkIiwidWFhLnVzZXIiLCJjbG91ZF9jb250cm9sbGVyLnJlYWQiLCJwYXNzd29yZC53cml0ZSIsInNjaW0ud3JpdGUiXSwiY2xpZW50X2lkIjoiY2YiLCJjaWQiOiJjZiIsImF6cCI6ImNmIiwiZ3JhbnRfdHlwZSI6InBhc3N3b3JkIiwidXNlcl9pZCI6IjI2OGM3MGZhLTExYmUtNGIxNS04ZDgyLTdkM2UxYzA1NDI1ZSIsIm9yaWdpbiI6InVhYSIsInVzZXJfbmFtZSI6ImFkbWluIiwiZW1haWwiOiJhZG1pbiIsImF1dGhfdGltZSI6MTUwMDYwMjg5NCwicmV2X3NpZyI6ImRmOThiNTI1IiwiaWF0IjoxNTAwNjAyODk0LCJleHAiOjE1MDA2MDM0OTQsImlzcyI6Imh0dHBzOi8vdWFhLjExNS42OC40Ni4xODYueGlwLmlvL29hdXRoL3Rva2VuIiwiemlkIjoid
WFhIiwiYXVkIjpbImNsb3VkX2NvbnRyb2xsZXIiLCJzY2ltIiwicGFzc3dvcmQiLCJjZiIsInVhYSIsIm9wZW5pZCIsImRvcHBsZXIiLCJyb3V0aW5nLnJvdXRlcl9ncm91cHMiXX0.SOVe6D-N-WHx3r12y6b-eo4Vw7cE8chGqLyavcxwLC239ntikXqnCEZciG0WIh-KkgWA9v3-spyL4QEi5traLQxPhutBRUrh7rvPPEJBc3NJqG4adT4sIBhrdS0ZPF5zMdSQcY1Sm195KNxfOG9rX-AF8_B-KOvJWkbHmokQiMqiOLPbOuTgy5mWhHW_A_zNJ5ChZR7YI7jlY5t_nkc1TousuQg9oVQ89y7-hXq9LSYHcxzWSOGiheyiLSw7oqRYmmWRYphN5jc38H6E_e7-fVvqGYyhwyQvHlrHjy6-56W_hO0DXAWafYQX_JdS0I83SDqXQRz8xg1ungNzT7Eaog
2017-07-21 11:08:10,725 DEBUG [cloudfoundry-client.token] (AbstractUaaTokenProvider.java:147) - Access Token: eyJhbGciOiJSUzI1NiIsImtpZCI6ImxlZ2FjeS10b2tlbi1rZXkiLCJ0eXAiOiJKV1QifQ.eyJqdGkiOiI1ZjE3Y2YwY2ViZWQ0OTE2YTFjZjA5OTYwZDg2OTdjMCIsInN1YiI6IjI2OGM3MGZhLTExYmUtNGIxNS04ZDgyLTdkM2UxYzA1NDI1ZSIsInNjb3BlIjpbImNsb3VkX2NvbnRyb2xsZXIuYWRtaW4iLCJyb3V0aW5nLnJvdXRlcl9ncm91cHMucmVhZCIsImNsb3VkX2NvbnRyb2xsZXIud3JpdGUiLCJkb3BwbGVyLmZpcmVob3NlIiwib3BlbmlkIiwicm91dGluZy5yb3V0ZXJfZ3JvdXBzLndyaXRlIiwic2NpbS5yZWFkIiwidWFhLnVzZXIiLCJjbG91ZF9jb250cm9sbGVyLnJlYWQiLCJwYXNzd29yZC53cml0ZSIsInNjaW0ud3JpdGUiXSwiY2xpZW50X2lkIjoiY2YiLCJjaWQiOiJjZiIsImF6cCI6ImNmIiwiZ3JhbnRfdHlwZSI6InBhc3N3b3JkIiwidXNlcl9pZCI6IjI2OGM3MGZhLTExYmUtNGIxNS04ZDgyLTdkM2UxYzA1NDI1ZSIsIm9yaWdpbiI6InVhYSIsInVzZXJfbmFtZSI6ImFkbWluIiwiZW1haWwiOiJhZG1pbiIsImF1dGhfdGltZSI6MTUwMDYwMjg5NCwicmV2X3NpZyI6ImRmOThiNTI1IiwiaWF0IjoxNTAwNjAyODk0LCJleHAiOjE1MDA2MDM0OTQsImlzcyI6Imh0dHBzOi8vdWFhLjExNS42OC40Ni4xODYueGlwLmlvL29hdXRoL3Rva2VuIiwiemlkIjoid
WFhIiwiYXVkIjpbImNsb3VkX2NvbnRyb2xsZXIiLCJzY2ltIiwicGFzc3dvcmQiLCJjZiIsInVhYSIsIm9wZW5pZCIsImRvcHBsZXIiLCJyb3V0aW5nLnJvdXRlcl9ncm91cHMiXX0.SOVe6D-N-WHx3r12y6b-eo4Vw7cE8chGqLyavcxwLC239ntikXqnCEZciG0WIh-KkgWA9v3-spyL4QEi5traLQxPhutBRUrh7rvPPEJBc3NJqG4adT4sIBhrdS0ZPF5zMdSQcY1Sm195KNxfOG9rX-AF8_B-KOvJWkbHmokQiMqiOLPbOuTgy5mWhHW_A_zNJ5ChZR7YI7jlY5t_nkc1TousuQg9oVQ89y7-hXq9LSYHcxzWSOGiheyiLSw7oqRYmmWRYphN5jc38H6E_e7-fVvqGYyhwyQvHlrHjy6-56W_hO0DXAWafYQX_JdS0I83SDqXQRz8xg1ungNzT7Eaog
2017-07-21 11:08:10,751 DEBUG [cloudfoundry-client.token] (AbstractUaaTokenProvider.java:151) - Access Token Issued At: 2017-07-21T02:08:14 UTC
2017-07-21 11:08:10,751 DEBUG [cloudfoundry-client.token] (AbstractUaaTokenProvider.java:151) - Access Token Issued At: 2017-07-21T02:08:14 UTC
2017-07-21 11:08:10,751 DEBUG [cloudfoundry-client.token] (AbstractUaaTokenProvider.java:152) - Access Token Expires At: 2017-07-21T02:18:14 UTC
2017-07-21 11:08:10,751 DEBUG [cloudfoundry-client.token] (AbstractUaaTokenProvider.java:152) - Access Token Expires At: 2017-07-21T02:18:14 UTC

reactor.ipc.netty.http.client.HttpClientException: HTTP request failed with code: 401.
Failing URI: /firehose/cf-nozzle
Suppressed: reactor.core.publisher.FluxOnAssembly$OnAssemblyException:
Assembly trace from producer [reactor.core.publisher.FluxMap] :
reactor.core.publisher.Flux.checkpoint(Flux.java:2914)
org.cloudfoundry.reactor.doppler.ReactorDopplerEndpoints.firehose(ReactorDopplerEndpoints.java:50)
org.cloudfoundry.reactor.doppler._ReactorDopplerClient.firehose(_ReactorDopplerClient.java:44)
org.cloudfoundry.reactor.doppler.ReactorDopplerClient.firehose(ReactorDopplerClient.java:14)
com.skcc.producer.nozzle.FirehoseReader.start(FirehoseReader.java:63)
org.springframework.context.support.DefaultLifecycleProcessor.doStart(DefaultLifecycleProcessor.java:175)
org.springframework.context.support.DefaultLifecycleProcessor.access$200(DefaultLifecycleProcessor.java:50)
org.springframework.context.support.DefaultLifecycleProcessor$LifecycleGroup.start(DefaultLifecycleProcessor.java:348)
org.springframework.context.support.DefaultLifecycleProcessor.startBeans(DefaultLifecycleProcessor.java:151)
org.springframework.context.support.DefaultLifecycleProcessor.onRefresh(DefaultLifecycleProcessor.java:114)
org.springframework.context.support.AbstractApplicationContext.finishRefresh(AbstractApplicationContext.java:880)
org.springframework.boot.context.embedded.EmbeddedWebApplicationContext.finishRefresh(EmbeddedWebApplicationContext.java:144)
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:546)
org.springframework.boot.context.embedded.EmbeddedWebApplicationContext.refresh(EmbeddedWebApplicationContext.java:122)
org.springframework.boot.SpringApplication.refresh(SpringApplication.java:693)
org.springframework.boot.SpringApplication.refreshContext(SpringApplication.java:360)
org.springframework.boot.SpringApplication.run(SpringApplication.java:303)
org.springframework.boot.SpringApplication.run(SpringApplication.java:1118)
org.springframework.boot.SpringApplication.run(SpringApplication.java:1107)
com.skcc.producer.CfProducerApplication.main(CfProducerApplication.java:31)
Error has been observed by the following operator(s):
|_ Flux.checkpoint(ReactorDopplerEndpoints.java:50)

I'm pleased to announce the release of Java Buildpacks v3.19 and v4.3. As always there are some bug fixes and a whole load of new functionality. Please see the release notes[1][2] for details about these and past releases.

As described in the release announcement for 4.0, the three month migration period will be completing shortly. During this period we've received no reports of any major problems and are ready to make 4.x the default releases for Cloud Foundry. We expect v3.19 to be both the final 3.x release, and the final 3.x release that is the default. With the release of v4.4 (historically this will be about 3 weeks from now), 4.x will become the default for all Java users on Cloud Foundry.

Thanks to everyone that provided feedback via GitHub and Slack during the migration period.


-Ben Hale
Cloud Foundry Java Experience


[1]: https://github.com/cloudfoundry/java-buildpack/releases/tag/v3.19
[2]: https://github.com/cloudfoundry/java-buildpack/releases/tag/v4.3

1. is there way to know about token expiration time using cf java client?
I'm using PasswordGrantTokenProvider

Configuring the `cf-java-client.token` logger to `DEBUG` will give you detailed information about the negotiated tokens.

```
cloudfoundry-client.request POST https://login.peach.springapps.io:443/oauth/token
cloudfoundry-client.response 200 https://login.peach.springapps.io:443/oauth/token (460 ms)
cloudfoundry-client.token Refresh Token: eyJhbGciOiJSUzI1NiIsImtpZCI6ImtleS0xIiwidHlwIjo...
cloudfoundry-client.token Refresh Token Issued At: 2017-07-20T16:27:12 UTC
cloudfoundry-client.token Refresh Token Expires At: 2017-08-03T16:27:12 UTC
cloudfoundry-client.token Access Token: eyJhbGciOiJSUzI1NiIsImtpZCI6ImtleS0xIiwidHlwIjoi...
cloudfoundry-client.token Access Token Issued At: 2017-07-20T16:27:12 UTC
cloudfoundry-client.token Access Token Expires At: 2017-07-20T18:27:12 UTC
```

2. sometimes there is 401 error when i restart the nozzle program. is there way to prevent it? how can i do?

The 401 is an expected part of the HTTP authentication handshake. The first call without a token returns a 401 telling the caller that a token must be presented. At this point, the client goes off to negotiate a token and re-makes the same call with the proper token, which is then accepted. Eagerly sending credentials without first being prompted by a 401 is considered poor security practice.

3. suppose token expiration time is ten minutes. during receiving data using subscribe method
is token expiration time extended automatically? or should refresh token every ten minute?

Tokens are only used during the initiation of a connection. So if a connection lives for 1000 hours, the token is only needed at the beginning of the request, not the entire duration. If the connection drops and is restarted, the standard token negotiation handshake takes place. If the token has expired (as indicated by a 401), then the token is refreshed and the request is automatically retried.


-Ben Hale
Cloud Foundry Java Experience

UAA DB is nothing special. We like to keep it simple.
We don't use foreign keys to simplify migration scripts.
We support four different database types, HSQLDB, MySQL(MariaDB),
PostgreSQL and SQL Server.

We made a choice to store some data in JSON format in text or clob columns.
We do this for data we don't want to query and index.


The UAADB is really a very small database, there isn't much to it. The one
thing we are considering reworking is data that is frequently deleted based
on time expiration. MySQL performance is really bad for large transactional
deletes and it can cause hiccups and consume both locks and CPU.

We use Flyway for database migrations between versions.

Filip


On Thu, Jul 20, 2017 at 8:49 AM, Gowrisankar M <gowrisankarbeece(a)gmail.com>
wrote:

Hi Colleages,

I am trying to understand CCDB/UAADB design . Can somebody share some link
for the db design of uaa/cc

BRs, Gowrisankar

Hi Colleages,

I am trying to understand CCDB/UAADB design . Can somebody share some link
for the db design of uaa/cc

BRs, Gowrisankar

Aren't space-scoped ASGs shared across all apps deployed in the same
space?

Yes

So if one app in a space has network access to a service, any other app in
the same space would be able to reach it, at least on the network level,
even if the other app isn't actually bound to the service?

Yes. Network access and service binding are two completely different
things. Just because a component has network access doesn't mean it will
have the IP & credentials to access a service. In the same way, an app
could have a service bound but not have network access.

As long as your services require authentication (which they should), IMHO
the situation you're describing doesn't seem to be a security issue. That
said, security happens in layers so if you can block at the network & not
provide credentials, that's better than just one of those.

tl;dr - if you're using ASGs to protect resources, be careful what apps you
put into an org and space.

Hope that helps!

Dan

On Tue, Jul 18, 2017 at 4:35 PM, Julz Friedman <julz.friedman(a)gmail.com>
wrote:

Garden does have (currently not very well documented) support for setting
hard cpu maximums as well as the fair share limits described above. This is
off by default but can be enabled via the 'garden.cpu_quota_per_share_in_us'
bosh property (more details at https://github.com/cloudfoundr
y/garden-runc-release/releases/tag/v1.3.0). This is a first pass at
solving this so we're very interested in feedback for it and any use cases
it still doesn't solve.


On Tue, 18 Jul 2017 at 14:07, Daniel Mikusa <dmikusa(a)pivotal.io> wrote:

John,

Further down the stack, Garden uses CPU cgroups to achieve CPU

resource management. CPU intensive applications can not affect other
applications in the same space, org or cell.

In the case of apps on the same cell, I would say that one CPU intensive
application can affect other applications on the same cell, but it cannot
completely starve out the other applications on the cell.

Each application on CF is given a number of CPU shares (I believe this
is proportional to the memory limit for the application, i.e. more memory,
more CPU shares) and, while this might be an over simplification, the
shares essentially guarantee you'll receive a minimum amount of CPU time.
They don't prevent you from getting more CPU time, but it prevents other
processes from starving out a process.

Ex 1: You have one Cell with two apps running on it. The apps have the
same memory limit, thus the same CPU shares.
- If App A is doing nothing, App B can make *full* use of the CPUs
- If App B is doing nothing, App A can make *full* use of the CPUs
- if App A & App B are running very CPU intensive workloads, they
should each roughly get half of the CPU resources.

It is technically possible for App A to affect App B's CPU time because
both are guaranteed their shares, however, it's not possible for App A to
starve App B and prevent it from getting any CPU time. The cgroups
configuration guarantees this an app a minimum amount of time.

Where you have to be careful is when you have applications of varying
memory limits (and thus varying CPU shares). The example above is simple
because they both have the same limits. If you have two applications with
wildly different memory limits, you might see issues.

Ex 2: You have one Cell with two apps running on it. App A is very
small and has a 64M memory limit, App B is very large and has a 8G memory
limit.
- Again, if App A is doing nothing, App B can make *full* use of the
CPUs
- Again, if App B is doing nothing, App A can make *full* use of the
CPUs
- If App A & App B are running very CPU intensive workloads, they will
*not* receive equal time on the CPU. App A will basically get 1/128th the
CPU time of App B because of the way CF configures the shares.

Despite this being a fair (i.e. App A is getting what it asked), App A
will undoubtedly be perceived as running slow by its users since it's
getting significantly less access to the CPU while App B is running its
intensive workload. Again, App B cannot completely starve App A, but
in this case because of the CPU shares, it can definitely impact App A a
lot more.

If you find yourself in this situation, you can try restarting your app,
which will perhaps cause it to be run on a different Cell where CPU is not
in contention or you can bump up your memory limit, which will give you
more CPU shares.

Hope that helps!

Dan

PS. George please feel free to correct me if I've misstated anything.



On Tue, Jul 18, 2017 at 5:26 AM, John jerrby <jjerrby(a)gmail.com> wrote:

Hi George,

Thanks!
1. So who "pay" :) when the application in CPU intensive ? if not
other app in the cell ...
2. if there any documentation which can shad some additional lights on
this topic it it will be great if you can share it...

Thanks a lot and have a nice day,

John

HI,

We have an old org for our which exceed quota after several month of teams usage, then we start to delete services manually which not used and this is not a simple job to run after quata , not used service and very hard to manage it...
We have a new Org in CF for Our teams ( we use native CF- OS) .

Now we have a much big Quota, (memory, disk,routes etc) but if we do not do some cleanup job a while the quota will exceed after few month again...
There is some service/ capability in native CF to do some cleanup or shout down automatically for services/app which not used/called after some defined time (like after 2-3 month ) maybe stop them or even delete them .. king of "Watch Dog" ?

Lets say I've the org admin rights ...

Thanks!

Hi Lior,

This part is very intersting, i'll hope we will get an answer that explain the IP issue since sounds like some security risk ...


Regards,
John

HI Daniel,

Thanks for this answer, I learned a lot from it!

Have a nice day!
John

I'm testing cf nozzle using cf client java and have three questions about token management

1. is there way to know about token expiration time using cf java client?
I'm using PasswordGrantTokenProvider

2. sometimes there is 401 error when i restart the nozzle program. is there way to prevent it? how can i do?

3. suppose token expiration time is ten minutes. during receiving data using subscribe method
is token expiration time extended automatically? or should refresh token every ten minute?

thanks and bless you.

Hello all -

Please see below for more information on 3 CAPI CVEs made public today.


Please reply if you have any questions.


Thanks,

Molly Crowther

CFF Security Team

CVE-2017-8033: Cloud Controller API filesystem traversal vulnerability

HIGH

Upgrade instructions: https://www.cloudfoundry.org/cve-2017-8033/

How to tell if your CF installation is affected

At this time we believe that all CF installations are vulnerable.

How to tell if your installation has been exploited

We do not have concrete exploit information at this time.

Immediate Mitigation

-

Turn off the App Bits Upload feature flag. NOTE: this will prevent all
CF Pushes but will not cause application downtime for running apps.

------------------------------


CVE-2017-8035: Cloud Controller API access to CC VM contents

CRITICAL

Upgrade instructions: https://www.cloudfoundry.org/cve-2017-8035/

How to tell if your CF installation is affected

At this time we believe that all CF installations using the versions of the
Cloud Controller API stated in the notice are vulnerable.

How to tell if your installation has been exploited

It is believed that this vulnerability has existed since cf-release 245
(October 2016). It is possible to search logs to determine if you have been
exploited.

Search logs for requests that include any of “droplet_path”,
“application_path”, “buildpack_path”, and “bits_path”. If any log lines
contain this text and they are being used in the query string of an http
request, then that is an indication of an exploit attempt.

Example log text containing one of the above search terms as a query
parameter: “PUT
/v2/apps/033c1ca1-c3bd-40d5-92f8-12c711ead64b/droplet/upload?droplet_path=/some/path”

Immediate Mitigation

-

It is possible to mitigate this issue prior to upgrade by turning off
developer access to the CC API.

------------------------------


CVE-2017-8036: Cloud Controller API regression

CRITICAL

Upgrade instructions: https://www.cloudfoundry.org/cve-2017-8036/

How to tell if your CF installation is affected

This issue only affects installations using CAPI-release v1.33.0.

How to tell if your installation has been exploited

We do not have concrete exploit information at this time.

Immediate Mitigation

-

Turn off the App Bits Upload feature flag. NOTE: this will prevent all
CF Pushes but will not cause application downtime for running apps.

These sound like great ideas! What is the difference between the app metric
forwarding mentioned here and what Scott's team is doing?

-Max

Hi Everyone -

The Loggregator team has been discussing two related features that surface more capabilities to App Developers. There are two separate concepts being proposed here. The first is the ability for developers to forward metrics into the firehose [1]. This expands abilities for developers to inspect custom aspects of their application and build automation on top of existing standards and tooling. The second concept is for developers to have access to a firehose segmented to their org/space[2]. This builds further on existing tooling, but exposes the tooling to development teams at a scope level they have access to on the platform. There is an intentional ordering to these separate but related proposals.

I appreciate your feedback and comments.

Thanks
Adam

[1] - https://docs.google.com/document/d/1hjMO3plNBDwtqCgVIYsayhCcl0k-H0Hzvaaam4SSkto/edit
[2] - https://docs.google.com/document/d/1z5aVaUn0J3sG3q5tGB1viDxAF70HZ1BYnF9vUe-c0j4/edit