Soliciting feedback for design proposal: TCP Routing
Shannon Coen
Currently Cloud Foundry only supports routing of http traffic to
applications. There are many use cases, especially related to IOT, for
which applications need to receive non-http traffic.
Together with Atul Kshirsagar and Fermin Ordaz from GE, we've begun initial
work on a TCP Routing service that would enable routing of non-http traffic
to applications running on Diego in Lattice and Cloud Foundry.
Our project proposal is open for public comment and we welcome your
feedback:
https://docs.google.com/document/d/1PZE_ieAZLew6nUKIB1eaNtDWRrZt57ffqwXch0K6lVw/edit?usp=sharing
We will be requesting this project be accepted into incubation with a Cloud
Foundry Foundation PMC.
Thank you,
Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.
applications. There are many use cases, especially related to IOT, for
which applications need to receive non-http traffic.
Together with Atul Kshirsagar and Fermin Ordaz from GE, we've begun initial
work on a TCP Routing service that would enable routing of non-http traffic
to applications running on Diego in Lattice and Cloud Foundry.
Our project proposal is open for public comment and we welcome your
feedback:
https://docs.google.com/document/d/1PZE_ieAZLew6nUKIB1eaNtDWRrZt57ffqwXch0K6lVw/edit?usp=sharing
We will be requesting this project be accepted into incubation with a Cloud
Foundry Foundation PMC.
Thank you,
Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.
Re: Scaling Services
Matt Cowger
I can't speak to a), but the general pattern for b) would be to store the
actual blob data into an object store of some sort (whether public like AWS
S3 or Azure, etc, or on a private service like Scality, EMC ECS, or
Cleversafe), and then simply store the URL / ID for that photo into the
database.
On Tue, Jun 2, 2015 at 2:12 PM, Flávio Henrique Schuindt da Silva <
flavio.schuindt(a)gmail.com> wrote:
--
-- Matt
actual blob data into an object store of some sort (whether public like AWS
S3 or Azure, etc, or on a private service like Scality, EMC ECS, or
Cleversafe), and then simply store the URL / ID for that photo into the
database.
On Tue, Jun 2, 2015 at 2:12 PM, Flávio Henrique Schuindt da Silva <
flavio.schuindt(a)gmail.com> wrote:
Hi, guys.
I'm a beginner in using CF and I successfully deployed cf-mysql-release
[1] and now I can write, read, etc from the database as a service bound in
my application.
Now, I have some questions and it would be really great if someone could
help me.
a) Ok, I have a database that works and its great. Imagine a scenario that
a lot of clients are acessing my app and now I have to scale. How CF scale
the service? I mean there must be some way to give more nodes on the maria
db cluster provided by [1], right?
b) If I need to save profile pictures to a user table. What should I do?
Save it as blob in the database since write data to disk is not recommended
by cf docs because apps are isolated each other in the DEA.
Thank you very much for your patient and time.
[1] - https://github.com/cloudfoundry/cf-mysql-release
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
-- Matt
Scaling Services
Flávio Henrique Schuindt da Silva <flavio.schuindt at gmail.com...>
Hi, guys.
I'm a beginner in using CF and I successfully deployed cf-mysql-release [1]
and now I can write, read, etc from the database as a service bound in my
application.
Now, I have some questions and it would be really great if someone could
help me.
a) Ok, I have a database that works and its great. Imagine a scenario that
a lot of clients are acessing my app and now I have to scale. How CF scale
the service? I mean there must be some way to give more nodes on the maria
db cluster provided by [1], right?
b) If I need to save profile pictures to a user table. What should I do?
Save it as blob in the database since write data to disk is not recommended
by cf docs because apps are isolated each other in the DEA.
Thank you very much for your patient and time.
[1] - https://github.com/cloudfoundry/cf-mysql-release
I'm a beginner in using CF and I successfully deployed cf-mysql-release [1]
and now I can write, read, etc from the database as a service bound in my
application.
Now, I have some questions and it would be really great if someone could
help me.
a) Ok, I have a database that works and its great. Imagine a scenario that
a lot of clients are acessing my app and now I have to scale. How CF scale
the service? I mean there must be some way to give more nodes on the maria
db cluster provided by [1], right?
b) If I need to save profile pictures to a user table. What should I do?
Save it as blob in the database since write data to disk is not recommended
by cf docs because apps are isolated each other in the DEA.
Thank you very much for your patient and time.
[1] - https://github.com/cloudfoundry/cf-mysql-release
Utilities PMC - 2015-06-02 notes
Mike Dalessio
Hi all,
We had a meeting of the Utilities PMC today, permanent notes are at:
https://github.com/cloudfoundry/pmc-notes/blob/master/Utilities/2015-06-02-utilities.md
which I've helpfully copied into this email below.
Cheers!
-mike
-----
*# Utilities PMC Meeting 2015-05-19*
*## Agenda*
1. Update on CI tools (Mike Dalessio)
2. Update on CLI (Greg Oehmen)
3. Update on Eclipse plugin and Java tools (Ryan Morgan)
4. Open Discussion
*## Attendees*
* Chip Childers, Cloud Foundry Foundation
* Mike Dalessio, Pivotal (PMC lead)
* Ryan Morgan, Pivotal
* Steve Winkler, GE
* Gert Drapers, HP
* Matt Sykes, IBM
* Michael Fraenkel, IBM
*## Update on CI tools (Mike Dalessio)*
- The Toolsmiths team will be shutting down the OSS GoCD pipeline,
which was only servicing the CLI team (and they are moving to
Concourse).
- The Buildpacks team has moved to concourse, and will be
open-sourcing their pipeline configurations once the environment has
been secured and it's not leaking credentials
- The Concourse team has started to put together some security
recommendations for setting up a secure Concourse deployment, with
particular attention to AWS configuration.
*## Update on CLI (Greg Oehman)*
* Ongoing work on service keys with Services team
* Finishing last details of Concourse migration
* Ongoing work on Plugin API (vetted plan/implementation with community at
CF Summit CLI Open House - great experience)
* Reviving `cfhelp` refactoring work with Mike Long, IBM Designers. Will
be next feature after Plugin API
*## Update on Eclipse plugin and Java tools (Ryan Morgan)*
* Work on 1.8.3 progressing, mostly bug fixes.
* Completed a spike on Debugging a Java application via SSH. Requires
Diego and currently only works in bosh-lite. Will be included in 1.8.3.
Story for this feature: https://www.pivotaltracker.com/story/show/94617426.
*## Open Discussion*
Nothing additional was discussed.
We had a meeting of the Utilities PMC today, permanent notes are at:
https://github.com/cloudfoundry/pmc-notes/blob/master/Utilities/2015-06-02-utilities.md
which I've helpfully copied into this email below.
Cheers!
-mike
-----
*# Utilities PMC Meeting 2015-05-19*
*## Agenda*
1. Update on CI tools (Mike Dalessio)
2. Update on CLI (Greg Oehmen)
3. Update on Eclipse plugin and Java tools (Ryan Morgan)
4. Open Discussion
*## Attendees*
* Chip Childers, Cloud Foundry Foundation
* Mike Dalessio, Pivotal (PMC lead)
* Ryan Morgan, Pivotal
* Steve Winkler, GE
* Gert Drapers, HP
* Matt Sykes, IBM
* Michael Fraenkel, IBM
*## Update on CI tools (Mike Dalessio)*
- The Toolsmiths team will be shutting down the OSS GoCD pipeline,
which was only servicing the CLI team (and they are moving to
Concourse).
- The Buildpacks team has moved to concourse, and will be
open-sourcing their pipeline configurations once the environment has
been secured and it's not leaking credentials
- The Concourse team has started to put together some security
recommendations for setting up a secure Concourse deployment, with
particular attention to AWS configuration.
*## Update on CLI (Greg Oehman)*
* Ongoing work on service keys with Services team
* Finishing last details of Concourse migration
* Ongoing work on Plugin API (vetted plan/implementation with community at
CF Summit CLI Open House - great experience)
* Reviving `cfhelp` refactoring work with Mike Long, IBM Designers. Will
be next feature after Plugin API
*## Update on Eclipse plugin and Java tools (Ryan Morgan)*
* Work on 1.8.3 progressing, mostly bug fixes.
* Completed a spike on Debugging a Java application via SSH. Requires
Diego and currently only works in bosh-lite. Will be included in 1.8.3.
Story for this feature: https://www.pivotaltracker.com/story/show/94617426.
*## Open Discussion*
Nothing additional was discussed.
Soliciting feedback on feature proposal: User-managed Service Brokers
Shannon Coen
Currently registration of service brokers is an admin-only function in
Cloud Foundry. We've heard users and operators ask for a feature that would
enable broker authors to register their own service brokers, as this will
remove barriers to development of service brokers and add support for
self-service marketplace catalog management for application developers.
Our proposal is open for public comment:
https://docs.google.com/document/d/1azArNcDtOjiq5wHx0BCS3OABfJf1PufPmc0OqfkFq7c/edit?usp=sharing
I've also linked to it from the cloudfoundry-community design docs page:
https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/Design-Documents
If this feature is of interest to you, please review our proposal and give
us feedback by commenting in the doc. The Services API team will likely
begin working on the feature next week.
Thank you,
Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.
Cloud Foundry. We've heard users and operators ask for a feature that would
enable broker authors to register their own service brokers, as this will
remove barriers to development of service brokers and add support for
self-service marketplace catalog management for application developers.
Our proposal is open for public comment:
https://docs.google.com/document/d/1azArNcDtOjiq5wHx0BCS3OABfJf1PufPmc0OqfkFq7c/edit?usp=sharing
I've also linked to it from the cloudfoundry-community design docs page:
https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/Design-Documents
If this feature is of interest to you, please review our proposal and give
us feedback by commenting in the doc. The Services API team will likely
begin working on the feature next week.
Thank you,
Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.
Re: sporadic connection resets between login and uaa
Filip Hanik
hi Jan, yes you are correct. And even in the old configuration, a
connection reset is a network issue, so you would have to see who initiated
the the reset (TCP RST package). Most likely the IP that hosts uaa.<domain>
- the load balancer?
toggle quoted message
Show quoted text
connection reset is a network issue, so you would have to see who initiated
the the reset (TCP RST package). Most likely the IP that hosts uaa.<domain>
- the load balancer?
On Tue, Jun 2, 2015 at 10:25 AM, Sievers, Jan <jan.sievers(a)sap.com> wrote:
Am I right this problem is obsolete since the login-uaa merge in CF 208
[1]?
Regards,
Jan
[1] http://lists.cloudfoundry.org/pipermail/cf-dev/2015-May/000087.html-----Original Message-----noticed
From: Sievers, Jan
Sent: Montag, 1. Juni 2015 11:31
To: 'cf-dev(a)lists.cloudfoundry.org'
Subject: sporadic connection resets between login and uaa
Hi,
while running the CF 207 smoke and acceptance tests repeatedly, wesporadic connection resets during 'cf login'balancer).
(see log snippet from login log below).
The connection reset is happening on the login machine when it's doing an
HTTP POST to
http://uaa.cf.<DOMAIN>/authenticate
(via load balancer, and getting a connection reset from the loadThis is happening ~ 1 out of 5 times if we run the smoke tests every 5client on
minutes.
We found that adding
-Dhttp.keepAlive=false
to JAVA_OPTS in /var/vcap/jobs/login/bin/login_ctl
works around the problem. Otherwise, by default there is a pool of 5
connections being kept alive and reused.
We use an F5 BigIP load balancer with 300 seconds socket idle timeout
configured.
Could this be a bug with stale connections being reused by the HTTPthe login machine?---
Best Regards,
Jan
--- log snippet from login machine ---
[2015-05-08 08:07:52.787] login - 9054 [http-bio-8080-exec-2] .... DEBUGDispatcherServlet: DispatcherServlet with name 'spring' processing POST---
request for [/error500]
[2015-05-08 08:07:52.787] login - 9054 [http-bio-8080-exec-2] .... DEBUGRequestMappingHandlerMapping: Looking up handler method for path/error500[2015-05-08 08:07:52.787] login - 9054 [http-bio-8080-exec-2] .... DEBUG---RequestMappingHandlerMapping: Returning handler method [publicorg.cloudfoundry.identity.uaa.login.HomeController.error500(org.springframewo
java.lang.Stringrk.ui.Model,javax.servlet.http.HttpServletRequest)]---
[2015-05-08 08:07:52.787] login - 9054 [http-bio-8080-exec-2] .... ERRORHomeController: Internal errornested
org.springframework.web.client.ResourceAccessException: I/O error on POST
request for "http://uaa.cf.<DOMAIN>/authenticate":Connection reset;exception is java.net.SocketException: Connection resetorg.springframework.web.client.RestTemplate.doExecute(RestTemplate.java:567)
atatorg.springframework.security.oauth2.client.OAuth2RestTemplate.doExecute(OAuth2RestTemplate.java:128)org.springframework.web.client.RestTemplate.execute(RestTemplate.java:512)
atatorg.springframework.web.client.RestTemplate.exchange(RestTemplate.java:454)atorg.cloudfoundry.identity.uaa.login.RemoteUaaAuthenticationManager.authenticate(RemoteUaaAuthenticationManager.java:137)org.cloudfoundry.identity.uaa.authentication.AuthzAuthenticationFilter.doFilt
ater(AuthzAuthenticationFilter.java:138)org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter
at(FilterChainProxy.java:342)org.springframework.security.web.context.request.async.WebAsyncManagerIntegra
attionFilter.doFilterInternal(WebAsyncManagerIntegrationFilter.java:50)org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFi
atlter.java:107)org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter
at(FilterChainProxy.java:342)org.springframework.security.web.context.SecurityContextPersistenceFilter.doF
atilter(SecurityContextPersistenceFilter.java:87)org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter
at(FilterChainProxy.java:342)org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChai
atnProxy.java:192)org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.j
atava:160)org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(Delegatin
atgFilterProxy.java:344)org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilte
atrProxy.java:261)org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationF
atilterChain.java:241)org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCha
atin.java:208)org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.jav
ata:220)org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.jav
ata:122)org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.
atjava:501)org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
atatorg.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)atorg.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:950)
at
org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:683)
at116)org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
atatorg.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116) [37/1995]org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
atatorg.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1070)org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(Abstract
atProtocol.java:611)org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:3
at14)java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:114
at5)java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:61
at5)org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.jav
ata:61)org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferI
at java.lang.Thread.run(Thread.java:744)
Caused by: java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:196)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
atmpl.java:136)org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferI
atmpl.java:152)org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImp
atl.java:270)org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResp
atonseParser.java:140)org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResp
atonseParser.java:57)org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.jav
ata:260)org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(Defau
atltBHttpClientConnection.java:161)sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.
at sun.reflect.GeneratedMethodAccessor121.invoke(Unknown Source)
atjava:43)org.apache.http.impl.conn.CPoolProxy.invoke(CPoolProxy.java:138)
at java.lang.reflect.Method.invoke(Method.java:606)
atat com.sun.proxy.$Proxy45.receiveResponseHeader(Unknown Source)org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExe
atcutor.java:271)org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java
at:123)org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:254
at)org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:195)
atatorg.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:108)
org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:86)
atatorg.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:186)org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.j
atava:82)org.springframework.http.client.HttpComponentsClientHttpRequest.executeIntern
atal(HttpComponentsClientHttpRequest.java:91)org.springframework.http.client.AbstractBufferingClientHttpRequest.executeInt
aternal(AbstractBufferingClientHttpRequest.java:48)org.springframework.http.client.AbstractClientHttpRequest.execute(AbstractCli
atentHttpRequest.java:53)org.springframework.web.client.RestTemplate.doExecute(RestTemplate.java:551)
at... 33 more_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
Re: What ports will be needed to support hm and loggregator
Lev Berman <lev.berman@...>
Sorry, I've missed your notes about the firewalls you configure for each CF
machine - this firewalls is what needs to be configured to accept UDP
traffic to ports 3456 and 3457 from any host. vSphere itself will probably
allow this traffic without any additional configuration.
toggle quoted message
Show quoted text
machine - this firewalls is what needs to be configured to accept UDP
traffic to ports 3456 and 3457 from any host. vSphere itself will probably
allow this traffic without any additional configuration.
On Tue, Jun 2, 2015 at 1:51 PM, Berman Lev <lev.berman(a)altoros.com> wrote:
I have never worked with vSphere, unfortunately. I've googled a bit and
found this table which shows which TCP and UDP ports are open by default on
vSphere VMs -
https://pubs.vmware.com/vsphere-55/index.jsp#com.vmware.vsphere.security.doc/GUID-ECEA77F5-D38E-4339-9B06-FF9B78E94B68.html.
Consult the vSphere documentation to find out how to add UDP 3456 and 3457
ports to this list.
On Tue, Jun 2, 2015 at 1:32 PM, Meng, Xiangyi <xiangyi.meng(a)emc.com>
wrote:I deployed my CF on vshpere server.
*From:* cf-dev-bounces(a)lists.cloudfoundry.org [mailto:
cf-dev-bounces(a)lists.cloudfoundry.org] *On Behalf Of *Lev Berman
*Sent:* 2015年6月2日 18:30
*To:* Discussions about Cloud Foundry projects and the system overall.
*Subject:* Re: [cf-dev] What ports will be needed to support hm and
loggregator
You have posted your Application Security Groups -
http://docs.pivotal.io/pivotalcf/adminguide/app-sec-groups.html. This
groups are created and managed by Cloud Foundry.
But the issue here is with security groups configured in your
infrastructure - AWS, OpenStack, etc. Which one is your CF deployed on?
On Tue, Jun 2, 2015 at 1:23 PM, Meng, Xiangyi <xiangyi.meng(a)emc.com>
wrote:
Hi, Lev
Would you please let me know what exactly I should add to my security
group? Following are the current configuration.
- name: public_networks
rules:
- protocol: all
destination: 0.0.0.0-9.255.255.255
- protocol: all
destination: 11.0.0.0-169.253.255.255
- protocol: all
destination: 169.255.0.0-172.15.255.255
- protocol: all
destination: 172.32.0.0-192.167.255.255
- protocol: all
destination: 192.169.0.0-255.255.255.255
- name: dns
rules:
- protocol: tcp
destination: 0.0.0.0/0
ports: '53'
- protocol: udp
destination: 0.0.0.0/0
ports: '53'
default_running_security_groups:
- public_networks
- dns
default_staging_security_groups:
- public_networks
- dns
Thanks,
Maggie
*From:* cf-dev-bounces(a)lists.cloudfoundry.org [mailto:
cf-dev-bounces(a)lists.cloudfoundry.org] *On Behalf Of *Lev Berman
*Sent:* 2015年6月2日 18:16
*To:* Discussions about Cloud Foundry projects and the system overall.
*Subject:* Re: [cf-dev] What ports will be needed to support hm and
loggregator
Hi,
At least for loggregator to successflly talk to metron agents, you need
to add a rule to a security group for your private subnet allowing the
ingress UDP traffic through ports 3456 and 3457 from all hosts (0.0.0.0/0).
See more about security group rules needed for CF here -
http://docs.cloudfoundry.org/deploying/common/security_groups.html.
On Tue, Jun 2, 2015 at 1:04 PM, Meng, Xiangyi <xiangyi.meng(a)emc.com>
wrote:
Hi,
I am updating my cf env from 172 to 197. But I found some issues after
upgrade is done. I couldn’t get the correct running application instance
number:
CF_TRACE=true cf apps
…
"running_instances": -1,
…
application started ?/3
Another issue is I can’t get log information from loggregator. “cf logs”
showed nothing after I restarted my application.
I think this may be related to our firewall configuration. Because in
another environment where no firewall is configured, hm and loggregator
work perfectly well. We have firewalls for deas, routers and all other
components separately(three firewalls). So would anyone please tell me what
ports we should open for deas, routers or other components?
Thanks,
Maggie
--
Lev Berman
Altoros - Cloud Foundry deployment, training and integration
Github*: *https://github.com/ldmberman
--
Lev Berman
Altoros - Cloud Foundry deployment, training and integration
Github*: *https://github.com/ldmberman
--
Lev Berman
Altoros - Cloud Foundry deployment, training and integration
Github
*: https://github.com/ldmberman <https://github.com/ldmberman> *
--
Lev Berman
Altoros - Cloud Foundry deployment, training and integration
Github
*: https://github.com/ldmberman <https://github.com/ldmberman>*
Lev Berman
Altoros - Cloud Foundry deployment, training and integration
Github
*: https://github.com/ldmberman <https://github.com/ldmberman>*
Re: What ports will be needed to support hm and loggregator
Lev Berman <ldmberman@...>
Sorry, I've missed your notes about the firewalls you configure for each CF
machine - this firewalls is what needs to be configured to accept UDP
traffic to ports 3456 and 3457 from any host. vSphere itself will probably
allow this traffic without any additional configuration.
toggle quoted message
Show quoted text
machine - this firewalls is what needs to be configured to accept UDP
traffic to ports 3456 and 3457 from any host. vSphere itself will probably
allow this traffic without any additional configuration.
On Tue, Jun 2, 2015 at 1:51 PM, Berman Lev <lev.berman(a)altoros.com> wrote:
I have never worked with vSphere, unfortunately. I've googled a bit and
found this table which shows which TCP and UDP ports are open by default on
vSphere VMs -
https://pubs.vmware.com/vsphere-55/index.jsp#com.vmware.vsphere.security.doc/GUID-ECEA77F5-D38E-4339-9B06-FF9B78E94B68.html.
Consult the vSphere documentation to find out how to add UDP 3456 and 3457
ports to this list.
On Tue, Jun 2, 2015 at 1:32 PM, Meng, Xiangyi <xiangyi.meng(a)emc.com>
wrote:I deployed my CF on vshpere server.
*From:* cf-dev-bounces(a)lists.cloudfoundry.org [mailto:
cf-dev-bounces(a)lists.cloudfoundry.org] *On Behalf Of *Lev Berman
*Sent:* 2015年6月2日 18:30
*To:* Discussions about Cloud Foundry projects and the system overall.
*Subject:* Re: [cf-dev] What ports will be needed to support hm and
loggregator
You have posted your Application Security Groups -
http://docs.pivotal.io/pivotalcf/adminguide/app-sec-groups.html. This
groups are created and managed by Cloud Foundry.
But the issue here is with security groups configured in your
infrastructure - AWS, OpenStack, etc. Which one is your CF deployed on?
On Tue, Jun 2, 2015 at 1:23 PM, Meng, Xiangyi <xiangyi.meng(a)emc.com>
wrote:
Hi, Lev
Would you please let me know what exactly I should add to my security
group? Following are the current configuration.
- name: public_networks
rules:
- protocol: all
destination: 0.0.0.0-9.255.255.255
- protocol: all
destination: 11.0.0.0-169.253.255.255
- protocol: all
destination: 169.255.0.0-172.15.255.255
- protocol: all
destination: 172.32.0.0-192.167.255.255
- protocol: all
destination: 192.169.0.0-255.255.255.255
- name: dns
rules:
- protocol: tcp
destination: 0.0.0.0/0
ports: '53'
- protocol: udp
destination: 0.0.0.0/0
ports: '53'
default_running_security_groups:
- public_networks
- dns
default_staging_security_groups:
- public_networks
- dns
Thanks,
Maggie
*From:* cf-dev-bounces(a)lists.cloudfoundry.org [mailto:
cf-dev-bounces(a)lists.cloudfoundry.org] *On Behalf Of *Lev Berman
*Sent:* 2015年6月2日 18:16
*To:* Discussions about Cloud Foundry projects and the system overall.
*Subject:* Re: [cf-dev] What ports will be needed to support hm and
loggregator
Hi,
At least for loggregator to successflly talk to metron agents, you need
to add a rule to a security group for your private subnet allowing the
ingress UDP traffic through ports 3456 and 3457 from all hosts (0.0.0.0/0).
See more about security group rules needed for CF here -
http://docs.cloudfoundry.org/deploying/common/security_groups.html.
On Tue, Jun 2, 2015 at 1:04 PM, Meng, Xiangyi <xiangyi.meng(a)emc.com>
wrote:
Hi,
I am updating my cf env from 172 to 197. But I found some issues after
upgrade is done. I couldn’t get the correct running application instance
number:
CF_TRACE=true cf apps
…
"running_instances": -1,
…
application started ?/3
Another issue is I can’t get log information from loggregator. “cf logs”
showed nothing after I restarted my application.
I think this may be related to our firewall configuration. Because in
another environment where no firewall is configured, hm and loggregator
work perfectly well. We have firewalls for deas, routers and all other
components separately(three firewalls). So would anyone please tell me what
ports we should open for deas, routers or other components?
Thanks,
Maggie
--
Lev Berman
Altoros - Cloud Foundry deployment, training and integration
Github*: *https://github.com/ldmberman
--
Lev Berman
Altoros - Cloud Foundry deployment, training and integration
Github*: *https://github.com/ldmberman
--
Lev Berman
Altoros - Cloud Foundry deployment, training and integration
Github
*: https://github.com/ldmberman <https://github.com/ldmberman> *
Re: What ports will be needed to support hm and loggregator
Lev Berman <lev.berman@...>
I have never worked with vSphere, unfortunately. I've googled a bit and
found this table which shows which TCP and UDP ports are open by default on
vSphere VMs -
https://pubs.vmware.com/vsphere-55/index.jsp#com.vmware.vsphere.security.doc/GUID-ECEA77F5-D38E-4339-9B06-FF9B78E94B68.html.
Consult the vSphere documentation to find out how to add UDP 3456 and 3457
ports to this list.
toggle quoted message
Show quoted text
found this table which shows which TCP and UDP ports are open by default on
vSphere VMs -
https://pubs.vmware.com/vsphere-55/index.jsp#com.vmware.vsphere.security.doc/GUID-ECEA77F5-D38E-4339-9B06-FF9B78E94B68.html.
Consult the vSphere documentation to find out how to add UDP 3456 and 3457
ports to this list.
On Tue, Jun 2, 2015 at 1:32 PM, Meng, Xiangyi <xiangyi.meng(a)emc.com> wrote:
I deployed my CF on vshpere server.
*From:* cf-dev-bounces(a)lists.cloudfoundry.org [mailto:
cf-dev-bounces(a)lists.cloudfoundry.org] *On Behalf Of *Lev Berman
*Sent:* 2015年6月2日 18:30
*To:* Discussions about Cloud Foundry projects and the system overall.
*Subject:* Re: [cf-dev] What ports will be needed to support hm and
loggregator
You have posted your Application Security Groups -
http://docs.pivotal.io/pivotalcf/adminguide/app-sec-groups.html. This
groups are created and managed by Cloud Foundry.
But the issue here is with security groups configured in your
infrastructure - AWS, OpenStack, etc. Which one is your CF deployed on?
On Tue, Jun 2, 2015 at 1:23 PM, Meng, Xiangyi <xiangyi.meng(a)emc.com>
wrote:
Hi, Lev
Would you please let me know what exactly I should add to my security
group? Following are the current configuration.
- name: public_networks
rules:
- protocol: all
destination: 0.0.0.0-9.255.255.255
- protocol: all
destination: 11.0.0.0-169.253.255.255
- protocol: all
destination: 169.255.0.0-172.15.255.255
- protocol: all
destination: 172.32.0.0-192.167.255.255
- protocol: all
destination: 192.169.0.0-255.255.255.255
- name: dns
rules:
- protocol: tcp
destination: 0.0.0.0/0
ports: '53'
- protocol: udp
destination: 0.0.0.0/0
ports: '53'
default_running_security_groups:
- public_networks
- dns
default_staging_security_groups:
- public_networks
- dns
Thanks,
Maggie
*From:* cf-dev-bounces(a)lists.cloudfoundry.org [mailto:
cf-dev-bounces(a)lists.cloudfoundry.org] *On Behalf Of *Lev Berman
*Sent:* 2015年6月2日 18:16
*To:* Discussions about Cloud Foundry projects and the system overall.
*Subject:* Re: [cf-dev] What ports will be needed to support hm and
loggregator
Hi,
At least for loggregator to successflly talk to metron agents, you need to
add a rule to a security group for your private subnet allowing the ingress
UDP traffic through ports 3456 and 3457 from all hosts (0.0.0.0/0). See
more about security group rules needed for CF here -
http://docs.cloudfoundry.org/deploying/common/security_groups.html.
On Tue, Jun 2, 2015 at 1:04 PM, Meng, Xiangyi <xiangyi.meng(a)emc.com>
wrote:
Hi,
I am updating my cf env from 172 to 197. But I found some issues after
upgrade is done. I couldn’t get the correct running application instance
number:
CF_TRACE=true cf apps
…
"running_instances": -1,
…
application started ?/3
Another issue is I can’t get log information from loggregator. “cf logs”
showed nothing after I restarted my application.
I think this may be related to our firewall configuration. Because in
another environment where no firewall is configured, hm and loggregator
work perfectly well. We have firewalls for deas, routers and all other
components separately(three firewalls). So would anyone please tell me what
ports we should open for deas, routers or other components?
Thanks,
Maggie
--
Lev Berman
Altoros - Cloud Foundry deployment, training and integration
Github*: *https://github.com/ldmberman
--
Lev Berman
Altoros - Cloud Foundry deployment, training and integration
Github*: *https://github.com/ldmberman
--
Lev Berman
Altoros - Cloud Foundry deployment, training and integration
Github
*: https://github.com/ldmberman <https://github.com/ldmberman>*
Lev Berman
Altoros - Cloud Foundry deployment, training and integration
Github
*: https://github.com/ldmberman <https://github.com/ldmberman>*
Re: What ports will be needed to support hm and loggregator
MaggieMeng
I deployed my CF on vshpere server.
From: cf-dev-bounces(a)lists.cloudfoundry.org [mailto:cf-dev-bounces(a)lists.cloudfoundry.org] On Behalf Of Lev Berman
Sent: 2015年6月2日 18:30
To: Discussions about Cloud Foundry projects and the system overall.
Subject: Re: [cf-dev] What ports will be needed to support hm and loggregator
You have posted your Application Security Groups - http://docs.pivotal.io/pivotalcf/adminguide/app-sec-groups.html. This groups are created and managed by Cloud Foundry.
But the issue here is with security groups configured in your infrastructure - AWS, OpenStack, etc. Which one is your CF deployed on?
On Tue, Jun 2, 2015 at 1:23 PM, Meng, Xiangyi <xiangyi.meng(a)emc.com<mailto:xiangyi.meng(a)emc.com>> wrote:
Hi, Lev
Would you please let me know what exactly I should add to my security group? Following are the current configuration.
- name: public_networks
rules:
- protocol: all
destination: 0.0.0.0-9.255.255.255
- protocol: all
destination: 11.0.0.0-169.253.255.255
- protocol: all
destination: 169.255.0.0-172.15.255.255
- protocol: all
destination: 172.32.0.0-192.167.255.255
- protocol: all
destination: 192.169.0.0-255.255.255.255
- name: dns
rules:
- protocol: tcp
destination: 0.0.0.0/0<http://0.0.0.0/0>
ports: '53'
- protocol: udp
destination: 0.0.0.0/0<http://0.0.0.0/0>
ports: '53'
default_running_security_groups:
- public_networks
- dns
default_staging_security_groups:
- public_networks
- dns
Thanks,
Maggie
From: cf-dev-bounces(a)lists.cloudfoundry.org<mailto:cf-dev-bounces(a)lists.cloudfoundry.org> [mailto:cf-dev-bounces(a)lists.cloudfoundry.org<mailto:cf-dev-bounces(a)lists.cloudfoundry.org>] On Behalf Of Lev Berman
Sent: 2015年6月2日 18:16
To: Discussions about Cloud Foundry projects and the system overall.
Subject: Re: [cf-dev] What ports will be needed to support hm and loggregator
Hi,
At least for loggregator to successflly talk to metron agents, you need to add a rule to a security group for your private subnet allowing the ingress UDP traffic through ports 3456 and 3457 from all hosts (0.0.0.0/0<http://0.0.0.0/0>). See more about security group rules needed for CF here - http://docs.cloudfoundry.org/deploying/common/security_groups.html.
On Tue, Jun 2, 2015 at 1:04 PM, Meng, Xiangyi <xiangyi.meng(a)emc.com<mailto:xiangyi.meng(a)emc.com>> wrote:
Hi,
I am updating my cf env from 172 to 197. But I found some issues after upgrade is done. I couldn’t get the correct running application instance number:
CF_TRACE=true cf apps
…
"running_instances": -1,
…
application started ?/3
Another issue is I can’t get log information from loggregator. “cf logs” showed nothing after I restarted my application.
I think this may be related to our firewall configuration. Because in another environment where no firewall is configured, hm and loggregator work perfectly well. We have firewalls for deas, routers and all other components separately(three firewalls). So would anyone please tell me what ports we should open for deas, routers or other components?
Thanks,
Maggie
--
Lev Berman
Altoros - Cloud Foundry deployment, training and integration
Github: https://github.com/ldmberman
--
Lev Berman
Altoros - Cloud Foundry deployment, training and integration
Github: https://github.com/ldmberman
From: cf-dev-bounces(a)lists.cloudfoundry.org [mailto:cf-dev-bounces(a)lists.cloudfoundry.org] On Behalf Of Lev Berman
Sent: 2015年6月2日 18:30
To: Discussions about Cloud Foundry projects and the system overall.
Subject: Re: [cf-dev] What ports will be needed to support hm and loggregator
You have posted your Application Security Groups - http://docs.pivotal.io/pivotalcf/adminguide/app-sec-groups.html. This groups are created and managed by Cloud Foundry.
But the issue here is with security groups configured in your infrastructure - AWS, OpenStack, etc. Which one is your CF deployed on?
On Tue, Jun 2, 2015 at 1:23 PM, Meng, Xiangyi <xiangyi.meng(a)emc.com<mailto:xiangyi.meng(a)emc.com>> wrote:
Hi, Lev
Would you please let me know what exactly I should add to my security group? Following are the current configuration.
- name: public_networks
rules:
- protocol: all
destination: 0.0.0.0-9.255.255.255
- protocol: all
destination: 11.0.0.0-169.253.255.255
- protocol: all
destination: 169.255.0.0-172.15.255.255
- protocol: all
destination: 172.32.0.0-192.167.255.255
- protocol: all
destination: 192.169.0.0-255.255.255.255
- name: dns
rules:
- protocol: tcp
destination: 0.0.0.0/0<http://0.0.0.0/0>
ports: '53'
- protocol: udp
destination: 0.0.0.0/0<http://0.0.0.0/0>
ports: '53'
default_running_security_groups:
- public_networks
- dns
default_staging_security_groups:
- public_networks
- dns
Thanks,
Maggie
From: cf-dev-bounces(a)lists.cloudfoundry.org<mailto:cf-dev-bounces(a)lists.cloudfoundry.org> [mailto:cf-dev-bounces(a)lists.cloudfoundry.org<mailto:cf-dev-bounces(a)lists.cloudfoundry.org>] On Behalf Of Lev Berman
Sent: 2015年6月2日 18:16
To: Discussions about Cloud Foundry projects and the system overall.
Subject: Re: [cf-dev] What ports will be needed to support hm and loggregator
Hi,
At least for loggregator to successflly talk to metron agents, you need to add a rule to a security group for your private subnet allowing the ingress UDP traffic through ports 3456 and 3457 from all hosts (0.0.0.0/0<http://0.0.0.0/0>). See more about security group rules needed for CF here - http://docs.cloudfoundry.org/deploying/common/security_groups.html.
On Tue, Jun 2, 2015 at 1:04 PM, Meng, Xiangyi <xiangyi.meng(a)emc.com<mailto:xiangyi.meng(a)emc.com>> wrote:
Hi,
I am updating my cf env from 172 to 197. But I found some issues after upgrade is done. I couldn’t get the correct running application instance number:
CF_TRACE=true cf apps
…
"running_instances": -1,
…
application started ?/3
Another issue is I can’t get log information from loggregator. “cf logs” showed nothing after I restarted my application.
I think this may be related to our firewall configuration. Because in another environment where no firewall is configured, hm and loggregator work perfectly well. We have firewalls for deas, routers and all other components separately(three firewalls). So would anyone please tell me what ports we should open for deas, routers or other components?
Thanks,
Maggie
--
Lev Berman
Altoros - Cloud Foundry deployment, training and integration
Github: https://github.com/ldmberman
--
Lev Berman
Altoros - Cloud Foundry deployment, training and integration
Github: https://github.com/ldmberman
Re: What ports will be needed to support hm and loggregator
Lev Berman <lev.berman@...>
You have posted your Application Security Groups -
http://docs.pivotal.io/pivotalcf/adminguide/app-sec-groups.html. This
groups are created and managed by Cloud Foundry.
But the issue here is with security groups configured in your
infrastructure - AWS, OpenStack, etc. Which one is your CF deployed on?
toggle quoted message
Show quoted text
http://docs.pivotal.io/pivotalcf/adminguide/app-sec-groups.html. This
groups are created and managed by Cloud Foundry.
But the issue here is with security groups configured in your
infrastructure - AWS, OpenStack, etc. Which one is your CF deployed on?
On Tue, Jun 2, 2015 at 1:23 PM, Meng, Xiangyi <xiangyi.meng(a)emc.com> wrote:
Hi, Lev
Would you please let me know what exactly I should add to my security
group? Following are the current configuration.
- name: public_networks
rules:
- protocol: all
destination: 0.0.0.0-9.255.255.255
- protocol: all
destination: 11.0.0.0-169.253.255.255
- protocol: all
destination: 169.255.0.0-172.15.255.255
- protocol: all
destination: 172.32.0.0-192.167.255.255
- protocol: all
destination: 192.169.0.0-255.255.255.255
- name: dns
rules:
- protocol: tcp
destination: 0.0.0.0/0
ports: '53'
- protocol: udp
destination: 0.0.0.0/0
ports: '53'
default_running_security_groups:
- public_networks
- dns
default_staging_security_groups:
- public_networks
- dns
Thanks,
Maggie
*From:* cf-dev-bounces(a)lists.cloudfoundry.org [mailto:
cf-dev-bounces(a)lists.cloudfoundry.org] *On Behalf Of *Lev Berman
*Sent:* 2015年6月2日 18:16
*To:* Discussions about Cloud Foundry projects and the system overall.
*Subject:* Re: [cf-dev] What ports will be needed to support hm and
loggregator
Hi,
At least for loggregator to successflly talk to metron agents, you need to
add a rule to a security group for your private subnet allowing the ingress
UDP traffic through ports 3456 and 3457 from all hosts (0.0.0.0/0). See
more about security group rules needed for CF here -
http://docs.cloudfoundry.org/deploying/common/security_groups.html.
On Tue, Jun 2, 2015 at 1:04 PM, Meng, Xiangyi <xiangyi.meng(a)emc.com>
wrote:
Hi,
I am updating my cf env from 172 to 197. But I found some issues after
upgrade is done. I couldn’t get the correct running application instance
number:
CF_TRACE=true cf apps
…
"running_instances": -1,
…
application started ?/3
Another issue is I can’t get log information from loggregator. “cf logs”
showed nothing after I restarted my application.
I think this may be related to our firewall configuration. Because in
another environment where no firewall is configured, hm and loggregator
work perfectly well. We have firewalls for deas, routers and all other
components separately(three firewalls). So would anyone please tell me what
ports we should open for deas, routers or other components?
Thanks,
Maggie
--
Lev Berman
Altoros - Cloud Foundry deployment, training and integration
Github*: *https://github.com/ldmberman
--
Lev Berman
Altoros - Cloud Foundry deployment, training and integration
Github
*: https://github.com/ldmberman <https://github.com/ldmberman>*
Lev Berman
Altoros - Cloud Foundry deployment, training and integration
Github
*: https://github.com/ldmberman <https://github.com/ldmberman>*
Re: What ports will be needed to support hm and loggregator
MaggieMeng
Hi, Lev
Would you please let me know what exactly I should add to my security group? Following are the current configuration.
- name: public_networks
rules:
- protocol: all
destination: 0.0.0.0-9.255.255.255
- protocol: all
destination: 11.0.0.0-169.253.255.255
- protocol: all
destination: 169.255.0.0-172.15.255.255
- protocol: all
destination: 172.32.0.0-192.167.255.255
- protocol: all
destination: 192.169.0.0-255.255.255.255
- name: dns
rules:
- protocol: tcp
destination: 0.0.0.0/0
ports: '53'
- protocol: udp
destination: 0.0.0.0/0
ports: '53'
default_running_security_groups:
- public_networks
- dns
default_staging_security_groups:
- public_networks
- dns
Thanks,
Maggie
From: cf-dev-bounces(a)lists.cloudfoundry.org [mailto:cf-dev-bounces(a)lists.cloudfoundry.org] On Behalf Of Lev Berman
Sent: 2015年6月2日 18:16
To: Discussions about Cloud Foundry projects and the system overall.
Subject: Re: [cf-dev] What ports will be needed to support hm and loggregator
Hi,
At least for loggregator to successflly talk to metron agents, you need to add a rule to a security group for your private subnet allowing the ingress UDP traffic through ports 3456 and 3457 from all hosts (0.0.0.0/0<http://0.0.0.0/0>). See more about security group rules needed for CF here - http://docs.cloudfoundry.org/deploying/common/security_groups.html.
On Tue, Jun 2, 2015 at 1:04 PM, Meng, Xiangyi <xiangyi.meng(a)emc.com<mailto:xiangyi.meng(a)emc.com>> wrote:
Hi,
I am updating my cf env from 172 to 197. But I found some issues after upgrade is done. I couldn’t get the correct running application instance number:
CF_TRACE=true cf apps
…
"running_instances": -1,
…
application started ?/3
Another issue is I can’t get log information from loggregator. “cf logs” showed nothing after I restarted my application.
I think this may be related to our firewall configuration. Because in another environment where no firewall is configured, hm and loggregator work perfectly well. We have firewalls for deas, routers and all other components separately(three firewalls). So would anyone please tell me what ports we should open for deas, routers or other components?
Thanks,
Maggie
--
Lev Berman
Altoros - Cloud Foundry deployment, training and integration
Github: https://github.com/ldmberman
Would you please let me know what exactly I should add to my security group? Following are the current configuration.
- name: public_networks
rules:
- protocol: all
destination: 0.0.0.0-9.255.255.255
- protocol: all
destination: 11.0.0.0-169.253.255.255
- protocol: all
destination: 169.255.0.0-172.15.255.255
- protocol: all
destination: 172.32.0.0-192.167.255.255
- protocol: all
destination: 192.169.0.0-255.255.255.255
- name: dns
rules:
- protocol: tcp
destination: 0.0.0.0/0
ports: '53'
- protocol: udp
destination: 0.0.0.0/0
ports: '53'
default_running_security_groups:
- public_networks
- dns
default_staging_security_groups:
- public_networks
- dns
Thanks,
Maggie
From: cf-dev-bounces(a)lists.cloudfoundry.org [mailto:cf-dev-bounces(a)lists.cloudfoundry.org] On Behalf Of Lev Berman
Sent: 2015年6月2日 18:16
To: Discussions about Cloud Foundry projects and the system overall.
Subject: Re: [cf-dev] What ports will be needed to support hm and loggregator
Hi,
At least for loggregator to successflly talk to metron agents, you need to add a rule to a security group for your private subnet allowing the ingress UDP traffic through ports 3456 and 3457 from all hosts (0.0.0.0/0<http://0.0.0.0/0>). See more about security group rules needed for CF here - http://docs.cloudfoundry.org/deploying/common/security_groups.html.
On Tue, Jun 2, 2015 at 1:04 PM, Meng, Xiangyi <xiangyi.meng(a)emc.com<mailto:xiangyi.meng(a)emc.com>> wrote:
Hi,
I am updating my cf env from 172 to 197. But I found some issues after upgrade is done. I couldn’t get the correct running application instance number:
CF_TRACE=true cf apps
…
"running_instances": -1,
…
application started ?/3
Another issue is I can’t get log information from loggregator. “cf logs” showed nothing after I restarted my application.
I think this may be related to our firewall configuration. Because in another environment where no firewall is configured, hm and loggregator work perfectly well. We have firewalls for deas, routers and all other components separately(three firewalls). So would anyone please tell me what ports we should open for deas, routers or other components?
Thanks,
Maggie
--
Lev Berman
Altoros - Cloud Foundry deployment, training and integration
Github: https://github.com/ldmberman
Re: What ports will be needed to support hm and loggregator
Lev Berman <lev.berman@...>
Hi,
At least for loggregator to successflly talk to metron agents, you need to
add a rule to a security group for your private subnet allowing the ingress
UDP traffic through ports 3456 and 3457 from all hosts (0.0.0.0/0). See
more about security group rules needed for CF here -
http://docs.cloudfoundry.org/deploying/common/security_groups.html.
toggle quoted message
Show quoted text
At least for loggregator to successflly talk to metron agents, you need to
add a rule to a security group for your private subnet allowing the ingress
UDP traffic through ports 3456 and 3457 from all hosts (0.0.0.0/0). See
more about security group rules needed for CF here -
http://docs.cloudfoundry.org/deploying/common/security_groups.html.
On Tue, Jun 2, 2015 at 1:04 PM, Meng, Xiangyi <xiangyi.meng(a)emc.com> wrote:
Hi,
I am updating my cf env from 172 to 197. But I found some issues after
upgrade is done. I couldn’t get the correct running application instance
number:
CF_TRACE=true cf apps
…
"running_instances": -1,
…
application started ?/3
Another issue is I can’t get log information from loggregator. “cf logs”
showed nothing after I restarted my application.
I think this may be related to our firewall configuration. Because in
another environment where no firewall is configured, hm and loggregator
work perfectly well. We have firewalls for deas, routers and all other
components separately(three firewalls). So would anyone please tell me what
ports we should open for deas, routers or other components?
Thanks,
Maggie
--
Lev Berman
Altoros - Cloud Foundry deployment, training and integration
Github
*: https://github.com/ldmberman <https://github.com/ldmberman>*
Lev Berman
Altoros - Cloud Foundry deployment, training and integration
Github
*: https://github.com/ldmberman <https://github.com/ldmberman>*
What ports will be needed to support hm and loggregator
MaggieMeng
Hi,
I am updating my cf env from 172 to 197. But I found some issues after upgrade is done. I couldn't get the correct running application instance number:
CF_TRACE=true cf apps
...
"running_instances": -1,
...
application started ?/3
Another issue is I can't get log information from loggregator. "cf logs" showed nothing after I restarted my application.
I think this may be related to our firewall configuration. Because in another environment where no firewall is configured, hm and loggregator work perfectly well. We have firewalls for deas, routers and all other components separately(three firewalls). So would anyone please tell me what ports we should open for deas, routers or other components?
Thanks,
Maggie
I am updating my cf env from 172 to 197. But I found some issues after upgrade is done. I couldn't get the correct running application instance number:
CF_TRACE=true cf apps
...
"running_instances": -1,
...
application started ?/3
Another issue is I can't get log information from loggregator. "cf logs" showed nothing after I restarted my application.
I think this may be related to our firewall configuration. Because in another environment where no firewall is configured, hm and loggregator work perfectly well. We have firewalls for deas, routers and all other components separately(three firewalls). So would anyone please tell me what ports we should open for deas, routers or other components?
Thanks,
Maggie
Re: sporadic connection resets between login and uaa
Sievers, Jan <jan.sievers@...>
Am I right this problem is obsolete since the login-uaa merge in CF 208 [1]?
Regards,
Jan
[1] http://lists.cloudfoundry.org/pipermail/cf-dev/2015-May/000087.html
toggle quoted message
Show quoted text
Regards,
Jan
[1] http://lists.cloudfoundry.org/pipermail/cf-dev/2015-May/000087.html
-----Original Message-----
From: Sievers, Jan
Sent: Montag, 1. Juni 2015 11:31
To: 'cf-dev(a)lists.cloudfoundry.org'
Subject: sporadic connection resets between login and uaa
Hi,
while running the CF 207 smoke and acceptance tests repeatedly, we noticed
sporadic connection resets during 'cf login'
(see log snippet from login log below).
The connection reset is happening on the login machine when it's doing an
HTTP POST to
http://uaa.cf.<DOMAIN>/authenticate
(via load balancer, and getting a connection reset from the load balancer).
This is happening ~ 1 out of 5 times if we run the smoke tests every 5
minutes.
We found that adding
-Dhttp.keepAlive=false
to JAVA_OPTS in /var/vcap/jobs/login/bin/login_ctl
works around the problem. Otherwise, by default there is a pool of 5
connections being kept alive and reused.
We use an F5 BigIP load balancer with 300 seconds socket idle timeout
configured.
Could this be a bug with stale connections being reused by the HTTP client on
the login machine?
Best Regards,
Jan
--- log snippet from login machine ---
[2015-05-08 08:07:52.787] login - 9054 [http-bio-8080-exec-2] .... DEBUG ---
DispatcherServlet: DispatcherServlet with name 'spring' processing POST
request for [/error500]
[2015-05-08 08:07:52.787] login - 9054 [http-bio-8080-exec-2] .... DEBUG ---
RequestMappingHandlerMapping: Looking up handler method for path /error500
[2015-05-08 08:07:52.787] login - 9054 [http-bio-8080-exec-2] .... DEBUG ---
RequestMappingHandlerMapping: Returning handler method [public
java.lang.String
org.cloudfoundry.identity.uaa.login.HomeController.error500(org.springframewo
rk.ui.Model,javax.servlet.http.HttpServletRequest)]
[2015-05-08 08:07:52.787] login - 9054 [http-bio-8080-exec-2] .... ERROR ---
HomeController: Internal error
org.springframework.web.client.ResourceAccessException: I/O error on POST
request for "http://uaa.cf.<DOMAIN>/authenticate":Connection reset; nested
exception is java.net.SocketException: Connection reset
at
org.springframework.web.client.RestTemplate.doExecute(RestTemplate.java:567)
at
org.springframework.security.oauth2.client.OAuth2RestTemplate.doExecute(OAuth
2RestTemplate.java:128)
at
org.springframework.web.client.RestTemplate.execute(RestTemplate.java:512)
at
org.springframework.web.client.RestTemplate.exchange(RestTemplate.java:454)
at
org.cloudfoundry.identity.uaa.login.RemoteUaaAuthenticationManager.authentica
te(RemoteUaaAuthenticationManager.java:137)
at
org.cloudfoundry.identity.uaa.authentication.AuthzAuthenticationFilter.doFilt
er(AuthzAuthenticationFilter.java:138)
at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter
(FilterChainProxy.java:342)
at
org.springframework.security.web.context.request.async.WebAsyncManagerIntegra
tionFilter.doFilterInternal(WebAsyncManagerIntegrationFilter.java:50)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFi
lter.java:107)
at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter
(FilterChainProxy.java:342)
at
org.springframework.security.web.context.SecurityContextPersistenceFilter.doF
ilter(SecurityContextPersistenceFilter.java:87)
at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter
(FilterChainProxy.java:342)
at
org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChai
nProxy.java:192)
at
org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.j
ava:160)
at
org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(Delegatin
gFilterProxy.java:344)
at
org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilte
rProxy.java:261)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationF
ilterChain.java:241)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCha
in.java:208)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.jav
a:220)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.jav
a:122)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.
java:501)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:950)
at
org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:683)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:
116)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:
116) [37/1995]
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Proces
sor.java:1070)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(Abstract
Protocol.java:611)
at
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:3
14)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:114
5)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:61
5)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.jav
a:61)
at java.lang.Thread.run(Thread.java:744)
Caused by: java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:196)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at
org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferI
mpl.java:136)
at
org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferI
mpl.java:152)
at
org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImp
l.java:270)
at
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResp
onseParser.java:140)
at
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResp
onseParser.java:57)
at
org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.jav
a:260)
at
org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(Defau
ltBHttpClientConnection.java:161)
at sun.reflect.GeneratedMethodAccessor121.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.
java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.apache.http.impl.conn.CPoolProxy.invoke(CPoolProxy.java:138)
at com.sun.proxy.$Proxy45.receiveResponseHeader(Unknown Source)
at
org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExe
cutor.java:271)
at
org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java
:123)
at
org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:254
)
at
org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:195)
at
org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:86)
at
org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:108)
at
org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.j
ava:186)
at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.j
ava:82)
at
org.springframework.http.client.HttpComponentsClientHttpRequest.executeIntern
al(HttpComponentsClientHttpRequest.java:91)
at
org.springframework.http.client.AbstractBufferingClientHttpRequest.executeInt
ernal(AbstractBufferingClientHttpRequest.java:48)
at
org.springframework.http.client.AbstractClientHttpRequest.execute(AbstractCli
entHttpRequest.java:53)
at
org.springframework.web.client.RestTemplate.doExecute(RestTemplate.java:551)
... 33 more
Memory Leak in doppler and metron_agent?
libnux <libnux.me@...>
Hi,
I'm running a v205 CF deployment with ~350 application instances.
I just found that the doppler process on the doppler node and the
metron_agent process on the gorouter node used too much memory(90.9% and
13.3 %), as below.
Acutually, the memory usage of metron_agent was also >90%, and I
restarted it yesterday, and just after 14 hours, the usage went up to
13.3%.
There are two doppler nodes and three gorouter nodes.
Process 'doppler'
============
status Running
monitoring status Monitored
pid 21648
parent pid 1
uptime 2d 11h 10m
children 0
memory kilobytes 14948028
memory kilobytes total 14948028
memory percent 90.9%
memory percent total 90.9%
cpu percent 12.5%
cpu percent total 12.5%
Process 'metron_agent'
==================
status Running
monitoring status Monitored
pid 28995
parent pid 1
uptime 14h 10m
children 2
memory kilobytes 2195608
memory kilobytes total 2195608
memory percent 13.3%
memory percent total 13.3%
cpu percent 6.8%
cpu percent total 6.8%
I'm running a v205 CF deployment with ~350 application instances.
I just found that the doppler process on the doppler node and the
metron_agent process on the gorouter node used too much memory(90.9% and
13.3 %), as below.
Acutually, the memory usage of metron_agent was also >90%, and I
restarted it yesterday, and just after 14 hours, the usage went up to
13.3%.
There are two doppler nodes and three gorouter nodes.
Process 'doppler'
============
status Running
monitoring status Monitored
pid 21648
parent pid 1
uptime 2d 11h 10m
children 0
memory kilobytes 14948028
memory kilobytes total 14948028
memory percent 90.9%
memory percent total 90.9%
cpu percent 12.5%
cpu percent total 12.5%
Process 'metron_agent'
==================
status Running
monitoring status Monitored
pid 28995
parent pid 1
uptime 14h 10m
children 2
memory kilobytes 2195608
memory kilobytes total 2195608
memory percent 13.3%
memory percent total 13.3%
cpu percent 6.8%
cpu percent total 6.8%
Are you having problems upgrading cf-release postgres?
CF Runtime
Good afternoon,
Last week, we merged a branch into cf-release that upgraded the postgres
instance if you are running one.
We saw this fail on two of our environments and reverted these changes on
Friday. We have since committed a fix and pushed that, too.
If you are using the develop branch of cf-release and your database did not
successfully upgrade, you should get the latest version, and do the
following on your postgres VM:
monit stop postgres
rm -rf /var/vcap/store/postgres-9.4.2
rm /var/vcap/store/FLAG_POSTGRES_UPGRADE
At that point you should be able to deploy the new version and it will
upgrade cleanly. Please let us know if you have any problems upgrading.
Dan Wendorf and Utako,
CF Runtime Team
Last week, we merged a branch into cf-release that upgraded the postgres
instance if you are running one.
We saw this fail on two of our environments and reverted these changes on
Friday. We have since committed a fix and pushed that, too.
If you are using the develop branch of cf-release and your database did not
successfully upgrade, you should get the latest version, and do the
following on your postgres VM:
monit stop postgres
rm -rf /var/vcap/store/postgres-9.4.2
rm /var/vcap/store/FLAG_POSTGRES_UPGRADE
At that point you should be able to deploy the new version and it will
upgrade cleanly. Please let us know if you have any problems upgrading.
Dan Wendorf and Utako,
CF Runtime Team
sporadic connection resets between login and uaa
Sievers, Jan <jan.sievers@...>
Hi,
while running the CF 207 smoke and acceptance tests repeatedly, we noticed sporadic connection resets during 'cf login'
(see log snippet from login log below).
The connection reset is happening on the login machine when it's doing an HTTP POST to
http://uaa.cf.<DOMAIN>/authenticate
(via load balancer, and getting a connection reset from the load balancer).
This is happening ~ 1 out of 5 times if we run the smoke tests every 5 minutes.
We found that adding
-Dhttp.keepAlive=false
to JAVA_OPTS in /var/vcap/jobs/login/bin/login_ctl
works around the problem. Otherwise, by default there is a pool of 5 connections being kept alive and reused.
We use an F5 BigIP load balancer with 300 seconds socket idle timeout configured.
Could this be a bug with stale connections being reused by the HTTP client on the login machine?
Best Regards,
Jan
--- log snippet from login machine ---
[2015-05-08 08:07:52.787] login - 9054 [http-bio-8080-exec-2] .... DEBUG --- DispatcherServlet: DispatcherServlet with name 'spring' processing POST request for [/error500]
[2015-05-08 08:07:52.787] login - 9054 [http-bio-8080-exec-2] .... DEBUG --- RequestMappingHandlerMapping: Looking up handler method for path /error500
[2015-05-08 08:07:52.787] login - 9054 [http-bio-8080-exec-2] .... DEBUG --- RequestMappingHandlerMapping: Returning handler method [public java.lang.String org.cloudfoundry.identity.uaa.login.HomeController.error500(org.springframework.ui.Model,javax.servlet.http.HttpServletRequest)]
[2015-05-08 08:07:52.787] login - 9054 [http-bio-8080-exec-2] .... ERROR --- HomeController: Internal error
org.springframework.web.client.ResourceAccessException: I/O error on POST request for "http://uaa.cf.<DOMAIN>/authenticate":Connection reset; nested exception is java.net.SocketException: Connection reset
at org.springframework.web.client.RestTemplate.doExecute(RestTemplate.java:567)
at org.springframework.security.oauth2.client.OAuth2RestTemplate.doExecute(OAuth2RestTemplate.java:128)
at org.springframework.web.client.RestTemplate.execute(RestTemplate.java:512)
at org.springframework.web.client.RestTemplate.exchange(RestTemplate.java:454)
at org.cloudfoundry.identity.uaa.login.RemoteUaaAuthenticationManager.authenticate(RemoteUaaAuthenticationManager.java:137)
at org.cloudfoundry.identity.uaa.authentication.AuthzAuthenticationFilter.doFilter(AuthzAuthenticationFilter.java:138)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
at org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter.doFilterInternal(WebAsyncManagerIntegrationFilter.java:50)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
at org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192)
at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160)
at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:344)
at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:261)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:501)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:950)
at org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:683)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116) [37/1995]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1070)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:611)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:314)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:744)
Caused by: java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:196)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:136)
at org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:152)
at org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:270)
at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:140)
at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:260)
at org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:161)
at sun.reflect.GeneratedMethodAccessor121.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.apache.http.impl.conn.CPoolProxy.invoke(CPoolProxy.java:138)
at com.sun.proxy.$Proxy45.receiveResponseHeader(Unknown Source)
at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:271)
at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:123)
at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:254)
at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:195)
at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:86)
at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:108)
at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:186)
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at org.springframework.http.client.HttpComponentsClientHttpRequest.executeInternal(HttpComponentsClientHttpRequest.java:91)
at org.springframework.http.client.AbstractBufferingClientHttpRequest.executeInternal(AbstractBufferingClientHttpRequest.java:48)
at org.springframework.http.client.AbstractClientHttpRequest.execute(AbstractClientHttpRequest.java:53)
at org.springframework.web.client.RestTemplate.doExecute(RestTemplate.java:551)
... 33 more
while running the CF 207 smoke and acceptance tests repeatedly, we noticed sporadic connection resets during 'cf login'
(see log snippet from login log below).
The connection reset is happening on the login machine when it's doing an HTTP POST to
http://uaa.cf.<DOMAIN>/authenticate
(via load balancer, and getting a connection reset from the load balancer).
This is happening ~ 1 out of 5 times if we run the smoke tests every 5 minutes.
We found that adding
-Dhttp.keepAlive=false
to JAVA_OPTS in /var/vcap/jobs/login/bin/login_ctl
works around the problem. Otherwise, by default there is a pool of 5 connections being kept alive and reused.
We use an F5 BigIP load balancer with 300 seconds socket idle timeout configured.
Could this be a bug with stale connections being reused by the HTTP client on the login machine?
Best Regards,
Jan
--- log snippet from login machine ---
[2015-05-08 08:07:52.787] login - 9054 [http-bio-8080-exec-2] .... DEBUG --- DispatcherServlet: DispatcherServlet with name 'spring' processing POST request for [/error500]
[2015-05-08 08:07:52.787] login - 9054 [http-bio-8080-exec-2] .... DEBUG --- RequestMappingHandlerMapping: Looking up handler method for path /error500
[2015-05-08 08:07:52.787] login - 9054 [http-bio-8080-exec-2] .... DEBUG --- RequestMappingHandlerMapping: Returning handler method [public java.lang.String org.cloudfoundry.identity.uaa.login.HomeController.error500(org.springframework.ui.Model,javax.servlet.http.HttpServletRequest)]
[2015-05-08 08:07:52.787] login - 9054 [http-bio-8080-exec-2] .... ERROR --- HomeController: Internal error
org.springframework.web.client.ResourceAccessException: I/O error on POST request for "http://uaa.cf.<DOMAIN>/authenticate":Connection reset; nested exception is java.net.SocketException: Connection reset
at org.springframework.web.client.RestTemplate.doExecute(RestTemplate.java:567)
at org.springframework.security.oauth2.client.OAuth2RestTemplate.doExecute(OAuth2RestTemplate.java:128)
at org.springframework.web.client.RestTemplate.execute(RestTemplate.java:512)
at org.springframework.web.client.RestTemplate.exchange(RestTemplate.java:454)
at org.cloudfoundry.identity.uaa.login.RemoteUaaAuthenticationManager.authenticate(RemoteUaaAuthenticationManager.java:137)
at org.cloudfoundry.identity.uaa.authentication.AuthzAuthenticationFilter.doFilter(AuthzAuthenticationFilter.java:138)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
at org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter.doFilterInternal(WebAsyncManagerIntegrationFilter.java:50)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
at org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192)
at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160)
at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:344)
at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:261)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:501)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:950)
at org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:683)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116) [37/1995]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1070)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:611)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:314)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:744)
Caused by: java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:196)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:136)
at org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:152)
at org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:270)
at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:140)
at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:260)
at org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:161)
at sun.reflect.GeneratedMethodAccessor121.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.apache.http.impl.conn.CPoolProxy.invoke(CPoolProxy.java:138)
at com.sun.proxy.$Proxy45.receiveResponseHeader(Unknown Source)
at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:271)
at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:123)
at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:254)
at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:195)
at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:86)
at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:108)
at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:186)
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at org.springframework.http.client.HttpComponentsClientHttpRequest.executeInternal(HttpComponentsClientHttpRequest.java:91)
at org.springframework.http.client.AbstractBufferingClientHttpRequest.executeInternal(AbstractBufferingClientHttpRequest.java:48)
at org.springframework.http.client.AbstractClientHttpRequest.execute(AbstractClientHttpRequest.java:53)
at org.springframework.web.client.RestTemplate.doExecute(RestTemplate.java:551)
... 33 more
Re: Cloudfoundry UAA / Questions
Daniel Jones
For users created in UAA database, are there any policies we could apply
regarding password expiry/strength of the password/lockout on repeated
retry failures etc..?
Currently there is a password score calculator. There is a feature being
implemented for a more clearly configurable password strength. Expect it to
be in the next release. Lockout is implemented, and will also be
configurable in the next release.
+1 for password expiry; that'd be really handy to have.
On Sun, May 31, 2015 at 2:43 AM, Frans Thamura <frans(a)meruvian.org> wrote:
fyi, we use UAA for our social login , take a look www.merv.id
F
--
Frans Thamura (曽志胜)
Java Champion
Shadow Master and Lead Investor
Meruvian.
Integrated Hypermedia Java Solution Provider.
Mobile: +628557888699
Blog: http://blogs.mervpolis.com/roller/flatburger (id)
FB: http://www.facebook.com/meruvian
TW: http://www.twitter.com/meruvian / @meruvian
Website: http://www.meruvian.org
"We grow because we share the same belief."
On Sun, May 31, 2015 at 1:11 AM, Filip Hanik <fhanik(a)pivotal.io> wrote:For users created in UAA database, are there any policies we could applyretry
regarding password expiry/strength of the password/lockout on repeatedfailures etc..?to
Currently there is a password score calculator. There is a feature being
implemented for a more clearly configurable password strength. Expect itbe in the next release. Lockout is implemented, and will also beuse
configurable in the next release.
Is there any pluggable mechanism for user creation in UAA that we couldto create them say in AD – instead of in UAA user database?of
The UAA can integrate with LDAP (AD) or with SAML IDPs. When you use onethese authentication mechanism, a shadow account will be created in theUAA.These users will only be able to authenticate against their respectivetenants
identity providers.
Is there any work/pocs done on UAA integration with Shibboleth Identity
provider to have federated identity? I.e. Integration with identity
providers behind firewalls?
I believe Shibboleth is a SAML v2 provider, so it should be able to be
configured like any other provider.
Is UAA HA/DR capable if the underlying user database is replicated?
Basically does it boil down to underlying UAA database HA/DR and anyidentity provider’s HA/DR capability?using
Yes, that is how we run our UAA in production. It's backed by a HA/DR
database.
Other than notion of Zones/Multi-tenants are there any advantages ofUAA over plain Spring Security OAuth2/Spring Cloud Security?satyapal.reddy(a)emc.com>
Yes, most of the work has already been done for you.
On Sat, May 30, 2015 at 11:58 AM, Reddy, Satyapal <wrote:retry
Looking into using UAA and have couple of questions:
For users created in UAA database, are there any policies we could apply
regarding password expiry/strength of the password/lockout on repeatedtenantsfailures etc..?
Is there any pluggable mechanism for user creation in UAA that we could
use to create them say in AD – instead of in UAA user database?
Is there any work/pocs done on UAA integration with Shibboleth Identity
provider to have federated identity? I.e. Integration with identity
providers behind firewalls?
Is UAA HA/DR capable if the underlying user database is replicated?
Basically does it boil down to underlying UAA database HA/DR and anyusingidentity provider’s HA/DR capability?
Other than notion of Zones/Multi-tenants are there any advantages of_______________________________________________UAA over plain Spring Security OAuth2/Spring Cloud Security?
Thanks
Satya
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
Regards,
Daniel Jones
EngineerBetter.com