Hi

I am trying to modify cloud foundry - java buildpack to add the consul agent into it, so that the application in the warden container of dea vm can have a consul agent for itself.

I could add the consul zip and unzip it as part of buildpack in the compile script.

But following are the issues I face:


1. I could not start consul agent by providing data-dir option "./consul agent -data-dir /tmp" . There is no response at this point and fails with staging error.

But without data-dir './consul agent' , the application gets staged with the buildpack

Compile script contents related to consul:
------------------------------
value = `unzip /tmp/staged/app/consul-0.5.0_linux_amd64.zip`
#value = `unzip /home/vcap/app/consul-0.5.0_linux_amd64.zip`
puts "Unzipped"
value = `chmod 777 consul`
puts "change mode"
value = `./consul agent -data-dir /tmp ` (Tried /home/vcap , /var/vcap/app as data-dir, but with same error)

We are pushing the app as cf push -p <app.jar>


2. Please let me know if I can access /home/vcap/app folder while staging the application

Thanks in advance...

Regards
Nithiyasri

Hello,

If there is HTTP Error 503 - Service unavailable response from the actual server to the go-router. Will the go-router route the request to another node ?. Is some configuration required at Go-router or it will handle automatically.

Thanks,
Vinod

We are using UAA 3.3.0 as our login server. We needed to customize the html structure of the login page in order to add additional links to it, custom coupon code registration, etc, more than just css, so we set up a spring app to act as the new login server. All this app really does is proxy the requests to UAA, keeping track of the uaa cookies in the session. This works great for the form authentication to the UAA internal login server. All of the /oauth/** requests run through this app to UAA as well.

We are now setting up SAML support and we tried following the same approach by proxying the SAML requests through our login server to UAA. It worked great for Okta, but ADFS not so great. ADFS basic auth was a no go so we configured our ADFS test box to use a login page. UAA doesn't redirect to the ADFS login screen like it does for Okta so when credentials are submitted, they get submitted to our custom app. I'm thinking that we should ditch the custom login server and create a custom build for UAA with the html that we need. Another option might be to run all of the SAML calls directly through UAA, but I'm not sure how to get the custom app to know the user is logged in. I'm concerned that even if we get this pass thru working with our ADFS test box we will just continue to encounter other scenarios with different IdP. What do you guys think? Should we ditch the custom login server? Is there anyway to supply custom HTML after the uaa.war is exploded?

Thanks Chip for this communication.

I'm wondering whether there is a CFF-maintained resource with the list of
CF-related CVEs the OSS community can have access to (ideally in a
programmatic way) ?

Similarly, is there CVE databases into which the CFF feeds the CF-related
CVEs (such as mitre.org [1] into which I could not yet find CF-related CVE
and CFF does not appear as a CNA [2]).

Thanks in advance,

Guillaume.

[1] https://www.google.com/search?q=site%3Acve.mitre.org+cloud+foundry
[2] https://cve.mitre.org/cve/cna.html


Guillaume.

On Thu, Jun 30, 2016 at 6:02 PM, Chip Childers <cchilders(a)cloudfoundry.org>
wrote:

CVE-2016-4468 UAA SQL Injection Severity

High
Vendor

Cloud Foundry Foundation
Versions Affected

-

Cloud Foundry release v237 and earlier versions
-

UAA release v3.4.0 and earlier versions
-

UAA release V12 and earlier versions

Description

There is the potential for a SQL injection attack in UAA for authenticated
users.
Mitigation

OSS users are strongly encouraged to follow one of the mitigations below:


-

Upgrade to Cloud Foundry v238 [1] or later
-

For standalone UAA users
-

For users using UAA Version 3.0.0 - 3.4.0, please upgrade to UAA
Release to v3.3.0.2 [3] or v3.4.1 [4]
-

For users using standalone UAA Version 2.X.X, please upgrade to UAA
Release to v2.7.4.4 [2]
-

For users using UAA-Release (UAA bosh release), please upgrade to
UAA-Release v12.2 [5] if upgrading to v3.4.1 [4] or v11.2 [6] if upgrading
to v3.3.0.2 [3]


Credit

Graham Viski, Digital Transformation Office, Australian Government
References

[1] https://github.com/cloudfoundry/cf-release/releases/tag/v238

[2] https://github.com/cloudfoundry/uaa/releases/tag/2.7.4.4

[3] https://github.com/cloudfoundry/uaa/releases/tag/3.3.0.2

[4] https://github.com/cloudfoundry/uaa/releases/tag/3.4.1

[5]
http://bosh.io/releases/github.com/cloudfoundry/uaa-release?version=12.2

[6]
http://bosh.io/releases/github.com/cloudfoundry/uaa-release?version=11.2

History

2016-06-30: Initial vulnerability report published

Hi Wayne,

About half a year ago I looked into this.
The issue with doing this from the CLI is that with the current CC APIs the CLI would still need to download all the files from git to upload them;
So lots of work for something an alias can do for you just as well, and the only value it would add is that it reduces the number of characters you need to type? Taking your example, by 15 characters (from 86 to 71)?

I thought it would be more interesting if CC could download the app files (and manifest?) from the (remote) repo itself, that would make the push operation significantly faster, maybe open up new workflows like CC pulling updates from git, but I believe the CAPI team at the time wasn’t interested.

Feel free to write a CLI plug-in, publish it in the CF-Community plugin repo and see how well it gets picked up?

Regards,
Dies Koper
Cloud Foundry CLI PM


From: Wayne E. Seguin [mailto:wayneeseguin(a)starkandwayne.com]
Sent: Sunday, July 03, 2016 1:42 AM
To: cf-dev
Subject: [cf-dev] [CF CLI] App Push Question

I know we can specify build pack when doing `cf push`.

I'm wondering if there is a way to also specify the application as either git or tarball uri (filesystem or remote).

Something like,

`cf push -a https://github.com/my/repo.git -b https://my.buildpack.url/`<https://my.buildpack.url/%60>

And be able to skip the `git clone > cd > cf push` workflow for example.
where `-a` is `application code uri` or some such.

If not, this seems to me like a good feature request?

Thanks,

~Wayne

Wayne,

There is a buildpack named "scm-buildpack" by James Bayer [1]. It might be
an answer for your question. Though it seems not having maintained for a
long time, I tried it several times and it basically worked.

But we also know there is some issues [2] [3] with the buildpack.

[1] https://github.com/jbayer/scm-buildpack
[2] https://github.com/jbayer/scm-buildpack/pull/2
[3] https://github.com/jbayer/scm-buildpack/pull/3

Hope it helps,


Wayne E. Seguin wrote

I know we can specify build pack when doing `cf push`.

I'm wondering if there is a way to also specify the application as either
git or tarball uri (filesystem or remote).

Something like,

`cf push -a https://github.com/my/repo.git -b https://my.buildpack.url/`

And be able to skip the `git clone > cd > cf push` workflow for example.
where `-a` is `application code uri` or some such.

If not, this seems to me like a good feature request?

Thanks,

~Wayne

-----
I'm not a ...
noburou taniguchi
--
View this message in context: http://cf-dev.70369.x6.nabble.com/cf-dev-CF-CLI-App-Push-Question-tp5317p5318.html
Sent from the CF Dev mailing list archive at Nabble.com.

I know we can specify build pack when doing `cf push`.

I'm wondering if there is a way to also specify the application as either
git or tarball uri (filesystem or remote).

Something like,

`cf push -a https://github.com/my/repo.git -b https://my.buildpack.url/`

And be able to skip the `git clone > cd > cf push` workflow for example.
where `-a` is `application code uri` or some such.

If not, this seems to me like a good feature request?

Thanks,

~Wayne

Hi, all,

We've finished moving these repositories into the 'cloudfoundry' GitHub org
and updating them to base their import paths on the 'code.cloudfoundry.org'
domain. In terms of tooling to assist with the move, we found that the
existing gomvpkg utility, go-get-able from
github.com/golang/tools/cmd/gomvpkg, handled most of the renaming correctly
within an ordinary GOPATH, although it did not always rewrite paths within
test files.

In the case of BOSH releases that double as GOPATHs with their dependencies
included via submodules, such as diego-release, we found the following Bash
script to be effective at rewriting both the source files in the release
and the BOSH packaging around them. It takes 3 arguments: the import path
of the existing package, the import path of its new location, and the
location of the BOSH release directory. It also assumes the existence of a
separate GOPATH in `~/go` (a common location for a user's default GOPATH).

#!/bin/bash

set -x

usage() {
echo "$0 SOURCE_PACKAGE TARGET_PACKAGE BOSH_RELEASE_DIR"
}

src_component=$1
target_component=$2
bosh_release_dir=$3

if [ -z ${src_component} ]; then
>&2 echo "ERROR: Specify a source package"
usage
exit 1
fi

if [ -z ${target_component} ]; then
>&2 echo "ERROR: Specify a target package"
usage
exit 1
fi

if [ -z ${bosh_release_dir} ]; then
>&2 echo "ERROR: Specify a BOSH release directory"
usage
exit 1
fi

pushd $bosh_release_dir
set -e
gomvpkg -from ${src_component} -to ${target_component}
set +e

list=$(egrep -lir ${src_component} src/ --exclude="*.md"
--exclude="*.test" --exclude=".git")
echo $list | xargs -n 1 sed -i
's|'${src_component}'|'${target_component}'|g'
echo $list | xargs -n 1 gofmt -w

egrep -lir ${src_component} packages/ --exclude="*.md" --exclude="*.test"
| xargs -n 1 sed -i 's|'${src_component}'|'${target_component}'|g'
egrep -lir ${src_component} scripts/ --exclude="*.md" --exclude="*.test"
| xargs -n 1 sed -i 's|'${src_component}'|'${target_component}'|g'
egrep -lir ${src_component} jobs/ --exclude="*.md" --exclude="*.test"
| xargs -n 1 sed -i 's|'${src_component}'|'${target_component}'|g'

rm -f src/${target_component}/.git
popd

pushd ~/go
GOPATH=$PWD
go get ${target_component}
cp -r src/${target_component}/.git
${bosh_release_dir}/src/${target_component}
popd

Diego-release also relies on its sync-submodule-config script (
https://github.com/cloudfoundry/diego-release/blob/develop/scripts/sync-submodule-config)
to ensure that the submodule URLs are updated correctly as part of
committing the update. If your release does not automatically sync its
submodules this way, you will have to update the .gitmodules file in your
repo by hand or with a `sed` command similar to those in the script above.

Thanks,
Eric, CF Runtime Diego PM

On Mon, Jun 27, 2016 at 6:18 AM, Will Pragnell <wpragnell(a)pivotal.io> wrote:

Ignore me, I can't read... looks like this is using that already. Nice!

On 27 June 2016 at 13:56, Will Pragnell <wpragnell(a)pivotal.io> wrote:

Have we abandoned plans for the import path service Eric proposed back in
April? If not, aren't we just going to have to update all our imports again
once that rolls out?

On 25 June 2016 at 18:36, Kris Hicks <khicks(a)pivotal.io> wrote:

I've found when doing this the easiest thing to do is to use sed to
remove existing imports followed by goimports -w on the same files.

KH


On Sunday, June 26, 2016, Amit Gupta <agupta(a)pivotal.io> wrote:

Congrats on making it official!

I assume you folks are going to build some scripts or some "go fmt -r"
to find/change all import paths that need updating. If you find anything
useful that other teams might be able to leverage, sharing would be much
appreciated.

Cheers,
Amit

On Fri, Jun 24, 2016 at 4:20 PM, Onsi Fakhouri <ofakhouri(a)pivotal.io>
wrote:

That stuff has always technically been foundation code and should have
moved out of pivotal-golang into cloudfoundry-incubator long ago. Back
when we made the org the rules about how orgs are structured weren't quite
so clear.

Onsi

On Fri, Jun 24, 2016 at 4:18 PM, Alex Suraci <asuraci(a)pivotal.io>
wrote:

why are we moving the pivotal-golang repos? I thought the point of
that was to be able to create those cheaply for super generic packages that
we just need to have somewhere in cases where the repo incubation
foundation lifecycle crap gets in the way. are we now able to create repos
willy-nilly under the cloudfoundry org?

On Sat, Jun 25, 2016, 6:13 AM James Myers <jmyers(a)pivotal.io> wrote:

Hi all,

We are currently in the process of moving all of the Diego
repositories from `cloudfoundry-incubator` to the `cloudfoundry`
organization.

Specifically we are moving the following repositories to the
`cloudfoundry` organization:

- auction
- auctioneer
- bbs
- benchmark-bbs
- buildpack_app_lifecycle
- cacheddownloader
- cf-debug-server
- cf-lager
- cf_http
- consuladapter
- converger
- diego-ssh
- diego-upgrade-stability-tests
- docker_app_lifecycle
- executor
- file-server
- healthcheck
- inigo
- locket
- rep
- route-emitter
- runtime-schema
- vizzini
- diego-cf-compatibility
- diego-ci-pools
- diego-ci
- diego-design-notes
- diego-dev-notes
- diego-dockerfiles
- diego-perf-release
- diego-release
- diego-stress-tests

We are also moving the following from `pivotal-golang` to
`cloudfoundry` as well:

- archiver
- bytefmt
- clock
- eventhub
- lager
- localip
- operationq

We are also renaming the following, and will be updating their
package names accordingly:

- benchmark-bbs -> benchmarkbbs
- buildpack_app_lifecycle -> buildpackapplifecycle
- cf-debug-server -> debugserver
- cf-lager -> cflager
- cf_http -> cfhttp
- docker_app_lifecycle -> dockerapplifecycle
- file-server -> fileserver
- runtime-schema -> runtimeschema

You might be asking yourself, what does this mean for me?

Generally it means the following:

- If you are importing any of the above repos in your golang code,
you should change it from `
github.com/cloudfoundry-incubator/REPO_NAME`
<http://github.com/cloudfoundry-incubator/REPO_NAME> to `
code.cloudfoundry.org/REPO_NAME`
<http://code.cloudfoundry.org/REPO_NAME>.

- Update your golang code when you update your dependencies to
reference the new package names marked above.

- If you are consuming the Diego bosh release from bosh.io, you
will need to update the location to
http://bosh.io/releases/github.com/cloudfoundry/diego-release.


Other than that, github redirects should handle most of the issues
for you.

As a side note we are also moving the following deprecated
repositories to the `cloudfoundry-attic`:

- diego-acceptance-tests
- diego-smoke-tests
- receptor
- runtime-metrics-server

Let us know if you have any questions.

Best,

Jim + Andrew, CF Diego Team

Another plugin: https://github.com/krujos/scaleover-plugin

I have it set in my env variables for the UAA instance.

http://i.imgur.com/ncaafT6.png

I have also set the DB explicitly in the UAA.yml, but it doesn't seem to be reading it (At least, it still shows mysql2)

https://gist.github.com/bryantp/ebb96e7b3d5208278c9d289f1d9951d9

unless the cf set-env myuaa JBP_CONFIG_SPRING_AUTO_RECONFIGURATION
'[enabled: false]'

is set, the build pack will reconfigure the connection pool

I think it is looking at VCAP Services. It partially configured the url correct (The random Username, Password and DB Name are correct) without me doing anything other than activating the mysql profile.

I have also disabled the Auto Config as per the docs

http://i.imgur.com/ncaafT6.png

Hi John / Eitan,

We have a couple tracks of work planned for the new V3 Cloud Foundry API:

Zero-downtime deployment - Diego to support changing an application
specification of a running LRP in a zero-downtime manner:
https://www.pivotaltracker.com/story/show/111166678

Native support for advanced deployment strategies like blue-green
deployment: https://www.pivotaltracker.com/story/show/124264941


The V3 API is still experimental, but we are working diligently to get to
general availability. Feel free to follow along in our Tracker, read the
docs, and visit us in Slack!

https://www.pivotaltracker.com/n/projects/966314
http://v3-apidocs.cloudfoundry.org/version/release-candidate/index.html
https://cloudfoundry.slack.com/messages/capi/


Thanks,

Nick

--
Nicholas Calugar
Product Manager - Cloud Foundry API
Pivotal Software, Inc.

I don't believe thats the case. It should be set in UAA.yml

Thanks,
Sree Tummidi
Sr. Product Manager
Identity - Pivotal Cloud Foundry

I don't think this is related to PWS. In this case UAA is just another app
running on CF, so it's really an issue about how UAA is loading it's
database configuration. From the instructions here [1], it seems that you
need to disable the Java build pack's auto reconfiguration. Unless UAA is
looking at VCAP_SERVICES for you then you'd need to configure the DB
manually. Have you tried configuring the DB settings in uaa.yml?

Sree - does UAA look at VCAP_SERVICES?

Dan

[1] - https://github.com/cloudfoundry/uaa#deploy-to-cloud-foundry

For PWS issues, you can create a support ticket on run.pivotal.io

Thanks,
Sree Tummidi
Sr. Product Manager
Identity - Pivotal Cloud Foundry


On Fri, Jul 1, 2016 at 10:02 AM, Bryan Perino <Bryan.Perino(a)gmail.com>
wrote:

I cross posted this to StackOverflow:


http://stackoverflow.com/questions/38150593/uaa-in-cloud-foundry-sqlexception

I was not sure if this was a PWS issue or Cloud Foundry. If it's a PWS
issue, this is the wrong place right?

i know that the cf autopilot plugin does this (
https://github.com/concourse/autopilot ).

this other plugin:
https://github.com/bluemixgaragelondon/cf-blue-green-deploy
may also be worth checking out.

i haven't used either enough to really vet them out, but i like this idea
of plugging in a suite of smoke tests to control proceeding with vs
aborting a deployment.

/ eitan

Hi

Is there already a built-in, out of the box solution for blue-green
deployment in CF now without having the need of deploying an app with a
different name and then working with map-route manually? If not, I find
having blue-green out of the box would be great. Right now, CF would switch
automatically at the end of the deployment (with a small downtime tradeoff)
by replacing the existing containers with the new one's.

Thanks.

John

I cross posted this to StackOverflow:

http://stackoverflow.com/questions/38150593/uaa-in-cloud-foundry-sqlexception

I was not sure if this was a PWS issue or Cloud Foundry. If it's a PWS issue, this is the wrong place right?

Hi Dies,

Congrats - great release (as usual)!

With respect to the CLI, I came across a question yesterday I couldn’t answer: Is there a way to list all orgs/spaces that are associated with a particular quota plan?

The best I could come up with was (for orgs):
for o in $(cf orgs); do cf org $o | grep -C 3 my_quota; done

Of course, with a long list of orgs this is running for quite some time. I also checked the Cloud Controller API pages to see if I can come up with something using `cf curl` but couldn’t find anything there.

Any suggestions on how to answer the above question more easily?

Thanks in advance,
Bernd

From: "Koper, Dies" <diesk(a)fast.au.fujitsu.com>
Reply-To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org>
Date: Thursday 30 June 2016 at 02:40
To: "cf-dev(a)lists.cloudfoundry.org" <cf-dev(a)lists.cloudfoundry.org>
Subject: [cf-dev] CF CLI v6.20.0 Released Today

The CF CLI team just cut 6.20.0. Binaries and link to release notes are available at:

https://github.com/cloudfoundry/cli#downloads

Route Services and Routes with Paths

Route services can now be bound to routes with paths.

Binding Security Groups to All Spaces of an Org

Security groups can now be bound to all spaces of an org in one command call.

Fixed Regressions

* Plug-in failures
Some plug-ins failed since cf CLI 6.17.0 due to an unintended change to the response of the CliCommandWithoutTerminalOutput function (#866<https://github.com/cloudfoundry/cli/issues/866>)
* .* in .cfignore
While cf CLI 6.13.0 correctly interprets pattern .* in .cfignore to mean ignore all files starting with a period, cf CLI 6.14.0 and greater ignores all files and fails to push the app.
This has been corrected. (#870<https://github.com/cloudfoundry/cli/issues/870>)
* cf copy-source with non-existing target app produces confusing error message
While cf CLI 6.17.1 correctly fails with a message that the target app could not be found, cf CLI 6.18.1 fails saying the target space could not be found.
This is addressed, and the command's help has been improved to clarify that the target app has to exist. (#849<https://github.com/cloudfoundry/cli/issues/849>)
* Negative WaitGroup Counter Panic
The cf CLI could panic when pushing an app when the noaa library the CLI uses to retrieve logs does a retry. (#850<https://github.com/cloudfoundry/cli/issues/850>)

Updated Commands

* bind-route-service and unbind-route-service now accept a route path
* bind-security-group now allows the space name to be omitted, binding the security group to all spaces of the org

New & Updated Community Plugins

* Copy Env v1.0.0: https://github.com/jthomas/copyenv
* Usage Report v1.3.1: https://github.com/krujos/usagereport-plugin
* Antifreeze v0.3.0: https://github.com/odlp/antifreeze

Enjoy!

Regards,
Dies Koper
Cloud Foundry CLI PM