pivotal deploys updated stemcells regularly to PWS. high and critical CVEs have a 48hr goal. we catch up on lows and mediums generally approximately once per month. wrote:

this the story that is tracking the stemcells with the patches: https://www.pivotaltracker.com/n/projects/956238/stories/113881681 wrote:

stemcells you can see here: https://github.com/cloudfoundry/bosh/releases search for USN the stacks releases have the CVEs for the rootfs, which you can see here: https://github.com/cloudfoundry/stack

konstantin, only red hat can distribute RHEL. CF is OSS, therefore centos is what we build and distribute as part of the cloud foundry foundation projects as a bosh stemcell. i'm not sure what source

perhaps this makes sense as a github issue? wayneeseguin(a)starkandwayne.com> wrote:

the x-forwarded-proto header is pretty important for large public clouds as most of them enable http and https that i'm aware of. in this situation, i'm not sure how we forego the header when it's als

sean, i think you'll find the approach being implemented by david takes us down the path that enables a IAM roles best-practice recommended by amazon. IAM credentials can be provided by the AWS metada

dave rocamora has been looking into this a bit and getting some advice from dmitriy: https://github.com/drocamor/bosh/commit/941215ee3076923c1c2aaf69d4d57df6b439e71c

correct. v213 is fine for new deployments. it is not possible to upgrade to v213 with zero-downtime to the cloud controllers from a previous release, which is the reason for the note. aliaksandr.prysm

i'm not sure that CF would fit within the free tier which only allows t2.micros, but you could try it and let us know how it goes. you would have a hard time fitting app containers on a VM with only 1

do you have a persistent disk backup? if so this can help. https://blog.starkandwayne.com/2014/10/10/restore-micro-bosh-from-just-its-persistent-disk/ guruprakashsrinivasamurthy(a)gmail.com> wrote:

this looks like DB migrations may be messed up.

i think the resurrector works on bosh-lite already. let us know if you find that isn't the case. michael.grifalconi(a)studenti.unimi.it> wrote:

looks interesting, would love to hear if people try this approach. thanks for sharing! leandro.21.2008(a)gmail.com> wrote:

dmitriy reads this list and hangs out in the #bosh irc channel [1]. the softlayer cpi is an example of an external cpi that can be used with bosh init, so you could probably look at how that one works

thanks for doing the research danny! please let us know if you try working on this. we'll definitely try and help if you get stuck. wrote:

that blog is a bit out of date. a track of work called "bosh external cpi" is about finished that enables plugging in the CPIs without having to make bosh component adjustments (depends on the target

typically you need to log into with "bosh ssh api_z1/0" and look at the logs to see why the job did not start. there are usually logs relating to what went wrong in /var/vcap/sys/log wrote:

CVE-2015-1328Severity: High Vendor: Canonical Ubuntu Versions Affected: Canonical Ubuntu 14.04 LTS with 3.16 kernel Description: Philip Pettersson discovered a privilege escalation when using overlayf

sounds like some sort of firewall or security groups issue, where the VMs that are created are not able to talk to the BOSH Director. did you perform this step: http://bosh.io/docs/deploy-microbosh-to