|
Re: PHP extension 'gettext' doesn't work?
toggle quoted message
Show quoted text
On Fri, Oct 23, 2015 at 8:44 PM, Daniel Mikusa <dmikusa(a)pivotal.io> wrote: OK, so really sorry this took me so long to investigate, but I think I've
found the issue. Ubuntu has these "language packs" and in order for
gettext to work the system has to have that language pack installed.
https://help.ubuntu.com/community/Locale
You can see what language packs are installed on your system by running
`locale -a`. I was testing this on an Ubuntu docker image and the only way
I could make it work was to install the language pack. As soon as I did
that and restarted Apache HTTPD, I started to get my translations.
Running `locale -a` on the `cflinuxfs2` docker image shows that only these
language packs are installed.
```
$ locale -a
C
C.UTF-8
POSIX
en_US.utf8
```
When I setup a test app and run it on CF, I get the same results. Only
`en_US.utf8` works.
Unfortunately, I'm not sure how you could go about installing more
language packs into the stack for CF. It seems that you have to install
them via `apt-get` and that simply won't work, since there's no root access
in the container. If anyone has any ideas about how to install more
language packs, let me know.
My only suggestion would be to use the intl extension instead of gettext.
I believe it offers similar functionality, although it's not something I've
done myself.
Hope that helps!
Dan
On Fri, Oct 9, 2015 at 4:47 AM, Hiroaki Ukaji <dt3snow.w(a)gmail.com> wrote:
Hi.
Thanks for your confirmation.
I'm glad that it seems like my intention is being conveyed.
(I'm sorry about my poor English...)
I'm looking forward to hearing a second look from you.
Thanks.
Hiroaki UKAJI
--
View this message in context:
http://cf-dev.70369.x6.nabble.com/cf-dev-PHP-extension-gettext-doesn-t-work-tp1984p2178.html
Sent from the CF Dev mailing list archive at Nabble.com.
|
|
|
Re: Disable HTTP transport
See this link. http://support.run.pivotal.io/entries/82035305-How-do-I-force-my-users-to-use-HTTPS-Dan On Sun, Oct 25, 2015 at 5:01 PM, Krzysztof Wilk <chris.m.wilk(a)gmail.com> wrote: Hello,
How can I disable HTTP transport of my Spring application deployed to
Pivotal Web Services?
I would like my application be available only through HTTPS transport.
When I run my application in "local mode' (e.g. in Tomcat servlet
container) disabling HTTP transport is simple. It is sufficient to disable
HTTP listener and enable HTTPS listener.
How can I achieve similar effect in Cloud Foundry PWS?
I have skimmed the following security description but found none:
https://docs.cloudfoundry.org/concepts/security.html
I would be grateful for pointing me to relevant documentation.
Best regards,
Krzysztof
|
|
|
mono apps are failed to start in CF
Balaramaraju JLSP <balaramaraju@...>
Hi All, I tried to push .net application [using https://github.com/cloudfoundry-community/.net-buildpack] to pivotal CF but is failing with following error. earlier same application used to run with out any issue. 2015-10-26T11:53:38.000+00:00 [STG] ERR No start command detected; command must be provided at runtime 2015-10-26T11:53:59.000+00:00 [STG] OUT Uploaded droplet (61.4M) 2015-10-26T11:54:07.000+00:00 [APP] ERR Usage: /tmp/lifecycle/launcher <app directory> <start command> <metadata> 2015-10-26T11:54:07.000+00:00 [APP] OUT Exit status 1 but same application working with my local cloud foundry (installed 3 months back). I couldn't follow recent changes in CF. dose any input commands changed recently ? *cf push command * cf push OwinFhir -b https://github.com/cloudfoundry-community/.net-buildpack-m 256M *cf push log* Creating app OwinFhir in org MONO / space development as ... OK Creating route owinfhir.cfapps.io... OK Binding owinfhir.cfapps.io to OwinFhir... OK Uploading OwinFhir... Uploading app files from: D:\Cloud\Git\cf_nise_installer\OwinSamp Uploading 361.7K, 14 files OK Starting app OwinFhir in org MONO / space development as OK Creating container Successfully created container Downloading app package... Downloaded app package (1.2M) Downloading buildpacks ( https://github.com/cloudfoundry-community/.net-buildpack)... Downloaded buildpacks Staging... -----> Downloading Mono runtime 3.4.0_full from http://ci-labs-buildpack-downloads.s3.amazonaws.com/mono/lucid/x86_64/mono-3.4.0_full.tar.gz(1.9s) expanding Mono to vendor/mono (1.6s) -----> Installing Mozilla certificate data to .config/.mono/certs (1.3s) -----> Downloading Procfile container current.linux-amd64 from https://godist.herokuapp.com/projects/ddollar/forego/releases/current/linux-amd64/forego(1.0s) -----> Patching Procfile to rename web: to _web: (0.0s) -----> Preparing AppSettingsAutoReconfiguration.exe (0.0s) *No start command detected; command must be provided at runtime* Exit status 0 Staging complete Uploading droplet, build artifacts cache... Uploading droplet... Uploading build artifacts cache... Uploaded build artifacts cache (59.7M) Uploaded droplet (61.4M) Uploading complete 0 of 1 instances running, 1 starting 0 of 1 instances running, 1 starting 0 of 1 instances running 0 of 1 instances running 0 of 1 instances running Thanks J L S P Balaramaraju
|
|
|
Re: [abacus] Abacus v0.0.2-rc.2 available
Christopher B Ferris <chrisfer@...>
toggle quoted message
Show quoted text
----- Original message -----
From: Jean-Sebastien Delfino <jsdelfino@...>
To: cf-dev@...
Cc:
Subject: [cf-dev] [abacus] Abacus v0.0.2-rc.2 available
Date: Fri, Oct 23, 2015 10:03 PM
Â
I'm happy to announce the availability of CF Abacus v0.0.2-rc.2 (incubating).
Â
Abacus provides usage metering and aggregation for Cloud Foundry services and app runtimes.
Â
This release candidate is for the interested members of the community to get a chance to try Abacus and ask any questions or submit issues and pull requests in the next few days before we cut a final v0.0.2 release.
Â
The pre-release Git tag and release notes can be found on Github:
Â
The CI build can be found on Travis CI:
Â
The npm modules can be found on npmjs:
Â
Please feel free to ask any questions about this pre-release of Abacus on this list.
Issues or -- even better -- pull requests are welcome on Github as well!
Â
For more info on Abacus please visit:
Â
Thanks! Â
Â
|
|
|
Re: CF-RELEASE v202 UPLOAD ERROR
toggle quoted message
Show quoted text
On Mon, Oct 26, 2015 at 12:16 AM, Parthiban Annadurai <senjiparthi(a)gmail.com wrote: Actually, sorry for the previous mails. Since, I have started with CF v202
release and it thrown some error so am switched to CF v210. But, again
because of some rollback issues we went back with CF v202 itself.
Currently, bosh deploy throws the following, I have attached the Debug Logs
too. Thanks.
Director task 310
Started unknown
Started unknown > Binding deployment. Done (00:00:00)
Started preparing deployment
Started preparing deployment > Binding releases. Done (00:00:00)
Started preparing deployment > Binding existing deployment. Done
(00:00:01)
Started preparing deployment > Binding resource pools. Done (00:00:00)
Started preparing deployment > Binding stemcells. Done (00:00:00)
Started preparing deployment > Binding templates. Done (00:00:00)
Started preparing deployment > Binding properties. Done (00:00:00)
Started preparing deployment > Binding unallocated VMs. Done (00:00:00)
Started preparing deployment > Binding instance networks. Done (00:00:00)
Started preparing package compilation > Finding packages to compile.
Done (00:00:00)
Started preparing dns > Binding DNS. Done (00:00:00)
Started creating bound missing vms
Started creating bound missing vms > medium_z1/0
Started creating bound missing vms > medium_z1/1
Started creating bound missing vms > router_z2/0. Done (00:01:09)
Failed creating bound missing vms > medium_z1/1: Timed out sending
`get_task' to f4dfe4e9-c897-4b9b-b7c7-63a908c10190 after 45 seconds
(00:04:03)
Done creating bound missing vms > medium_z1/0 (00:05:14)
Failed creating bound missing vms (00:05:14)
Error 450002: Timed out sending `get_task' to
f4dfe4e9-c897-4b9b-b7c7-63a908c10190 after 45 seconds
On 24 October 2015 at 06:40, Parthiban Annadurai <senjiparthi(a)gmail.com>
wrote:
Thanks Amit for your suggestions. Let you know after regenerating the
manifest again.
On 24 October 2015 at 11:47, Amit Gupta <agupta(a)pivotal.io> wrote:
Regenerate your manifest.
On Fri, Oct 23, 2015 at 10:49 PM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:
Okay Amit. Yaa, I changed my CF Version from v202 to v210. Could you
share that metron_agent.deployment property of the manifest which is
required in v210? Thanks.
On 24 October 2015 at 10:57, Amit Gupta <agupta(a)pivotal.io> wrote:
Parthiban,
Your log.txt shows that you're using cf-release version 210, but your
subject message says you're trying v202. Perhaps you've checked out v202
of cf-release and used the spiff tooling to generate the manifests from
that version. v202 doesn't include the metron_agent.deployment property in
its manifest, which is required in v210.
On Fri, Oct 23, 2015 at 10:07 PM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:
I have created the manifest file using SPIFF tool. Any issues with
that?
On 23 October 2015 at 20:49, Amit Gupta <agupta(a)pivotal.io> wrote:
How did you create your manifest in the first place?
On Fri, Oct 23, 2015 at 8:17 AM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:
After trying the suggestions, now its throws the following error,
Started preparing configuration > Binding configuration. Failed:
Error filling in template `metron_agent.json.erb' for `ha_proxy_z1/0' (line
5: Can't find property `["metron_agent.deployment"]') (00:00:00)
Error 100: Error filling in template `metron_agent.json.erb' for
`ha_proxy_z1/0' (line 5: Can't find property `["metron_agent.deployment"]')
Could anyone on this??
On 22 October 2015 at 18:08, Amit Gupta <agupta(a)pivotal.io> wrote:
Try running "bosh cck" and recreating VMs from last known apply
spec. You should also make sure that the IPs you're allocating to your
jobs are accessible from the BOSH director VM.
On Thu, Oct 22, 2015 at 5:27 AM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:
Yaa sure Amit. I have attached both the files with this mail.
Could you please? Thanks.
On 21 October 2015 at 19:49, Amit Gupta <agupta(a)pivotal.io>
wrote:
Can you share the output of "bosh vms" and "bosh task 51
--debug". It's preferable if you copy the terminal outputs and paste them
to Gists or Pastebins and share the links.
On Tue, Oct 20, 2015 at 6:18 AM, James Bayer <jbayer(a)pivotal.io>
wrote:
sometimes a message like that is due to networking issues. does
the bosh director and the VM it is creating have an available network path
to reach each other? sometimes ssh'ing in to the VM that is identified can
yield more debug clues.
On Tue, Oct 20, 2015 at 5:09 AM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:
Thanks Bharath and Amit for the helpful solutions. I have
surpassed that error. Now, bosh deploy strucks like in attached image.
Could you anyone please?
Regards
Parthiban A
On 20 October 2015 at 11:57, Amit Gupta <agupta(a)pivotal.io>
wrote:
Bharath, I think you mean to increase the *disk* size on the
compilation VMs, not the memory size.
Parthiban, the error message is happening during compiling,
saying "No space left on device". This means your compilation VMs are
running out of space on disk. This means you need to increase the
allocated disk for your compilation VMs. In the "compilation" section of
your deployment manifest, you can specify "cloud_properties". This is
where you will specify disk size. These "cloud_properties" look the same
as the could_properties specified for a resource pool. Depending on your
IaaS, the structure of the cloud_properties section differs. See here:
https://bosh.io/docs/deployment-manifest.html#resource-pools-cloud-properties
On Mon, Oct 19, 2015 at 11:13 PM, Bharath Posa <
bharathp(a)vedams.com> wrote:
hi parthiban
It seems you are running out of space in your vm in which
you are compiling . try to increase the size of memory in your compilation
vm .
regards
Bharath
On Mon, Oct 19, 2015 at 7:39 PM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:
Hello All,
Thanks All for the helpful suggestions.
Actually, now we r facing the following issue while kicking bosh deploy,
Done compiling packages >
nats/d3a1f853f4980682ed8b48e4706b7280e2b7ce0e (00:01:07)
Failed compiling packages >
buildpack_php/9c72be716ab8629d7e6feed43012d1d671720157: Action Failed
get_task: Task aba21e6a-2031-4a69-5b72-f238ecd07051 result: Compiling
package buildpack_php: Compressing compiled package: Shelling out to tar:
Running command: 'tar czf
/var/vcap/data/tmp/bosh-platform-disk-TarballCompressor-CompressFilesInDir762165297
-C
/var/vcap/data/packages/buildpack_php/9c72be716ab8629d7e6feed43012d1d671720157.1-
.', stdout: '', stderr: '
gzip: stdout: No space left on device
': signal: broken pipe (00:02:41)
Failed compiling packages (00:02:41)
Error 450001: Action Failed get_task: Task
aba21e6a-2031-4a69-5b72-f238ecd07051 result: Compiling package
buildpack_php: Compressing compiled package: Shelling out to tar: Running
command: 'tar czf
/var/vcap/data/tmp/bosh-platform-disk-TarballCompressor-CompressFilesInDir762165297
-C
/var/vcap/data/packages/buildpack_php/9c72be716ab8629d7e6feed43012d1d671720157.1-
.', stdout: '', stderr: '
gzip: stdout: No space left on device
': signal: broken pipe
Could Anyone on this issue?
Regards
Parthiban A
On 19 October 2015 at 14:30, Bharath Posa <
bharathp(a)vedams.com> wrote:
Hi partiban
can u do a checksum of the tar file .
it should come like this *sha1:
b6f596eaff4c7af21cc18a52ef97e19debb00403*
example:
*sha1sum {file}*
regards
Bharath
On Mon, Oct 19, 2015 at 1:12 PM, Eric Poelke <
epoelke(a)gmail.com> wrote:
You actually do not need to download it. if you just run
--
`bosh upload release
https://bosh.io/d/github.com/cloudfoundry/cf-release?v=202`
<https://bosh.io/d/github.com/cloudfoundry/cf-release?v=202>
The director will pull in the release directly from
bosh.io.
--
Thank you,
James Bayer
|
|
|
Re: CF-RELEASE v202 UPLOAD ERROR
Parthiban Annadurai <senjiparthi@...>
Actually, sorry for the previous mails. Since, I have started with CF v202 release and it thrown some error so am switched to CF v210. But, again because of some rollback issues we went back with CF v202 itself. Currently, bosh deploy throws the following, I have attached the Debug Logs too. Thanks. Director task 310 Started unknown Started unknown > Binding deployment. Done (00:00:00) Started preparing deployment Started preparing deployment > Binding releases. Done (00:00:00) Started preparing deployment > Binding existing deployment. Done (00:00:01) Started preparing deployment > Binding resource pools. Done (00:00:00) Started preparing deployment > Binding stemcells. Done (00:00:00) Started preparing deployment > Binding templates. Done (00:00:00) Started preparing deployment > Binding properties. Done (00:00:00) Started preparing deployment > Binding unallocated VMs. Done (00:00:00) Started preparing deployment > Binding instance networks. Done (00:00:00) Started preparing package compilation > Finding packages to compile. Done (00:00:00) Started preparing dns > Binding DNS. Done (00:00:00) Started creating bound missing vms Started creating bound missing vms > medium_z1/0 Started creating bound missing vms > medium_z1/1 Started creating bound missing vms > router_z2/0. Done (00:01:09) Failed creating bound missing vms > medium_z1/1: Timed out sending `get_task' to f4dfe4e9-c897-4b9b-b7c7-63a908c10190 after 45 seconds (00:04:03) Done creating bound missing vms > medium_z1/0 (00:05:14) Failed creating bound missing vms (00:05:14) Error 450002: Timed out sending `get_task' to f4dfe4e9-c897-4b9b-b7c7-63a908c10190 after 45 seconds On 24 October 2015 at 06:40, Parthiban Annadurai <senjiparthi(a)gmail.com> wrote: Thanks Amit for your suggestions. Let you know after regenerating the
manifest again.
On 24 October 2015 at 11:47, Amit Gupta <agupta(a)pivotal.io> wrote:
Regenerate your manifest.
On Fri, Oct 23, 2015 at 10:49 PM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:
Okay Amit. Yaa, I changed my CF Version from v202 to v210. Could you
share that metron_agent.deployment property of the manifest which is
required in v210? Thanks.
On 24 October 2015 at 10:57, Amit Gupta <agupta(a)pivotal.io> wrote:
Parthiban,
Your log.txt shows that you're using cf-release version 210, but your
subject message says you're trying v202. Perhaps you've checked out v202
of cf-release and used the spiff tooling to generate the manifests from
that version. v202 doesn't include the metron_agent.deployment property in
its manifest, which is required in v210.
On Fri, Oct 23, 2015 at 10:07 PM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:
I have created the manifest file using SPIFF tool. Any issues with
that?
On 23 October 2015 at 20:49, Amit Gupta <agupta(a)pivotal.io> wrote:
How did you create your manifest in the first place?
On Fri, Oct 23, 2015 at 8:17 AM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:
After trying the suggestions, now its throws the following error,
Started preparing configuration > Binding configuration. Failed:
Error filling in template `metron_agent.json.erb' for `ha_proxy_z1/0' (line
5: Can't find property `["metron_agent.deployment"]') (00:00:00)
Error 100: Error filling in template `metron_agent.json.erb' for
`ha_proxy_z1/0' (line 5: Can't find property `["metron_agent.deployment"]')
Could anyone on this??
On 22 October 2015 at 18:08, Amit Gupta <agupta(a)pivotal.io> wrote:
Try running "bosh cck" and recreating VMs from last known apply
spec. You should also make sure that the IPs you're allocating to your
jobs are accessible from the BOSH director VM.
On Thu, Oct 22, 2015 at 5:27 AM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:
Yaa sure Amit. I have attached both the files with this mail.
Could you please? Thanks.
On 21 October 2015 at 19:49, Amit Gupta <agupta(a)pivotal.io> wrote:
Can you share the output of "bosh vms" and "bosh task 51
--debug". It's preferable if you copy the terminal outputs and paste them
to Gists or Pastebins and share the links.
On Tue, Oct 20, 2015 at 6:18 AM, James Bayer <jbayer(a)pivotal.io>
wrote:
sometimes a message like that is due to networking issues. does
the bosh director and the VM it is creating have an available network path
to reach each other? sometimes ssh'ing in to the VM that is identified can
yield more debug clues.
On Tue, Oct 20, 2015 at 5:09 AM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:
Thanks Bharath and Amit for the helpful solutions. I have
surpassed that error. Now, bosh deploy strucks like in attached image.
Could you anyone please?
Regards
Parthiban A
On 20 October 2015 at 11:57, Amit Gupta <agupta(a)pivotal.io>
wrote:
Bharath, I think you mean to increase the *disk* size on the
compilation VMs, not the memory size.
Parthiban, the error message is happening during compiling,
saying "No space left on device". This means your compilation VMs are
running out of space on disk. This means you need to increase the
allocated disk for your compilation VMs. In the "compilation" section of
your deployment manifest, you can specify "cloud_properties". This is
where you will specify disk size. These "cloud_properties" look the same
as the could_properties specified for a resource pool. Depending on your
IaaS, the structure of the cloud_properties section differs. See here:
https://bosh.io/docs/deployment-manifest.html#resource-pools-cloud-properties
On Mon, Oct 19, 2015 at 11:13 PM, Bharath Posa <
bharathp(a)vedams.com> wrote:
hi parthiban
It seems you are running out of space in your vm in which you
are compiling . try to increase the size of memory in your compilation vm .
regards
Bharath
On Mon, Oct 19, 2015 at 7:39 PM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:
Hello All,
Thanks All for the helpful suggestions.
Actually, now we r facing the following issue while kicking bosh deploy,
Done compiling packages >
nats/d3a1f853f4980682ed8b48e4706b7280e2b7ce0e (00:01:07)
Failed compiling packages >
buildpack_php/9c72be716ab8629d7e6feed43012d1d671720157: Action Failed
get_task: Task aba21e6a-2031-4a69-5b72-f238ecd07051 result: Compiling
package buildpack_php: Compressing compiled package: Shelling out to tar:
Running command: 'tar czf
/var/vcap/data/tmp/bosh-platform-disk-TarballCompressor-CompressFilesInDir762165297
-C
/var/vcap/data/packages/buildpack_php/9c72be716ab8629d7e6feed43012d1d671720157.1-
.', stdout: '', stderr: '
gzip: stdout: No space left on device
': signal: broken pipe (00:02:41)
Failed compiling packages (00:02:41)
Error 450001: Action Failed get_task: Task
aba21e6a-2031-4a69-5b72-f238ecd07051 result: Compiling package
buildpack_php: Compressing compiled package: Shelling out to tar: Running
command: 'tar czf
/var/vcap/data/tmp/bosh-platform-disk-TarballCompressor-CompressFilesInDir762165297
-C
/var/vcap/data/packages/buildpack_php/9c72be716ab8629d7e6feed43012d1d671720157.1-
.', stdout: '', stderr: '
gzip: stdout: No space left on device
': signal: broken pipe
Could Anyone on this issue?
Regards
Parthiban A
On 19 October 2015 at 14:30, Bharath Posa <
bharathp(a)vedams.com> wrote:
Hi partiban
can u do a checksum of the tar file .
it should come like this *sha1:
b6f596eaff4c7af21cc18a52ef97e19debb00403*
example:
*sha1sum {file}*
regards
Bharath
On Mon, Oct 19, 2015 at 1:12 PM, Eric Poelke <
epoelke(a)gmail.com> wrote:
You actually do not need to download it. if you just run
--
`bosh upload release
https://bosh.io/d/github.com/cloudfoundry/cf-release?v=202`
<https://bosh.io/d/github.com/cloudfoundry/cf-release?v=202>
The director will pull in the release directly from
bosh.io.
--
Thank you,
James Bayer
|
|
|
Delivery failure (sfpj@listserve.uwec.edu)
Your message has encountered delivery problems
to the following recipient(s):
sfpj
(Was addressed to sfpj(a)listserve.uwec.edu)
Delivery failed
The message originator is not a list member
in [115.160.242.246]) by listserve.uwec.edu
(Rockliffe SMTPRA 9.4.1) with ESMTP id <B0061296225(a)listserve.uwec.edu> =
for <sfpj(a)listserve.uwec.edu>;
Mon, 26 Oct 2015 00:21:45 -0500
Message-ID: <B0061296225(a)listserve.uwec.edu>
From: cf-dev(a)lists.cloudfoundry.org
To: sfpj(a)listserve.uwec.edu
Subject: Mail System Error - Returned Mail
Date: Mon, 26 Oct 2015 10:51:32 +0530
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary=3D"----=3D_NextPart_000_0009_B71E4C50.64693E54"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
|
|
|
How to restrict permissions on apps filesystem to protect against remote code upload ?
Guillaume Berche
Hi, Following up onto this thread initiated last year on vcap-dev: https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/b3690cd8-87cb-4deb-a33c-06e069e46800%40cloudfoundry.org?utm_medium=email&utm_source=footerNow that user namespaces are supported by garden, and that diego integrated them as unprivileged containers, I'm wondering if a buildpack compile script running in unprivileged mode (i.e. within user namespace) would be able to create namespaced users and groups (say user=apache-owner part of group=vcap) and to assign file ownership to user apache-owner, only granting user vcap read+execution permissions to the files ? I yet have to try this into diego. Anyone tried it ? If not, can this use-case be considered ? Searching on the garden docs [0] and tracker, I could only find the following apparently related stories [1] and [2] I see diego is currently parsing the user mentionned into the image, but does not seem making use of it [3]. Maybe something that could be mentionned into [4] ? Thanks in advance, Guillaume. [0] https://godoc.org/github.com/cloudfoundry-incubator/garden[1] https://www.pivotaltracker.com/story/show/101501294 I can create an unprivileged container in a user namespace [2] https://www.pivotaltracker.com/story/show/101501296 File permissions are correct in unprivileged containers [3] https://github.com/cloudfoundry-incubator/docker_app_lifecycle/blob/8205117b94734a52d1f31bda6fd66168d8fbdc66/builder/builder_runner.go#L93[4] https://github.com/cloudfoundry-incubator/diego-design-notes/blob/master/docker-support.md#docker-deltasOn Mon, Dec 8, 2014 at 4:18 PM, James Bayer wrote: user namespaces were recently added to garden, so it's likely when diego
is incorporated we'll have those features.
there are no short-term plans to use different types of users in the
staging process afaik, but your suggestions seem reasonable. dieu, mark
kropf and onsi should consider them.
On Wed, Dec 10, 2014 at 5:05 PM, James Bayer <jbayer(a)pivotal.io> wrote: we haven't decided which user to use to run the docker images quite yet.
some docker images will assume a particular user, so just using "vcap" may
exclude some of those from working.
in order to be root, we'd have to be confident that user namespaces
provide adequate security and isolation. user namespaces were recently
added to garden and diego has a story to investigate being able to use root
[1], but i appreciate the importance of your comments on running processes
with least privilege. we'll sort this out as we get closer to running apps
with diego in production.
[1] https://www.pivotaltracker.com/story/show/78606184
On Wed, Dec 10, 2014 at 2:58 AM, Guillaume Berche <bercheg(a)gmail.com>
wrote:
Actually, rather than " use different types of users in the staging
process", this would rather be granting sudo access to the vcap user to be
able to create other users, and chown files to these new users.
Alternatively, have the staging process run as a container "root" user with
permissions to do the previous actions and set default user to run (similar
to USER in docker file [7] ).
By the way, I'm curious how the cf push <docker_image> upcoming feature
will run the docker top process: will that be with run with root (id=0) as
it defaults in docker [7] (or specified USER in docker file) or will it
remains vcap (which would require file permissions on the docker image to
allow world read/execute permissions) ?
[7] https://docs.docker.com/reference/builder/#user
[8] https://docs.docker.com/reference/run/#user
Thanks,
Guillaume.
On Mon, Dec 8, 2014 at 4:18 PM, James Bayer wrote:
user namespaces were recently added to garden, so it's likely when diego
is incorporated we'll have those features.
there are no short-term plans to use different types of users in the
staging process afaik, but your suggestions seem reasonable. dieu, mark
kropf and onsi should consider them.
On Mon, Dec 8, 2014 at 6:25 AM, Guillaume Berche wrote:
Hi,
It's sometimes documented as a best practice [1] [2] to restrict the
permissions on an app executable content in order to limit the cases where
a vulnerable app would allow a remote attacker to upload code on the file
system and use the container resources to run arbitrary code and perform
harm.
In particular, I'm asked whether in the php buildpack (or my custom
fork), I could setup os-level permissions in the buildpack to prevent write
permissions at runtime on potentially executable filesystem locations, e.g.
droplet files to be owned by another user than vcap (say "vcap-stager" that
would be in the vcap group) with read,execute permissions given to vcap
group but no write permissions.
On CloudFoundry, I understand that both the buildpack and the droplet
run with the vcap user (commands run with container-info-buildpack [5]),
with no other user available, nor sudo access to file ownership
$ id vcap
uid=20156(vcap) gid=20156(vcap) groups=20156(vcap)
$ groups vcap
vcap : vcap
$ ls -al /home/vcap
drwxr-xr-x 5 vcap vcap 4096 Dec 8 13:04 .
drwxr-xr-x 3 root root 4096 Dec 8 12:57 ..
$ umask
0077
What would then be best practices on cloudfoundry to prevent remote
code injection from vulnerable apps?
Any plans to support root user during staging, so that custom users
can added at staging time, and secure that with user namespaces similar to
what docker is planning [6] ?
Thanks,
Guillaume.
[1]
http://httpd.apache.org/docs/current/en/misc/security_tips.html#serverroot
[2] http://www.w3.org/Security/faq/wwwsf3.html
[3]
http://docs.cloudfoundry.org/devguide/deploy-apps/environment-variable.html#USER
[4]
https://github.com/cloudfoundry/bosh/blob/master/stemcell_builder/stages/bosh_users/assets/sudoers
[5] https://github.com/cloudfoundry-community/container-info-buildpack
[6]
https://docs.docker.com/articles/security/#docker-daemon-attack-surface
--
You received this message because you are subscribed to the Google
Groups "Cloud Foundry Developers" group.
To view this discussion on the web visit
https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/b3690cd8-87cb-4deb-a33c-06e069e46800%40cloudfoundry.org
<https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/b3690cd8-87cb-4deb-a33c-06e069e46800%40cloudfoundry.org?utm_medium=email&utm_source=footer>
.
To unsubscribe from this group and stop receiving emails from it, send
an email to vcap-dev+unsubscribe(a)cloudfoundry.org.
--
Thank you,
James Bayer
--
You received this message because you are subscribed to a topic in the
Google Groups "Cloud Foundry Developers" group.
To view this discussion on the web visit
https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAB%3Dt-sVYk4DWx9N8ELCSB1Grr3nyyia4j3hNpo4tcaC7Kvoomw%40mail.gmail.com
<https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAB%3Dt-sVYk4DWx9N8ELCSB1Grr3nyyia4j3hNpo4tcaC7Kvoomw%40mail.gmail.com?utm_medium=email&utm_source=footer>
.
-- You received this message because you are subscribed to the Google Groups
"Cloud Foundry Developers" group.
To view this discussion on the web visit
https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/67dc7b50-b3e8-4d2e-b1c6-5e8610727719%40cloudfoundry.org
<https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/67dc7b50-b3e8-4d2e-b1c6-5e8610727719%40cloudfoundry.org?utm_medium=email&utm_source=footer>
.
To unsubscribe from this group and stop receiving emails from it, send an
email to vcap-dev+unsubscribe(a)cloudfoundry.org.
--
Thank you,
James Bayer
--
You received this message because you are subscribed to a topic in the
Google Groups "Cloud Foundry Developers" group.
To view this discussion on the web visit
https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAB%3Dt-sWfSZ-iGDO53ae0%3D-BQV6g4T3v%2B7HDDTMqbvTRgc8DRXg%40mail.gmail.com
<https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAB%3Dt-sWfSZ-iGDO53ae0%3D-BQV6g4T3v%2B7HDDTMqbvTRgc8DRXg%40mail.gmail.com?utm_medium=email&utm_source=footer>
.
|
|
|
Re: Buildpacks PMC - 2015-10-12 Notes
Guillaume Berche
Thanks Mike for your response and sorry for delay in following up. Responses inline. On Wed, Oct 14, 2015 at 3:18 PM, Mike Dalessio <mdalessio(a)pivotal.io> wrote:
Related to the architecture epic, What's the outcome of this epic and the
general direction the buildpack team is taking for pluggeable staging
pipeline ?
We're having some discussions now as to next steps. Ideally I'd like to
identify a track of feature work that will drive out a set of features for
extending the buildpack staging lifecycle. If you or anyone else has
suggestions, I'm all ears.
Following are some aspects that were previously discussed and I think deserve some fixes related to buildpack staging life cycle, what about setting up a design proposal as suggested by James Bayer into [0] to detail them with the community ? - buildpack versionning [b1] - offer standard caching mechanism for pulled internet dependencies [b2] - enabling buildpack debugging traces could be standardized across buildpacks and potentially support added to cf cli and dea, e.g. displaying last git commits for a custom git repo when debugging is enabled - heroku compile ENV_DIR compatibility support in diego [b3] - support for automatically restaging vulnerable apps, once corresponding buildpacks vulnerabilities are fixed by a new buildpack [b4] - buildpack governance support: in some organizations, there is a need to scope some buildpacks per org/spaces, and possibly restrict usage of custom buildpacks. - somewhat related, suggesting to improve the droplet download capability to push the resulting droplet as a docket image into a [private] docker repo. This might seem more natural than the current download tar.gz droplet bits followed by a push to the binary buildpack that is suffering from symlinks uploads portability issues [b5] [b0] https://groups.google.com/a/cloudfoundry.org/d/msg/vcap-dev/A84xVoi8MmE/mos1CYvnxvAJ[b1] http://cf-dev.70369.x6.nabble.com/cf-dev-Droplets-and-Stacks-tp946p2422.html[b2] https://groups.google.com/a/cloudfoundry.org/d/msg/vcap-dev/A84xVoi8MmE/AuQt3nF3ImcJ[b3] https://github.com/cloudfoundry-incubator/buildpack_app_lifecycle/issues/12[b4] https://github.com/cloudfoundry/java-buildpack/issues/231#issuecomment-142200625[b5] https://www.pivotaltracker.com/n/projects/966314/stories/95890146
The Experiment #5 [3] relying on environment variables POST_BUILDPACK
seems pretty promising. Would it support an orderer list of post buildpacks
?
No reason it couldn't support an ordered set of buildpacks. I'm not fully
convinced this is the best way to proceed, but it's certainly the easiest,
and we're looking at it pretty hard at this point.
Concerning the story "Experiment #6: Investigate using a pluggable / web
services model for extending staging to operators and developers" [1] we
had discussed together into [2]. The story is marked as accepted, but I
can't see the result, and future work, including how this could be exposed
to CF operators or users.
This experiment was cut short, as the "web hook" model introduced too many
reliability concerns, in my opinion, especially around relying on external
services to stage an app. I'm open to revisiting it in the future, but
would like to try more pedestrian solutions first.
Can you please elaborate on your perception of reliability concerns with an HTTP-based API for staging pipelines ? CloudFoundry currently heavily relies on (internal) HTTP APIs for its internal workings, or external HTTP APIs such as the service broker, or the upcoming route services. What is then the preferred solution for now ? Is the mention of an S3-API-based pipeline with processes handling their transformation, similar to the proof-of-concept vito proposed into [p1] [p1] https://github.com/vito/cfv4 ?
Can you share with the community a summary of learnings from these
experiments and where the "buildpack lifecycle" would be go in the future?
Absolutely, I will do so soon.
If ever you or part of the buildpacks team is making it to the Berlin Cf Summit, that'd be great to have a community session around this, possibly in the preceding unconference on sunday.
|
|
|
Guillaume Berche
toggle quoted message
Show quoted text
On Thu, Aug 6, 2015 at 8:02 PM, Mike Dalessio <mdalessio(a)pivotal.io> wrote:
The /v2/buildpacks endpoint (used by the "cf buildpacks" command)
displays the last update date for a buildpack, e.g.
{
"metadata": {
"guid": "e000b78c-c898-419e-843c-2fd64175527e",
"url": "/v2/buildpacks/e000b78c-c898-419e-843c-2fd64175527e",
"created_at": "2014-04-08T22:05:34Z",
"updated_at": "2015-07-08T23:26:42Z"
},
"entity": {
"name": "java_buildpack",
"position": 3,
"enabled": true,
"locked": false,
"filename": "java-buildpack-v3.1.zip"
}
}
Would'nt it make sense to have the CC increment a version number for each
update so that it becomes easier to query than only relying on dates
comparison ?
While it's great to have buildpacks provide themselves detailed
versionning info for their code and their most important
dependencies/remote artifacts, I feel the cf platform should provide a bit
more support to help identify versions of buildpacks used by apps, such as:
- refine the app summary endpoint [g2]:
- for system buildpacks: include the buildpack guid (in addition to
the buildpack name) as to allow correlation to /v2/buildpacks endpoint
- for custom buildpacks (url): record and display the git hash commit
for a buildpack url
- refine the app listing endpoints [g4] or v3 [g5] to
- support querying app per system buildpack id
- support querying app by dates of "package_updated_at" or best a
version number as suggested above
I'm wondering whether the CAPI team working on API V3 is planning some
work in this area, and could comment the suggestions above.
I'll let Dieu respond to these suggestions, as she's the CAPI PM.
|
|
|
Hello, How can I disable HTTP transport of my Spring application deployed to Pivotal Web Services? I would like my application be available only through HTTPS transport. When I run my application in "local mode' (e.g. in Tomcat servlet container) disabling HTTP transport is simple. It is sufficient to disable HTTP listener and enable HTTPS listener. How can I achieve similar effect in Cloud Foundry PWS? I have skimmed the following security description but found none: https://docs.cloudfoundry.org/concepts/security.htmlI would be grateful for pointing me to relevant documentation. Best regards, Krzysztof
|
|
|
Re: Cloud Foundry Java Client V2
Guillaume Berche
Thanks Ben for sharing details of this important effort with the community. In the light of the ongoing implementation for the v2 cf-java-client implementation, does the Java experience team feels that of the 300+ documented API endpoints, there is room for a consistent, systematic approach for the low level API that matches these low-level CC API endpoints ? Does the team feel that this low level API could be automatically generated from a formal REST API specification ? Could some of the effort in 100% Java coverage could be shifted in maintaining a formal REST API specification, from which the Java low-level client could be generated automatically, similar to what google is systematically doing when providing client libraries [1], in multiple languages including java [2], php, JS, Node.Js, Go, ruby, .Net for all of google REST APIs, using automatic client code generation [3]. The question of a formal CC API REST API spec was brought to the CAPI team in the context of the v3 CC API at [4], and I'd like to know if the teams generating the clients feel there is room for automation, and mutualization of effort among programming languages (in particular Java, go, Js) for the v3 version, building on learnings and experience from existing CC API clients. Thanks in advance, Guillaume. [1] https://developers.google.com/discovery/libraries?hl=en[2] https://developers.google.com/api-client-library/java/[3] https://github.com/google/apis-client-generator[4] https://github.com/cloudfoundry/cc-api-v3-style-guide/issues/46
On Thu, Oct 15, 2015 at 9:21 PM, Ben Hale <bhale(a)pivotal.io> wrote: As many of you are aware, the Cloud Foundry Java Client has been a bit
neglected lately. There are various reasons for this, but today I’m
pleased to announce that we’ve begun a V2 effort and that progress is swift.
We on the Cloud Foundry Java Experience team have been aware for some time
that the current implementation of the Java Client is less than ideal.
Among the most common complaints were the lack of separation between
interface and implementation, the subpar network performance, and the
requirement that users understand how to orchestrate common concepts like
`push` on their own. (For a more in-depth treatment of issues we
identified, please see the stellar work done by Scott Fredrick[1].) V2
aims to address all of these issues with a ground-up redesign of the client.
To address the issue of a lack of separation between interface and
implementation, we’ve broken out the API into a project containing no
implementation. This project (`cloudfoundry-client`) consists of a
collection of interfaces and immutable datatypes. There is only a single
dependency, and it isn’t Spring! The intent here was to create an API that
could be implemented with multiple strategies, but requiring the minimal
amount of code for each of those implementations. The API itself is now
reactive (the single dependency is on Reactive Streams, the precursor to
reactive support in Java 9) which we believe will more closely align with
the trends towards non-blocking network communication. We will be
providing a single implementation of this API, based on Spring
(`cloudfoundry-client-spring`) but welcome additional implementations. We
believe we’ve created a good environment for alternatives and would be
happy to hear suggestions on how to improve if that turns out not to be the
case.
In V1, the coverage of the APIs[2] was incomplete (about half, if I had to
guess). Our commitment is to deliver a complete API and implementation in
V2, including all 300+ documented APIs. We’ve observed that this API might
not actually be the right level of abstraction for many users though.
Knowing that you need to create an application, create a package, stage a
droplet, create and start a process, etc. for `push` is quite a burden on
many users of the project. So, we’re also providing a
`cloudfoundry-operations` project that builds on the `cloudfoundry-client`
API but instead of mapping onto the low-level REST API, we’re going to map
roughly onto the `cf` CLI API. We suspect that nearly all users will want
to `cloudFoundryOperations.push()` instead of the low-level alternative, so
both choices are useful. This API and implementation will only depend on
`cloudfoundry-client` allowing any implementation of that API to be used.
Finally, we’ll be bringing the build-system plugins up to date with the
systems that they are built for and ensuring that they cover a breadth of
useful functionality at build time.
This leaves the question about what will happen to V1. We have a
commitment to fixing up the bugs that have been identified in the
code-base, but we’re not going to be doing any work that involves adding
APIs. We feel that users who need those APIs are better served moving to
V2. I’ll be feeding open issues from the backlog into the V2 stream of
work to ensure that we aren’t seeing any resource starvation and you can
expect future releases out of the `1.x` branch.
I hope that this comes as welcome news to the community and look forward
to the feedback. I highly encourage users to keep an eye Pivotal
Tracker[3] to see our progress and submit requests through GitHub[4].
-Ben Hale
Cloud Foundry Java Experience
[1]:
https://docs.google.com/document/d/1Ui-67dBPYoADltErL80xXYEr_INPqdNJG9Va4gPBM-I/edit?usp=sharing
[2]: http://apidocs.cloudfoundry.org/221/
[3]: https://www.pivotaltracker.com/projects/816799
[4]: https://github.com/cloudfoundry/cf-java-client
|
|
|
Re: Diego and Maven support
Dan,
It seems to me that there is more than one cause of this problem.
I have done the following:
1. upgraded cf CLI from 6.12 to 6.13
2.cf set-health-check MY_APP_NAME none
3. set <healthCheckTimeout>180</healthCheckTimeout> (pom.xml)
4. removed env variables in order to allow Maven to set them again
Still no luck.
However, I have read that there is intensive development of Maven client plugin 2.x happening now. I will give it a try as soon as first release is available.
Best,
Krzysztof
|
|
|
doppler issue which fails to emit logs with syslog protocol on CFv212
Hi, I am investigating the doppler issue on CFv212 that sending logs to the external logging service with syslog protocol fails. As my understanding, the following messages are supposed to be recorded in the "doppler.stdout.log" if the doppler got the syslog drain url from etcd successfully. However it is actually missing. - Missing log messages which is expected to be shown {"timestamp":xxxxxx,"process_id":xxxx,"source":"doppler","log_level":"info","message":"Syslog Sink syslog://xx.xx.xx.xx:xxxx: Running.","data":null,"file":"/var/vcap/data/compile/doppler/loggregator/src/doppler/sinks/syslog/syslog_sink.go","line":56,"method":"doppler/sinks/syslog.(*SyslogSink).Run"} {"timestamp":xxxxxx,"process_id":xxxx,"source":"doppler","log_level":"info","message":"Syslog Sink syslog://xxxxxx:xxxxxx: successfully connected.","data":null,"file":"/var/vcap/data/compile/doppler/loggregator/src/doppler/sinks/syslog/syslog_sink.go","line":112,"method":"doppler/sinks/syslog.(*SyslogSink).Run"} Instead, there are a lot of etcd error events found as follows. {"timestamp":xxxxxxxxx,"process_id":xxx,"source":"doppler","log_level":"error","message":"AppStoreWatcher: Got error while waiting for ETCD events: store request timed out","data":null,"file":"/var/vcap/data/compile/doppler/loggregator/src/github.com/cloudfoundry/loggregatorlib/store/app_service_store_watcher.go","line":79,"method":"github.com/cloudfoundry/loggregatorlib/store.(*AppServiceStoreWatcher).Run"} I have two question about this. ============= Q1) Does anyone know what this event indicates and how it affects the CF environment? In the normal envrionment, is this event still triggered (In other words, can we ignore this error event messages?) Q2) If the etcd got some trouble at the moment, which cf component is also made an influence on? I guess at the least the following cf components could be affected. Do we have anyting else? - router : to support routing api - hm9000 : to support health check - doppler: to get syslog drain urls from etcd - syslog-binder to get syslog drain urls from cc and then store them to etcd - trafficcontroller, metron agents : to find healthy dopplers to access to) ============= Note that I am also doubting the following errors in the "syslog_drain_binder.stdout.log". This message indicates that syslog_drain_binder failed to get syslog drain urls from cc. {"timestamp":xxxx,"process_id":xxxx,"source":"syslog_drain_binder","log_level":"error","message":"Error when polling cloud controller: Remote server error: Unauthorized","data":null,"file":"/var/vcap/data/compile/syslog_drain_binder/loggregator/src/syslog_drain_binder/main.go","line":68,"method":"main.main"} Therefore I have not yet concluded the etcd mainly caused the issue, however need to understand the exact meaning of the error event message above as well as any impact on the cf envrionment if there is something wrong with the behaviour of etcd. Regards, Masumi -- View this message in context: http://cf-dev.70369.x6.nabble.com/doppler-issue-which-fails-to-emit-logs-with-syslog-protocol-on-CFv212-tp2418.htmlSent from the CF Dev mailing list archive at Nabble.com.
|
|
|
Re: CF-RELEASE v202 UPLOAD ERROR
Parthiban Annadurai <senjiparthi@...>
Thanks Amit for your suggestions. Let you know after regenerating the
manifest again.
toggle quoted message
Show quoted text
On 24 October 2015 at 11:47, Amit Gupta <agupta(a)pivotal.io> wrote: Regenerate your manifest.
On Fri, Oct 23, 2015 at 10:49 PM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:
Okay Amit. Yaa, I changed my CF Version from v202 to v210. Could you
share that metron_agent.deployment property of the manifest which is
required in v210? Thanks.
On 24 October 2015 at 10:57, Amit Gupta <agupta(a)pivotal.io> wrote:
Parthiban,
Your log.txt shows that you're using cf-release version 210, but your
subject message says you're trying v202. Perhaps you've checked out v202
of cf-release and used the spiff tooling to generate the manifests from
that version. v202 doesn't include the metron_agent.deployment property in
its manifest, which is required in v210.
On Fri, Oct 23, 2015 at 10:07 PM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:
I have created the manifest file using SPIFF tool. Any issues with that?
On 23 October 2015 at 20:49, Amit Gupta <agupta(a)pivotal.io> wrote:
How did you create your manifest in the first place?
On Fri, Oct 23, 2015 at 8:17 AM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:
After trying the suggestions, now its throws the following error,
Started preparing configuration > Binding configuration. Failed:
Error filling in template `metron_agent.json.erb' for `ha_proxy_z1/0' (line
5: Can't find property `["metron_agent.deployment"]') (00:00:00)
Error 100: Error filling in template `metron_agent.json.erb' for
`ha_proxy_z1/0' (line 5: Can't find property `["metron_agent.deployment"]')
Could anyone on this??
On 22 October 2015 at 18:08, Amit Gupta <agupta(a)pivotal.io> wrote:
Try running "bosh cck" and recreating VMs from last known apply
spec. You should also make sure that the IPs you're allocating to your
jobs are accessible from the BOSH director VM.
On Thu, Oct 22, 2015 at 5:27 AM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:
Yaa sure Amit. I have attached both the files with this mail. Could
you please? Thanks.
On 21 October 2015 at 19:49, Amit Gupta <agupta(a)pivotal.io> wrote:
Can you share the output of "bosh vms" and "bosh task 51
--debug". It's preferable if you copy the terminal outputs and paste them
to Gists or Pastebins and share the links.
On Tue, Oct 20, 2015 at 6:18 AM, James Bayer <jbayer(a)pivotal.io>
wrote:
sometimes a message like that is due to networking issues. does
the bosh director and the VM it is creating have an available network path
to reach each other? sometimes ssh'ing in to the VM that is identified can
yield more debug clues.
On Tue, Oct 20, 2015 at 5:09 AM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:
Thanks Bharath and Amit for the helpful solutions. I have
surpassed that error. Now, bosh deploy strucks like in attached image.
Could you anyone please?
Regards
Parthiban A
On 20 October 2015 at 11:57, Amit Gupta <agupta(a)pivotal.io>
wrote:
Bharath, I think you mean to increase the *disk* size on the
compilation VMs, not the memory size.
Parthiban, the error message is happening during compiling,
saying "No space left on device". This means your compilation VMs are
running out of space on disk. This means you need to increase the
allocated disk for your compilation VMs. In the "compilation" section of
your deployment manifest, you can specify "cloud_properties". This is
where you will specify disk size. These "cloud_properties" look the same
as the could_properties specified for a resource pool. Depending on your
IaaS, the structure of the cloud_properties section differs. See here:
https://bosh.io/docs/deployment-manifest.html#resource-pools-cloud-properties
On Mon, Oct 19, 2015 at 11:13 PM, Bharath Posa <
bharathp(a)vedams.com> wrote:
hi parthiban
It seems you are running out of space in your vm in which you
are compiling . try to increase the size of memory in your compilation vm .
regards
Bharath
On Mon, Oct 19, 2015 at 7:39 PM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:
Hello All,
Thanks All for the helpful suggestions.
Actually, now we r facing the following issue while kicking bosh deploy,
Done compiling packages >
nats/d3a1f853f4980682ed8b48e4706b7280e2b7ce0e (00:01:07)
Failed compiling packages >
buildpack_php/9c72be716ab8629d7e6feed43012d1d671720157: Action Failed
get_task: Task aba21e6a-2031-4a69-5b72-f238ecd07051 result: Compiling
package buildpack_php: Compressing compiled package: Shelling out to tar:
Running command: 'tar czf
/var/vcap/data/tmp/bosh-platform-disk-TarballCompressor-CompressFilesInDir762165297
-C
/var/vcap/data/packages/buildpack_php/9c72be716ab8629d7e6feed43012d1d671720157.1-
.', stdout: '', stderr: '
gzip: stdout: No space left on device
': signal: broken pipe (00:02:41)
Failed compiling packages (00:02:41)
Error 450001: Action Failed get_task: Task
aba21e6a-2031-4a69-5b72-f238ecd07051 result: Compiling package
buildpack_php: Compressing compiled package: Shelling out to tar: Running
command: 'tar czf
/var/vcap/data/tmp/bosh-platform-disk-TarballCompressor-CompressFilesInDir762165297
-C
/var/vcap/data/packages/buildpack_php/9c72be716ab8629d7e6feed43012d1d671720157.1-
.', stdout: '', stderr: '
gzip: stdout: No space left on device
': signal: broken pipe
Could Anyone on this issue?
Regards
Parthiban A
On 19 October 2015 at 14:30, Bharath Posa <
bharathp(a)vedams.com> wrote:
Hi partiban
can u do a checksum of the tar file .
it should come like this *sha1:
b6f596eaff4c7af21cc18a52ef97e19debb00403*
example:
*sha1sum {file}*
regards
Bharath
On Mon, Oct 19, 2015 at 1:12 PM, Eric Poelke <
epoelke(a)gmail.com> wrote:
You actually do not need to download it. if you just run --
`bosh upload release
https://bosh.io/d/github.com/cloudfoundry/cf-release?v=202`
<https://bosh.io/d/github.com/cloudfoundry/cf-release?v=202>
The director will pull in the release directly from bosh.io
.
--
Thank you,
James Bayer
|
|
|
Re: CF-RELEASE v202 UPLOAD ERROR
Regenerate your manifest.
toggle quoted message
Show quoted text
On Fri, Oct 23, 2015 at 10:49 PM, Parthiban Annadurai <senjiparthi(a)gmail.com wrote: Okay Amit. Yaa, I changed my CF Version from v202 to v210. Could you share
that metron_agent.deployment property of the manifest which is required in
v210? Thanks.
On 24 October 2015 at 10:57, Amit Gupta <agupta(a)pivotal.io> wrote:
Parthiban,
Your log.txt shows that you're using cf-release version 210, but your
subject message says you're trying v202. Perhaps you've checked out v202
of cf-release and used the spiff tooling to generate the manifests from
that version. v202 doesn't include the metron_agent.deployment property in
its manifest, which is required in v210.
On Fri, Oct 23, 2015 at 10:07 PM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:
I have created the manifest file using SPIFF tool. Any issues with that?
On 23 October 2015 at 20:49, Amit Gupta <agupta(a)pivotal.io> wrote:
How did you create your manifest in the first place?
On Fri, Oct 23, 2015 at 8:17 AM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:
After trying the suggestions, now its throws the following error,
Started preparing configuration > Binding configuration. Failed: Error
filling in template `metron_agent.json.erb' for `ha_proxy_z1/0' (line 5:
Can't find property `["metron_agent.deployment"]') (00:00:00)
Error 100: Error filling in template `metron_agent.json.erb' for
`ha_proxy_z1/0' (line 5: Can't find property `["metron_agent.deployment"]')
Could anyone on this??
On 22 October 2015 at 18:08, Amit Gupta <agupta(a)pivotal.io> wrote:
Try running "bosh cck" and recreating VMs from last known apply
spec. You should also make sure that the IPs you're allocating to your
jobs are accessible from the BOSH director VM.
On Thu, Oct 22, 2015 at 5:27 AM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:
Yaa sure Amit. I have attached both the files with this mail. Could
you please? Thanks.
On 21 October 2015 at 19:49, Amit Gupta <agupta(a)pivotal.io> wrote:
Can you share the output of "bosh vms" and "bosh task 51 --debug".
It's preferable if you copy the terminal outputs and paste them to Gists or
Pastebins and share the links.
On Tue, Oct 20, 2015 at 6:18 AM, James Bayer <jbayer(a)pivotal.io>
wrote:
sometimes a message like that is due to networking issues. does
the bosh director and the VM it is creating have an available network path
to reach each other? sometimes ssh'ing in to the VM that is identified can
yield more debug clues.
On Tue, Oct 20, 2015 at 5:09 AM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:
Thanks Bharath and Amit for the helpful solutions. I have
surpassed that error. Now, bosh deploy strucks like in attached image.
Could you anyone please?
Regards
Parthiban A
On 20 October 2015 at 11:57, Amit Gupta <agupta(a)pivotal.io>
wrote:
Bharath, I think you mean to increase the *disk* size on the
compilation VMs, not the memory size.
Parthiban, the error message is happening during compiling,
saying "No space left on device". This means your compilation VMs are
running out of space on disk. This means you need to increase the
allocated disk for your compilation VMs. In the "compilation" section of
your deployment manifest, you can specify "cloud_properties". This is
where you will specify disk size. These "cloud_properties" look the same
as the could_properties specified for a resource pool. Depending on your
IaaS, the structure of the cloud_properties section differs. See here:
https://bosh.io/docs/deployment-manifest.html#resource-pools-cloud-properties
On Mon, Oct 19, 2015 at 11:13 PM, Bharath Posa <
bharathp(a)vedams.com> wrote:
hi parthiban
It seems you are running out of space in your vm in which you
are compiling . try to increase the size of memory in your compilation vm .
regards
Bharath
On Mon, Oct 19, 2015 at 7:39 PM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:
Hello All,
Thanks All for the helpful suggestions. Actually,
now we r facing the following issue while kicking bosh deploy,
Done compiling packages >
nats/d3a1f853f4980682ed8b48e4706b7280e2b7ce0e (00:01:07)
Failed compiling packages >
buildpack_php/9c72be716ab8629d7e6feed43012d1d671720157: Action Failed
get_task: Task aba21e6a-2031-4a69-5b72-f238ecd07051 result: Compiling
package buildpack_php: Compressing compiled package: Shelling out to tar:
Running command: 'tar czf
/var/vcap/data/tmp/bosh-platform-disk-TarballCompressor-CompressFilesInDir762165297
-C
/var/vcap/data/packages/buildpack_php/9c72be716ab8629d7e6feed43012d1d671720157.1-
.', stdout: '', stderr: '
gzip: stdout: No space left on device
': signal: broken pipe (00:02:41)
Failed compiling packages (00:02:41)
Error 450001: Action Failed get_task: Task
aba21e6a-2031-4a69-5b72-f238ecd07051 result: Compiling package
buildpack_php: Compressing compiled package: Shelling out to tar: Running
command: 'tar czf
/var/vcap/data/tmp/bosh-platform-disk-TarballCompressor-CompressFilesInDir762165297
-C
/var/vcap/data/packages/buildpack_php/9c72be716ab8629d7e6feed43012d1d671720157.1-
.', stdout: '', stderr: '
gzip: stdout: No space left on device
': signal: broken pipe
Could Anyone on this issue?
Regards
Parthiban A
On 19 October 2015 at 14:30, Bharath Posa <bharathp(a)vedams.com
wrote: Hi partiban
can u do a checksum of the tar file .
it should come like this *sha1:
b6f596eaff4c7af21cc18a52ef97e19debb00403*
example:
*sha1sum {file}*
regards
Bharath
On Mon, Oct 19, 2015 at 1:12 PM, Eric Poelke <
epoelke(a)gmail.com> wrote:
You actually do not need to download it. if you just run --
`bosh upload release
https://bosh.io/d/github.com/cloudfoundry/cf-release?v=202`
<https://bosh.io/d/github.com/cloudfoundry/cf-release?v=202>
The director will pull in the release directly from bosh.io.
--
Thank you,
James Bayer
|
|
|
Re: CF-RELEASE v202 UPLOAD ERROR
Parthiban Annadurai <senjiparthi@...>
Okay Amit. Yaa, I changed my CF Version from v202 to v210. Could you share
that metron_agent.deployment property of the manifest which is required in
v210? Thanks.
toggle quoted message
Show quoted text
On 24 October 2015 at 10:57, Amit Gupta <agupta(a)pivotal.io> wrote: Parthiban,
Your log.txt shows that you're using cf-release version 210, but your
subject message says you're trying v202. Perhaps you've checked out v202
of cf-release and used the spiff tooling to generate the manifests from
that version. v202 doesn't include the metron_agent.deployment property in
its manifest, which is required in v210.
On Fri, Oct 23, 2015 at 10:07 PM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:
I have created the manifest file using SPIFF tool. Any issues with that?
On 23 October 2015 at 20:49, Amit Gupta <agupta(a)pivotal.io> wrote:
How did you create your manifest in the first place?
On Fri, Oct 23, 2015 at 8:17 AM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:
After trying the suggestions, now its throws the following error,
Started preparing configuration > Binding configuration. Failed: Error
filling in template `metron_agent.json.erb' for `ha_proxy_z1/0' (line 5:
Can't find property `["metron_agent.deployment"]') (00:00:00)
Error 100: Error filling in template `metron_agent.json.erb' for
`ha_proxy_z1/0' (line 5: Can't find property `["metron_agent.deployment"]')
Could anyone on this??
On 22 October 2015 at 18:08, Amit Gupta <agupta(a)pivotal.io> wrote:
Try running "bosh cck" and recreating VMs from last known apply spec.
You should also make sure that the IPs you're allocating to your jobs are
accessible from the BOSH director VM.
On Thu, Oct 22, 2015 at 5:27 AM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:
Yaa sure Amit. I have attached both the files with this mail. Could
you please? Thanks.
On 21 October 2015 at 19:49, Amit Gupta <agupta(a)pivotal.io> wrote:
Can you share the output of "bosh vms" and "bosh task 51 --debug".
It's preferable if you copy the terminal outputs and paste them to Gists or
Pastebins and share the links.
On Tue, Oct 20, 2015 at 6:18 AM, James Bayer <jbayer(a)pivotal.io>
wrote:
sometimes a message like that is due to networking issues. does the
bosh director and the VM it is creating have an available network path to
reach each other? sometimes ssh'ing in to the VM that is identified can
yield more debug clues.
On Tue, Oct 20, 2015 at 5:09 AM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:
Thanks Bharath and Amit for the helpful solutions. I have
surpassed that error. Now, bosh deploy strucks like in attached image.
Could you anyone please?
Regards
Parthiban A
On 20 October 2015 at 11:57, Amit Gupta <agupta(a)pivotal.io> wrote:
Bharath, I think you mean to increase the *disk* size on the
compilation VMs, not the memory size.
Parthiban, the error message is happening during compiling,
saying "No space left on device". This means your compilation VMs are
running out of space on disk. This means you need to increase the
allocated disk for your compilation VMs. In the "compilation" section of
your deployment manifest, you can specify "cloud_properties". This is
where you will specify disk size. These "cloud_properties" look the same
as the could_properties specified for a resource pool. Depending on your
IaaS, the structure of the cloud_properties section differs. See here:
https://bosh.io/docs/deployment-manifest.html#resource-pools-cloud-properties
On Mon, Oct 19, 2015 at 11:13 PM, Bharath Posa <
bharathp(a)vedams.com> wrote:
hi parthiban
It seems you are running out of space in your vm in which you
are compiling . try to increase the size of memory in your compilation vm .
regards
Bharath
On Mon, Oct 19, 2015 at 7:39 PM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:
Hello All,
Thanks All for the helpful suggestions. Actually,
now we r facing the following issue while kicking bosh deploy,
Done compiling packages >
nats/d3a1f853f4980682ed8b48e4706b7280e2b7ce0e (00:01:07)
Failed compiling packages >
buildpack_php/9c72be716ab8629d7e6feed43012d1d671720157: Action Failed
get_task: Task aba21e6a-2031-4a69-5b72-f238ecd07051 result: Compiling
package buildpack_php: Compressing compiled package: Shelling out to tar:
Running command: 'tar czf
/var/vcap/data/tmp/bosh-platform-disk-TarballCompressor-CompressFilesInDir762165297
-C
/var/vcap/data/packages/buildpack_php/9c72be716ab8629d7e6feed43012d1d671720157.1-
.', stdout: '', stderr: '
gzip: stdout: No space left on device
': signal: broken pipe (00:02:41)
Failed compiling packages (00:02:41)
Error 450001: Action Failed get_task: Task
aba21e6a-2031-4a69-5b72-f238ecd07051 result: Compiling package
buildpack_php: Compressing compiled package: Shelling out to tar: Running
command: 'tar czf
/var/vcap/data/tmp/bosh-platform-disk-TarballCompressor-CompressFilesInDir762165297
-C
/var/vcap/data/packages/buildpack_php/9c72be716ab8629d7e6feed43012d1d671720157.1-
.', stdout: '', stderr: '
gzip: stdout: No space left on device
': signal: broken pipe
Could Anyone on this issue?
Regards
Parthiban A
On 19 October 2015 at 14:30, Bharath Posa <bharathp(a)vedams.com>
wrote:
Hi partiban
can u do a checksum of the tar file .
it should come like this *sha1:
b6f596eaff4c7af21cc18a52ef97e19debb00403*
example:
*sha1sum {file}*
regards
Bharath
On Mon, Oct 19, 2015 at 1:12 PM, Eric Poelke <
epoelke(a)gmail.com> wrote:
You actually do not need to download it. if you just run --
`bosh upload release
https://bosh.io/d/github.com/cloudfoundry/cf-release?v=202`
<https://bosh.io/d/github.com/cloudfoundry/cf-release?v=202>
The director will pull in the release directly from bosh.io.
--
Thank you,
James Bayer
|
|
|
Re: CF-RELEASE v202 UPLOAD ERROR
Parthiban,
Your log.txt shows that you're using cf-release version 210, but your
subject message says you're trying v202. Perhaps you've checked out v202
of cf-release and used the spiff tooling to generate the manifests from
that version. v202 doesn't include the metron_agent.deployment property in
its manifest, which is required in v210.
toggle quoted message
Show quoted text
On Fri, Oct 23, 2015 at 10:07 PM, Parthiban Annadurai <senjiparthi(a)gmail.com wrote: I have created the manifest file using SPIFF tool. Any issues with that?
On 23 October 2015 at 20:49, Amit Gupta <agupta(a)pivotal.io> wrote:
How did you create your manifest in the first place?
On Fri, Oct 23, 2015 at 8:17 AM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:
After trying the suggestions, now its throws the following error,
Started preparing configuration > Binding configuration. Failed: Error
filling in template `metron_agent.json.erb' for `ha_proxy_z1/0' (line 5:
Can't find property `["metron_agent.deployment"]') (00:00:00)
Error 100: Error filling in template `metron_agent.json.erb' for
`ha_proxy_z1/0' (line 5: Can't find property `["metron_agent.deployment"]')
Could anyone on this??
On 22 October 2015 at 18:08, Amit Gupta <agupta(a)pivotal.io> wrote:
Try running "bosh cck" and recreating VMs from last known apply spec.
You should also make sure that the IPs you're allocating to your jobs are
accessible from the BOSH director VM.
On Thu, Oct 22, 2015 at 5:27 AM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:
Yaa sure Amit. I have attached both the files with this mail. Could
you please? Thanks.
On 21 October 2015 at 19:49, Amit Gupta <agupta(a)pivotal.io> wrote:
Can you share the output of "bosh vms" and "bosh task 51 --debug".
It's preferable if you copy the terminal outputs and paste them to Gists or
Pastebins and share the links.
On Tue, Oct 20, 2015 at 6:18 AM, James Bayer <jbayer(a)pivotal.io>
wrote:
sometimes a message like that is due to networking issues. does the
bosh director and the VM it is creating have an available network path to
reach each other? sometimes ssh'ing in to the VM that is identified can
yield more debug clues.
On Tue, Oct 20, 2015 at 5:09 AM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:
Thanks Bharath and Amit for the helpful solutions. I have surpassed
that error. Now, bosh deploy strucks like in attached image. Could you
anyone please?
Regards
Parthiban A
On 20 October 2015 at 11:57, Amit Gupta <agupta(a)pivotal.io> wrote:
Bharath, I think you mean to increase the *disk* size on the
compilation VMs, not the memory size.
Parthiban, the error message is happening during compiling, saying
"No space left on device". This means your compilation VMs are running out
of space on disk. This means you need to increase the allocated disk for
your compilation VMs. In the "compilation" section of your deployment
manifest, you can specify "cloud_properties". This is where you will
specify disk size. These "cloud_properties" look the same as the
could_properties specified for a resource pool. Depending on your IaaS,
the structure of the cloud_properties section differs. See here:
https://bosh.io/docs/deployment-manifest.html#resource-pools-cloud-properties
On Mon, Oct 19, 2015 at 11:13 PM, Bharath Posa <
bharathp(a)vedams.com> wrote:
hi parthiban
It seems you are running out of space in your vm in which you are
compiling . try to increase the size of memory in your compilation vm .
regards
Bharath
On Mon, Oct 19, 2015 at 7:39 PM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:
Hello All,
Thanks All for the helpful suggestions. Actually,
now we r facing the following issue while kicking bosh deploy,
Done compiling packages >
nats/d3a1f853f4980682ed8b48e4706b7280e2b7ce0e (00:01:07)
Failed compiling packages >
buildpack_php/9c72be716ab8629d7e6feed43012d1d671720157: Action Failed
get_task: Task aba21e6a-2031-4a69-5b72-f238ecd07051 result: Compiling
package buildpack_php: Compressing compiled package: Shelling out to tar:
Running command: 'tar czf
/var/vcap/data/tmp/bosh-platform-disk-TarballCompressor-CompressFilesInDir762165297
-C
/var/vcap/data/packages/buildpack_php/9c72be716ab8629d7e6feed43012d1d671720157.1-
.', stdout: '', stderr: '
gzip: stdout: No space left on device
': signal: broken pipe (00:02:41)
Failed compiling packages (00:02:41)
Error 450001: Action Failed get_task: Task
aba21e6a-2031-4a69-5b72-f238ecd07051 result: Compiling package
buildpack_php: Compressing compiled package: Shelling out to tar: Running
command: 'tar czf
/var/vcap/data/tmp/bosh-platform-disk-TarballCompressor-CompressFilesInDir762165297
-C
/var/vcap/data/packages/buildpack_php/9c72be716ab8629d7e6feed43012d1d671720157.1-
.', stdout: '', stderr: '
gzip: stdout: No space left on device
': signal: broken pipe
Could Anyone on this issue?
Regards
Parthiban A
On 19 October 2015 at 14:30, Bharath Posa <bharathp(a)vedams.com>
wrote:
Hi partiban
can u do a checksum of the tar file .
it should come like this *sha1:
b6f596eaff4c7af21cc18a52ef97e19debb00403*
example:
*sha1sum {file}*
regards
Bharath
On Mon, Oct 19, 2015 at 1:12 PM, Eric Poelke <epoelke(a)gmail.com
wrote: You actually do not need to download it. if you just run --
`bosh upload release
https://bosh.io/d/github.com/cloudfoundry/cf-release?v=202`
<https://bosh.io/d/github.com/cloudfoundry/cf-release?v=202>
The director will pull in the release directly from bosh.io.
--
Thank you,
James Bayer
|
|
|
Re: CF-RELEASE v202 UPLOAD ERROR
Parthiban Annadurai <senjiparthi@...>
I have created the manifest file using SPIFF tool. Any issues with that?
toggle quoted message
Show quoted text
On 23 October 2015 at 20:49, Amit Gupta <agupta(a)pivotal.io> wrote: How did you create your manifest in the first place?
On Fri, Oct 23, 2015 at 8:17 AM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:
After trying the suggestions, now its throws the following error,
Started preparing configuration > Binding configuration. Failed: Error
filling in template `metron_agent.json.erb' for `ha_proxy_z1/0' (line 5:
Can't find property `["metron_agent.deployment"]') (00:00:00)
Error 100: Error filling in template `metron_agent.json.erb' for
`ha_proxy_z1/0' (line 5: Can't find property `["metron_agent.deployment"]')
Could anyone on this??
On 22 October 2015 at 18:08, Amit Gupta <agupta(a)pivotal.io> wrote:
Try running "bosh cck" and recreating VMs from last known apply spec.
You should also make sure that the IPs you're allocating to your jobs are
accessible from the BOSH director VM.
On Thu, Oct 22, 2015 at 5:27 AM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:
Yaa sure Amit. I have attached both the files with this mail. Could you
please? Thanks.
On 21 October 2015 at 19:49, Amit Gupta <agupta(a)pivotal.io> wrote:
Can you share the output of "bosh vms" and "bosh task 51 --debug".
It's preferable if you copy the terminal outputs and paste them to Gists or
Pastebins and share the links.
On Tue, Oct 20, 2015 at 6:18 AM, James Bayer <jbayer(a)pivotal.io>
wrote:
sometimes a message like that is due to networking issues. does the
bosh director and the VM it is creating have an available network path to
reach each other? sometimes ssh'ing in to the VM that is identified can
yield more debug clues.
On Tue, Oct 20, 2015 at 5:09 AM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:
Thanks Bharath and Amit for the helpful solutions. I have surpassed
that error. Now, bosh deploy strucks like in attached image. Could you
anyone please?
Regards
Parthiban A
On 20 October 2015 at 11:57, Amit Gupta <agupta(a)pivotal.io> wrote:
Bharath, I think you mean to increase the *disk* size on the
compilation VMs, not the memory size.
Parthiban, the error message is happening during compiling, saying
"No space left on device". This means your compilation VMs are running out
of space on disk. This means you need to increase the allocated disk for
your compilation VMs. In the "compilation" section of your deployment
manifest, you can specify "cloud_properties". This is where you will
specify disk size. These "cloud_properties" look the same as the
could_properties specified for a resource pool. Depending on your IaaS,
the structure of the cloud_properties section differs. See here:
https://bosh.io/docs/deployment-manifest.html#resource-pools-cloud-properties
On Mon, Oct 19, 2015 at 11:13 PM, Bharath Posa <bharathp(a)vedams.com
wrote: hi parthiban
It seems you are running out of space in your vm in which you are
compiling . try to increase the size of memory in your compilation vm .
regards
Bharath
On Mon, Oct 19, 2015 at 7:39 PM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:
Hello All,
Thanks All for the helpful suggestions. Actually,
now we r facing the following issue while kicking bosh deploy,
Done compiling packages >
nats/d3a1f853f4980682ed8b48e4706b7280e2b7ce0e (00:01:07)
Failed compiling packages >
buildpack_php/9c72be716ab8629d7e6feed43012d1d671720157: Action Failed
get_task: Task aba21e6a-2031-4a69-5b72-f238ecd07051 result: Compiling
package buildpack_php: Compressing compiled package: Shelling out to tar:
Running command: 'tar czf
/var/vcap/data/tmp/bosh-platform-disk-TarballCompressor-CompressFilesInDir762165297
-C
/var/vcap/data/packages/buildpack_php/9c72be716ab8629d7e6feed43012d1d671720157.1-
.', stdout: '', stderr: '
gzip: stdout: No space left on device
': signal: broken pipe (00:02:41)
Failed compiling packages (00:02:41)
Error 450001: Action Failed get_task: Task
aba21e6a-2031-4a69-5b72-f238ecd07051 result: Compiling package
buildpack_php: Compressing compiled package: Shelling out to tar: Running
command: 'tar czf
/var/vcap/data/tmp/bosh-platform-disk-TarballCompressor-CompressFilesInDir762165297
-C
/var/vcap/data/packages/buildpack_php/9c72be716ab8629d7e6feed43012d1d671720157.1-
.', stdout: '', stderr: '
gzip: stdout: No space left on device
': signal: broken pipe
Could Anyone on this issue?
Regards
Parthiban A
On 19 October 2015 at 14:30, Bharath Posa <bharathp(a)vedams.com>
wrote:
Hi partiban
can u do a checksum of the tar file .
it should come like this *sha1:
b6f596eaff4c7af21cc18a52ef97e19debb00403*
example:
*sha1sum {file}*
regards
Bharath
On Mon, Oct 19, 2015 at 1:12 PM, Eric Poelke <epoelke(a)gmail.com>
wrote:
You actually do not need to download it. if you just run --
`bosh upload release
https://bosh.io/d/github.com/cloudfoundry/cf-release?v=202`
<https://bosh.io/d/github.com/cloudfoundry/cf-release?v=202>
The director will pull in the release directly from bosh.io.
--
Thank you,
James Bayer
|
|
|
[abacus] Abacus v0.0.2-rc.2 available
|
|
|
