|
Re: can we install ruby gems in existing cf stacks (cflinuxfs2) without recreate stack
DHR
So I think your problem is that your gems are on the DEA at staging time but aren't being found by the Ruby layer, right?
toggle quoted messageShow quoted text
If so the normal approach is to point to them via an env Var (eg BUNDLE_PATH, GEM_PATH), however your compile, detect, release scripts are already in Ruby (not bash) so perhaps you could load them using Gem.paths. Example on http://stackoverflow.com/questions/28764389/set-gem-home-path-or-gem-path-programmatically
On 24 May 2016, at 18:08, Lingesh Mouleeshwaran <lingeshmouleeshwaran(a)gmail.com> wrote:
|
|
|
|
Re: can we externalize pivotal repository path in java buildpack??
DHR
You could change the config/repository.yml to point to a DNS name on your network. Then build out one or more local repositories on your network using the Java-buildpack-dependency-builder: https://github.com/cloudfoundry/java-buildpack-dependency-builder
toggle quoted messageShow quoted text
And then alias that DNS onto your server(s).
On 24 May 2016, at 18:25, Lingesh Mouleeshwaran <lingeshmouleeshwaran(a)gmail.com> wrote:
|
|
|
|
can we externalize pivotal repository path in java buildpack??
Lingesh Mouleeshwaran
Hi Cloudfoundry ,
In java-buildpack ,*https://download.run.pivotal.io <https://download.run.pivotal.io> *URL is used for default_repository_root for all binaries , but this URL may not be accessible or very slow in china network. Please can somebody suggest like how can we externalize this repository path so that one buildpack can switch to multiple repositories. Regards, Lingesh M
|
|
|
|
Re: can we install ruby gems in existing cf stacks (cflinuxfs2) without recreate stack
Lingesh Mouleeshwaran
not an issue .Thanks Dan !!!
toggle quoted messageShow quoted text
On Tue, May 24, 2016 at 4:56 PM, Daniel Mikusa <dmikusa(a)pivotal.io> wrote:
OK, my fault. I misunderstood what you're trying to do here. I was
|
|
|
|
Re: All-In-One Virtual Machine for CF
Gwenn Etourneau
You can take a look at https://github.com/pivotal-cf/pcfdev.
Thanks On Tue, May 24, 2016 at 4:07 AM, Francesco D'Andria <fradandria(a)gmail.com> wrote: Hi all, sorry in advance of the maybe naif question.
|
|
|
|
Re: can we install ruby gems in existing cf stacks (cflinuxfs2) without recreate stack
Daniel Mikusa
OK, my fault. I misunderstood what you're trying to do here. I was
thinking that your application needed the gems, but it's your build pack that needs them. You originally said... *Example :* Our modified java buildpack not running on existing stacksbecause of few of the ruby gems are missing in the file system. so we would require to install few ruby gem and use the modified java buildpack. If the build pack needs additional gems then you would want to pack the gems with the build pack. I'm not sure what the best way to do this would be, I'm sure someone with more ruby experience can say. Ideas that come to mind: add it as a git submodule, vendor it (seems like what you're doing), maybe just copy the src in if it's small. Basically the build pack needs to be self contained (especially so that it works in offline environments). Anything it needs, should be included with the build pack. Dan On Tue, May 24, 2016 at 1:37 AM, Lingesh Mouleeshwaran < lingeshmouleeshwaran(a)gmail.com> wrote: yes Dan,
|
|
|
|
All-In-One Virtual Machine for CF
Francesco D'Andria
Hi all, sorry in advance of the maybe naif question.
I was wondering if I could find somewhere an all-In-One Virtual Machine with the last version of CF like openshift origin. thank you in advance and regards Francesco
|
|
|
|
Re: can we install ruby gems in existing cf stacks (cflinuxfs2) without recreate stack
Lingesh Mouleeshwaran
yes Dan,
toggle quoted messageShow quoted text
we have used below commands to package the buildpack . bundle install bundle exec rake package version=custom-java-buildpack after that we will take the zip and create a offline buildpack using cf cli. Regards Lingesh M
On Mon, May 23, 2016 at 7:16 PM, Daniel Mikusa <dmikusa(a)pivotal.io> wrote:
You need to bundle install the gem in the staging container. The build
|
|
|
|
Re: CVE-2016-0781 UAA Password Reset Vulnerability
Sree Tummidi
yes, there has been a typo. Thank you for pointing out !
The correct CVE number is : *CVE-2016-3084* Thanks, Sree Tummidi Sr. Product Manager Identity - Pivotal Cloud Foundry On Mon, May 23, 2016 at 10:05 AM, Graham Bleach < graham.bleach(a)digital.cabinet-office.gov.uk> wrote: Hi Chip,
|
|
|
|
Re: CVE-2016-0781 UAA Password Reset Vulnerability
Graham Bleach
Hi Chip,
On 23 May 2016 at 17:00, Chip Childers <cchilders(a)cloudfoundry.org> wrote: CVE-2016-0781 UAA Password Reset VulnerabilityI think there might be a typo here as the CVE reference seems to be the same as for the UAA persistent XSS vulnerability. G
|
|
|
|
CVE-2016-0781 UAA Password Reset Vulnerability
Chip Childers <cchilders@...>
CVE-2016-0781 UAA Password Reset VulnerabilitySeverity
Low Vendor Cloud Foundry Foundation Versions Affected - Cloud Foundry release v236 and earlier versions - UAA release v3.3.0 and earlier versions - All versions of Login-server - UAA release v10 and earlier versions Description The UAA reset password flow is vulnerable to a brute force attack due to multiple active codes at a given time. This vulnerability is applicable only when using the UAA internal user store for authentication. Deployments enabled for integration via SAML or LDAP are not affected. Mitigation Users are strongly encouraged to follow one of the mitigations below: - Upgrade to Cloud Foundry v237 [1] or later - For standalone UAA users - For users using UAA version 3.3.0 or prior, please upgrade to UAA Release to v3.3.0.1 [2] or later - For users using standalone login-server 1.X, please upgrade to UAA Release to v3.3.0.1 [2] or later - For users using UAA-Release (UAA bosh release), please upgrade to UAA-Release v11 [3] or later Credit GE Digital Inc. References [1] https://github.com/cloudfoundry/cf-release/releases/tag/v237 [2] https://github.com/cloudfoundry/uaa/releases/tag/3.3.0.1 [3] https://github.com/cloudfoundry/uaa-release/releases/tag/v11 History 2016-Mar-23: Initial vulnerability report published
|
|
|
|
Re: DEA Monitoring Capabilities
Chawki, Amin <amin.chawki@...>
-What information were you trying to understand from mem_used_bytes?
toggle quoted messageShow quoted text
We used mem_used_bytes and mem_free_bytes (currently metrics from bosh) to get an overview over the real overall memory usage of all apps as an approximation. This helps us to get a better understanding of the current overcommit factor. -As far as the healthy metric from HM9000, it was quite misleading. It reported healthy as long as the metrics server was running which wasn't any indication of health. What exactly do you want to know? Ah ok, I was not aware of that. Is there any reliable way to verify whether HM9000 is healthy? Best Regards and Thanks, Amin From: Michael Fraenkel <michael.fraenkel(a)gmail.com> Reply-To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org> Date: Monday 23 May 2016 at 13:17 To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org> Subject: [cf-dev] Re: DEA Monitoring Capabilities When 234 was released, we did not realize that Collector was creating additional metrics. Based on reports, we have added back any missing metrics that people felt were needed. Let me know if we still have missing metrics as you move beyond 234. In 234, while we did not report available_memory_ratio, we do report remaining_memory. If your DEAs have the same amount of memory, the ratio can be computed or you can use the current value directly. What information were you trying to understand from mem_used_bytes? As far as the healthy metric from HM9000, it was quite misleading. It reported healthy as long as the metrics server was running which wasn't any indication of health. What exactly do you want to know? - Michael
On 5/20/16 4:41 AM, Chawki, Amin wrote:
Hi, by upgrading to CF v234 (including pre-release v232) we lost all our monitoring capabilities regarding DEA and HM9000 (we were still using Collector). By migrating to Firehose only a fraction of the metrics was available. Very important metrics for our productive systems like ‘available_memory_ratio’ were just added in CF v235. In the meantime, we were pretty much “flying blind”. We replaced not existing metrics like ‘DEA…mem_used_bytes’ and ‘HM9000…healthy’, which were available via Collector, with metrics from Bosh. Is this the way to go or are there any plans to add them again? Best Regards, Amin
|
|
|
|
Re: can we install ruby gems in existing cf stacks (cflinuxfs2) without recreate stack
Daniel Mikusa
You need to bundle install the gem in the staging container. The build
pack would generally do this. Dan On Mon, May 23, 2016 at 8:25 AM, Lingesh Mouleeshwaran < lingeshmouleeshwaran(a)gmail.com> wrote: Hi Dan ,
|
|
|
|
Re: can we install ruby gems in existing cf stacks (cflinuxfs2) without recreate stack
Lingesh Mouleeshwaran
Hi Dan ,
toggle quoted messageShow quoted text
yes I have installed the require gem via *bundle install* to specify the path of vendor staging directories which is available in below paths /var/vcap/data/packages/dea_next/* /vendor/cache /var/vcap/data/packages/warden/*/vendor/cache using buildpack Gemfile. Still I am not seeing these require gem is available in staging container. So staging container during compile phase. Regards Lingesh M
On Mon, May 23, 2016 at 5:35 PM, Daniel Mikusa <dmikusa(a)pivotal.io> wrote:
On Mon, May 23, 2016 at 3:41 AM, Lingesh Mouleeshwaran <
|
|
|
|
Re: can we install ruby gems in existing cf stacks (cflinuxfs2) without recreate stack
Daniel Mikusa
On Mon, May 23, 2016 at 3:41 AM, Lingesh Mouleeshwaran <
lingeshmouleeshwaran(a)gmail.com> wrote: Thanks DHR and Sunil ,This is the way you should be doing it. What about this doesn't help / work for you? Dan
|
|
|
|
Re: DEA Monitoring Capabilities
Michael Fraenkel <michael.fraenkel@...>
When 234 was released, we did not realize that Collector was creating
toggle quoted messageShow quoted text
additional metrics. Based on reports, we have added back any missing metrics that people felt were needed. Let me know if we still have missing metrics as you move beyond 234. In 234, while we did not report available_memory_ratio, we do report remaining_memory. If your DEAs have the same amount of memory, the ratio can be computed or you can use the current value directly. What information were you trying to understand from mem_used_bytes? As far as the healthy metric from HM9000, it was quite misleading. It reported healthy as long as the metrics server was running which wasn't any indication of health. What exactly do you want to know? - Michael
On 5/20/16 4:41 AM, Chawki, Amin wrote:
|
|
|
|
Re: can we install ruby gems in existing cf stacks (cflinuxfs2) without recreate stack
Lingesh Mouleeshwaran
Thanks DHR and Sunil ,
@ DHR , I have followed your way to install the gem on staging directory , but it doesn't help. is this same way followed by existing cloudfoundry java buildpack ?? @ Sunil , Please could you elaborate more on your approach , I coudn't get your suggestion. Regards Lingesh M On Fri, May 20, 2016 at 7:56 AM, Sunil Babu <cloudgrp.assist(a)gmail.com> wrote: Hi
|
|
|
|
Re: Cloud Foundry API - Should users be able to remove themselves from an Org or Space?
Charles Wu
Nick,
The last two seem to be too strict. A user should be able to remove themselves from spaces as long as the organization has an OrgManager who has the power to reassign users to the space in the appropriate roles. Curious how others look at it. The policies otherwise described are consistent with what we permit on Pivotal Web Services. Charles Wu Product Owner Pivotal Web Services (run.pivotal.io) On Fri, May 20, 2016 at 12:14 PM, Nicholas Calugar <ncalugar(a)pivotal.io> wrote: Hi Cloud Foundry,
|
|
|
|
Cloud Foundry API - Should users be able to remove themselves from an Org or Space?
Nicholas Calugar
Hi Cloud Foundry,
We have a request from an API client that would like for users to be able to remove themselves from an Organization or Space. This allows self-service without the app obtaining an admin token to remove the user. Several restrictions that we might want to incorporate: - Deny if the user is the last User in the org? - Deny if the user is the last Org Manager in the org? - Deny if the user is the last Billing Manager in the org? - Deny if the user is the last User in the space? - Deny if the user is the last SpaceManager in the space? Any objections to this or any other restrictions we should consider? Thanks, Nick
|
|
|
|
Re: DEA Monitoring Capabilities
Jim CF Campbell
Looks like the Runtime team took some out in v234, added them back in in
v235. From the Runtime Slack: On Fri, May 20, 2016 at 11:47 AM, Jim CF Campbell <jcampbell(a)pivotal.io> wrote: Yep, I've had a back thread with Runtime OG who now has the DEA metrics -- Jim Campbell | Product Manager | Cloud Foundry | Pivotal.io | 303.618.0963
|
|
|
