Date   

Re: can't login with cf CLI but the UAAC tool works

kyle havlovitz <kylehav@...>
 

Ok, thanks for the helpful links.
I replaced my config with the uaa.yml and login.yml from there and now the
uaac commands from above work and I can run 'uaac token owner get'. I still
can't login to cf with the cli though.

On Fri, Sep 4, 2015 at 4:15 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

Minimalist defaults are in the UAA repo (uaa.yml and login.yml)
https://github.com/cloudfoundry/uaa/tree/master/uaa/src/main/resources

Yaml is very sensitive to indentation. So hand crafting it may become a
bit difficult.

If you want the UAA to provide all default values (including
admin/adminsecret client and cf/<blank password> client, then don't add any
uaa.yml config file at all. Just start up UAA with it's defaults.
It will suck in client defaults from

https://github.com/cloudfoundry/uaa/blob/feature/invitations_flow_by_email_domain/uaa/src/main/webapp/WEB-INF/spring/oauth-clients.xml#L47-L172

Filip


On Fri, Sep 4, 2015 at 2:05 PM, kyle havlovitz <kylehav(a)gmail.com> wrote:

is there an example somewhere of a minimalist working config for them?
I'm going through at the moment and trying to make mine resemble the config
here:
https://github.com/cloudfoundry/cf-release/blob/master/jobs/uaa/templates/uaa.yml.erb

I'm also defining a test admin user in the scim users section

On Fri, Sep 4, 2015 at 4:00 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

ok, that tells me that your configuration of the UAA clients is incorrect



On Fri, Sep 4, 2015 at 1:44 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

ok so the 'uaac token client get' fails, and the error is 'Bad
credentials'

On Fri, Sep 4, 2015 at 3:33 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

ok, so we can validate that

uaac target http://localhost:8080
uaac token client get admin -s <your admin client secret>
uaac clients

Should show your 'cf' client in the list

then we can do

uaac token owner get cf <username> -s "" -p <user password>

and if that works, we can take it to the next step



On Fri, Sep 4, 2015 at 1:26 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

I started the uaa by building from the tagged version in cf-release
v215 and running it via tomcat with a custom config file, but I didn't
specify a database. I have both a cf and admin section in the uaa clients
config:

cf:

id: cf
override: true
authorized-grant-types: password,implicit,refresh_token
authorities: uaa.none
scope:
cloud_controller.read,cloud_controller.write,openid,password.write,cloud_controller.admin,scim.read,scim.write
secret: 'xxxxxxxxxx'

admin:

id: admin
authorized-grant-types: client_credentials
authorities:
clients.read,clients.write,clients.secret,password.write,scim.read,uaa.admin
scope: read,write,password
resource-ids: clients
secret: 'xxxxxxxxxx'


On Fri, Sep 4, 2015 at 3:09 PM, Filip Hanik <fhanik(a)pivotal.io>
wrote:

ok, so the URL you have is /oauth/token, that's fine. your trace
returns

"authorization_endpoint":"http://localhost:8080","token_endpoint":"
http://localhost:8080/uaa"

indicating that there is a misconfiguration somewhere, but we can
fix that later.

How did you start the UAA? Are you sure that your UAA has a client
named 'cf' in its database?



On Fri, Sep 4, 2015 at 1:05 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

Running that command against /uaa/oauth/token gives just a redirect
to /login. Doing it with /oauth/token gives a 401 unauthorized, same as the
cf cli.

What do you mean by deploy it as root "/"? As in, a override the
url it hosts the endpoints at?


Re: can't login with cf CLI but the UAAC tool works

Filip Hanik
 

Minimalist defaults are in the UAA repo (uaa.yml and login.yml)
https://github.com/cloudfoundry/uaa/tree/master/uaa/src/main/resources

Yaml is very sensitive to indentation. So hand crafting it may become a bit
difficult.

If you want the UAA to provide all default values (including
admin/adminsecret client and cf/<blank password> client, then don't add any
uaa.yml config file at all. Just start up UAA with it's defaults.
It will suck in client defaults from
https://github.com/cloudfoundry/uaa/blob/feature/invitations_flow_by_email_domain/uaa/src/main/webapp/WEB-INF/spring/oauth-clients.xml#L47-L172

Filip

On Fri, Sep 4, 2015 at 2:05 PM, kyle havlovitz <kylehav(a)gmail.com> wrote:

is there an example somewhere of a minimalist working config for them? I'm
going through at the moment and trying to make mine resemble the config
here:
https://github.com/cloudfoundry/cf-release/blob/master/jobs/uaa/templates/uaa.yml.erb

I'm also defining a test admin user in the scim users section

On Fri, Sep 4, 2015 at 4:00 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

ok, that tells me that your configuration of the UAA clients is incorrect



On Fri, Sep 4, 2015 at 1:44 PM, kyle havlovitz <kylehav(a)gmail.com> wrote:

ok so the 'uaac token client get' fails, and the error is 'Bad
credentials'

On Fri, Sep 4, 2015 at 3:33 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

ok, so we can validate that

uaac target http://localhost:8080
uaac token client get admin -s <your admin client secret>
uaac clients

Should show your 'cf' client in the list

then we can do

uaac token owner get cf <username> -s "" -p <user password>

and if that works, we can take it to the next step



On Fri, Sep 4, 2015 at 1:26 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

I started the uaa by building from the tagged version in cf-release
v215 and running it via tomcat with a custom config file, but I didn't
specify a database. I have both a cf and admin section in the uaa clients
config:

cf:

id: cf
override: true
authorized-grant-types: password,implicit,refresh_token
authorities: uaa.none
scope:
cloud_controller.read,cloud_controller.write,openid,password.write,cloud_controller.admin,scim.read,scim.write
secret: 'xxxxxxxxxx'

admin:

id: admin
authorized-grant-types: client_credentials
authorities:
clients.read,clients.write,clients.secret,password.write,scim.read,uaa.admin
scope: read,write,password
resource-ids: clients
secret: 'xxxxxxxxxx'


On Fri, Sep 4, 2015 at 3:09 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

ok, so the URL you have is /oauth/token, that's fine. your trace
returns

"authorization_endpoint":"http://localhost:8080","token_endpoint":"
http://localhost:8080/uaa"

indicating that there is a misconfiguration somewhere, but we can fix
that later.

How did you start the UAA? Are you sure that your UAA has a client
named 'cf' in its database?



On Fri, Sep 4, 2015 at 1:05 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

Running that command against /uaa/oauth/token gives just a redirect
to /login. Doing it with /oauth/token gives a 401 unauthorized, same as the
cf cli.

What do you mean by deploy it as root "/"? As in, a override the url
it hosts the endpoints at?


Re: can't login with cf CLI but the UAAC tool works

kyle havlovitz <kylehav@...>
 

is there an example somewhere of a minimalist working config for them? I'm
going through at the moment and trying to make mine resemble the config
here:
https://github.com/cloudfoundry/cf-release/blob/master/jobs/uaa/templates/uaa.yml.erb

I'm also defining a test admin user in the scim users section

On Fri, Sep 4, 2015 at 4:00 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

ok, that tells me that your configuration of the UAA clients is incorrect



On Fri, Sep 4, 2015 at 1:44 PM, kyle havlovitz <kylehav(a)gmail.com> wrote:

ok so the 'uaac token client get' fails, and the error is 'Bad
credentials'

On Fri, Sep 4, 2015 at 3:33 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

ok, so we can validate that

uaac target http://localhost:8080
uaac token client get admin -s <your admin client secret>
uaac clients

Should show your 'cf' client in the list

then we can do

uaac token owner get cf <username> -s "" -p <user password>

and if that works, we can take it to the next step



On Fri, Sep 4, 2015 at 1:26 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

I started the uaa by building from the tagged version in cf-release
v215 and running it via tomcat with a custom config file, but I didn't
specify a database. I have both a cf and admin section in the uaa clients
config:

cf:

id: cf
override: true
authorized-grant-types: password,implicit,refresh_token
authorities: uaa.none
scope:
cloud_controller.read,cloud_controller.write,openid,password.write,cloud_controller.admin,scim.read,scim.write
secret: 'xxxxxxxxxx'

admin:

id: admin
authorized-grant-types: client_credentials
authorities:
clients.read,clients.write,clients.secret,password.write,scim.read,uaa.admin
scope: read,write,password
resource-ids: clients
secret: 'xxxxxxxxxx'


On Fri, Sep 4, 2015 at 3:09 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

ok, so the URL you have is /oauth/token, that's fine. your trace
returns

"authorization_endpoint":"http://localhost:8080","token_endpoint":"
http://localhost:8080/uaa"

indicating that there is a misconfiguration somewhere, but we can fix
that later.

How did you start the UAA? Are you sure that your UAA has a client
named 'cf' in its database?



On Fri, Sep 4, 2015 at 1:05 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

Running that command against /uaa/oauth/token gives just a redirect
to /login. Doing it with /oauth/token gives a 401 unauthorized, same as the
cf cli.

What do you mean by deploy it as root "/"? As in, a override the url
it hosts the endpoints at?


Re: can't login with cf CLI but the UAAC tool works

Filip Hanik
 

ok, that tells me that your configuration of the UAA clients is incorrect

On Fri, Sep 4, 2015 at 1:44 PM, kyle havlovitz <kylehav(a)gmail.com> wrote:

ok so the 'uaac token client get' fails, and the error is 'Bad
credentials'

On Fri, Sep 4, 2015 at 3:33 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

ok, so we can validate that

uaac target http://localhost:8080
uaac token client get admin -s <your admin client secret>
uaac clients

Should show your 'cf' client in the list

then we can do

uaac token owner get cf <username> -s "" -p <user password>

and if that works, we can take it to the next step



On Fri, Sep 4, 2015 at 1:26 PM, kyle havlovitz <kylehav(a)gmail.com> wrote:

I started the uaa by building from the tagged version in cf-release v215
and running it via tomcat with a custom config file, but I didn't specify a
database. I have both a cf and admin section in the uaa clients config:

cf:

id: cf
override: true
authorized-grant-types: password,implicit,refresh_token
authorities: uaa.none
scope:
cloud_controller.read,cloud_controller.write,openid,password.write,cloud_controller.admin,scim.read,scim.write
secret: 'xxxxxxxxxx'

admin:

id: admin
authorized-grant-types: client_credentials
authorities:
clients.read,clients.write,clients.secret,password.write,scim.read,uaa.admin
scope: read,write,password
resource-ids: clients
secret: 'xxxxxxxxxx'


On Fri, Sep 4, 2015 at 3:09 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

ok, so the URL you have is /oauth/token, that's fine. your trace returns

"authorization_endpoint":"http://localhost:8080","token_endpoint":"
http://localhost:8080/uaa"

indicating that there is a misconfiguration somewhere, but we can fix
that later.

How did you start the UAA? Are you sure that your UAA has a client
named 'cf' in its database?



On Fri, Sep 4, 2015 at 1:05 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

Running that command against /uaa/oauth/token gives just a redirect to
/login. Doing it with /oauth/token gives a 401 unauthorized, same as the cf
cli.

What do you mean by deploy it as root "/"? As in, a override the url
it hosts the endpoints at?


Re: CATs failing

Quintessence Anx
 

Aha! Thank you very much. We have been working on network issues but I
think for the interim I will up the cf_push_timeout.

On Fri, Sep 4, 2015 at 2:08 PM, Amit Gupta <agupta(a)pivotal.io> wrote:

curl exit code 6 means DNS failed. xip.io is flaky, so we this often in
our dev environments where our app domains tend to be HA_PROXY_IP.xip.io.

The CATS expect the apps to finish uploading, staging, and running in 2
minutes, although in reality this can take longer depending on the size of
the app, the number of dependencies it needs to fetch, etc. The CATS apps
are designed to generally get up and running within the 2 minute period,
but can't account for all possible types of network slowness.

openjdk is 43M and downloading on my machine takes about 7 seconds. In
your test output, we see it took 55 seconds. The last thing it was trying
to do was upload the 51M droplet, then at some point the 2min time limit
for everything to finish gets hit and the test fails. My guess is you're
experiencing network issues. If you can't fix those, you may want to
configure a more lenient push timeout in your acceptance_tests errand:


https://github.com/cloudfoundry/cf-release/blob/5fa14702bca4d36d1fdc7241c63d0b3e40dcbe90/jobs/acceptance-tests/spec#L69

Note, the above value is in seconds, so for e.g. if you want 3 minutes,
set it to 180.

On Fri, Sep 4, 2015 at 10:52 AM, Quintessence Anx <qanx(a)starkandwayne.com>
wrote:

Good afternoon!

Our CF deployment fails 4 of the CATs. I have put the errors and the full
output in a GIST here:

https://gist.github.com/qanx/677d64df27d911f39acd

Summary:

* There's a curl error even though the curl succeeds when I run it in
terminal.
* There's a Java buildpack error I can't figure out.
* There are two other buildpack errors, one each for the binary and
staticfile buildpacks. I believe these are expected, though, since we don't
have these two buildpacks in our deployment.

Does anyone know what could be causing these failures?

Thanks!

Quinn


Re: can't login with cf CLI but the UAAC tool works

kyle havlovitz <kylehav@...>
 

ok so the 'uaac token client get' fails, and the error is 'Bad credentials'

On Fri, Sep 4, 2015 at 3:33 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

ok, so we can validate that

uaac target http://localhost:8080
uaac token client get admin -s <your admin client secret>
uaac clients

Should show your 'cf' client in the list

then we can do

uaac token owner get cf <username> -s "" -p <user password>

and if that works, we can take it to the next step



On Fri, Sep 4, 2015 at 1:26 PM, kyle havlovitz <kylehav(a)gmail.com> wrote:

I started the uaa by building from the tagged version in cf-release v215
and running it via tomcat with a custom config file, but I didn't specify a
database. I have both a cf and admin section in the uaa clients config:

cf:

id: cf
override: true
authorized-grant-types: password,implicit,refresh_token
authorities: uaa.none
scope:
cloud_controller.read,cloud_controller.write,openid,password.write,cloud_controller.admin,scim.read,scim.write
secret: 'xxxxxxxxxx'

admin:

id: admin
authorized-grant-types: client_credentials
authorities:
clients.read,clients.write,clients.secret,password.write,scim.read,uaa.admin
scope: read,write,password
resource-ids: clients
secret: 'xxxxxxxxxx'


On Fri, Sep 4, 2015 at 3:09 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

ok, so the URL you have is /oauth/token, that's fine. your trace returns

"authorization_endpoint":"http://localhost:8080","token_endpoint":"
http://localhost:8080/uaa"

indicating that there is a misconfiguration somewhere, but we can fix
that later.

How did you start the UAA? Are you sure that your UAA has a client named
'cf' in its database?



On Fri, Sep 4, 2015 at 1:05 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

Running that command against /uaa/oauth/token gives just a redirect to
/login. Doing it with /oauth/token gives a 401 unauthorized, same as the cf
cli.

What do you mean by deploy it as root "/"? As in, a override the url it
hosts the endpoints at?


Re: can't login with cf CLI but the UAAC tool works

Filip Hanik
 

ok, so we can validate that

uaac target http://localhost:8080
uaac token client get admin -s <your admin client secret>
uaac clients

Should show your 'cf' client in the list

then we can do

uaac token owner get cf <username> -s "" -p <user password>

and if that works, we can take it to the next step

On Fri, Sep 4, 2015 at 1:26 PM, kyle havlovitz <kylehav(a)gmail.com> wrote:

I started the uaa by building from the tagged version in cf-release v215
and running it via tomcat with a custom config file, but I didn't specify a
database. I have both a cf and admin section in the uaa clients config:

cf:

id: cf
override: true
authorized-grant-types: password,implicit,refresh_token
authorities: uaa.none
scope:
cloud_controller.read,cloud_controller.write,openid,password.write,cloud_controller.admin,scim.read,scim.write
secret: 'xxxxxxxxxx'

admin:

id: admin
authorized-grant-types: client_credentials
authorities:
clients.read,clients.write,clients.secret,password.write,scim.read,uaa.admin
scope: read,write,password
resource-ids: clients
secret: 'xxxxxxxxxx'


On Fri, Sep 4, 2015 at 3:09 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

ok, so the URL you have is /oauth/token, that's fine. your trace returns

"authorization_endpoint":"http://localhost:8080","token_endpoint":"
http://localhost:8080/uaa"

indicating that there is a misconfiguration somewhere, but we can fix
that later.

How did you start the UAA? Are you sure that your UAA has a client named
'cf' in its database?



On Fri, Sep 4, 2015 at 1:05 PM, kyle havlovitz <kylehav(a)gmail.com> wrote:

Running that command against /uaa/oauth/token gives just a redirect to
/login. Doing it with /oauth/token gives a 401 unauthorized, same as the cf
cli.

What do you mean by deploy it as root "/"? As in, a override the url it
hosts the endpoints at?


[lattice] v0.4.0

Marco Nicosia
 

On behalf of the Lattice AND the Routing teams, I am pleased to announce
v0.4.0 of Lattice!

We've taken some time off to convert our pipelines from GoCD to Concourse,
and the Routing team has integrated the TCP Router into Lattice. This is
something we've been looking forward to, please check it out and give us
feedback!

The full release notes are included below.

I'm also happy to announce David Wadden as the new Product Manager for
Lattice. David's been the anchor of the project team for the last 6 months,
so he's well-equipped to step into the position. Please welcome in his new
role, and thank you David!

As always:
- If you think you've found a bug, please file a GitHub issue.
- If you have a contribution, we'd be happy to give you feedback via a
Pull Request.
- You can track our prioritized queue of work at:
http://bit.ly/lattice-tracker

--
Marco Nicosia && David Wadden


---------- Forwarded message ----------
From: Marco Nicosia <notifications(a)github.com>
Date: Fri, Sep 4, 2015 at 11:12 AM
Subject: [lattice] v0.4.0
To: cloudfoundry-incubator/lattice <lattice(a)noreply.github.com>


v0.4.0

Beginning with v0.4.1, direct access to Lattice cells will be restricted to
private addresses within the cluster.

Introducing TCP Router

TCP Router is a collection of components that balances traffic across one
or more instances of an application. Unlike gorouter, tcp-router balances
traffic other than HTTP, such as mysql, redis, or mongodb. Using ltc, a
user defines a route from an external port on the Lattice brain to an
exposed port on the application container. Under the hood, tcp-emitter
regularly updates HAProxy <http://www.haproxy.org/> with the TCP routes
defined on the Lattice cluster.

- #172 <https://github.com/cloudfoundry-incubator/lattice/pull/172> #182
<https://github.com/cloudfoundry-incubator/lattice/pull/182> #191
<https://github.com/cloudfoundry-incubator/lattice/pull/191>: Merge TCP
Router functionality [#101089176
<https://www.pivotaltracker.com/story/show/101089176>] [#101699282
<https://www.pivotaltracker.com/story/show/101699282>] [#102296358
<https://www.pivotaltracker.com/story/show/102296358>]
- [image: :+1:] Big thanks to the Routing team for their
contributions! @shalako <https://github.com/shalako> @fordaz
<https://github.com/fordaz> @atulkc <https://github.com/atulkc>
- --routes no longer works on ltc create and ltc launch-droplet.
- Use the --http-routes flag to define HTTP routes for an app. [
#100758692 <https://www.pivotaltracker.com/story/show/100758692>] [
#100436212 <https://www.pivotaltracker.com/story/show/100436212>]
- --http-routes takes a comma-delimited set of ROUTE:CONTAINER_PORT
- This is reversed from --routes (*breaking change*)
- New --tcp-routes flag takes comma-delimited set of
EXTERNAL_PORT:CONTAINER_PORT
- Multiple TCP routes can route to same container port. [#101697408
<https://www.pivotaltracker.com/story/show/101697408>]
- ltc update changes HTTP and/or TCP routes for a running application. [
#98240702 <https://www.pivotaltracker.com/story/show/98240702>]
- Replaces ltc update-routes (will be removed in a future release).
- ltc status and ltc list show TCP routes [#100258924
<https://www.pivotaltracker.com/story/show/100258924>] [#100258722
<https://www.pivotaltracker.com/story/show/100258722>]

New Distribution Bundles

With the recent conversion to Concourse <http://concourse.ci/> as our CI
platform, we took the opportunity to change the way we distribute Lattice
-- no more git checkout; vagrant up. Starting with *v0.4.0*, we distribute
a *bundle* (links below) that contains ltc along with the vagrant/terraform
files needed to launch Lattice.

- Distribute Lattice via bundles [#101458202
<https://www.pivotaltracker.com/story/show/101458202>] [#101314108
<https://www.pivotaltracker.com/story/show/101314108>] [#101314112
<https://www.pivotaltracker.com/story/show/101314112>]

New Features

- ltc target --s3 uses an S3 bucket as the droplet store [#100236758
<https://www.pivotaltracker.com/story/show/100236758>] [#100237448
<https://www.pivotaltracker.com/story/show/100237448>]
- Allows multiple developers to share droplets
- Persists droplets across subsequent Lattice deployments
- ltc create --monitor-command uses a custom healthcheck command [
#91461922 <https://www.pivotaltracker.com/story/show/91461922>]

Usability Fixes

- ltc target times out when a connection to the blob store hangs [
#101164182 <https://www.pivotaltracker.com/story/show/101164182>]
- No longer downloads RootFS at provision-time on Vagrant and AWS [
#101844068 <https://www.pivotaltracker.com/story/show/101844068>] [
#101844098 <https://www.pivotaltracker.com/story/show/101844098>]
- Upgraded base Ubuntu image to 14.04.3 [#102162900
<https://www.pivotaltracker.com/story/show/102162900>]
- Document
<https://github.com/cloudfoundry-incubator/lattice/tree/v0.4.0#vagrant-ip-conflict-errors>
how to diagnose and resolve multiple vagrant instances running [
#101992188 <https://www.pivotaltracker.com/story/show/101992188>]

For Developers

- ci.lattice.cf shows the current build status [#101284204
<https://www.pivotaltracker.com/story/show/101284204>]
- As part of our migration to Concourse, we now track master. Moving
forward, please submit any PRs against the *master* branch. [#101834808
<https://www.pivotaltracker.com/story/show/101834808>]


View it on GitHub
<https://github.com/cloudfoundry-incubator/lattice/releases/tag/v0.4.0>.


Re: can't login with cf CLI but the UAAC tool works

kyle havlovitz <kylehav@...>
 

I started the uaa by building from the tagged version in cf-release v215
and running it via tomcat with a custom config file, but I didn't specify a
database. I have both a cf and admin section in the uaa clients config:

cf:

id: cf
override: true
authorized-grant-types: password,implicit,refresh_token
authorities: uaa.none
scope:
cloud_controller.read,cloud_controller.write,openid,password.write,cloud_controller.admin,scim.read,scim.write
secret: 'xxxxxxxxxx'

admin:

id: admin
authorized-grant-types: client_credentials
authorities:
clients.read,clients.write,clients.secret,password.write,scim.read,uaa.admin
scope: read,write,password
resource-ids: clients
secret: 'xxxxxxxxxx'

On Fri, Sep 4, 2015 at 3:09 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

ok, so the URL you have is /oauth/token, that's fine. your trace returns

"authorization_endpoint":"http://localhost:8080","token_endpoint":"
http://localhost:8080/uaa"

indicating that there is a misconfiguration somewhere, but we can fix that
later.

How did you start the UAA? Are you sure that your UAA has a client named
'cf' in its database?



On Fri, Sep 4, 2015 at 1:05 PM, kyle havlovitz <kylehav(a)gmail.com> wrote:

Running that command against /uaa/oauth/token gives just a redirect to
/login. Doing it with /oauth/token gives a 401 unauthorized, same as the cf
cli.

What do you mean by deploy it as root "/"? As in, a override the url it
hosts the endpoints at?


Re: can't login with cf CLI but the UAAC tool works

Filip Hanik
 

ok, so the URL you have is /oauth/token, that's fine. your trace returns

"authorization_endpoint":"http://localhost:8080","token_endpoint":"
http://localhost:8080/uaa"

indicating that there is a misconfiguration somewhere, but we can fix that
later.

How did you start the UAA? Are you sure that your UAA has a client named
'cf' in its database?

On Fri, Sep 4, 2015 at 1:05 PM, kyle havlovitz <kylehav(a)gmail.com> wrote:

Running that command against /uaa/oauth/token gives just a redirect to
/login. Doing it with /oauth/token gives a 401 unauthorized, same as the cf
cli.

What do you mean by deploy it as root "/"? As in, a override the url it
hosts the endpoints at?


Re: can't login with cf CLI but the UAAC tool works

kyle havlovitz <kylehav@...>
 

Running that command against /uaa/oauth/token gives just a redirect to
/login. Doing it with /oauth/token gives a 401 unauthorized, same as the cf
cli.

What do you mean by deploy it as root "/"? As in, a override the url it
hosts the endpoints at?


Re: So many hard-coded dropsonde destinations to metrons

Amit Kumar Gupta
 

Oddly, I can see your list on nabble here:

http://cf-dev.70369.x6.nabble.com/So-many-hard-coded-dropsonde-destinations-to-metrons-tp1474.html

But it's just blank in the email, and also on the cloudfoundry.org archive:

https://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.cloudfoundry.org/thread/73TWLI6BVETB5PCI4CBKXNCLUZRJJIIV/

Here's the list for anyone else trying to read it:

garden-linux-release/src/github.com/cloudfoundry/dropsonde/dropsonde.go:
10:// dropsonde.Initialize("localhost:3457", origins...)

garden-linux-release/src/
github.com/cloudfoundry-incubator/garden-linux/main.go:
175: "localhost:3457",

github.com/cloudfoundry-incubator/auctioneer/cmd/auctioneer/main.go:
84: dropsondeDestination = "localhost:3457"

github.com/cloudfoundry-incubator/bbs/cmd/bbs/main.go:
67: dropsondeDestination = "localhost:3457"

github.com/cloudfoundry-incubator/converger/cmd/converger/main.go:
82: dropsondeDestination = "localhost:3457"

github.com/cloudfoundry-incubator/diego-ssh/cmd/ssh-proxy/main.go:
68: dropsondeDestination = "localhost:3457"

github.com/cloudfoundry-incubator/file-server/cmd/file-server/main.go:
59: dropsondeDestination = "localhost:3457"

github.com/cloudfoundry-incubator/garden-linux/old/main.go:
178: "localhost:3457",

github.com/cloudfoundry-incubator/nsync/cmd/nsync-bulker/main.go:
109: dropsondeDestination = "localhost:3457"

github.com/cloudfoundry-incubator/nsync/cmd/nsync-listener/main.go:
53: dropsondeDestination = "localhost:3457"

github.com/cloudfoundry-incubator/receptor/cmd/receptor/main.go:
120: dropsondeDestination = "localhost:3457"

github.com/cloudfoundry-incubator/rep/cmd/rep/main.go:
166: dropsondeDestination = "localhost:3457"

github.com/cloudfoundry-incubator/route-emitter/cmd/route-emitter/main.go:
91: dropsondeDestination = "localhost:3457"

github.com/cloudfoundry-incubator/runtime-metrics-server/cmd/runtime-metrics-server/main.go
:
65: "localhost:3457",

github.com/cloudfoundry-incubator/stager/cmd/stager/main.go:
89: dropsondeDestination = "localhost:3457"

github.com/cloudfoundry-incubator/tps/cmd/tps-listener/main.go:
53: dropsondeDestination = "localhost:3457"

github.com/cloudfoundry-incubator/tps/cmd/tps-watcher/main.go:
74: dropsondeDestination = "localhost:3457"

On Fri, Sep 4, 2015 at 3:34 AM, Noburou TANIGUCHI <dev(a)nota.m001.jp> wrote:

Hi,
(This is a post in proxy of my collegue.)

There are so many hard-coded dropsonde destinations (actually each of them
is a metron's listening port) in multiple repositories, while metron's
listening port itself is configurable.

Below is the list that we've found it is hard-coded:



Are they going to be finally configurable in the near future, or is there
any reason to hard-code them?

Thanks in advance.



-----
I'm not a ...
noburou taniguchi
--
View this message in context:
http://cf-dev.70369.x6.nabble.com/So-many-hard-coded-dropsonde-destinations-to-metrons-tp1474.html
Sent from the CF Dev mailing list archive at Nabble.com.


Re: can't login with cf CLI but the UAAC tool works

Filip Hanik
 

ok, this should be an easy one to test (put in your username and password)

curl -v -XPOST -H"Accept:application/json" -u "cf:" -d
"username=marissa&password=koala&client_id=cf&grant_type=password" "
http://localhost:8080/uaa/oauth/token"

and this should return a token

POST /oauth/token HTTP/1.1
Host: localhost:8080

I had expected this to be
POST */uaa*/oauth/token HTTP/1.1
Host: localhost:8080

So it is possible that the CF CLI doesn't support the relative paths, and
you may have to deploy it as root "/"

Filip

On Fri, Sep 4, 2015 at 12:10 PM, kyle havlovitz <kylehav(a)gmail.com> wrote:

cf login
API endpoint: http://localhost:8181
REQUEST: [2015-09-04T17:53:29Z]
GET /v2/info HTTP/1.1
Host: localhost:8181
Accept: application/json
Content-Type: application/json
User-Agent: go-cli 6.12.3-c0c9a03 / linux


RESPONSE: [2015-09-04T17:53:29Z]
HTTP/1.1 200 OK
Content-Length: 406
Connection: keep-alive
Content-Type: application/json;charset=utf-8
Server: thin
X-Content-Type-Options: nosniff
X-Vcap-Request-Id: 9d81e286-dcae-4673-868a-ea4982713581
{"name":"vcap","build":"2222","support":"http://support.local.example.com","version":2,"description":"CF
v2 test environment","authorization_endpoint":"http://localhost:8080
","token_endpoint":"http://localhost:8080/uaa
","min_cli_version":null,"min_recommended_cli_version":null,"api_version":"2.34.0","app_ssh_endpoint":null,"app_ssh_host_key_fingerprint":null,"logging_endpoint":"ws://
127.0.0.1:9090"}
Warning: Insecure http API endpoint detected: secure https API endpoints
are recommended

REQUEST: [2015-09-04T17:53:29Z]
GET /login HTTP/1.1
Host: localhost:8080
Accept: application/json
Content-Type: application/json
User-Agent: go-cli 6.12.3-c0c9a03 / linux


RESPONSE: [2015-09-04T17:53:29Z]
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Access-Control-Allow-Origin: *
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Cache-Control: no-cache, no-store, max-age=0
Content-Language: en-US
Content-Type: application/json;charset=UTF-8
Date: Fri, 04 Sep 2015 17:53:29 GMT
Expires: 0
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Pragma: no-cache
Pragma: no-cache
Server: Apache-Coyote/1.1
Strict-Transport-Security: max-age=31536000
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-Xss-Protection: 1; mode=block
1fd

{"timestamp":"2015-08-05T00:00:41+0000","app":{"version":"2.5.1"},"idpDefinitions":[],"fieldUsernameShow":true,"zone_name":"uaa","commit_id":"eae6724","prompts":{"username":["text","Email"],"password":["password","Password"]},"forgotPasswordLink":"/forgot_password","createAccountLink":"/create_account","links":{"register":"/create_account","passwd":"/forgot_password","login":"
http://localhost:8080/login","uaa":"http://localhost:8080/uaa
"},"entityID":"cloudfoundry-saml-login","linkCreateAccountShow":true}
0


Email> admin
Password>
Authenticating...
REQUEST: [2015-09-04T17:53:37Z]
POST /oauth/token HTTP/1.1
Host: localhost:8080
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/x-www-form-urlencoded
User-Agent: go-cli 6.12.3-c0c9a03 / linux
grant_type=password&password=[PRIVATE DATA HIDDEN]&scope=&username=admin
RESPONSE: [2015-09-04T17:53:37Z]
HTTP/1.1 401 Unauthorized
Transfer-Encoding: chunked
Access-Control-Allow-Origin: *
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Cache-Control: no-store
Content-Type: application/json
Date: Fri, 04 Sep 2015 17:53:37 GMT
Expires: 0
Pragma: no-cache
Pragma: no-cache
Server: Apache-Coyote/1.1
Www-Authenticate: Basic realm="UAA/client", error="unauthorized",
error_description="Bad credentials"
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-Xss-Protection: 1; mode=block
3e
{"error":"unauthorized","error_description":"Bad credentials"}
0

Also: when i do 'uaac token get' with those same credentials, it succeeds.


Re: can't login with cf CLI but the UAAC tool works

kyle havlovitz <kylehav@...>
 


cf login
API endpoint: http://localhost:8181
REQUEST: [2015-09-04T17:53:29Z]
GET /v2/info HTTP/1.1
Host: localhost:8181
Accept: application/json
Content-Type: application/json
User-Agent: go-cli 6.12.3-c0c9a03 / linux


RESPONSE: [2015-09-04T17:53:29Z]
HTTP/1.1 200 OK
Content-Length: 406
Connection: keep-alive
Content-Type: application/json;charset=utf-8
Server: thin
X-Content-Type-Options: nosniff
X-Vcap-Request-Id: 9d81e286-dcae-4673-868a-ea4982713581
{"name":"vcap","build":"2222","support":"http://support.local.example.com","version":2,"description":"CF
v2 test environment","authorization_endpoint":"http://localhost:8080
","token_endpoint":"http://localhost:8080/uaa
","min_cli_version":null,"min_recommended_cli_version":null,"api_version":"2.34.0","app_ssh_endpoint":null,"app_ssh_host_key_fingerprint":null,"logging_endpoint":"ws://
127.0.0.1:9090"}
Warning: Insecure http API endpoint detected: secure https API endpoints
are recommended

REQUEST: [2015-09-04T17:53:29Z]
GET /login HTTP/1.1
Host: localhost:8080
Accept: application/json
Content-Type: application/json
User-Agent: go-cli 6.12.3-c0c9a03 / linux


RESPONSE: [2015-09-04T17:53:29Z]
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Access-Control-Allow-Origin: *
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Cache-Control: no-cache, no-store, max-age=0
Content-Language: en-US
Content-Type: application/json;charset=UTF-8
Date: Fri, 04 Sep 2015 17:53:29 GMT
Expires: 0
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Pragma: no-cache
Pragma: no-cache
Server: Apache-Coyote/1.1
Strict-Transport-Security: max-age=31536000
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-Xss-Protection: 1; mode=block
1fd

{"timestamp":"2015-08-05T00:00:41+0000","app":{"version":"2.5.1"},"idpDefinitions":[],"fieldUsernameShow":true,"zone_name":"uaa","commit_id":"eae6724","prompts":{"username":["text","Email"],"password":["password","Password"]},"forgotPasswordLink":"/forgot_password","createAccountLink":"/create_account","links":{"register":"/create_account","passwd":"/forgot_password","login":"
http://localhost:8080/login","uaa":"http://localhost:8080/uaa
"},"entityID":"cloudfoundry-saml-login","linkCreateAccountShow":true}
0


Email> admin
Password>
Authenticating...
REQUEST: [2015-09-04T17:53:37Z]
POST /oauth/token HTTP/1.1
Host: localhost:8080
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/x-www-form-urlencoded
User-Agent: go-cli 6.12.3-c0c9a03 / linux
grant_type=password&password=[PRIVATE DATA HIDDEN]&scope=&username=admin
RESPONSE: [2015-09-04T17:53:37Z]
HTTP/1.1 401 Unauthorized
Transfer-Encoding: chunked
Access-Control-Allow-Origin: *
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Cache-Control: no-store
Content-Type: application/json
Date: Fri, 04 Sep 2015 17:53:37 GMT
Expires: 0
Pragma: no-cache
Pragma: no-cache
Server: Apache-Coyote/1.1
Www-Authenticate: Basic realm="UAA/client", error="unauthorized",
error_description="Bad credentials"
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-Xss-Protection: 1; mode=block
3e
{"error":"unauthorized","error_description":"Bad credentials"}
0

Also: when i do 'uaac token get' with those same credentials, it succeeds.


Re: CATs failing

Amit Kumar Gupta
 

curl exit code 6 means DNS failed. xip.io is flaky, so we this often in
our dev environments where our app domains tend to be HA_PROXY_IP.xip.io.

The CATS expect the apps to finish uploading, staging, and running in 2
minutes, although in reality this can take longer depending on the size of
the app, the number of dependencies it needs to fetch, etc. The CATS apps
are designed to generally get up and running within the 2 minute period,
but can't account for all possible types of network slowness.

openjdk is 43M and downloading on my machine takes about 7 seconds. In
your test output, we see it took 55 seconds. The last thing it was trying
to do was upload the 51M droplet, then at some point the 2min time limit
for everything to finish gets hit and the test fails. My guess is you're
experiencing network issues. If you can't fix those, you may want to
configure a more lenient push timeout in your acceptance_tests errand:

https://github.com/cloudfoundry/cf-release/blob/5fa14702bca4d36d1fdc7241c63d0b3e40dcbe90/jobs/acceptance-tests/spec#L69

Note, the above value is in seconds, so for e.g. if you want 3 minutes, set
it to 180.

On Fri, Sep 4, 2015 at 10:52 AM, Quintessence Anx <qanx(a)starkandwayne.com>
wrote:

Good afternoon!

Our CF deployment fails 4 of the CATs. I have put the errors and the full
output in a GIST here:

https://gist.github.com/qanx/677d64df27d911f39acd

Summary:

* There's a curl error even though the curl succeeds when I run it in
terminal.
* There's a Java buildpack error I can't figure out.
* There are two other buildpack errors, one each for the binary and
staticfile buildpacks. I believe these are expected, though, since we don't
have these two buildpacks in our deployment.

Does anyone know what could be causing these failures?

Thanks!

Quinn


Re: can't login with cf CLI but the UAAC tool works

Filip Hanik
 

Turn on trace, and post your data here. remember, if this is a prod
environment, you may want to send me the token directly
We can show you how to decode this token, and see why it is invalid.

Filip

On Fri, Sep 4, 2015 at 11:59 AM, kyle havlovitz <kylehav(a)gmail.com> wrote:

I'm having an issue with my cloud controller/UAA setup where when I do cf
login I get '401 unauthorized' back, but when I use the uaac command line
tool to get a token it works fine. This makes me think the UAA is working
but something is off with the cloud controller config, but I'm not sure
what. The only strange thing I see is that the CLI is POSTing to
/oauth/token and the uaac goes to /oauth/authorize.

This is all using v215 of cloudfoundry running/built locally and 6.12.3 of
the cli. Is there some endpoint that needs to be set correctly in the cloud
controller config?



can't login with cf CLI but the UAAC tool works

kyle havlovitz <kylehav@...>
 

I'm having an issue with my cloud controller/UAA setup where when I do cf
login I get '401 unauthorized' back, but when I use the uaac command line
tool to get a token it works fine. This makes me think the UAA is working
but something is off with the cloud controller config, but I'm not sure
what. The only strange thing I see is that the CLI is POSTing to
/oauth/token and the uaac goes to /oauth/authorize.

This is all using v215 of cloudfoundry running/built locally and 6.12.3 of
the cli. Is there some endpoint that needs to be set correctly in the cloud
controller config?


Re: Generic data points for dropsonde

Benjamin Black
 

johannes,

the problem of upstream schema changes causing downstream change or
breakage is the current situation: every addition of a metric type implies
a change to the dropsonde-protocol requiring everything downstream to be
updated.

the schema concerns are similar. currently there is no schema whatsoever
beyond the very fine grained "this is a name and this is a value". this
means every implementation of redis info export, for example, can, and
almost certainly will, be different. this results in every downstream
consumer having to know every possible variant or to only support specific
variants, both exactly the problem you are looking to avoid.

i share the core concern regarding ensuring points are "sufficiently" self
describing. however, there is no clear line delineating what is sufficient.
the current proposal pushes almost everything out to schema. we could
imagine a change to the attributes that includes what an attribute is
(gauge, counter, etc), what the units are for the attribute, and so on.

it is critical that we balance the complexity of the points against
complexity of the consumers as there is no free lunch here. which specific
functionality would you want to see in the generic points to achieve the
balance you prefer?


b



On Wed, Sep 2, 2015 at 2:07 PM, Johannes Tuchscherer <
jtuchscherer(a)pivotal.io> wrote:

The current way of sending metrics as either Values or Counters through
the pipeline makes the development of a downstream consumer (=nozzle)
pretty easy. If you look at the datadog nozzle[0], it just takes all
ValueMetrics and Counters and sends them off to datadog. The nozzle does
not have to know anything about these metrics (e.g. their origin, name, or
layout).

Adding a new way to send metrics as a nested object would make the
downstream implementation certainly more complicated. In that case, the
nozzle developer has to know what metrics are included inside the generic
point (basically the schema of the metric) and treat each point
accordingly. For example, if I were to write a nozzle that emits metrics to
Graphite with a StatsD client (like it is done here[1]), I need to know if
my int64 value is a Gauge or a Counter. Also, my consumer is under constant
risk of breaking when the upstream schema changes.

We are already facing this problem with the container metrics. But at
least the container metrics are in a defined format that is well documented
and not likely to change.

I agree with you, though, the the dropsonde protocol could use a mechanism
for easier extension. Having a GenericPoint and/or GenericEvent seems like
a good idea that I whole-heartedly support. I would just like to stay away
from nested metrics. I think the cost of adding more logic into the
downstream consumer (and making it harder to maintain) is not worth the
benefit of a more concise metric transport.


[0] https://github.com/cloudfoundry-incubator/datadog-firehose-nozzle
[1] https://github.com/CloudCredo/graphite-nozzle

On Tue, Sep 1, 2015 at 5:52 PM, Benjamin Black <bblack(a)pivotal.io> wrote:

great questions, dwayne.

1) the partition key is intended to be used in a similar manner to
partitioners in distributed systems like cassandra or kafka. the specific
behavior i would like to make part of the contract is two-fold: that all
data with the same key is routed to the same partition and that all data in
a partition is FIFO (meaning no ordering guarantees beyond arrival time).

this could help with the multi-line log problem by ensuring a single
consumer will receive all lines for a given log entry in order, allowing
simple reassembly. however, the lines might be interleaved with other lines
with the same key or even other keys that happen to map to the same
partition, so the consumer does require a bit of intelligence. this was
actually one of the driving scenarios for adding the key.

2) i expect typical points to be in the hundreds of bytes to a few KB. if
we find ourselves regularly needing much larger points, especially near
that 64KB limit, i'd look to the JSON representation as the hierarchical
structure is more efficiently managed there.


b




On Tue, Sep 1, 2015 at 4:42 PM, <dschultz(a)pivotal.io> wrote:

Hi Ben,

I was wondering if you could give a concrete use case for the partition
key functionality.

In particular I am interested in how we solve multi line log entries. I
think it would be better to solve it by keeping all the data (the multiple
lines) together throughout the logging/metrics pipeline, but could see how
something like a partition key might help keep the data together as well.

Second question: how large do you see these point messages getting
(average and max)? There are still several stages of the logging/metrics
pipeline that use UDP with a standard 64K size limit.

Thanks,
Dwayne

On Aug 28, 2015, at 4:54 PM, Benjamin Black <bblack(a)pivotal.io> wrote:

All,

The existing dropsonde protocol uses a different message type for each
event type. HttpStart, HttpStop, ContainerMetrics, and so on are all
distinct types in the protocol definition. This requires protocol changes
to introduce any new event type, making such changes very expensive. We've
been working for the past few weeks on an addition to the dropsonde
protocol to support easier future extension to new types of events and to
make it easier for users to define their own events.

The document linked below [1] describes a generic data point message
capable of carrying multi-dimensional, multi-metric points as sets of
name/value pairs. This new message is expected to be added as an additional
entry in the existing dropsonde protocol metric type enum. Things are now
at a point where we'd like to get feedback from the community before moving
forward with implementation.

Please contribute your thoughts on the document in whichever way you are
most comfortable: comments on the document, email here, or email directly
to me. If you comment on the document, please make sure you are logged in
so we can keep track of who is asking for what. Your views are not just
appreciated, but critical to the continued health and success of the Cloud
Foundry community. Thank you!


b

[1]
https://docs.google.com/document/d/1SzvT1BjrBPqUw6zfSYYFfaW9vX_dTZZjn5sl2nxB6Bc/edit?usp=sharing





CATs failing

Quintessence Anx
 

Good afternoon!

Our CF deployment fails 4 of the CATs. I have put the errors and the full
output in a GIST here:

https://gist.github.com/qanx/677d64df27d911f39acd

Summary:

* There's a curl error even though the curl succeeds when I run it in
terminal.
* There's a Java buildpack error I can't figure out.
* There are two other buildpack errors, one each for the binary and
staticfile buildpacks. I believe these are expected, though, since we don't
have these two buildpacks in our deployment.

Does anyone know what could be causing these failures?

Thanks!

Quinn


Re: Status of support for route paths in cli

Mike Youngstrom
 

Great! Thanks Dieu.

Mike

On Fri, Sep 4, 2015 at 10:46 AM, Dieu Cao <dcao(a)pivotal.io> wrote:

Shannon recently pulled the story over into the Routing team's tracker [1]
with the intention to submit a PR for it to the CLI team.

-Dieu
CF CAPI PM

[1] https://www.pivotaltracker.com/story/show/93368928

On Fri, Sep 4, 2015 at 9:09 AM, Mike Youngstrom <youngm(a)gmail.com> wrote:

Route path support has been in the CC and Router for several months now.
What is the status of getting these into the CLI? I did a quick search for
a CLI tracker story and couldn't find one.

Mike

7901 - 7920 of 9421