cf login problem

438 views
Skip to first unread message

legendW

unread,
Nov 17, 2014, 4:52:39 AM11/17/14
to vcap...@cloudfoundry.org
Hello everyone !
I deployed cf 191 using bosh 114 in my openstack environment
and used the latest cf cli to login: 
/usr/bin/cf login -a https://api.cf-cloud.com --skip-ssl-validation      
the cf cli reports:
FAILED
Error performing request: Get https://login.cf-cloud.com/login: stopped after 1 redirect

API endpoint:   https://api.cf-cloud.com (API version: 2.16.0)
Not logged in. Use 'cf login' to log in.


anyone can help ? thanks !

Alexander Lomov

unread,
Nov 17, 2014, 5:01:49 AM11/17/14
to vcap...@cloudfoundry.org
Hello. I've already updated installation to v192, but when I had v191 I haven't seen such errors. 

Sample of CF deployment would be helpful there.

--
You received this message because you are subscribed to the Google Groups "Cloud Foundry Developers" group.
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/bad7cd97-ee9f-4a23-8376-796a967d7b41%40cloudfoundry.org.

To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.

Message has been deleted

fi...@hanik.com

unread,
Nov 18, 2014, 2:22:37 PM11/18/14
to vcap...@cloudfoundry.org
That definitely shouldn't happen. Here is what you should see

curl -v https://login.run.pivotal.io/login

in the 'login' job, there is a file called /var/vcap/data/system/log/login/login.log (IIRC)

let us know what that outputs when you hit it with a wget or curl


Filip



On Monday, November 17, 2014 5:42:47 AM UTC-7, legendW wrote:
my deployment file is generated using spiff（attached in this mail）.
and i used wget to have some tests:

(1) 
wget https://api.cf-cloud.com/info --no-check-certificate
it got:
{"name":"vcap","build":"2222","support":"http://support.cloudfoundry.com","version":2,"description":"Cloud Foundry sponsored by Pivotal","authorization_endpoint":"https://login.cf-cloud.com","token_endpoint":"https://uaa.cf-cloud.com","allow_debug":true}

(2)
wget https://login.cf-cloud.com/login -S --no-check-certificate --max-redirect=1
it got:
HTTP request sent, awaiting response...
  HTTP/1.1 302 Found
  Cache-Control: private
  Content-Length: 0
  Date: Mon, 17 Nov 2014 12:33:38 GMT
  Expires: Thu, 01 Jan 1970 00:00:00 UTC
  Server: Apache-Coyote/1.1
  X-Cf-Requestid: 80783f64-0c55-4eb4-4768-3a55c2f6c6c3
  Content-Type: text/plain; charset=utf-8
Location: https://login.cf-cloud.com/login [following]
--2014-11-17 20:32:29--  https://login.cf-cloud.com/login
Reusing existing connection to login.cf-cloud.com:443.
HTTP request sent, awaiting response...
  HTTP/1.1 302 Found
  Cache-Control: private
  Content-Length: 0
  Date: Mon, 17 Nov 2014 12:33:38 GMT
  Expires: Thu, 01 Jan 1970 00:00:00 UTC
  Server: Apache-Coyote/1.1
  X-Cf-Requestid: caf7be68-125d-43bf-6dc8-f4a22bc5de66
  Content-Type: text/plain; charset=utf-8
Location: https://login.cf-cloud.com/login [following]
1 redirections exceeded.

(3)
wget https://uaa.cf-cloud.com/login -S --no-check-certificate --max-redirect=1
it got:
HTTP request sent, awaiting response...
  HTTP/1.1 200 OK
  Content-Language: en-US
  Content-Length: 1311
  Content-Type: text/html;charset=ISO-8859-1
  Date: Mon, 17 Nov 2014 12:35:51 GMT
  Server: Apache-Coyote/1.1
  X-Cf-Requestid: e47fceea-9532-422f-6919-565e0c718efd
Length: 1311 (1.3K) [text/html]
Saving to: ‘login’

and content of ‘login’:

<!DOCTYPE html>
<html lang='en'>
<head>
<title>UAA Login | Cloud Foundry</title>
<meta charset='utf-8'>
</head>
<body id="micro">
<div class="content">
<article class="container">
<p>Sign in with your CloudFoundry credentials.</p>
<form id="loginForm" name="loginForm"
action="/login.do" method="POST" novalidate>
<div>


<input id='username' type='text'
name='username' placeholder='Email' />

<input id='password' type='password'
name='password' placeholder='Password' />

</div>
<button type="submit" class="button">Sign in</button>
</form>
</article>
<div class="message">
<p>
If you are reading this you are probably in the wrong place because
the UAA does not support a branded UI out of the box. To login to
<code>Pivotal Web Services</code>
<a href="https://login.run.pivotal.io">click here.</a> If you were
re-directed here by another application, please contact the owner of
that application and tell them to use the Login Server as UI entry
point.
</p>
</div>
</div>
<div class="footer"
title="Version: 1.8.3, Commit: git-metadata-not-found, Timestamp: 2014-09-26T01:19:07+0000">
Copyright &copy;
2014
Pivotal Software, Inc. All rights reserved.
</div>
</body>
</html>

it seems that https://login.cf-cloud.com/login   always redirect client to itself

legendW

unread,
Nov 19, 2014, 8:28:40 AM11/19/14
to vcap...@cloudfoundry.org, fi...@hanik.com
Thanks for your responding!

when i run this cmd: curl -k -v https://login.cf-cloud.com/login
"/var/vcap/data/system/log/login/login.log"  DON'T has any output

AND ONLY the latest localhost_access.*.log file: "/var/vcap/data/system/log/login/localhost_access.2014-11-19.log" got some output:
188.168.0.106 - - [19/Nov/2014:13:07:35 +0000] "GET /login HTTP/1.1" 302 -
here 188.168.0.106  is router_z1/0

and i notice:
188.168.0.18 - - [19/Nov/2014:13:12:48 +0000] "GET /healthz HTTP/1.1" 302 -
188.168.0.18 - - [19/Nov/2014:13:12:48 +0000] "GET /varz HTTP/1.1" 302 -
every 30 seconds. here 188.168.0.18 is stats_z1/0

on the client side, it reports:
> GET /login HTTP/1.1
> User-Agent: curl/7.35.0
> Accept: */*
>
< HTTP/1.1 302 Found
< Cache-Control: private
< Content-Length: 0
< Date: Wed, 19 Nov 2014 13:07:35 GMT
< Expires: Thu, 01 Jan 1970 00:00:00 UTC
* Server Apache-Coyote/1.1 is not blacklisted
< Server: Apache-Coyote/1.1
< X-Cf-Requestid: 16cb1e8b-697a-4270-7109-8d3396f206eb
< Content-Type: text/plain; charset=utf-8
<
* Connection #0 to host login.cf-cloud.com left intact

it seems that the login job continuously redirects the client to itself ! 

by the way, i tried set the properties.login.enabled to false to bypass the login job 
and use the uaa for authentication(as reported in my previous mail, the uaa works well), 
then everything is OK !

I just wonder what's the problem with login job, or maybe there're some problems with the manifest ?


在 2014年11月19日星期三UTC+8上午3时22分37秒，fi...@hanik.com写道：

Filip Hanik

unread,
Nov 19, 2014, 9:45:34 AM11/19/14
to vcap...@cloudfoundry.org
I have a suspicion,

By default a CF installation expects that you use a certain networking scheme.
188.168.0.106 for the router gets rejected as the login job does not recognize the IP address.
This IP address is hard coded in 

After this PR gets pulled in, it will be configurable

You could validate this by commenting or removing the following lines



--
You received this message because you are subscribed to the Google Groups "Cloud Foundry Developers" group.
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/9a2e57ff-cbe0-4d09-8c86-4bad6d7f8ee8%40cloudfoundry.org.

legendW

unread,
Nov 19, 2014, 11:12:02 AM11/19/14
to vcap...@cloudfoundry.org, fha...@pivotal.io
i removed L15~L19, monit restart login, and got the same result


在 2014年11月19日星期三UTC+8下午10时45分34秒，Filip Hanik写道：

James Myers

unread,
Dec 3, 2014, 7:39:22 PM12/3/14
to vcap...@cloudfoundry.org, fha...@pivotal.io
Hi LegendW,

Sorry for responding so late. Are you still seeing this problem? If so, could you please give us some more information about your deployment? More specifically the infrastructure of your deployment, and your deployment manifest with sensitive information removed.

Thanks,

Jim and Matt, CF Runtime Team

jpal...@pivotal.io

unread,
Dec 5, 2014, 1:22:48 PM12/5/14
to vcap...@cloudfoundry.org, fha...@pivotal.io
Hi LegendW,

Are you using a self signed cert for your load balancer or have you provided a signed certificate?


On Wednesday, November 19, 2014 8:12:02 AM UTC-8, legendW wrote:

legendW

unread,
Dec 9, 2014, 12:38:01 PM12/9/14
to vcap...@cloudfoundry.org, fha...@pivotal.io, jpal...@pivotal.io
Hi !
Sorry for being late here.
Just as you ask, I'm using a self signed cert generated by openssl tools. Any suggestions are appreciated !

During these days, my Openstack has been upgraded to Juno, so I deployed a new v194 cf with bosh 1.2781.0. The result is the same as before.
The config file is attached to provide more info.

PS: the template config files in cf-release/spec/fixtures/openstack/  have a BUG, the default passwords for ccdb role ccadmin are different in two places, 
one is admin_password, the other is ccadmin_password. This causes the api service fails to start because it can't login the db, it reports:
rake aborted!
Sequel::DatabaseConnectionError: PG::ConnectionBad: FATAL:  password authentication failed for user "ccadmin"
/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sequel-4.15.0/lib/sequel/adapters/postgres.rb:218:in `initialize'

When I resolve this problem by making them identical, I also found that the passwords for ccdb role uaaadmin have the same problem.


在 2014年12月6日星期六UTC+8上午2时22分48秒，jpal...@pivotal.io写道：
cf194.yml

Joseph Palermo

unread,
Dec 9, 2014, 8:46:24 PM12/9/14
to vcap...@cloudfoundry.org, fha...@pivotal.io, jpal...@pivotal.io
Thanks for the info. Nothing is really jumping out at us. 

Could you grab the access logs on the gorouter instance (/var/vcap/sys/log/gorouter/access.log) while doing a "cf login"? If the requests are not reaching the login server, it might help to see if they are getting through the router or not. If there is nothing in access.log, check the gorouter.log although I would not expect the login request to generate any output there.

mrwa...@gmail.com

unread,
Dec 9, 2014, 10:12:54 PM12/9/14
to vcap...@cloudfoundry.org, fha...@pivotal.io, jpal...@pivotal.io
here’s the output in the access.log:
api.cf194.com - [10/12/2014:02:52:30 +0000] "GET /v2/info HTTP/1.1" 200 306 "-" "go-cli 6.7.0-c38c991 / linux" 192.136.0.151:35247 x_forwarded_for:"10.121.101.2" vcap_request_id:148c5824-1e65-40d0-79b9-3fa58256206d response_time:0.009574820 app_id:
login.cf194.com - [10/12/2014:02:52:30 +0000] "GET /login HTTP/1.1" 302 0 "-" "go-cli 6.7.0-c38c991 / linux" 192.136.0.151:35248 x_forwarded_for:"10.121.101.2" vcap_request_id:863138c0-75e2-464c-713b-eee7c94c7614 response_time:0.005054067 app_id:
login.cf194.com - [10/12/2014:02:52:30 +0000] "GET /login HTTP/1.1" 302 0 "-" "Go 1.1 package http" 192.136.0.151:35249 x_forwarded_for:"10.121.101.2" vcap_request_id:93dc4738-aa9f-46e3-5db4-76ff393b004f response_time:0.002490618 app_id:

and on the login server, /var/vcap/sys/log/login/localhost_access.2014-12-10.log says:
192.136.0.17 - - [10/Dec/2014:03:06:16 +0000] "GET /varz HTTP/1.1" 302 -
192.136.0.17 - - [10/Dec/2014:03:06:16 +0000] "GET /healthz HTTP/1.1" 302 -
192.136.0.156 - - [10/Dec/2014:03:06:16 +0000] "GET /login HTTP/1.1" 302 -
192.136.0.156 - - [10/Dec/2014:03:06:16 +0000] "GET /login HTTP/1.1" 302 -

here 192.136.0.151 is the ha_proxy, 192.136.0.156 is the router, 192.136.0.17 is the stats, 10.121.101.2 is the openstack router_gateway (my test host is on 192.135 net, and cf is on 192.136 net)

it seems that login not only redirects the request of router, but also other node such as stats

mrwa...@gmail.com

unread,
Dec 9, 2014, 10:30:03 PM12/9/14
to vcap...@cloudfoundry.org, fha...@pivotal.io, jpal...@pivotal.io
in a regular process, when the login receives the request of the client, what is it supposed to do ? As i understand it, it should grad some authentication form data from 
the uaa and send it to the client (or redirect the client to some other authentication service)? Why login server redirects the client to itself again and again ?

在 2014年12月10日，09:46，Joseph Palermo <jpal...@pivotal.io> 写道：

Robert Gallagher

unread,
Dec 10, 2014, 12:48:02 PM12/10/14
to vcap...@cloudfoundry.org, Filip Hanik, jpal...@pivotal.io
Hi LegendW,

In this step:

    You could validate this by commenting or removing the following lines

- did you remove the lines from the /var/vcap/jobs/login/config/tomcat/server.xml config file directly on the login VM? If you changed it in tomcat.server.xml.erb in cf-release, you would have to create another BOSH release to propagate that change to the login server.

Thanks,
Rob & Madhura - CF Identity team

To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/72E688FD-18E5-46A6-B223-EDCB8B29E276%40gmail.com.

mrwa...@gmail.com

unread,
Dec 11, 2014, 4:46:07 AM12/11/14
to vcap...@cloudfoundry.org, Filip Hanik, jpal...@pivotal.io, rgall...@pivotal.io
According to fhanik’s comment, i found the solution: 
ADD my net address 192\.136\.\d{1,3}\.\d{1,3} to the internalProxies list rather than remove the list, and restart login.
it makes login’s tomcat takes my test vm as a trusted internalProxies and thus won’t reject it
i think the better solution is to assign the right private net address in the openstack env, or when login server is redeployed, 
all change will be gone away

But to make things all right, i have to make a cert with CN uaa.cf194.com for the haproxy,
and import it to login through login.uaa_certificate, or this cert (for access uaa server) can’t 
pass the verification on login server no matter the ssl.skip_cert_verify is true or false.

finally everything is OK now, thank you all !


Reply all
Reply to author
Forward
0 new messages