Date   

Re: Error 400007: `stats_z1/0' is not running after update

Amit Kumar Gupta
 

I often take the following approach to debugging issues like this:

* Open two shell sessions to your failing VM using bosh ssh, and switch to
superuser
* In one session, `watch monit summary`. You might see collector going back
and forth between initializing and not monitored, but please report
anything else of interest you see here
* In the other session, `cd /var/vcap/sys/log` and then `watch
--differences=cumulative ls -altr **/*` to see which files are being
written to while the startup processes are thrashing. Then `tail -f FILE_1
FILE_2 ...` listing all the files that were being written to, and seem
relevant to the thrashing process(es) in monit


On Wed, Sep 23, 2015 at 12:21 AM, Guangcai Wang <guangcai.wang(a)gmail.com>
wrote:

It frequently logs the message below. It seems not helpful.


{"timestamp":1442987404.9433253,"message":"collector.started","log_level":"info","source":"collector","data":{},"thread_id":70132569199380,"fiber_id":70132570371720,"process_id":19392,"file":"/var/vcap/packages/collector/lib/collector/config.rb","lineno":45,"method":"setup_logging"}

the only possible error message from the bosh debug log is
"ntp":{"message":"bad ntp server"}

But I don't think, it is related to the failure of stats_z1 updating.

I, [2015-09-23 04:55:59 #2392] [canary_update(stats_z1/0)] INFO --
DirectorJobRunner: Checking if stats_z1/0 has been updated after
63.333333333333336 seconds
D, [2015-09-23 04:55:59 #2392] [canary_update(stats_z1/0)] DEBUG --
DirectorJobRunner: SENT: agent.7d3452bd-679e-4a97-8514-63a373a54ffd
{"method":"get_state","arguments":[],"reply_to":"director.c5b97fc1-b972-47ec-9412-a83ad240823b.473fda64-6ac3-4a53-9ebc-321fc7eabd7a"}
D, [2015-09-23 04:55:59 #2392] [] DEBUG -- DirectorJobRunner: RECEIVED:
director.c5b97fc1-b972-47ec-9412-a83ad240823b.473fda64-6ac3-4a53-9ebc-321fc7eabd7a
{"value":{"properties":{"logging":{"max_log_file_size":""}},"job":{"name":"stats_z1","release":"","template":"fluentd","version":"4c71c87bbf0144428afacd470e2a5e32b91932fc","sha1":"b141c6037d429d732bf3d67f7b79f8d7d80aac5d","blobstore_id":"d8451d63-2e4f-4664-93a8-a77e5419621d","templates":[{"name":"fluentd","version":"4c71c87bbf0144428afacd470e2a5e32b91932fc","sha1":"b141c6037d429d732bf3d67f7b79f8d7d80aac5d","blobstore_id":"d8451d63-2e4f-4664-93a8-a77e5419621d"},{"name":"collector","version":"889b187e2f6adc453c61fd8f706525b60e4b85ed","sha1":"f5ae15a8fa2417bf984513e5c4269f8407a274dc","blobstore_id":"3eeb0166-a75c-49fb-9f28-c29788dbf64d"},{"name":"metron_agent","version":"e6df4c316b71af68dfc4ca476c8d1a4885e82f5b","sha1":"42b6d84ad9368eba0508015d780922a43a86047d","blobstore_id":"e578bfb0-9726-4754-87ae-b54c8940e41a"},{"name":"apaas_collector","version":"8808f0ae627a54706896a784dba47570c92e0c8b","sha1":"b9a63da925b40910445d592c70abcf4d23ffe84d","blobstore_id":"3e6fa71a-07f7-446a-96f4-3caceea02f2f"}]},"packages":{"apaas_collector":{"name":"apaas_collector","version":"f294704d51d4517e4df3d8417a3d7c71699bc04d.1","sha1":"5af77ceb01b7995926dbd4ad7481dcb7c3d94faf","blobstore_id":"fa0e96b9-71a6-4828-416e-dde3427a73a9"},"collector":{"name":"collector","version":"ba47450ce83b8f2249b75c79b38397db249df48b.1","sha1":"0bf8ee0d69b3f21cf1878a43a9616cb7e14f6f25","blobstore_id":"722a5455-f7f7-427d-7e8d-e562552857bc"},"common":{"name":"common","version":"99c756b71550530632e393f5189220f170a69647.1","sha1":"90159de912c9bfc71740324f431ddce1a5fede00","blobstore_id":"37be6f28-c340-4899-7fd3-3517606491bb"},"fluentd-0.12.13":{"name":"fluentd-0.12.13","version":"71d8decbba6c863bff6c325f1f8df621a91eb45f.1","sha1":"2bd32b3d3de59e5dbdd77021417359bb5754b1cf","blobstore_id":"7bc81ac6-7c24-4a94-74d1-bb9930b07751"},"metron_agent":{"name":"metron_agent","version":"997d87534f57cad148d56c5b8362b72e726424e4.1","sha1":"a21404c50562de75000d285a02cd43bf098bfdb9","blobstore_id":"6c7cf72c-9ace-40a1-4632-c27946bf631e"},"ruby-2.1.6":{"name":"ruby-2.1.6","version":"41d0100ffa4b21267bceef055bc84dc37527fa35.1","sha1":"8a9867197682cabf2bc784f71c4d904bc479c898","blobstore_id":"536bc527-3225-43f6-7aad-71f36addec80"}},"configuration_hash":"a73c7d06b0257746e95aaa2ca994c11629cbd324","networks":{"private_cf_subnet":{"cloud_properties":{"name":"random","net_id":"1e1c9aca-0b5a-4a8f-836a-54c18c21c9b9","security_groups":["az1_cf_management_secgroup_bosh_cf_ssh_cf2","az1_cf_management_secgroup_cf_private_cf2","az1_cf_management_secgroup_cf_public_cf2"]},"default":["dns","gateway"],"dns":["192.168.110.8","133.162.193.10","133.162.193.9","192.168.110.10"],"dns_record_name":"0.stats-z1.private-cf-subnet.cf-apaas.microbosh","gateway":"192.168.110.11","ip":"192.168.110.204","netmask":"255.255.255.0"}},"resource_pool":{"cloud_properties":{"instance_type":"S-1"},"name":"small_z1","stemcell":{"name":"bosh-openstack-kvm-ubuntu-trusty-go_agent","version":"2989"}},"deployment":"cf-apaas","index":0,"persistent_disk":0,"persistent_disk_pool":null,"rendered_templates_archive":{"sha1":"0ffd89fa41e02888c9f9b09c6af52ea58265a8ec","blobstore_id":"4bd01ae7-a69a-4fe5-932b-d98137585a3b"},"agent_id":"7d3452bd-679e-4a97-8514-63a373a54ffd","bosh_protocol":"1","job_state":"failing","vm":{"name":"vm-12d45510-096d-4b8b-9547-73ea5fda00c2"},"ntp":{"message":"bad
ntp server"}}}


On Wed, Sep 23, 2015 at 5:13 PM, Amit Gupta <agupta(a)pivotal.io> wrote:

Please check the file collector/collector.log, it's in a subdirectory of
the unpacked log tarball.

On Wed, Sep 23, 2015 at 12:01 AM, Guangcai Wang <guangcai.wang(a)gmail.com>
wrote:

Actually, I checked the two files in status_z1 job VM. I did not find
any clues. Attached for reference.

On Wed, Sep 23, 2015 at 4:54 PM, Amit Gupta <agupta(a)pivotal.io> wrote:

If you do "bosh logs stats_z1 0 --job" you will get a tarball of all
the logs for the relevant processes running on the stats_z1/0 VM. You will
likely find some error messages in the collectors stdout or stderr logs.

On Tue, Sep 22, 2015 at 11:30 PM, Guangcai Wang <
guangcai.wang(a)gmail.com> wrote:

It does not help.

I always see the "collector" process bouncing between "running" and
"does not exit" when I use "monit summary" in a while loop.

Who knows how to get the real error when the "collector" process is
not failed? Thanks.

On Wed, Sep 23, 2015 at 4:11 PM, Tony <Tonyl(a)fast.au.fujitsu.com>
wrote:

My approach is to login on the stats vm and sudo, then
run "monit status" and restart the failed processes or simply restart
all
processes by running "monit restart all"

wait for a while(5~10 minutes at most)
If there is still some failed process, e.g. collector
then run ps -ef | grep collector
and kill the processes in the list(may be you need to run kill -9
sometimes)

then "monit restart all"

Normally, it will fix the issue "Failed: `XXX' is not running after
update"



--
View this message in context:
http://cf-dev.70369.x6.nabble.com/cf-dev-Error-400007-stats-z1-0-is-not-running-after-update-tp1901p1902.html
Sent from the CF Dev mailing list archive at Nabble.com.


Re: Removing support for v1 service brokers

Mike Youngstrom
 

Thanks Dieu, honestly I was just trying to find an angle to bargain for a
bit more time. :) Three months is generous. But six months would be
glorious. :)

After the CAB call this month we got started converting our brokers over
but our migration is more difficult because we use Service instance
credentials quite a bit and those don't appear to be handled well when
doing "migrate-service-instances". I think we can do 3 months but we'll be
putting our users through a bit of a fire drill.

That said I'll understand if you stick to 3 months since, we should have
started this conversion log ago.

Mike

On Wed, Sep 23, 2015 at 1:22 AM, Dieu Cao <dcao(a)pivotal.io> wrote:

We've found NATS to be unstable under certain conditions, temporary
network interruptions or network instability, around the client
reconnection logic.
We've seen that it could take anywhere from a few seconds to half an hour
to reconnect properly. We spent a fair amount of time investigating ways to
improve the reconnection logic and have made some improvements but believe
that it's best to work towards not having this dependency.
You can find more about this in the stories in this epic [1].

Mike, in addition to removing the NATS dependency, this will remove the
burden on the team, almost a weekly fight, in terms of maintaining
backwards compatibility for the v1 broker spec any time we work on adding
functionality to the service broker api.
I'll work with the team in the next couple of weeks on specific stories
and I'll link to it here.

[1] https://www.pivotaltracker.com/epic/show/1440790


On Tue, Sep 22, 2015 at 10:07 PM, Mike Youngstrom <youngm(a)gmail.com>
wrote:

Thanks for the announcement.

To be clear is this announcement to cease support for the old v1 brokers
or is this to eliminate support for the v1 api in the CC? Does the v1 CC
code depend on NATS? None of my custom v1 brokers depend on NATS.

Mike

On Tue, Sep 22, 2015 at 6:01 PM, Dieu Cao <dcao(a)pivotal.io> wrote:

Hello all,

We plan to remove support for v1 service brokers in about 3 months, in a
cf-release following 12/31/2015.
We are working towards removing CF's dependency on NATS and the v1
service brokers are still dependent on NATS.
Please let me know if you have questions/concerns about this timeline.

I'll be working on verifying a set of steps that you can find here [1]
that document how to migrate your service broker from v1 to v2 and what is
required in order to persist user data and will get that posted to the
service broker api docs officially.

-Dieu
CF CAPI PM

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




Re: DEA/Warden staging error

kyle havlovitz <kylehav@...>
 

Here's the output from those commands:
https://gist.github.com/MrEnzyme/36592831b1c46d44f007
Soon after running those I noticed that the container loses its IPv4
address shortly after coming up and ifconfig looks like this:

root(a)cf-build:/home/cloud-user/test# ifconfig -a
docker0 Link encap:Ethernet HWaddr 56:84:7a:fe:97:99
inet addr:172.17.42.1 Bcast:0.0.0.0 Mask:255.255.0.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
eth0 Link encap:Ethernet HWaddr fa:16:3e:cd:f3:0a
inet addr:172.25.1.52 Bcast:172.25.1.127 Mask:255.255.255.128
inet6 addr: fe80::f816:3eff:fecd:f30a/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:515749 errors:0 dropped:0 overruns:0 frame:0
TX packets:295471 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1162366659 (1.1 GB) TX bytes:59056756 (59.0 MB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:45057315 errors:0 dropped:0 overruns:0 frame:0
TX packets:45057315 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:18042315375 (18.0 GB) TX bytes:18042315375 (18.0 GB)
w-190db6c54la-0 Link encap:Ethernet HWaddr 12:dc:ba:da:38:5b
inet6 addr: fe80::10dc:baff:feda:385b/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1454 Metric:1
RX packets:12 errors:0 dropped:0 overruns:0 frame:0
TX packets:227 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:872 (872.0 B) TX bytes:35618 (35.6 KB)

Any idea what would be causing that?


On Tue, Sep 22, 2015 at 10:31 PM, Matthew Sykes <matthew.sykes(a)gmail.com>
wrote:

Based on your description, it doesn't sound like warden networking or the
warden iptables chains are your problem. Are you able to share all of your
routes and chains via a gist?

route -n
ifconfig -a
iptables -L -n -v -t filter
iptables -L -n -v -t nat
iptables -L -n -v -t mangle

Any kernel messages that look relevant in the message buffer (dmesg)?

Have you tried doing a network capture to verify the packets are look the
way you expect? Are you sure your host routing rules are good? Do the
warden subnets overlap with any network accessible to the host?

Based on previous notes, it doesn't sound like this is a standard
deployment so it's hard to say what could be impacting you.

On Tue, Sep 22, 2015 at 1:08 PM, Kyle Havlovitz (kyhavlov) <
kyhavlov(a)cisco.com> wrote:

I didn’t; I’m still having this problem. Even adding this lenient
security group didn’t let me get any traffic out of the VM:

[{"name":"allow_all","rules":[{"protocol":"all","destination":"0.0.0.0/0
"},{"protocol":"tcp","destination":"0.0.0.0/0
","ports":"1-65535"},{"protocol":"udp","destination":"0.0.0.0/0
","ports":"1-65535"}]}]

The only way I was able to get traffic out was by manually removing the
reject/drop iptables rules that warden set up, and even with that the
container still lost all connectivity after 30 seconds.

From: CF Runtime <cfruntime(a)gmail.com>
Reply-To: "Discussions about Cloud Foundry projects and the system
overall." <cf-dev(a)lists.cloudfoundry.org>
Date: Tuesday, September 22, 2015 at 12:50 PM
To: "Discussions about Cloud Foundry projects and the system overall." <
cf-dev(a)lists.cloudfoundry.org>
Subject: [cf-dev] Re: Re: Re: Re: Re: Re: Re: Re: DEA/Warden staging
error

Hey Kyle,

Did you make any progress?

Zak & Mikhail
CF Release Integration Team

On Thu, Sep 17, 2015 at 10:28 AM, CF Runtime <cfruntime(a)gmail.com> wrote:

It certainly could be. By default the contains reject all egress
traffic. CC security groups configure iptables rules that allow traffic
out.

One of the default security groups in the BOSH templates allows access
on port 53. If you have no security groups, the containers will not be able
to make any outgoing requests.

Joseph & Natalie
CF Release Integration Team

On Thu, Sep 17, 2015 at 8:44 AM, Kyle Havlovitz (kyhavlov) <
kyhavlov(a)cisco.com> wrote:

On running git clone inside the container via the warden shell, I get:
"Cloning into 'staticfile-buildpack'...
fatal: unable to access '
https://github.com/cloudfoundry/staticfile-buildpack/': Could not
resolve host: github.com".
So the container can't get to anything outside of it (I also tried
pinging some external IPs to make sure it wasn't a DNS thing). Would this
be caused by cloud controller security group settings?

--
Matthew Sykes
matthew.sykes(a)gmail.com


Re: Curious why CF UAA uses DNS

Filip Hanik
 

hi Anna,

Can you elaborate a little bit about what you are referring to?
I'm not quite sure what you are asking.

Filip


On Wed, Sep 23, 2015 at 8:23 AM, Anna Muravieva <ana-mur21s(a)yandex.ru>
wrote:

Hello,

We are using cf product in development. The question relates to uaa, if
you coordinate in research will be very appreciated. What are the benefits
why CF UAA uses DNS in routes management in opposite to checking this
identity for instance in request header.

Thanks in advance,
Anna


Curious why CF UAA uses DNS

Anna Muravieva
 

Hello,
We are using cf product in development. The question relates to uaa, if you coordinate in research will be very appreciated. What are the benefits why CF UAA uses DNS in routes management in opposite to checking this identity for instance in request header.
Thanks in advance, Anna


Curious why CF UAA uses DNS

Anna Muravieva
 

Hello,

We are using cf product in development. The question relates to uaa, if you coordinate in research will be very appreciated. What are the benefits why CF UAA uses DNS in routes management in opposite to checking this identity for instance in request header.

Thanks in advance,
Anna


RSA Security Analytics Users List

Mary Lopez <mary.lopez@...>
 

Hi,



Would you be interested in acquiring the list of users using RSA Security
Analytics?

We also have some authentic data of other Cloud Computing, ERP, PLM,
Analytics software users too.

Job Titles - CIO, CTO, Data Center Managers, CSO, Director of IT, IT
Security Head, Network Engineer etc.



Information Fields - Name, Title, Email, Phone Numbers, Company Name and
Company Details like Physical Address, Web Address, Revenue Size, Employee
Size and Industry.



Reach out with your specific requirement and get a set of free samples.



If you are not the right person to discuss this, please forward this email
to the right person in your organization.



I look forward to hearing from you.



Kind Regards,



Mary Lopez

Business Development Coordinator

Dynamics IT Solutions

7800 Shoal Creek Blvd.

Suite 230-S

Austin, TX 78757



If you do not wish to receive an email from us, please reply "Remove" in the
subject line.


Re: Security Question --- Securely wipe data on warden container removal / destruction???

Will Pragnell <wpragnell@...>
 

Guillaume, I'm not aware of any plans for secure memory wiping
specifically, but I can say that another track of security work is one of
several candidates for the next phase of work on Garden after OCS/runC
integration is completed.

That said, such a change may fall outside the remit of the Garden team; it
may be a platform wide change that involves changes to the stemcell.

On 23 September 2015 at 13:28, Guillaume Berche <bercheg(a)gmail.com> wrote:

Chris, thanks for bringing up this important security topic.

In terms of secrets an app is handling and carrying, I'd think its code
has generally limited sensitivity (e.g credentials or API key secrets are
rather stored in env vars). I'd expect memory to be much more sensitive
(e.g. holding user data), as well as state handed over to data services (12
factor apps are unlikely to store much state on their ephemeral file
system).

So related to your question about securely wipping data upon app instance
deletion, it may be interesting to consider secure RAM wiping when an app
container exits (sometimes killed by the oomkiller leaving few opportunity
for the app itself to wipe out RAM before exit). See related discussions in
[1] [2] [3] [4]. Quickly searching the bosh stemcell builder, and bosh
tracker I could not find mention of gresec or pax linux kernel
packages/patches that could strengthen RAM wiping after an app instance
exits.

Will, do you know if is there plans to tackle such kernel hardening ?

Related to secrets stored on disk in data services (p-mysql, p-redis), the
services should be designed to not provide access to previous deleted
service instances when normally functionning. The secured data wiping might
be useful if ever the data service itself would get compromised so that an
attacker would not be able to access data from deleted service instances
after hand.

Guillaume.

[1]
http://security.stackexchange.com/questions/42179/is-there-any-linux-distro-or-kernel-patch-that-wipes-a-process-memory-space-afte
[2] https://github.com/coreos/bugs/issues/332#issuecomment-109293958
[3]
https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Sanitize_all_freed_memory
[4]
https://blog.docker.com/2013/08/containers-docker-how-secure-are-they/#other-kernel-security-features


On Thu, Sep 17, 2015 at 1:38 PM, Will Pragnell <wpragnell(a)pivotal.io>
wrote:

In Diego/Garden, container files are stored on btrfs subvolumes. When a
container is destroyed, the subvolume is removed with btrfs subvolume
delete. I don’t think this does anything particularly fancy, and I don’t
think it classifies as “secure deletion”.


On 17 September 2015 at 11:53, Chris K <christopherkugler2(a)yahoo.de>
wrote:

Hello again,

I'm sorry for having to revive this topic, but I'm still unaware about
the deletion process.

[... ] i believe with standard removal tools.
Could you please specify the term "standard removal tool". What's the
standard? Is standard just the deletion of the pointer pointing on files /
segments, or is secure deletion state of the art?
I'd be thankful for any reference on documentation regarding this topic.

Thanks in advance.

Cheers Chris


Re: Security group rules to allow HTTP communication between 2 apps deployed on CF

Naveen Asapu
 

I'm using cf version 6.12.1


Re: Security Question --- Securely wipe data on warden container removal / destruction???

Guillaume Berche
 

Chris, thanks for bringing up this important security topic.

In terms of secrets an app is handling and carrying, I'd think its code has
generally limited sensitivity (e.g credentials or API key secrets are
rather stored in env vars). I'd expect memory to be much more sensitive
(e.g. holding user data), as well as state handed over to data services (12
factor apps are unlikely to store much state on their ephemeral file
system).

So related to your question about securely wipping data upon app instance
deletion, it may be interesting to consider secure RAM wiping when an app
container exits (sometimes killed by the oomkiller leaving few opportunity
for the app itself to wipe out RAM before exit). See related discussions in
[1] [2] [3] [4]. Quickly searching the bosh stemcell builder, and bosh
tracker I could not find mention of gresec or pax linux kernel
packages/patches that could strengthen RAM wiping after an app instance
exits.

Will, do you know if is there plans to tackle such kernel hardening ?

Related to secrets stored on disk in data services (p-mysql, p-redis), the
services should be designed to not provide access to previous deleted
service instances when normally functionning. The secured data wiping might
be useful if ever the data service itself would get compromised so that an
attacker would not be able to access data from deleted service instances
after hand.

Guillaume.

[1]
http://security.stackexchange.com/questions/42179/is-there-any-linux-distro-or-kernel-patch-that-wipes-a-process-memory-space-afte
[2] https://github.com/coreos/bugs/issues/332#issuecomment-109293958
[3]
https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Sanitize_all_freed_memory
[4]
https://blog.docker.com/2013/08/containers-docker-how-secure-are-they/#other-kernel-security-features

On Thu, Sep 17, 2015 at 1:38 PM, Will Pragnell <wpragnell(a)pivotal.io> wrote:

In Diego/Garden, container files are stored on btrfs subvolumes. When a
container is destroyed, the subvolume is removed with btrfs subvolume
delete. I don’t think this does anything particularly fancy, and I don’t
think it classifies as “secure deletion”.


On 17 September 2015 at 11:53, Chris K <christopherkugler2(a)yahoo.de>
wrote:

Hello again,

I'm sorry for having to revive this topic, but I'm still unaware about
the deletion process.

[... ] i believe with standard removal tools.
Could you please specify the term "standard removal tool". What's the
standard? Is standard just the deletion of the pointer pointing on files /
segments, or is secure deletion state of the art?
I'd be thankful for any reference on documentation regarding this topic.

Thanks in advance.

Cheers Chris


Re: How to deploy a Web application using HTTPs

Juan Antonio Breña Moral <bren at juanantonio.info...>
 

@James,

who add the headers?

"x-forwarded-for":"CLIENT_REAL_IP, CLOUD_FOUNDRY_IP",
"x-forwarded-proto":"https"

the load balancer or the GoRouter?


Re: Security group rules to allow HTTP communication between 2 apps deployed on CF

Denilson Nastacio <dnastacio@...>
 

The message indicates this problem is unrelated to security groups. You
would get something like "host not found" instead of "connection refused".

Which version of CF are you using?
Can you curl a url from app2 at all?

On Wed, Sep 23, 2015, 3:27 AM Naveen Asapu <asapu.naveen(a)gmail.com> wrote:

Hi Matthew Sykes,

Actually I'm trying to monitor usage of app in bluemix. for that i'm using
cf-abacus in the example steps this command also there.

can u suggest how to monitor app usage using curl and cloudfoundary

--
Thanks
Naveen Asapu


Re: How to deploy a Web application using HTTPs

Juan Antonio Breña Moral <bren at juanantonio.info...>
 

Hi James,

Now, understood your technical explanation:

"the standard way to do this is to terminate SSL at a load balancer, which then forwards to the CF routing tier. the hop between the load balancer and the cf router may be done with SSL. the network path from gorouter to the DEA / Diego Cell backend is only supported with http today."

"app client ---HTTPS---> LB ---HTTPS---> GoRouter ---HTTP---> DEA/DiegoCell"

Cloud foundry supports SSL connections, but currently GoRouter only handle http.

I checked the idea and I noticed that when I deploy an application, the platform add the following http headers:

"x-forwarded-for":"CLIENT_REAL_IP, CLOUD_FOUNDRY_IP",
"x-forwarded-proto":"https"

So, if you only want to execute an API for example with https, it is necessary to filter with this header:

"x-forwarded-proto":"https" (The idea from Matthew Sykes)

I think that it is necessary to create another issue to add the support for http2 I checked, but if fails, the same reason:

https://github.com/jabrena/CloudFoundryLab/blob/master/Node_HelloWorld_http2/index.js


Re: Avoid some folder or files using the command cf push

Juan Antonio Breña Moral <bren at juanantonio.info...>
 

Many thanks for the info, I will check the file: .cfignore

http://docs.pivotal.io/pivotalcf/devguide/deploy-apps/prepare-to-deploy.html

Juan Antonio


Re: Avoid some folder or files using the command cf push

Chunhua Zhang <chzhang@...>
 

please ref to :
https://docs.cloudfoundry.org/devguide/deploy-apps/manifest.htmlHow cf push
Finds the Application

By default, cf push recursively pushes the contents of the current working
directory. Alternatively, you can provide a path using either a manifest or
a command line option.

- If the path is to a directory, cf push recursively pushes the contents
of that directory instead of the current working directory.
- If the path is to a file, cf push pushes only that file.

*Note*: If you want to push more than a single file, but not the entire
contents of a directory, consider using a .cfignore file to tell cf push what
to exclude.

2015-09-23 16:08 GMT+08:00 Juan Antonio Breña Moral <bren(a)juanantonio.info>:

Hi,

sometimes, I deploy applications using CLI with the command cf push. This
command uploads the content of a folder and it uses the manifest file. I
would like to know if exist some way in the manifest.yml or another file to
avoid uploading some folder.

For example, if any developer create Node.js Application, the folder
node_modules is not necessary to upload because Node.js buildpack is able
to read and download the required dependencies described in the file
package.json

Does exist some way to do it?

Many thanks in advance.

Juan Antonio
--
Thanks & Best Regards,
chunhua, zhang(张春华)
M: +86 187 5198 6615
Department: CONSULTING
Manager: Leon Cheng
IT issue? Mail to: ask(a)pivotal.io


Avoid some folder or files using the command cf push

Juan Antonio Breña Moral <bren at juanantonio.info...>
 

Hi,

sometimes, I deploy applications using CLI with the command cf push. This command uploads the content of a folder and it uses the manifest file. I would like to know if exist some way in the manifest.yml or another file to avoid uploading some folder.

For example, if any developer create Node.js Application, the folder node_modules is not necessary to upload because Node.js buildpack is able to read and download the required dependencies described in the file package.json

Does exist some way to do it?

Many thanks in advance.

Juan Antonio


Re: Security group rules to allow HTTP communication between 2 apps deployed on CF

Naveen Asapu
 

Hi Matthew Sykes,

Actually I'm trying to monitor usage of app in bluemix. for that i'm using cf-abacus in the example steps this command also there.

can u suggest how to monitor app usage using curl and cloudfoundary

--
Thanks
Naveen Asapu


Re: Removing support for v1 service brokers

Dieu Cao <dcao@...>
 

We've found NATS to be unstable under certain conditions, temporary network
interruptions or network instability, around the client reconnection logic.
We've seen that it could take anywhere from a few seconds to half an hour
to reconnect properly. We spent a fair amount of time investigating ways to
improve the reconnection logic and have made some improvements but believe
that it's best to work towards not having this dependency.
You can find more about this in the stories in this epic [1].

Mike, in addition to removing the NATS dependency, this will remove the
burden on the team, almost a weekly fight, in terms of maintaining
backwards compatibility for the v1 broker spec any time we work on adding
functionality to the service broker api.
I'll work with the team in the next couple of weeks on specific stories and
I'll link to it here.

[1] https://www.pivotaltracker.com/epic/show/1440790

On Tue, Sep 22, 2015 at 10:07 PM, Mike Youngstrom <youngm(a)gmail.com> wrote:

Thanks for the announcement.

To be clear is this announcement to cease support for the old v1 brokers
or is this to eliminate support for the v1 api in the CC? Does the v1 CC
code depend on NATS? None of my custom v1 brokers depend on NATS.

Mike

On Tue, Sep 22, 2015 at 6:01 PM, Dieu Cao <dcao(a)pivotal.io> wrote:

Hello all,

We plan to remove support for v1 service brokers in about 3 months, in a
cf-release following 12/31/2015.
We are working towards removing CF's dependency on NATS and the v1
service brokers are still dependent on NATS.
Please let me know if you have questions/concerns about this timeline.

I'll be working on verifying a set of steps that you can find here [1]
that document how to migrate your service broker from v1 to v2 and what is
required in order to persist user data and will get that posted to the
service broker api docs officially.

-Dieu
CF CAPI PM

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




Re: Error 400007: `stats_z1/0' is not running after update

iamflying
 

It frequently logs the message below. It seems not helpful.

{"timestamp":1442987404.9433253,"message":"collector.started","log_level":"info","source":"collector","data":{},"thread_id":70132569199380,"fiber_id":70132570371720,"process_id":19392,"file":"/var/vcap/packages/collector/lib/collector/config.rb","lineno":45,"method":"setup_logging"}

the only possible error message from the bosh debug log is
"ntp":{"message":"bad ntp server"}

But I don't think, it is related to the failure of stats_z1 updating.

I, [2015-09-23 04:55:59 #2392] [canary_update(stats_z1/0)] INFO --
DirectorJobRunner: Checking if stats_z1/0 has been updated after
63.333333333333336 seconds
D, [2015-09-23 04:55:59 #2392] [canary_update(stats_z1/0)] DEBUG --
DirectorJobRunner: SENT: agent.7d3452bd-679e-4a97-8514-63a373a54ffd
{"method":"get_state","arguments":[],"reply_to":"director.c5b97fc1-b972-47ec-9412-a83ad240823b.473fda64-6ac3-4a53-9ebc-321fc7eabd7a"}
D, [2015-09-23 04:55:59 #2392] [] DEBUG -- DirectorJobRunner: RECEIVED:
director.c5b97fc1-b972-47ec-9412-a83ad240823b.473fda64-6ac3-4a53-9ebc-321fc7eabd7a
{"value":{"properties":{"logging":{"max_log_file_size":""}},"job":{"name":"stats_z1","release":"","template":"fluentd","version":"4c71c87bbf0144428afacd470e2a5e32b91932fc","sha1":"b141c6037d429d732bf3d67f7b79f8d7d80aac5d","blobstore_id":"d8451d63-2e4f-4664-93a8-a77e5419621d","templates":[{"name":"fluentd","version":"4c71c87bbf0144428afacd470e2a5e32b91932fc","sha1":"b141c6037d429d732bf3d67f7b79f8d7d80aac5d","blobstore_id":"d8451d63-2e4f-4664-93a8-a77e5419621d"},{"name":"collector","version":"889b187e2f6adc453c61fd8f706525b60e4b85ed","sha1":"f5ae15a8fa2417bf984513e5c4269f8407a274dc","blobstore_id":"3eeb0166-a75c-49fb-9f28-c29788dbf64d"},{"name":"metron_agent","version":"e6df4c316b71af68dfc4ca476c8d1a4885e82f5b","sha1":"42b6d84ad9368eba0508015d780922a43a86047d","blobstore_id":"e578bfb0-9726-4754-87ae-b54c8940e41a"},{"name":"apaas_collector","version":"8808f0ae627a54706896a784dba47570c92e0c8b","sha1":"b9a63da925b40910445d592c70abcf4d23ffe84d","blobstore_id":"3e6fa71a-07f7-446a-96f4-3caceea02f2f"}]},"packages":{"apaas_collector":{"name":"apaas_collector","version":"f294704d51d4517e4df3d8417a3d7c71699bc04d.1","sha1":"5af77ceb01b7995926dbd4ad7481dcb7c3d94faf","blobstore_id":"fa0e96b9-71a6-4828-416e-dde3427a73a9"},"collector":{"name":"collector","version":"ba47450ce83b8f2249b75c79b38397db249df48b.1","sha1":"0bf8ee0d69b3f21cf1878a43a9616cb7e14f6f25","blobstore_id":"722a5455-f7f7-427d-7e8d-e562552857bc"},"common":{"name":"common","version":"99c756b71550530632e393f5189220f170a69647.1","sha1":"90159de912c9bfc71740324f431ddce1a5fede00","blobstore_id":"37be6f28-c340-4899-7fd3-3517606491bb"},"fluentd-0.12.13":{"name":"fluentd-0.12.13","version":"71d8decbba6c863bff6c325f1f8df621a91eb45f.1","sha1":"2bd32b3d3de59e5dbdd77021417359bb5754b1cf","blobstore_id":"7bc81ac6-7c24-4a94-74d1-bb9930b07751"},"metron_agent":{"name":"metron_agent","version":"997d87534f57cad148d56c5b8362b72e726424e4.1","sha1":"a21404c50562de75000d285a02cd43bf098bfdb9","blobstore_id":"6c7cf72c-9ace-40a1-4632-c27946bf631e"},"ruby-2.1.6":{"name":"ruby-2.1.6","version":"41d0100ffa4b21267bceef055bc84dc37527fa35.1","sha1":"8a9867197682cabf2bc784f71c4d904bc479c898","blobstore_id":"536bc527-3225-43f6-7aad-71f36addec80"}},"configuration_hash":"a73c7d06b0257746e95aaa2ca994c11629cbd324","networks":{"private_cf_subnet":{"cloud_properties":{"name":"random","net_id":"1e1c9aca-0b5a-4a8f-836a-54c18c21c9b9","security_groups":["az1_cf_management_secgroup_bosh_cf_ssh_cf2","az1_cf_management_secgroup_cf_private_cf2","az1_cf_management_secgroup_cf_public_cf2"]},"default":["dns","gateway"],"dns":["192.168.110.8","133.162.193.10","133.162.193.9","192.168.110.10"],"dns_record_name":"0.stats-z1.private-cf-subnet.cf-apaas.microbosh","gateway":"192.168.110.11","ip":"192.168.110.204","netmask":"255.255.255.0"}},"resource_pool":{"cloud_properties":{"instance_type":"S-1"},"name":"small_z1","stemcell":{"name":"bosh-openstack-kvm-ubuntu-trusty-go_agent","version":"2989"}},"deployment":"cf-apaas","index":0,"persistent_disk":0,"persistent_disk_pool":null,"rendered_templates_archive":{"sha1":"0ffd89fa41e02888c9f9b09c6af52ea58265a8ec","blobstore_id":"4bd01ae7-a69a-4fe5-932b-d98137585a3b"},"agent_id":"7d3452bd-679e-4a97-8514-63a373a54ffd","bosh_protocol":"1","job_state":"failing","vm":{"name":"vm-12d45510-096d-4b8b-9547-73ea5fda00c2"},"ntp":{"message":"bad
ntp server"}}}

On Wed, Sep 23, 2015 at 5:13 PM, Amit Gupta <agupta(a)pivotal.io> wrote:

Please check the file collector/collector.log, it's in a subdirectory of
the unpacked log tarball.

On Wed, Sep 23, 2015 at 12:01 AM, Guangcai Wang <guangcai.wang(a)gmail.com>
wrote:

Actually, I checked the two files in status_z1 job VM. I did not find any
clues. Attached for reference.

On Wed, Sep 23, 2015 at 4:54 PM, Amit Gupta <agupta(a)pivotal.io> wrote:

If you do "bosh logs stats_z1 0 --job" you will get a tarball of all
the logs for the relevant processes running on the stats_z1/0 VM. You will
likely find some error messages in the collectors stdout or stderr logs.

On Tue, Sep 22, 2015 at 11:30 PM, Guangcai Wang <guangcai.wang(a)gmail.com
wrote:
It does not help.

I always see the "collector" process bouncing between "running" and
"does not exit" when I use "monit summary" in a while loop.

Who knows how to get the real error when the "collector" process is not
failed? Thanks.

On Wed, Sep 23, 2015 at 4:11 PM, Tony <Tonyl(a)fast.au.fujitsu.com>
wrote:

My approach is to login on the stats vm and sudo, then
run "monit status" and restart the failed processes or simply restart
all
processes by running "monit restart all"

wait for a while(5~10 minutes at most)
If there is still some failed process, e.g. collector
then run ps -ef | grep collector
and kill the processes in the list(may be you need to run kill -9
sometimes)

then "monit restart all"

Normally, it will fix the issue "Failed: `XXX' is not running after
update"



--
View this message in context:
http://cf-dev.70369.x6.nabble.com/cf-dev-Error-400007-stats-z1-0-is-not-running-after-update-tp1901p1902.html
Sent from the CF Dev mailing list archive at Nabble.com.


Re: Error 400007: `stats_z1/0' is not running after update

Amit Kumar Gupta
 

Please check the file collector/collector.log, it's in a subdirectory of
the unpacked log tarball.

On Wed, Sep 23, 2015 at 12:01 AM, Guangcai Wang <guangcai.wang(a)gmail.com>
wrote:

Actually, I checked the two files in status_z1 job VM. I did not find any
clues. Attached for reference.

On Wed, Sep 23, 2015 at 4:54 PM, Amit Gupta <agupta(a)pivotal.io> wrote:

If you do "bosh logs stats_z1 0 --job" you will get a tarball of all the
logs for the relevant processes running on the stats_z1/0 VM. You will
likely find some error messages in the collectors stdout or stderr logs.

On Tue, Sep 22, 2015 at 11:30 PM, Guangcai Wang <guangcai.wang(a)gmail.com>
wrote:

It does not help.

I always see the "collector" process bouncing between "running" and
"does not exit" when I use "monit summary" in a while loop.

Who knows how to get the real error when the "collector" process is not
failed? Thanks.

On Wed, Sep 23, 2015 at 4:11 PM, Tony <Tonyl(a)fast.au.fujitsu.com> wrote:

My approach is to login on the stats vm and sudo, then
run "monit status" and restart the failed processes or simply restart
all
processes by running "monit restart all"

wait for a while(5~10 minutes at most)
If there is still some failed process, e.g. collector
then run ps -ef | grep collector
and kill the processes in the list(may be you need to run kill -9
sometimes)

then "monit restart all"

Normally, it will fix the issue "Failed: `XXX' is not running after
update"



--
View this message in context:
http://cf-dev.70369.x6.nabble.com/cf-dev-Error-400007-stats-z1-0-is-not-running-after-update-tp1901p1902.html
Sent from the CF Dev mailing list archive at Nabble.com.

7481 - 7500 of 9425