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

Hi Mike,

Yes, exactly the same as the current behavior when the Gorouter can't
establish a TCP connection. We currently reject the request after three
failed attempts.

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

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

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/1zkPVGNnBX18rWdOpinIEtRxte3kwpVhIyS9_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-failure-with-route-registration-tp6703p7220.html
Sent from the CF Dev mailing list archive at Nabble.com.

Hi,

Aren't space-scoped ASGs shared across all apps deployed in the same space?
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?


--
Regards,
Lior

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/
cloudfoundry/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

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/cloudfoundry/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.

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

I'll ask. Thanks.

On Tue, Jul 18, 2017 at 2:56 AM Stanislav German-Evtushenko <
s.germanevtushenko(a)rakuten.com> wrote:

Hi,

Can anybody reach mailing list server admin and ask them to fix the
hostname so that "Archived-At" has lists.cloudfoundry.org instead of
localhost and (if possible) to add the same link to the email body?

Best regards,
Stanislav

--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815

Hi Dies,

Due to some internal decisions, we are still in migration phase.

Will it be possible to postpone the deletion of the plugin from community
plugin repo?

Thanks
Ronak



--
View this message in context: http://cf-dev.70369.x6.nabble.com/cf-dev-EOL-for-Diego-Enabler-cf-CLI-plugin-31-July-2017-tp7209p7214.html
Sent from the CF Dev mailing list archive at Nabble.com.