Date   

Re: Can't login into api

Gwenn Etourneau
 

It seems the routers and Haproxy works as you get the 404 from the routers "404
Not Found: Requested route ('api.subdomain.domain') does not exist."
Maybe something wrong in the manifest especially around system or apps
domain

On Mon, Jul 20, 2015 at 6:26 PM, Schwerdtfeger, Christian <
christian.schwerdtfeger(a)n4group.de> wrote:

Hello together,

i've deployed Cloudfoundry into AWS like following:

- bosh aws create like descriped here:
http://docs.cloudfoundry.org/deploying/ec2/bootstrap-aws-vpc.html
- Installation of bosh like descriped on this page:
http://bosh.io/docs/deploy-microbosh-to-aws.html
- installed cloudfoundry using cf-boshworkspace (
https://github.com/cloudfoundry-community/cf-boshworkspace)

My deployment uses the cf-tiny-scalable.yml deployment of cf-boshworkspace
and is starting secondary AZ nodes for backbone, api and runner.

With some minor modifications i've got the installation to run through
without error.
After that i tried to "curl api.subdomain.domain/info" and get "404 Not
Found: Requested route ('api.subdomain.domain') does not exist."

Does someone of you have a glue where to search the error? The output of
"monit status" on nodes "public_haproxy_z1/0" and "api_z1/0" seems to be
okay. All processes are marked as "running" and "monitored".

Thank you
Christian

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: Merge Request for

Gwenn Etourneau
 

I merge it.
This repos since unmaintained since some month.

On Tue, Jul 21, 2015 at 1:32 AM, Jeff Sloyer <jsloyer(a)gmail.com> wrote:

Hello,

I have submitted a PR (
https://github.com/cloudfoundry-community/cf-meteor-buildpack/pull/3) for
the Meteor buildpack, what is the process for it getting reviewed and
merged?



_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: Send a message to all application instances

Gwenn Etourneau
 

It depends, but what James suggest is to use an external service for
PUB/SUB.
All your application listen on it and they will get notifify.

On Tue, Jul 21, 2015 at 5:15 AM, Peter Dotchev <dotchev(a)gmail.com> wrote:

Hi James,

But how does this service deliver the messages to all app instances? is it
via HTTP?

Best regards,
Peter D


On Mon, Jul 20, 2015 at 11:11 AM, James Bayer <jbayer(a)pivotal.io> wrote:

a common way is to use a pub/sub pattern with a cf service the app binds
to. the service could be something like rabbitmq or redis that supports the
pub/sub pattern.

On Sun, Jul 19, 2015 at 11:35 PM, Peter Dotchev <dotchev(a)gmail.com>
wrote:

Hello,

I could not find a way to send/broadcast a message to all instances of a
given application in Cloud Foundry.
How can I notify all app instances of certain events?
If I just send a HTTP request, CF router will dispatch it to a single
instance of the app.
What solutions do you use in such cases.

Best regards,
Peter D.


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
Thank you,

James Bayer

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Diego log grouping

MJ
 

We have a Diego 1099 deployment and syslog_daemon_config configured. We see a 1:1 mapping for Diego platform messages to syslog messages. In other words, for each syslog message that hits the wire, there is one platform message as its payload. This works well with Splunk, which is ultimately where the messages end up.

We have another deployment, but on Diego 1304, with its syslog_daemon_config identical to the other, but Splunk is *not* ingesting its logs. We ran a packet capture and discovered that this deployment is grouping its log messages in a 1:n manner: For each syslog message on the wire, we have multiple platform messages within, separated by newlines. I suspect this is the reason the logs aren't being ingested.

I took a quick glance at the code and it seems like this might be due to ifrit/grouper, but I can't say for sure.

Has anyone run into this issue?

Thanks,
Mike


Re: 3 etcd nodes don't work well in single zone

Tony
 

Hi Amit,

Thanks for your reply.
Yes, we still get stuck here.

And let's me introduce George who is checking this issue in detail. He will
send log and report with more details to you soon.

BTW, We know how to get logs from bosh vms. Thank you very much.

Regards,
Tony



--
View this message in context: http://cf-dev.70369.x6.nabble.com/cf-dev-3-etcd-nodes-don-t-work-well-in-single-zone-tp746p788.html
Sent from the CF Dev mailing list archive at Nabble.com.


[ANN] Buildpack releases: ruby, php, python, nodejs, staticfile

Mike Dalessio
 

Hello CF community,

I'd like to announce update releases of the ruby, php, python, nodejs and
staticfile buildpacks.

*CF Binaries*

Primarily these releases were made to ship CF-specific binaries, as
discussed earlier on this mailing list, hence the minor version bump for
ruby, python, and nodejs.

The PHP buildpack also rolls in a restructuring of the manifest file,
meaning that instead of enumerating hundreds of PHP and HTTPD modules, the
module files are included in the "parent" tarball. As a result, previous
manifests are unlikely to work, and you'll notice that we've removed the
manifest-including-unsupported.yml file from the repository, and bumped the
major version to indicate a backwards-incompatible change.

*Security*

You'll also note a CVE related to the Rubygems client packaged by JRuby was
addressed in the ruby buildpack with the update of JRuby from 1.7.19 to
1.7.21.
------------------------------
Rubyv1.6.0 - 2015-07-20

https://github.com/cloudfoundry/ruby-buildpack/releases/tag/v1.6.0

- Include CF built binaries (
https://www.pivotaltracker.com/story/show/97136960)

Packaged binaries:

| name | version | cf_stacks |
|----------------------------|------------------------------|------------|
| ruby | 2.0.0 | cflinuxfs2 |
| ruby | 2.1.5 | cflinuxfs2 |
| ruby | 2.1.6 | cflinuxfs2 |
| ruby | 2.2.1 | cflinuxfs2 |
| ruby | 2.2.2 | cflinuxfs2 |
| jruby | ruby-1.9.3-jruby-1.7.21 | cflinuxfs2 |
| jruby | ruby-2.0.0-jruby-1.7.21 | cflinuxfs2 |
| jruby | ruby-2.2.2-jruby-9.0.0.0.rc2 | cflinuxfs2 |
| node | 0.12.7 | cflinuxfs2 |
| bundler | 1.9.7 | cflinuxfs2 |
| libyaml | 0.1.6 | cflinuxfs2 |
| openjdk1.8-latest | - | cflinuxfs2 |
| rails3_serve_static_assets | - | cflinuxfs2 |
| rails_log_stdout | - | cflinuxfs2 |

v1.5.2 - 2015-07-13

https://github.com/cloudfoundry/ruby-buildpack/releases/tag/v1.5.2

-

Update 1.7.* jrubies to 1.7.21 in response to CVE-2015-4020 Add support
for JRuby 9.0.0.0.rc2 Remove support for JRuby 9.0.0.0.rc1 (
https://www.pivotaltracker.com/story/show/98856174)
-

Add support for node version 0.12.7 (
https://www.pivotaltracker.com/story/show/98855140)

Packaged binaries:

| name | version | cf_stacks |
|----------------------------|------------------------------|------------|
| ruby | 2.0.0 | cflinuxfs2 |
| ruby | 2.1.5 | cflinuxfs2 |
| ruby | 2.1.6 | cflinuxfs2 |
| ruby | 2.2.1 | cflinuxfs2 |
| ruby | 2.2.2 | cflinuxfs2 |
| jruby | ruby-1.9.3-jruby-1.7.21 | cflinuxfs2 |
| jruby | ruby-2.0.0-jruby-1.7.21 | cflinuxfs2 |
| jruby | ruby-2.2.2-jruby-9.0.0.0.rc2 | cflinuxfs2 |
| node | 0.12.7 | cflinuxfs2 |
| bundler | 1.9.7 | cflinuxfs2 |
| libyaml | 0.1.6 | cflinuxfs2 |
| openjdk1.8-latest | - | cflinuxfs2 |
| rails3_serve_static_assets | - | cflinuxfs2 |
| rails_log_stdout | - | cflinuxfs2 |

PHPv4.0.0 - 2015-07-20

https://github.com/cloudfoundry/php-buildpack/releases/tag/v4.0.0

-

upgrade PHP 5.6.11, 5.5.27, and 5.4.43 (
https://www.pivotaltracker.com/story/show/98855368)
-

Package all PHP modules in a single tarball

Instead of downloading PHP modules individually, include all modules in
a single tarball to make the manifest more manageable. (
https://www.pivotaltracker.com/story/show/95473520)
-

Package all httpd modules in a single tarball

Instead of downloading httpd modules individually, include all modules
in a single tarball to make the manifest more manageable. (
https://www.pivotaltracker.com/story/show/95473520)
-

Add nginx 1.9.2, upgrade to 1.6.3; drop 1.7.x (
https://www.pivotaltracker.com/story/show/98855608)
-

Include current stack in unsupported stack message (
https://www.pivotaltracker.com/story/show/98579464)

Packaged binaries:

| name | version | cf_stacks |
|----------|---------------|------------|
| php | 5.4.42 | cflinuxfs2 |
| php | 5.4.43 | cflinuxfs2 |
| php | 5.5.26 | cflinuxfs2 |
| php | 5.5.27 | cflinuxfs2 |
| php | 5.6.10 | cflinuxfs2 |
| php | 5.6.11 | cflinuxfs2 |
| hhvm | 3.5.0 | cflinuxfs2 |
| hhvm | 3.5.1 | cflinuxfs2 |
| hhvm | 3.6.0 | cflinuxfs2 |
| hhvm | 3.6.1 | cflinuxfs2 |
| composer | 1.0.0-alpha10 | cflinuxfs2 |
| httpd | 2.4.12 | cflinuxfs2 |
| newrelic | 4.20.2.95 | cflinuxfs2 |
| nginx | 1.6.3 | cflinuxfs2 |
| nginx | 1.8.0 | cflinuxfs2 |
| nginx | 1.9.2 | cflinuxfs2 |

Pythonv1.5.0 - 2015-07-20

https://github.com/cloudfoundry/python-buildpack/releases/tag/v1.5.0

-

Include CF built binaries (
https://www.pivotaltracker.com/story/show/97136960)
-

Include current stack in unsupported stack message (
https://www.pivotaltracker.com/story/show/98579464)
-

Update pip to 7.1.0
-

Update setuptools to 18.0.1
-

Set xtrace if $BUILDPACK_XTRACE set

Packaged binaries:

| name | version | cf_stacks |
|-------------|---------|------------|
| python | 2.7.10 | cflinuxfs2 |
| python | 2.7.9 | cflinuxfs2 |
| python | 3.3.5 | cflinuxfs2 |
| python | 3.3.6 | cflinuxfs2 |
| python | 3.4.2 | cflinuxfs2 |
| python | 3.4.3 | cflinuxfs2 |
| libffi | 3.1 | cflinuxfs2 |
| libmemcache | 1.0.18 | cflinuxfs2 |

NodeJSv1.5.0 - 2015-07-20

https://github.com/cloudfoundry/nodejs-buildpack/releases/tag/v1.5.0

-

remove versions 0.8.x and 0.9.x from manifest (
https://www.pivotaltracker.com/story/show/97770112)
-

Include CF built binaries (
https://www.pivotaltracker.com/story/show/97136960)

Packaged binaries:

| name | version | cf_stacks |
|------|---------|------------|
| node | 0.10.38 | cflinuxfs2 |
| node | 0.10.40 | cflinuxfs2 |
| node | 0.11.15 | cflinuxfs2 |
| node | 0.11.16 | cflinuxfs2 |
| node | 0.12.6 | cflinuxfs2 |
| node | 0.12.7 | cflinuxfs2 |

v1.4.2 -- 2015-07-13

https://github.com/cloudfoundry/nodejs-buildpack/releases/tag/v1.4.2

- Security upgrade to nodejs 0.12.7 Add support for node version 0.10.40
Remove support for node version 0.10.37 (
https://www.pivotaltracker.com/story/show/98855140)

Packaged binaries:

| name | version | cf_stacks |
|------|---------|------------|
| node | 0.10.38 | cflinuxfs2 |
| node | 0.10.40 | cflinuxfs2 |
| node | 0.11.15 | cflinuxfs2 |
| node | 0.11.16 | cflinuxfs2 |
| node | 0.12.4 | cflinuxfs2 |
| node | 0.12.6 | cflinuxfs2 |
| node | 0.12.7 | cflinuxfs2 |
| node | 0.8.27 | cflinuxfs2 |
| node | 0.8.28 | cflinuxfs2 |
| node | 0.9.11 | cflinuxfs2 |
| node | 0.9.12 | cflinuxfs2 |

StaticFilev1.2.1 - 2015-07-17

https://github.com/cloudfoundry/staticfile-buildpack/releases/tag/v1.2.1

-

Adding helpful message for unsupported stack (
https://www.pivotaltracker.com/story/show/98579464)
-

Compress nginx response body for more MIME types (
https://www.pivotaltracker.com/story/show/98128132)
-

Update nginx to version 1.8.0 (
https://www.pivotaltracker.com/story/show/97663450)

Packaged binaries:

| name | version | cf_stacks |
|-------|---------|------------|
| nginx | 1.8.0 | cflinuxfs2 |



.


Re: 3 etcd nodes don't work well in single zone

Amit Kumar Gupta
 

Hi Tony,

Are you still having this issue?

Having 3 etcd nodes in a single zone should work perfectly fine. Can you
include logs from your HM9k nodes and your etcd nodes covering a few minutes
where the messed up instance reporting issue is happening. Please let me
know if you need guidance in getting logs of a BOSH VM.

Amit



-----
Amit, CF OSS Release Integration PM
Pivotal Software, Inc.
--
View this message in context: http://cf-dev.70369.x6.nabble.com/cf-dev-3-etcd-nodes-don-t-work-well-in-single-zone-tp746p786.html
Sent from the CF Dev mailing list archive at Nabble.com.


Re: Send a message to all application instances

Peter Dotchev <dotchev@...>
 

Hi James,

But how does this service deliver the messages to all app instances? is it
via HTTP?

Best regards,
Peter D

On Mon, Jul 20, 2015 at 11:11 AM, James Bayer <jbayer(a)pivotal.io> wrote:

a common way is to use a pub/sub pattern with a cf service the app binds
to. the service could be something like rabbitmq or redis that supports the
pub/sub pattern.

On Sun, Jul 19, 2015 at 11:35 PM, Peter Dotchev <dotchev(a)gmail.com> wrote:

Hello,

I could not find a way to send/broadcast a message to all instances of a
given application in Cloud Foundry.
How can I notify all app instances of certain events?
If I just send a HTTP request, CF router will dispatch it to a single
instance of the app.
What solutions do you use in such cases.

Best regards,
Peter D.


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
Thank you,

James Bayer

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


UAA Release 2.4.1 Now Available !

Sree Tummidi
 

*Features*

- Update the Identity Provider End Point to save and retrieve Lockout
policy per zone <https://www.pivotaltracker.com/story/show/87445084>
- Show relevant message after user lockout
<https://www.pivotaltracker.com/story/show/98994270>
- Updated SAML identity provider configuration to accept an
addShadowUser property to govern shadow account creating during SAML
Authentication <https://www.pivotaltracker.com/story/show/97780020>
- Expose Managing /Users & /Groups to a Zone Admin
<https://www.pivotaltracker.com/story/show/98490322>
- New Scope for Creating Clients in a Zone
<https://www.pivotaltracker.com/story/show/98491608>
- Allow to build uaa with Java 8
<https://www.pivotaltracker.com/story/show/98609740>

*Bug Fixes*

- UAADB Housekeeping: Clean up unused/expired oauth_codes and one time
passcodes <https://www.pivotaltracker.com/story/show/98149612>
- Querying users with pagination will return duplicate users
<https://www.pivotaltracker.com/story/show/96657510>
- Serialization/deserialization issues of Java Objects stored in UAADB
<https://www.pivotaltracker.com/story/show/98148936>


View it on GitHub <https://github.com/cloudfoundry/uaa/releases/tag/2.4.1>.


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


Merge Request for

Jeff Sloyer
 

Hello,

I have submitted a PR (
https://github.com/cloudfoundry-community/cf-meteor-buildpack/pull/3) for
the Meteor buildpack, what is the process for it getting reviewed and
merged?


Can't login into api

Schwerdtfeger, Christian <christian.schwerdtfeger@...>
 

Hello together,

i've deployed Cloudfoundry into AWS like following:

- bosh aws create like descriped here:
http://docs.cloudfoundry.org/deploying/ec2/bootstrap-aws-vpc.html
- Installation of bosh like descriped on this page:
http://bosh.io/docs/deploy-microbosh-to-aws.html
- installed cloudfoundry using cf-boshworkspace (
https://github.com/cloudfoundry-community/cf-boshworkspace)

My deployment uses the cf-tiny-scalable.yml deployment of cf-boshworkspace
and is starting secondary AZ nodes for backbone, api and runner.

With some minor modifications i've got the installation to run through
without error.
After that i tried to "curl api.subdomain.domain/info" and get "404 Not
Found: Requested route ('api.subdomain.domain') does not exist."

Does someone of you have a glue where to search the error? The output of
"monit status" on nodes "public_haproxy_z1/0" and "api_z1/0" seems to be
okay. All processes are marked as "running" and "monitored".

Thank you
Christian


Re: Send a message to all application instances

James Bayer
 

a common way is to use a pub/sub pattern with a cf service the app binds
to. the service could be something like rabbitmq or redis that supports the
pub/sub pattern.

On Sun, Jul 19, 2015 at 11:35 PM, Peter Dotchev <dotchev(a)gmail.com> wrote:

Hello,

I could not find a way to send/broadcast a message to all instances of a
given application in Cloud Foundry.
How can I notify all app instances of certain events?
If I just send a HTTP request, CF router will dispatch it to a single
instance of the app.
What solutions do you use in such cases.

Best regards,
Peter D.


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

--
Thank you,

James Bayer


Send a message to all application instances

Peter Dotchev <dotchev@...>
 

Hello,

I could not find a way to send/broadcast a message to all instances of a
given application in Cloud Foundry.
How can I notify all app instances of certain events?
If I just send a HTTP request, CF router will dispatch it to a single
instance of the app.
What solutions do you use in such cases.

Best regards,
Peter D.


Re: Did anybody deploy a wiki as app to CF?

sabith ks
 

There are couple of them listed in the php buildpack @
https://github.com/cloudfoundry/php-buildpack#examples

On Sat, Jul 18, 2015 at 12:29 PM James Bayer <jbayer(a)pivotal.io> wrote:

i started a list of 3rd party compatible apps [1] for cloud foundry. if
you know of apps that work, please add it on the wiki, especially if there
are setup steps.


https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/3rd-Party-Compatible-Apps

On Fri, Jul 17, 2015 at 1:13 PM, john mcteague <john.mcteague(a)gmail.com>
wrote:

We've successfully deployed Drupal (7.3x), we used the blog article as a
starting point, but are using the vanilla php bp (so no varnish) and are
using s3fs module against our own internal s3 store for images. Modules and
themes need to be pushed as part of the app so we dont loose them on
restage activities.

In addition we have mediawiki running. We dont have any s3 filesystem
configured so we need to push images along with the main app otherwise we
loose them. For this reason its not a general purpose wiki.
LocalSettings.php was modified to read the VCAP_SERVICES data for mysql.

John



On Fri, Jul 17, 2015 at 2:24 PM, Daniel Mikusa <dmikusa(a)pivotal.io>
wrote:

On Fri, Jul 17, 2015 at 2:08 AM, James Bayer <jbayer(a)pivotal.io> wrote:

this shows how to use drupal which is a cms with wiki functions
http://blog.pivotal.io/pivotal-cloud-foundry/products/how-to-deploy-drupal-to-pivotal-cf-within-seconds
Be careful with this. It uses a custom build pack (fork of standard PHP
BP) and last I saw, it wasn't updated for `cflinuxfs2`.

Dan




if you're in a private deployment, the services shown for drupal are
both available as oss and listed on bosh.io.

mediawiki is a php app with mysql as an option:
https://www.mediawiki.org

but i'm not aware of install instructions for that. there are other
options here: https://en.wikipedia.org/wiki/List_of_wiki_software

On Fri, Jul 10, 2015 at 3:09 PM, jtuchscherer(a)pivotal.io <
jtuchscherer(a)pivotal.io> wrote:

Hi Stephan,

I managed to get an instiki(instiki.org) instance up and running on
PWS. I
had to change a few things to get it to work and even with those
changes, it
isn't great yet. For example, uploaded files are stored locally in the
Warden container. Therefore, they get lost when the app is restarted.
But it
wouldn't be to hard to change the code to use an S3 bucket as a storage
solution, I just didn't bother yet.

I will clean up my local changes and document them, then I'll push
them up
to github.

P.S.: I also looked for some other open source wiki engines. I didn't
find a
single one that could be deployed to CF (or any other PaaS) without
major
changes.



--
View this message in context:
http://cf-dev.70369.x6.nabble.com/cf-dev-Did-anybody-deploy-a-wiki-as-app-to-CF-tp643p680.html
Sent from the CF Dev mailing list archive at Nabble.com.
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
Thank you,

James Bayer

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
Thank you,

James Bayer
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
Thanks
Sabith
408.896.6261
Mail send from portable device, excuse for any typos


Re: Did anybody deploy a wiki as app to CF?

James Bayer
 

i started a list of 3rd party compatible apps [1] for cloud foundry. if you
know of apps that work, please add it on the wiki, especially if there are
setup steps.

https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/3rd-Party-Compatible-Apps

On Fri, Jul 17, 2015 at 1:13 PM, john mcteague <john.mcteague(a)gmail.com>
wrote:

We've successfully deployed Drupal (7.3x), we used the blog article as a
starting point, but are using the vanilla php bp (so no varnish) and are
using s3fs module against our own internal s3 store for images. Modules and
themes need to be pushed as part of the app so we dont loose them on
restage activities.

In addition we have mediawiki running. We dont have any s3 filesystem
configured so we need to push images along with the main app otherwise we
loose them. For this reason its not a general purpose wiki.
LocalSettings.php was modified to read the VCAP_SERVICES data for mysql.

John



On Fri, Jul 17, 2015 at 2:24 PM, Daniel Mikusa <dmikusa(a)pivotal.io> wrote:

On Fri, Jul 17, 2015 at 2:08 AM, James Bayer <jbayer(a)pivotal.io> wrote:

this shows how to use drupal which is a cms with wiki functions
http://blog.pivotal.io/pivotal-cloud-foundry/products/how-to-deploy-drupal-to-pivotal-cf-within-seconds
Be careful with this. It uses a custom build pack (fork of standard PHP
BP) and last I saw, it wasn't updated for `cflinuxfs2`.

Dan




if you're in a private deployment, the services shown for drupal are
both available as oss and listed on bosh.io.

mediawiki is a php app with mysql as an option:
https://www.mediawiki.org

but i'm not aware of install instructions for that. there are other
options here: https://en.wikipedia.org/wiki/List_of_wiki_software

On Fri, Jul 10, 2015 at 3:09 PM, jtuchscherer(a)pivotal.io <
jtuchscherer(a)pivotal.io> wrote:

Hi Stephan,

I managed to get an instiki(instiki.org) instance up and running on
PWS. I
had to change a few things to get it to work and even with those
changes, it
isn't great yet. For example, uploaded files are stored locally in the
Warden container. Therefore, they get lost when the app is restarted.
But it
wouldn't be to hard to change the code to use an S3 bucket as a storage
solution, I just didn't bother yet.

I will clean up my local changes and document them, then I'll push them
up
to github.

P.S.: I also looked for some other open source wiki engines. I didn't
find a
single one that could be deployed to CF (or any other PaaS) without
major
changes.



--
View this message in context:
http://cf-dev.70369.x6.nabble.com/cf-dev-Did-anybody-deploy-a-wiki-as-app-to-CF-tp643p680.html
Sent from the CF Dev mailing list archive at Nabble.com.
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
Thank you,

James Bayer

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
Thank you,

James Bayer


Re: [buildpacks] CF-built binaries: release timeline and beta testing

James Bayer
 

mike d is the best to answer, but i'll take a crack at it

On Fri, Jul 17, 2015 at 3:24 PM, Shawn Nielsen <sknielse(a)gmail.com> wrote:

Two questions on these cf-built binaries:

1. From my understanding, the purpose of this is to compile the binaries
so they are optimized for the cf specific stacks (e.g. cflinuxfs2 ) as
opposed to something that was generically compiled (e.g. to 64 bit
trusty). Can you confirm this or expound upon this if there are other
reasons?
for some buildpacks, we have been relying on heroku binaries which is an
external dependency. we want the cf team to be in complete control of how
and when the binaries are built. this ensures cf can be in control of our
own destiny when for patching security issues or bugs. additionally it
means cf can take responsibility for how the binaries are compiled to
increase trust of the binary contents.



2. Are these binaries available in offline mode only or is there also
intent that they will be hosted, allowing us to consume them in an online
mode?
most/all cf buildpacks are available in online and offline mode as i
understand it. see:
https://github.com/cloudfoundry-incubator/buildpack-packager/blob/master/doc/disconnected_environments.md



Thanks,

-Shawn

On Mon, Jul 13, 2015 at 2:08 PM, Mike Dalessio <mdalessio(a)pivotal.io>
wrote:



On Mon, Jul 13, 2015 at 1:08 PM, Daniel Mikusa <dmikusa(a)pivotal.io>
wrote:

On Wed, Jul 8, 2015 at 1:55 PM, Mike Dalessio <mdalessio(a)pivotal.io>
wrote:

Hi all,

In the June CAB call, it was mentioned that the Buildpacks team was
working on generating CF-specific binaries to be packaged in the
buildpacks. I'm pleased to announce that the team is ready to start
shipping these binaries in the golang, nodejs, php, python, and ruby
buildpacks for the cflinuxfs2 stack.

*__We're planning to cut releases of these buildpacks with the CF*
*binaries on Monday, 20 July.__*

In the meantime, I'd like to ask the community to beta these buildpacks
and give us feedback.

We're successfully running [BRATs][1] (the buildpack runtime acceptance
tests) on these binaries, so we don't expect any issues; but we'd love to
hear if anyone experiences any issues deploying their apps.

Obviously, until we cut official releases, you should use judgement
when deciding where to use these beta buildpacks.

[1]: https://github.com/cloudfoundry/brats


*## Timeline, Versioning and Proposed Changes*

Unless we hear of any blocking issues, we'll cut official releases of
the go, node, php, python and ruby buildpacks on July 20th.

When we cut these releases, we'll be bumping the major version number,
and removing the `manifest-including-unsupported.yml` file from the
repository HEAD. I'd love to hear anyone's opinion on these changes as well.


*## How to deploy with the "beta" binary buildpacks*

Until we cut official releases, we are maintaining a git branch in each
buildpack repository, named `cf-binary-beta`, in which the manifest points
at our CF-specific binaries.

If your CF deployment has access to the public internet, you can push
your app and specify the github repo and branch with the `-b` option.

*__Go:__*

`cf push <appname> -b
https://github.com/cloudfoundry/go-buildpack#cf-binary-beta`
<https://github.com/cloudfoundry/go-buildpack#cf-binary-beta>

*__Node:__*

`cf push <appname> -b
https://github.com/cloudfoundry/nodejs-buildpack#cf-binary-beta`
<https://github.com/cloudfoundry/nodejs-buildpack#cf-binary-beta>

*__PHP:__*

`cf push <appname> -b
https://github.com/cloudfoundry/php-buildpack#cf-binary-beta`
<https://github.com/cloudfoundry/php-buildpack#cf-binary-beta>
Looks good mostly. One minor issue. It seems like the snmp extension
is not loading correctly. Looks to be missing a required shared library.

2015-07-13T12:29:53.09-0400 [App/0] OUT 16:29:53 php-fpm |
[13-Jul-2015 16:29:53] NOTICE: PHP message: PHP Warning: PHP Startup:
Unable to load dynamic library
'/home/vcap/app/php/lib/php/extensions/no-debug-non-zts-20100525/snmp.so' -
libnetsnmp.so.30: cannot open shared object file: No such file or directory
in Unknown on line 0

That's with PHP 5.4.42, 5.5.26 and 5.6.10.
Good catch, I've created a story for this:
https://www.pivotaltracker.com/story/show/98980384





One other thing, which is not really an issue, but perhaps an
optimization. I noticed for the PHP extensions the bundle has both ".a"
and ".so" files for many of the extensions. The ".a" static libraries
should not be necessary, just the ".so" shared libraries. Seems like
removing them could save 8 to 9M. You could save another 25M by deleting
the bin/php-cgi file. You really only need bin/php for cmd line stuff and
sbin/php-fpm for web apps. Can't think of any reason you'd need / want to
do cgi. It's not a ton of space, 35M X 3 (each current version) + 35M X 3
(each of previous versions) - whatever compression will save. Just thought
I'd throw it out there though.

Another good catch, I've created a story to look into it:
https://www.pivotaltracker.com/story/show/98980692




Dan




*__Python:__*

`cf push <appname> -b
https://github.com/cloudfoundry/python-buildpack#cf-binary-beta`
<https://github.com/cloudfoundry/python-buildpack#cf-binary-beta>

*__Ruby:__*

`cf push <appname> -b
https://github.com/cloudfoundry/ruby-buildpack#cf-binary-beta`
<https://github.com/cloudfoundry/ruby-buildpack#cf-binary-beta>


If your CF deployment doesn't have access to the public internet and
you'd like to try these buildpacks, please reach out directly and we'll
figure out the best way to accommodate.


*## Tooling Details*

If you'd like to take a look at how we're currently building these
binaries, our tooling is open-sourced at:

https://github.com/cloudfoundry/binary-builder
Note that `binary-builder` uses the rootfs docker image to compile each
binary, which means that this tool can easily be extended to essentially
cross-compile **any** binary for a CF rootfs. We'd love to hear your
feedback on this, as well.


Thanks,
-mike



_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
Thank you,

James Bayer


Re: [buildpacks] CF-built binaries: release timeline and beta testing

Shawn Nielsen
 

Two questions on these cf-built binaries:

1. From my understanding, the purpose of this is to compile the binaries
so they are optimized for the cf specific stacks (e.g. cflinuxfs2 ) as
opposed to something that was generically compiled (e.g. to 64 bit
trusty). Can you confirm this or expound upon this if there are other
reasons?

2. Are these binaries available in offline mode only or is there also
intent that they will be hosted, allowing us to consume them in an online
mode?

Thanks,

-Shawn

On Mon, Jul 13, 2015 at 2:08 PM, Mike Dalessio <mdalessio(a)pivotal.io> wrote:



On Mon, Jul 13, 2015 at 1:08 PM, Daniel Mikusa <dmikusa(a)pivotal.io> wrote:

On Wed, Jul 8, 2015 at 1:55 PM, Mike Dalessio <mdalessio(a)pivotal.io>
wrote:

Hi all,

In the June CAB call, it was mentioned that the Buildpacks team was
working on generating CF-specific binaries to be packaged in the
buildpacks. I'm pleased to announce that the team is ready to start
shipping these binaries in the golang, nodejs, php, python, and ruby
buildpacks for the cflinuxfs2 stack.

*__We're planning to cut releases of these buildpacks with the CF*
*binaries on Monday, 20 July.__*

In the meantime, I'd like to ask the community to beta these buildpacks
and give us feedback.

We're successfully running [BRATs][1] (the buildpack runtime acceptance
tests) on these binaries, so we don't expect any issues; but we'd love to
hear if anyone experiences any issues deploying their apps.

Obviously, until we cut official releases, you should use judgement when
deciding where to use these beta buildpacks.

[1]: https://github.com/cloudfoundry/brats


*## Timeline, Versioning and Proposed Changes*

Unless we hear of any blocking issues, we'll cut official releases of
the go, node, php, python and ruby buildpacks on July 20th.

When we cut these releases, we'll be bumping the major version number,
and removing the `manifest-including-unsupported.yml` file from the
repository HEAD. I'd love to hear anyone's opinion on these changes as well.


*## How to deploy with the "beta" binary buildpacks*

Until we cut official releases, we are maintaining a git branch in each
buildpack repository, named `cf-binary-beta`, in which the manifest points
at our CF-specific binaries.

If your CF deployment has access to the public internet, you can push
your app and specify the github repo and branch with the `-b` option.

*__Go:__*

`cf push <appname> -b
https://github.com/cloudfoundry/go-buildpack#cf-binary-beta`
<https://github.com/cloudfoundry/go-buildpack#cf-binary-beta>

*__Node:__*

`cf push <appname> -b
https://github.com/cloudfoundry/nodejs-buildpack#cf-binary-beta`
<https://github.com/cloudfoundry/nodejs-buildpack#cf-binary-beta>

*__PHP:__*

`cf push <appname> -b
https://github.com/cloudfoundry/php-buildpack#cf-binary-beta`
<https://github.com/cloudfoundry/php-buildpack#cf-binary-beta>
Looks good mostly. One minor issue. It seems like the snmp extension is
not loading correctly. Looks to be missing a required shared library.

2015-07-13T12:29:53.09-0400 [App/0] OUT 16:29:53 php-fpm |
[13-Jul-2015 16:29:53] NOTICE: PHP message: PHP Warning: PHP Startup:
Unable to load dynamic library
'/home/vcap/app/php/lib/php/extensions/no-debug-non-zts-20100525/snmp.so' -
libnetsnmp.so.30: cannot open shared object file: No such file or directory
in Unknown on line 0

That's with PHP 5.4.42, 5.5.26 and 5.6.10.
Good catch, I've created a story for this:
https://www.pivotaltracker.com/story/show/98980384





One other thing, which is not really an issue, but perhaps an
optimization. I noticed for the PHP extensions the bundle has both ".a"
and ".so" files for many of the extensions. The ".a" static libraries
should not be necessary, just the ".so" shared libraries. Seems like
removing them could save 8 to 9M. You could save another 25M by deleting
the bin/php-cgi file. You really only need bin/php for cmd line stuff and
sbin/php-fpm for web apps. Can't think of any reason you'd need / want to
do cgi. It's not a ton of space, 35M X 3 (each current version) + 35M X 3
(each of previous versions) - whatever compression will save. Just thought
I'd throw it out there though.

Another good catch, I've created a story to look into it:
https://www.pivotaltracker.com/story/show/98980692




Dan




*__Python:__*

`cf push <appname> -b
https://github.com/cloudfoundry/python-buildpack#cf-binary-beta`
<https://github.com/cloudfoundry/python-buildpack#cf-binary-beta>

*__Ruby:__*

`cf push <appname> -b
https://github.com/cloudfoundry/ruby-buildpack#cf-binary-beta`
<https://github.com/cloudfoundry/ruby-buildpack#cf-binary-beta>


If your CF deployment doesn't have access to the public internet and
you'd like to try these buildpacks, please reach out directly and we'll
figure out the best way to accommodate.


*## Tooling Details*

If you'd like to take a look at how we're currently building these
binaries, our tooling is open-sourced at:

https://github.com/cloudfoundry/binary-builder
Note that `binary-builder` uses the rootfs docker image to compile each
binary, which means that this tool can easily be extended to essentially
cross-compile **any** binary for a CF rootfs. We'd love to hear your
feedback on this, as well.


Thanks,
-mike



_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: Soliciting feedback on a UX change for route services

Shannon Coen
 

Guillaume,

Including the app_id with the request forwarded to the route service
becomes misleading/false when, upon receiving the request back from the
route service, the pre-determined app no longer has instances available. At
that time GoRouter should be able to choose a different app instance for
the route, possibly of a different app, rather than rejecting the request
or re-forwarding the request to the route service with a different app id.
Otherwise, the route service may be making false associations.

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Thu, Jun 25, 2015 at 9:19 PM, Guillaume Berche <bercheg(a)gmail.com> wrote:

I was about to suggest a similar UX for expressing a list of route
services, by relying on params ordering

cf update-route DOMAIN [-n HOST] (-s 'service instance' )*
cf update-route DOMAIN [-n HOST] -s caching -s https-only -s rate-limiting

Besides, If the MVP does not include support for multiple route services,
route service implementers might be able to experiment with supporting
arbitrary params as a way for users to specify fine grain options, possibly
ordered

cf create-service large-grain-route-service -p '{ "caching": true,
"ssl_only": true, "rate_limit": 3 }'

+1 for Mike's suggestions to allow for some route services to be
implemented in an upfront LB such as no router. This might address the
latency and availability concerns in the initial MVP ("route services to
forward requests back through the LB and GoRouter")

Lastly, it seems important that route services be able to output logs that
end up being associated with the app that receive the associated traffic
(e.g. cache hit or cache miss for a specific incoming request). With route
services being associated to routes (and not being bound to app instances
anymore), I'd like to re-iterate the suggestion I made in the design
document (on Feb 17) to have the gorouter include the app_id in the headers
of the signed request it sends to route service(s). This will allow for a
route service with log_emiter scope to add entries to the proper app
through loggregator/doppler. Of course, this also means that when a route
is associated to multiple apps, the load balancing decision among app is
made prior to sending traffic to route service(s). I'd imagine the app_id
could be propagated in the signed request headers when going through route
services and finally reaching the gorouter before hitting the app (as to
preserve the stateless nature of gorouter).

Guillaume.


On Fri, Jun 26, 2015 at 12:04 AM, Shannon Coen <scoen(a)pivotal.io> wrote:

This is great. Thank you, Mike.

FWIW, James had the following suggestion update-route could be used to
associate multiple routes, and express their chain order. We're not fixed
on this UX. We'll consider this more carefully when we get closer to the CF
CLI work.

cf update-route DOMAIN [-n HOST] [-s 'list,of,service,instances']

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Thu, Jun 25, 2015 at 12:58 PM, Mike Youngstrom <youngm(a)gmail.com>
wrote:


This is interesting. Could you flesh this out for me? What use cases do
you have in mind for associating a service instance with a route, but not
providing a forwarding address?

I would imagine you could bind a service to a route any time you want to
customize incoming traffic in some way. But that customization wouldn't
necessarily have to be implemented as a proxy.

Here are a few examples:

* A Public facing service as an indicator that a given route should be
made public facing. (Would require a broker to orchestrate stuff outside
of CF DNS, applying DoS security profiles to the route, force ssl on the
front end load balancer, etc.)
* A service to apply web front caching to a route. Could be done as a
proxy but could also be done by changing config in a front end load
balancer that supports caching like an F5 LTM.
* Rate limiting. Could be implemented as a proxy, or could be
implemented by applying some config in a front end load balancer
* A security service to limit client IP addresses allowed to connect on
a route. Again could be implemented as a proxy if you trust
X-Forwarded-For or simply change some config on a front end load balancer
no new proxy needed.

Basically a service applied to a route could trigger and manage all
kinds of functionality not necessarily implemented as proxy orchestrated by
the GoRouter.

It also occurs to me that the only time chain ordering of route services
seems to be an issue is in the case of a proxy url. So, it is unfortunate
that I'd be limited to binding only one route service when I may want to
apply all kinds of functionality to a route not implemented as a proxy
because user defined ordering isn't an issue.

That said I can see how it can be difficult for CF to provide a generic
solution to the kind of functionality applied above and that you may not
want to distract from the basic Route Services MVP to accommodate these
types of use cases. I guess I can only hope that you keep the concept of
applying non proxy functionality to a route in mind as you move through
your MVP.

Mike

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: Did anybody deploy a wiki as app to CF?

john mcteague <john.mcteague@...>
 

We've successfully deployed Drupal (7.3x), we used the blog article as a
starting point, but are using the vanilla php bp (so no varnish) and are
using s3fs module against our own internal s3 store for images. Modules and
themes need to be pushed as part of the app so we dont loose them on
restage activities.

In addition we have mediawiki running. We dont have any s3 filesystem
configured so we need to push images along with the main app otherwise we
loose them. For this reason its not a general purpose wiki.
LocalSettings.php was modified to read the VCAP_SERVICES data for mysql.

John

On Fri, Jul 17, 2015 at 2:24 PM, Daniel Mikusa <dmikusa(a)pivotal.io> wrote:

On Fri, Jul 17, 2015 at 2:08 AM, James Bayer <jbayer(a)pivotal.io> wrote:

this shows how to use drupal which is a cms with wiki functions
http://blog.pivotal.io/pivotal-cloud-foundry/products/how-to-deploy-drupal-to-pivotal-cf-within-seconds
Be careful with this. It uses a custom build pack (fork of standard PHP
BP) and last I saw, it wasn't updated for `cflinuxfs2`.

Dan




if you're in a private deployment, the services shown for drupal are both
available as oss and listed on bosh.io.

mediawiki is a php app with mysql as an option:
https://www.mediawiki.org

but i'm not aware of install instructions for that. there are other
options here: https://en.wikipedia.org/wiki/List_of_wiki_software

On Fri, Jul 10, 2015 at 3:09 PM, jtuchscherer(a)pivotal.io <
jtuchscherer(a)pivotal.io> wrote:

Hi Stephan,

I managed to get an instiki(instiki.org) instance up and running on
PWS. I
had to change a few things to get it to work and even with those
changes, it
isn't great yet. For example, uploaded files are stored locally in the
Warden container. Therefore, they get lost when the app is restarted.
But it
wouldn't be to hard to change the code to use an S3 bucket as a storage
solution, I just didn't bother yet.

I will clean up my local changes and document them, then I'll push them
up
to github.

P.S.: I also looked for some other open source wiki engines. I didn't
find a
single one that could be deployed to CF (or any other PaaS) without major
changes.



--
View this message in context:
http://cf-dev.70369.x6.nabble.com/cf-dev-Did-anybody-deploy-a-wiki-as-app-to-CF-tp643p680.html
Sent from the CF Dev mailing list archive at Nabble.com.
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
Thank you,

James Bayer

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: Encryption method of CF CLI when running commands

James Bayer
 

the "cf api api.SYSTEMDOMAIN" command requires https with a valid cert
unless you use the flag that bypasses that.

$ cf api api.example.com
Setting api endpoint to api.example.com...
FAILED
Invalid SSL Cert for api.example.com
TIP: Use 'cf api --skip-ssl-validation' to continue with an insecure API
endpoint

once targeted, you can see the other endpoint protocols by looking at the
/v2/info endpoint. the default settings are to use HTTPS everywhere.
whether you use a valid cert or not depends on how you configure the
server-side and whether you instruct the cli to ignore the cert checking.

e.g. this is for run.pivotal.io which uses secure transports for the UAA
(where your user/pw is sent unless you're using a SAML endpoint with "cf
login --sso") and getting the logs out of the system.

cf curl /v2/info

{
"name": "vcap",
"build": "2222",
"support": "http://support.cloudfoundry.com",
"version": 2,
"description": "Cloud Foundry sponsored by Pivotal",
"authorization_endpoint": "https://login.run.pivotal.io",
"token_endpoint": "https://uaa.run.pivotal.io",
"min_cli_version": null,
"min_recommended_cli_version": null,
"api_version": "2.33.0",
"app_ssh_endpoint": "ssh.run.pivotal.io:2222",
"app_ssh_host_key_fingerprint": null,
"logging_endpoint": "wss://loggregator.run.pivotal.io:4443",
"doppler_logging_endpoint": "wss://doppler.run.pivotal.io:443"
}

On Fri, Jul 17, 2015 at 9:55 AM, César Iván . <cesar_k13(a)hotmail.com> wrote:

Hi everyone,

I'm going to try to develop a plugin that uses the CF CLI, but I'm a bit
worried about security, so the question is, what type of encryption uses
the CF CLI when running commands?

i.e: when I run the *login *command I need to type my user and pass, how
does it transport data from the server to the client and vice versa?

Thanks!

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

--
Thank you,

James Bayer

8601 - 8620 of 9425