On Mon, Jun 13, 2016 at 9:50 AM, Nithiyasri Gnanasekaran -X (ngnanase -
TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com> wrote:

Hi



Thanks for clarifying my doubts ..



After starting nginx (61679 via PORt env variable) and gunicorn ( on 8000
), my curl to these fail saying connection refused..



root(a)8119291b-a084-45ea-9183-ea1e65e75bf3:/var/vcap/data/warden/depot/19k1k75ve4t#
curl http://localhost:61679

curl: (7) Failed to connect to localhost port 61679: Connection refused

root(a)8119291b-a084-45ea-9183-ea1e65e75bf3:/var/vcap/data/warden/depot/19k1k75ve4t#
curl http://127.0.0.1:61679

curl: (7) Failed to connect to 127.0.0.1 port 61679: Connection refused

root(a)8119291b-a084-45ea-9183-ea1e65e75bf3:/var/vcap/data/warden/depot/19k1k75ve4t#
curl http://127.0.0.1:8000

curl: (7) Failed to connect to 127.0.0.1 port 8000: Connection refused

root(a)8119291b-a084-45ea-9183-ea1e65e75bf3:/var/vcap/data/warden/depot/19k1k75ve4t#
curl http://localhost:8000

curl: (7) Failed to connect to localhost port 8000: Connection refused

Try curling ${HOST_IP}:61679, where HOST_IP is the IP address assigned to
the eth0 interface on the DEA VM. You should be able to obtain it from
`bosh vms` output, or from running `ifconfig eth0` on the VM.

The NAT rules are set up to forward only traffic destined to that IP
address to the containers, as you can see from running `iptables-save -t
nat` on the DEA or Diego Cell VM.

Best,
Eric

Hi

Thanks for clarifying my doubts ..

After starting nginx (61679 via PORt env variable) and gunicorn ( on 8000 ), my curl to these fail saying connection refused..

root(a)8119291b-a084-45ea-9183-ea1e65e75bf3:/var/vcap/data/warden/depot/19k1k75ve4t# curl http://localhost:61679
curl: (7) Failed to connect to localhost port 61679: Connection refused
root(a)8119291b-a084-45ea-9183-ea1e65e75bf3:/var/vcap/data/warden/depot/19k1k75ve4t# curl http://127.0.0.1:61679
curl: (7) Failed to connect to 127.0.0.1 port 61679: Connection refused
root(a)8119291b-a084-45ea-9183-ea1e65e75bf3:/var/vcap/data/warden/depot/19k1k75ve4t# curl http://127.0.0.1:8000
curl: (7) Failed to connect to 127.0.0.1 port 8000: Connection refused
root(a)8119291b-a084-45ea-9183-ea1e65e75bf3:/var/vcap/data/warden/depot/19k1k75ve4t# curl http://localhost:8000
curl: (7) Failed to connect to localhost port 8000: Connection refused

Though the logs show that gunicorn is started:

2016-06-13T16:36:37.56+0000 [App/0] INFO [2016-06-13 16:36:37 +0000] [40] [INFO] Starting gunicorn 19.3.0
2016-06-13T16:36:37.56+0000 [App/0] INFO [2016-06-13 16:36:37 +0000] [40] [INFO] Listening at: http://0.0.0.0:8000 (40)
2016-06-13T16:36:37.56+0000 [App/0] INFO [2016-06-13 16:36:37 +0000] [40] [INFO] Using worker: sync
2016-06-13T16:36:37.57+0000 [App/0] INFO [2016-06-13 16:36:37 +0000] [46] [INFO] Booting worker with pid: 46
2016-06-13T16:36:37.61+0000 [App/0] INFO [2016-06-13 16:36:37 +0000] [47] [INFO] Booting worker with pid: 47
2016-06-13T16:36:37.68+0000 [App/0] INFO [2016-06-13 16:36:37 +0000] [50] [INFO] Booting worker with pid: 50

Ps –ef | grep guni

root(a)8119291b-a084-45ea-9183-ea1e65e75bf3:/var/vcap/data/warden/depot/19k1k75ve4t# ps -ef | grep guni
root 8936 2380 0 16:49 pts/1 00:00:00 grep --color=auto guni
20239 32308 32256 0 16:36 ? 00:00:00 /app/.heroku/python/bin/python /home/vcap/app/.heroku/python/bin/gunicorn --workers 3 --bind 0.0.0.0:8000 idmapi.wsgi:application
20239 32448 32308 0 16:36 ? 00:00:00 /app/.heroku/python/bin/python /home/vcap/app/.heroku/python/bin/gunicorn --workers 3 --bind 0.0.0.0:8000 idmapi.wsgi:application
20239 32449 32308 0 16:36 ? 00:00:00 /app/.heroku/python/bin/python /home/vcap/app/.heroku/python/bin/gunicorn --workers 3 --bind 0.0.0.0:8000 idmapi.wsgi:application
20239 32452 32308 0 16:36 ? 00:00:00 /app/.heroku/python/bin/python /home/vcap/app/.heroku/python/bin/gunicorn --workers 3 --bind 0.0.0.0:8000 idmapi.wsgi:application

Pls let me know why the curl is failing for both the ports..
Sorry if its not related to cloud foundry


Regards
Nithiyasri
From: Eric Malm [mailto:emalm(a)pivotal.io]
Sent: Monday, June 13, 2016 4:18 AM
To: Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com>; Discussions about Cloud Foundry projects and the system overall. <cf-dev(a)lists.cloudfoundry.org>
Subject: Re: [cf-dev] Re: Reg executing sudo commands in DEA vm

On Fri, Jun 10, 2016 at 12:57 PM, Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com<mailto:ngnanase(a)cisco.com>> wrote:
Hi
Now I understand the use of the PORT env in the warden. I am using the same for nginx whichis offered by CF.

But what port should I specify for gunicorn running in the same app... CF offers only one port /app. Can I use any unused port listed by netstat –lntl for gunicorn.

If you expect gunicorn to receive traffic only from the local nginx, you should be able to configure it to use any port above 1024 which isn't already bound by a process inside the container.

Thanks,
Eric

On Fri, Jun 10, 2016 at 12:57 PM, Nithiyasri Gnanasekaran -X (ngnanase -
TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com> wrote:

Hi

Now I understand the use of the PORT env in the warden. I am using the
same for nginx whichis offered by CF.



But what port should I specify for gunicorn running in the same app... CF
offers only one port /app. Can I use any unused port listed by netstat
–lntl for gunicorn.

If you expect gunicorn to receive traffic only from the local nginx, you
should be able to configure it to use any port above 1024 which isn't
already bound by a process inside the container.

Thanks,
Eric

Hi, Vinod,

Release notes for CF generally state a version of Diego and any other
related releases that are known to be compatible. Since CF v220 + Diego
v0.1434.0, the internal APIs have stabilized, and from those releases
onward we intend the system to be upgradable without downtime for
sufficiently redundant deployments.

Thanks,
Eric, CF Runtime Diego PM

On Fri, Jun 10, 2016 at 2:22 PM, ronak banka <ronakbanka.cse(a)gmail.com>
wrote:

Hi Vinod,

you can check the compatibility versions here
<https://github.com/cloudfoundry-incubator/diego-cf-compatibility>

Thanks
Ronak

On Sat, Jun 11, 2016 at 1:45 AM, Vinod Singh <vinoddandy(a)gmail.com> wrote:

Friends,

What is first version of CF release which supports Diego architecture?
Sorry for asking basic question, but I am picking up again..

Thx, Singh

Hi,

Does the lattice app instance stay in a down state? What happens when CF
restarts it? Also, what version of garden-linux-release is deployed?

I've just now been able to run `cf push lattice-app -o
cloudfoundry/lattice-app` to push the lattice-app image to a CF environment
running dev versions of CF and Diego later than v237 and v0.1472.0,
respectively, and according to the logs it runs fine. I observe the pair of
exit-status codes you report from the logs of this instance only when I
intentionally stop the entire app or use `cf restart-app-instance` to
restart one of its instances.

Thanks,
Eric, CF Runtime Diego PM

Hi, there

I uploaded my cf deployment from 233 to 237 using bosh, and deploy
diego(diego-release-0.1472.0) along cf deployoment.

The deployment itself is successful. And I am able to push apps using
buildpacks to diego backend instead of DEA backend.

Howerver, when I try to push docker image to diego backend using command:

*cf docker-push my-app cloudfoundry/lattice-app*

It failed to start , cf app my-app shows the status is down:

cf app my-app

requested state: started
instances: 0/1
usage: 1G x 1 instances
urls: my-app.example.com
last uploaded: Sun Jun 12 05:44:14 UTC 2016
stack: cflinuxfs2
buildpack: unknown

state since cpu memory disk details
#0 *down* 1970-01-01 12:00:00 AM 0.0% 0 of 1G 0 of 1G


cf docker-push my-app cloudfoundry/lattice-app

and cf logs my-app--recent shows "Lattice-app" starts successfully first,
then exit with some error. Any suggestions? Your help is appreciated!

016-06-12T05:44:14.76+0000 [API/0] OUT Created app with guid
c6c68c6b-7727-45ba-a5e9-d7a7867cc5e4
2016-06-12T05:44:15.04+0000 [API/0] OUT Updated app with guid
c6c68c6b-7727-45ba-a5e9-d7a7867cc5e4
({"route"=>"c34726a5-1275-47a4-9a49-b7a481753200"})
2016-06-12T05:44:15.68+0000 [API/0] OUT Updated app with guid
c6c68c6b-7727-45ba-a5e9-d7a7867cc5e4 ({"state"=>"STARTED"})
2016-06-12T05:44:33.95+0000 [STG/0] OUT Creating container
2016-06-12T05:44:34.19+0000 [STG/0] OUT Successfully created container
2016-06-12T05:44:34.19+0000 [STG/0] OUT Staging...
2016-06-12T05:44:34.21+0000 [STG/0] OUT Staging process started ...
2016-06-12T05:44:36.28+0000 [STG/0] OUT Staging process finished
2016-06-12T05:44:36.28+0000 [STG/0] OUT Exit status 0
2016-06-12T05:44:36.28+0000 [STG/0] OUT Staging Complete
2016-06-12T05:44:36.52+0000 [CELL/0] OUT Creating container
2016-06-12T05:44:48.13+0000 [CELL/0] OUT Successfully created container
2016-06-12T05:44:48.13+0000 [CELL/0] OUT Starting health monitoring of
container
2016-06-12T05:44:48.15+0000 [APP/0] OUT
{"timestamp":"1465710288.151398897","source":"lattice-app","message":"lattice-app.lattice-app.starting","log_level":1,"data":{"ports":["8080"]}}
2016-06-12T05:44:48.15+0000 [APP/0] OUT
{"timestamp":"1465710288.151749372","source":"lattice-app","message":"lattice-app.lattice-app.up","log_level":1,"data":{"port":"8080"}}
2016-06-12T05:44:48.65+0000 [CELL/0] OUT Container became healthy
2016-06-12T05:44:49.15+0000 [APP/0] OUT Lattice-app. Says Hello. on
index: 0
2016-06-12T05:44:50.15+0000 [APP/0] OUT Lattice-app. Says Hello. on
index: 0
2016-06-12T05:44:51.15+0000 [APP/0] OUT Lattice-app. Says Hello. on
index: 0
2016-06-12T05:44:52.15+0000 [APP/0] OUT Lattice-app. Says Hello. on
index: 0
2016-06-12T05:44:53.15+0000 [APP/0] OUT Lattice-app. Says Hello. on
index: 0
2016-06-12T05:44:54.15+0000 [APP/0] OUT Lattice-app. Says Hello. on
index: 0
2016-06-12T05:44:55.15+0000 [APP/0] OUT Lattice-app. Says Hello. on
index: 0
2016-06-12T05:44:56.15+0000 [APP/0] OUT Lattice-app. Says Hello. on
index: 0
2016-06-12T05:44:57.15+0000 [APP/0] OUT Lattice-app. Says Hello. on
index: 0
2016-06-12T05:44:58.15+0000 [APP/0] OUT Lattice-app. Says Hello. on
index: 0
2016-06-12T05:44:59.15+0000 [APP/0] OUT Lattice-app. Says Hello. on
index: 0
2016-06-12T05:45:00.15+0000 [APP/0] OUT Lattice-app. Says Hello. on
index: 0
2016-06-12T05:45:01.15+0000 [APP/0] OUT Lattice-app. Says Hello. on
index: 0
2016-06-12T05:45:02.15+0000 [APP/0] OUT Lattice-app. Says Hello. on
index: 0
2016-06-12T05:45:03.15+0000 [APP/0] OUT Lattice-app. Says Hello. on
index: 0
2016-06-12T05:45:04.09+0000 [CELL/0] OUT Exit status 0
2016-06-12T05:45:04.09+0000 [APP/0] OUT Exit status 2

Hi Padma,

We currently don't broadcast any events from the Cloud Controller.

Could you describe the use-case a bit more? What sort of task do you want
to do? What application / process would listen for these events?


Thanks,

Nick

Hi Vinod,

you can check the compatibility versions here
<https://github.com/cloudfoundry-incubator/diego-cf-compatibility>

Thanks
Ronak

Hi
Now I understand the use of the PORT env in the warden. I am using the same for nginx whichis offered by CF.

But what port should I specify for gunicorn running in the same app... CF offers only one port /app. Can I use any unused port listed by netstat –lntl for gunicorn.


Regards
Nithiaysri



From: Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco)
Sent: Saturday, June 11, 2016 12:15 AM
To: 'Eric Malm' <emalm(a)pivotal.io>
Cc: 'Discussions about Cloud Foundry projects and the system overall.' <cf-dev(a)lists.cloudfoundry.org>
Subject: RE: [cf-dev] Re: Reg executing sudo commands in DEA vm

Hi

I have started nginx in 8010 and gunicorn in 8000.
Though the processes are running in ps –ef cmd, curl to localhost:8000 & 8010 are connection refusing..

Even the ports used by the DEA vm doesn’t show 8000 & 8010

I selected 8010, as it is not listed in netstat –lntl command. Does this method apply to DEA vm?
Is there any specific way to find out the port number offered by CF to DEA , as you had mentioned in the below mail..

From: Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco)
Sent: Friday, June 10, 2016 12:39 AM
To: 'Eric Malm' <emalm(a)pivotal.io<mailto:emalm(a)pivotal.io>>
Cc: 'Discussions about Cloud Foundry projects and the system overall.' <cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>>
Subject: RE: [cf-dev] Re: Reg executing sudo commands in DEA vm

It worked!

We are not using PORT env variable..We have directly hardcoded only the port number.
I thought the permission issue is due to non-nginx user and it dint strike me its below 1024

Thanks Much!!!

Regards
Nithiyasri

From: Eric Malm [mailto:emalm(a)pivotal.io]
Sent: Friday, June 10, 2016 12:00 AM
To: Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com<mailto:ngnanase(a)cisco.com>>; cf-dev <cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>>
Subject: Re: [cf-dev] Re: Reg executing sudo commands in DEA vm

On Thu, Jun 9, 2016 at 11:23 AM, Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com<mailto:ngnanase(a)cisco.com>> wrote:
Hi Eric

The error is “Permission Denied” on the port..
As you told, I tried with port 90.. Again the same error Permission Denied..

I didn't tell you to use port 90. I said to use whatever CF provides to your process in the PORT environment variable. The process isn't running as root, so it won't be able to bind any port below 1024.


From: Eric Malm [mailto:emalm(a)pivotal.io<mailto:emalm(a)pivotal.io>]
Sent: Thursday, June 09, 2016 10:59 PM
To: Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com<mailto:ngnanase(a)cisco.com>>
Cc: Discussions about Cloud Foundry projects and the system overall. <cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>>; Jayarajan Ramapurath Kozhummal (jayark) <jayark(a)cisco.com<mailto:jayark(a)cisco.com>>

Subject: Re: [cf-dev] Re: Reg executing sudo commands in DEA vm

Hi, Nithiyasri,

As Amit already mentioned on another thread, you need to make sure nginx is binding to the port conveyed in the PORT environment variable. It will not be able to bind port 80 because it's not running as root. This seems to be how the PHP buildpack accomplishes that for its nginx config: https://github.com/cloudfoundry/php-buildpack/blob/d9b1f27af8d5083401f0ac5e81f9578fc19b619f/defaults/config/nginx/server-defaults.conf#L2

Best,
Eric

Hi

I have started nginx in 8010 and gunicorn in 8000.
Though the processes are running in ps –ef cmd, curl to localhost:8000 & 8010 are connection refusing..

Even the ports used by the DEA vm doesn’t show 8000 & 8010

I selected 8010, as it is not listed in netstat –lntl command. Does this method apply to DEA vm?
Is there any specific way to find out the port number offered by CF to DEA , as you had mentioned in the below mail..

From: Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco)
Sent: Friday, June 10, 2016 12:39 AM
To: 'Eric Malm' <emalm(a)pivotal.io>
Cc: 'Discussions about Cloud Foundry projects and the system overall.' <cf-dev(a)lists.cloudfoundry.org>
Subject: RE: [cf-dev] Re: Reg executing sudo commands in DEA vm

It worked!

We are not using PORT env variable..We have directly hardcoded only the port number.
I thought the permission issue is due to non-nginx user and it dint strike me its below 1024

Thanks Much!!!

Regards
Nithiyasri

From: Eric Malm [mailto:emalm(a)pivotal.io]
Sent: Friday, June 10, 2016 12:00 AM
To: Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com<mailto:ngnanase(a)cisco.com>>; cf-dev <cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>>
Subject: Re: [cf-dev] Re: Reg executing sudo commands in DEA vm

On Thu, Jun 9, 2016 at 11:23 AM, Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com<mailto:ngnanase(a)cisco.com>> wrote:
Hi Eric

The error is “Permission Denied” on the port..
As you told, I tried with port 90.. Again the same error Permission Denied..

I didn't tell you to use port 90. I said to use whatever CF provides to your process in the PORT environment variable. The process isn't running as root, so it won't be able to bind any port below 1024.


From: Eric Malm [mailto:emalm(a)pivotal.io<mailto:emalm(a)pivotal.io>]
Sent: Thursday, June 09, 2016 10:59 PM
To: Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com<mailto:ngnanase(a)cisco.com>>
Cc: Discussions about Cloud Foundry projects and the system overall. <cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>>; Jayarajan Ramapurath Kozhummal (jayark) <jayark(a)cisco.com<mailto:jayark(a)cisco.com>>

Subject: Re: [cf-dev] Re: Reg executing sudo commands in DEA vm

Hi, Nithiyasri,

As Amit already mentioned on another thread, you need to make sure nginx is binding to the port conveyed in the PORT environment variable. It will not be able to bind port 80 because it's not running as root. This seems to be how the PHP buildpack accomplishes that for its nginx config: https://github.com/cloudfoundry/php-buildpack/blob/d9b1f27af8d5083401f0ac5e81f9578fc19b619f/defaults/config/nginx/server-defaults.conf#L2

Best,
Eric

Friends,

What is first version of CF release which supports Diego architecture?
Sorry for asking basic question, but I am picking up again..

Thx, Singh

Hi,

During our CloudFoundry acceptance tests we encountered the following error:

```
[2016-06-07 11:38:28.36 (UTC)]> cf auth admin [REDACTED]
API endpoint: [REDACTED]
Authenticating...
FAILED
The targeted API endpoint could not be reached.
```

The error has only occurred twice in the last few days, after tens of test runs. Access log on the VM on which UAA was running indicated an HTTP code of 500 was returned in response to the oauth token being POSTed:

`"POST /oauth/token HTTP/1.1" 500 137`

We can't find anything in the UAA application logs which indicate an error occurred (even with debug enabled).
We are struggling to replicate this error and determine the conditions which generate it.

Any ideas?

Thanks,

Hi,

Is there any way to listen and react to space deletion events?
Any hook available to do some tasks before the space is deleted?

Thanks,
Kind Regards,
Padma

Hi Shannon,

On Thu, Jun 9, 2016 at 2:22 AM, Shannon Coen <scoen(a)pivotal.io> wrote:

On Wed, Jun 8, 2016 at 5:03 AM, Isuru Haththotuwa <isurulucky(a)gmail.com>
wrote:

Hi Shannon,

Thanks for the reply.

On Wed, Jun 8, 2016 at 4:36 AM, Shannon Coen <scoen(a)pivotal.io> wrote:

If I understand you correctly, you would like your application to
receive requests on multiple ports. Is that correct? Does it matter what
ports your application clients send requests to? Could you please share the
details of your use cases for this functionality?

The usecase is that an application listening to multiple types of traffic
(http, tcp, binary, etc.) from multiple ports exposed in the container.
Therefore I guess we would need to have multiple ports open from the host
side as well.

If your application receives http traffic on more than one port, you would
not need another port opened, only another route. For non-HTTP traffic, you
would need a TCP route (with a reserved port) for each app port. The route
ports will not match your application ports. Does this sound like it would
fulfill your needs?

Maybe I might have misunderstood this. My current understanding is, if the
application instance needs to listen with multiple ports (from the
container side) for multiple types of traffic, there should be multiple
ports opened (from the host node/VM side), which should forward traffic to
the relevant container port:

host port 1 (5005) -----------------> container port 1 (9080)

host port 2 (5006) -----------------> container port 2 (9081)

As I understood, its possible to define a route with a non-standard port
(5005/5006 as shown in the sketch above). But currently the application
instance will listen on 8080 only, hence CF will only forward the traffic
to same container port (8080) for both the routes. Please correct me if I'm
wrong.

Currently HTTP requests may only be sent to 80 or 443. Your app may
receive requests on one port only. On DEAs, this port is randomized and can
be discovered from the $PORT env var. On Diego, this env var is also
present but is always 8080.

This isn't a limitation of Diego; Diego will open whatever container
ports a client tells it to. However, we have not yet added the business
logic to Cloud Controller to expose management of these ports to
application developers.

You discovered that two ports are already opened on the container. The
second port is opened automatically in support of the feature that enables
a developer to SSH into the container. The env var you identified, CF_INSTANCE_PORTS,
is a list of all ports opened on the container. This env var should be
considered an internal implementation detail as it contains ports used by
internal system components to which an app should not bind. The env var is
documented as there are a few use cases where an app needs to know what the
host port is.

We do plan to enable applications to listen on multiple ports. Clients
will still make HTTP requests to 80 or 443, but a developer will be able to
specify the application port when mapping a route to an application.

E.g.
myapp.cf.com -> myapp listening on 8080
myapp.cf.com/admin -> myapp listening on 6000

I'm currently drafting a proposal for this feature and will share it
soon for feedback.

This is indeed great news!

If your clients must call your application on a port besides 80 or 443,
I would recommend exploring our support for TCP routing (see the CLI help
file for create-route). Developers can reserve non-standard ports for a
route, like tcp.cf.com:6000, and CF will route requests for it to your
application port on 8080. After we deliver support for custom app ports, as
described above, you would be able to specify both the route port and the
app port.





Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Tue, Jun 7, 2016 at 1:18 AM, Isuru Haththotuwa <isurulucky(a)gmail.com>
wrote:

Hi all,

Is it possible to expose two ports of an Application via from CF to
external traffic, via an externally routable address and multiple ports?

While going through the documentation, came across [1], which suggests
that requests are served from port 80 and 443 only. However, while trying
out the sample spring application [2] on CF (using the hosted CF in pivotal
web services), I could actually see that there are multiple port mappings
defined by invoking the rest API [3]. Additionally, in pivotal.io
docs, I see the definition of CF-INSTANCE-PORTS, which seems to support
multiple port mappings from host to container.

I'm curios to know if exposing multiple ports from the host and
container side is possible.

Thanks in advance.

[1].
https://docs.cloudfoundry.org/devguide/deploy-apps/prepare-to-deploy.html#ports

[2]. https://github.com/cloudfoundry-samples/spring-music

[3].
{
"0": {
"state": "RUNNING",
"stats": {
"name": "spring-music",
"uris": [
"spring-music-moonlit-melioration.cfapps.io"
],
"host": "10.10.115.53",
"port": 64248,
"net_info": {
"address": "10.10.115.53",
* "ports": [*
* {*
* "container_port": 8080,*
* "host_port": 64248*
* },*
* {*
* "container_port": 2222,*
* "host_port": 64249*
* }*
* ]*
},
"uptime": 9484,
"mem_quota": 536870912,
"disk_quota": 1073741824,
"fds_quota": 16384,
"usage": {
"time": "2016-05-20T11:12:38.944471672Z",
"cpu": 0.0010850797743361504,
"mem": 460423168,
"disk": 166739968
}
}
}
}

[4].
http://docs.run.pivotal.io/devguide/deploy-apps/environment-variable.html#CF-INSTANCE-PORTS

--
Thanks and Regards,
Isuru

--
Thanks and Regards,
Isuru

It worked!

We are not using PORT env variable..We have directly hardcoded only the port number.
I thought the permission issue is due to non-nginx user and it dint strike me its below 1024

Thanks Much!!!

Regards
Nithiyasri

From: Eric Malm [mailto:emalm(a)pivotal.io]
Sent: Friday, June 10, 2016 12:00 AM
To: Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com>; cf-dev <cf-dev(a)lists.cloudfoundry.org>
Subject: Re: [cf-dev] Re: Reg executing sudo commands in DEA vm

On Thu, Jun 9, 2016 at 11:23 AM, Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com<mailto:ngnanase(a)cisco.com>> wrote:
Hi Eric

The error is “Permission Denied” on the port..
As you told, I tried with port 90.. Again the same error Permission Denied..

I didn't tell you to use port 90. I said to use whatever CF provides to your process in the PORT environment variable. The process isn't running as root, so it won't be able to bind any port below 1024.


From: Eric Malm [mailto:emalm(a)pivotal.io<mailto:emalm(a)pivotal.io>]
Sent: Thursday, June 09, 2016 10:59 PM
To: Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com<mailto:ngnanase(a)cisco.com>>
Cc: Discussions about Cloud Foundry projects and the system overall. <cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>>; Jayarajan Ramapurath Kozhummal (jayark) <jayark(a)cisco.com<mailto:jayark(a)cisco.com>>

Subject: Re: [cf-dev] Re: Reg executing sudo commands in DEA vm

Hi, Nithiyasri,

As Amit already mentioned on another thread, you need to make sure nginx is binding to the port conveyed in the PORT environment variable. It will not be able to bind port 80 because it's not running as root. This seems to be how the PHP buildpack accomplishes that for its nginx config: https://github.com/cloudfoundry/php-buildpack/blob/d9b1f27af8d5083401f0ac5e81f9578fc19b619f/defaults/config/nginx/server-defaults.conf#L2

Best,
Eric

On Thu, Jun 9, 2016 at 11:23 AM, Nithiyasri Gnanasekaran -X (ngnanase -
TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com> wrote:

Hi Eric



The error is “Permission Denied” on the port..

As you told, I tried with port 90.. Again the same error Permission
Denied..

I didn't tell you to use port 90. I said to use whatever CF provides to
your process in the PORT environment variable. The process isn't running as
root, so it won't be able to bind any port below 1024.

*From:* Eric Malm [mailto:emalm(a)pivotal.io]
*Sent:* Thursday, June 09, 2016 10:59 PM
*To:* Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco) <
ngnanase(a)cisco.com>
*Cc:* Discussions about Cloud Foundry projects and the system overall. <
cf-dev(a)lists.cloudfoundry.org>; Jayarajan Ramapurath Kozhummal (jayark) <
jayark(a)cisco.com>

*Subject:* Re: [cf-dev] Re: Reg executing sudo commands in DEA vm



Hi, Nithiyasri,



As Amit already mentioned on another thread, you need to make sure nginx
is binding to the port conveyed in the PORT environment variable. It will
not be able to bind port 80 because it's not running as root. This seems to
be how the PHP buildpack accomplishes that for its nginx config:
https://github.com/cloudfoundry/php-buildpack/blob/d9b1f27af8d5083401f0ac5e81f9578fc19b619f/defaults/config/nginx/server-defaults.conf#L2

Best,
Eric

Hi Felix,

We'd love to work with you on understanding this. Could you drop a message
in the Loggregator OSS Slack
<https://cloudfoundry.slack.com/messages/loggregator/> channel so we can
have a conversation about this?

Danke schön!

Jim

--
Jim Campbell | Product Manager | Cloud Foundry | Pivotal.io | 303.618.0963

Hi, Nithiyasri,

As Amit already mentioned on another thread, you need to make sure nginx is
binding to the port conveyed in the PORT environment variable. It will not
be able to bind port 80 because it's not running as root. This seems to be
how the PHP buildpack accomplishes that for its nginx config:
https://github.com/cloudfoundry/php-buildpack/blob/d9b1f27af8d5083401f0ac5e81f9578fc19b619f/defaults/config/nginx/server-defaults.conf#L2

Best,
Eric

On Thu, Jun 9, 2016 at 10:20 AM, Nithiyasri Gnanasekaran -X (ngnanase -
TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com> wrote:

Hi



Please let me know how can I bind the port 80 to a non root user.

Currently after starting nginx as a non root user, I cannot bind port 80
due to permission issue.



ERR nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied)



Please let me know if non-portRootBinding can be done in the DEA/warden
container



Regards

Nithiyasri



*From:* Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at
Cisco)
*Sent:* Wednesday, June 08, 2016 7:57 AM
*To:* 'Eric Malm' <emalm(a)pivotal.io>
*Cc:* Jayarajan Ramapurath Kozhummal (jayark) <jayark(a)cisco.com>
*Subject:* RE: [cf-dev] Re: Reg executing sudo commands in DEA vm



Hi Eric



Thanks much for the detailed explanation..

So when I do cf push, it happens in the container and that vcap user
cannot get sudo privileges.



So Please suggest me on how can I handle this. Now CF is restricting me
not to install Nginx, but which needs sudo privileges..

So can I not push an application, which uses Nginx in cloud foundry….



*ERR 2016/06/07 05:59:29 [warn] 34#0: the "user" directive makes sense
only if the master process runs with super-user privileges, ignored in
/home/vcap/app/nginx/conf/nginx.conf:5*





Regards

Nithiyasri



*From:* Eric Malm [mailto:emalm(a)pivotal.io <emalm(a)pivotal.io>]
*Sent:* Wednesday, June 08, 2016 2:23 AM
*To:* Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco) <
ngnanase(a)cisco.com>
*Subject:* Re: [cf-dev] Re: Reg executing sudo commands in DEA vm



Responses inline.



On Tue, Jun 7, 2016 at 3:00 AM, Nithiyasri Gnanasekaran -X (ngnanase -
TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com> wrote:

1. vcap(a)e3da8039-ff08-4b9e-9492-922b0f4b30f4:/var/vcap/data/warden/depot/19k1kejlrto$
echo "c1oudc0w" | sudo -S ./test2.sh

[sudo] password for vcap: I am running test2.sh

In this case, you're running your script as the vcap user on the host VM,
not inside the container. You're able to use sudo as above because BOSH has
provisioned the vcap user with the default 'c1oudc0w' password and included
it in the admin group, which has sudo privileges. The vcap user inside the
container has a different configuration that comes from the filesystem that
applies inside the container.

2. Logging into wsh: If I do wsh , I cannot access the
depot/19k1kejlrto folder, because there is where the scripts are placed

vcap(a)e3da8039-ff08-4b9e-9492-922b0f4b30f4:/var/vcap/data/warden/depot/19k1kejlrto#
sudo ./bin/wsh

root(a)19k1kejlrto:~# ls

firstboot.sh

root(a)19k1kejlrto:~# pwd

/root

root(a)19k1kejlrto:~# cd /var/vcap/data/warden/depot/19k1kejlrto

bash: cd: /var/vcap/data/warden/depot/19k1kejlrto: No such file or
directory

root(a)19k1kejlrto:~# cd /var/vcap/data/warden/depot

bash: cd: /var/vcap/data/warden/depot: No such file or directory

root(a)19k1kejlrto:~# cd /var/vcap/data/

root(a)19k1kejlrto:/var/vcap/data# ls

dea_next



sudo su lands in the same location but via wsh, it lands in a different
folder and not accessible to the depot/19k1kejlrto .. But in both the
cases, they land in as root user only..

I could not decipher the difference..





One way in which warden (and garden-linux/garden-runc) containers are
isolated from the host is that they have a different root filesystem.
That's why you don't see the script files you wrote on the host inside the
container. As I mentioned above, that's also why the vcap user behaves
differently between the host VM and the container.



Thanks,

Eric

Hi

Please let me know how can I bind the port 80 to a non root user.
Currently after starting nginx as a non root user, I cannot bind port 80 due to permission issue.

ERR nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied)

Please let me know if non-portRootBinding can be done in the DEA/warden container

Regards
Nithiyasri

From: Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco)
Sent: Wednesday, June 08, 2016 7:57 AM
To: 'Eric Malm' <emalm(a)pivotal.io>
Cc: Jayarajan Ramapurath Kozhummal (jayark) <jayark(a)cisco.com>
Subject: RE: [cf-dev] Re: Reg executing sudo commands in DEA vm

Hi Eric

Thanks much for the detailed explanation..
So when I do cf push, it happens in the container and that vcap user cannot get sudo privileges.

So Please suggest me on how can I handle this. Now CF is restricting me not to install Nginx, but which needs sudo privileges..
So can I not push an application, which uses Nginx in cloud foundry….

ERR 2016/06/07 05:59:29 [warn] 34#0: the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /home/vcap/app/nginx/conf/nginx.conf:5


Regards
Nithiyasri

From: Eric Malm [mailto:emalm(a)pivotal.io]
Sent: Wednesday, June 08, 2016 2:23 AM
To: Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com<mailto:ngnanase(a)cisco.com>>
Subject: Re: [cf-dev] Re: Reg executing sudo commands in DEA vm

Responses inline.

On Tue, Jun 7, 2016 at 3:00 AM, Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com<mailto:ngnanase(a)cisco.com>> wrote:
1. vcap(a)e3da8039-ff08-4b9e-9492-922b0f4b30f4:/var/vcap/data/warden/depot/19k1kejlrto$ echo "c1oudc0w" | sudo -S ./test2.sh

[sudo] password for vcap: I am running test2.sh
In this case, you're running your script as the vcap user on the host VM, not inside the container. You're able to use sudo as above because BOSH has provisioned the vcap user with the default 'c1oudc0w' password and included it in the admin group, which has sudo privileges. The vcap user inside the container has a different configuration that comes from the filesystem that applies inside the container.

2. Logging into wsh: If I do wsh , I cannot access the depot/19k1kejlrto folder, because there is where the scripts are placed
vcap(a)e3da8039-ff08-4b9e-9492-922b0f4b30f4:/var/vcap/data/warden/depot/19k1kejlrto# sudo ./bin/wsh
root(a)19k1kejlrto:~# ls
firstboot.sh
root(a)19k1kejlrto:~# pwd
/root
root(a)19k1kejlrto:~# cd /var/vcap/data/warden/depot/19k1kejlrto
bash: cd: /var/vcap/data/warden/depot/19k1kejlrto: No such file or directory
root(a)19k1kejlrto:~# cd /var/vcap/data/warden/depot
bash: cd: /var/vcap/data/warden/depot: No such file or directory
root(a)19k1kejlrto:~# cd /var/vcap/data/
root(a)19k1kejlrto:/var/vcap/data# ls
dea_next

sudo su lands in the same location but via wsh, it lands in a different folder and not accessible to the depot/19k1kejlrto .. But in both the cases, they land in as root user only..
I could not decipher the difference..


One way in which warden (and garden-linux/garden-runc) containers are isolated from the host is that they have a different root filesystem. That's why you don't see the script files you wrote on the host inside the container. As I mentioned above, that's also why the vcap user behaves differently between the host VM and the container.

Thanks,
Eric

Hello Jim,

I am working for Springer Nature in Berlin. As of now our experience
with the loggregator-trafficcontroller is is that it behaves like it has
a memory leak :-) We are actually wondering if anyone else has this
problem. We're running version 231 with 80 runners and 4
loggregator-trafficcontrollers and 8 dopplers.

As of now we're using the loggregator-trafficcontroller only to fetch
the logs from and send them into our ELK. In the future we'll also
consume metrics from it and I would be happy to share our experience
about that.

Please let me know if you have any information on other parties running
OSS installations with the same kind of problems on the loggregators.


Felix