Charm needed: rails (framework)

[Mark Mims]

A framework charm to deploy a Rails application

[Mark Mims (mark-mims)]

working on this

[Dustin Kirkland  (kirkland)]

Dependency of CloudFoundry Server. Marking high.

[Mark Mims (mark-mims)]

this works, but needs:
  - externalize configuration
  - rewrite hooks in ruby (target audience)

[Jorge Castro (jorge)]

It would be interesting to see a Rails charm integrate these as an option: http://wiki.brightbox.co.uk/docs:ruby-ng

[Mark Mims (mark-mims)]

ok, this has been sitting in a usable state for quite a while.

We'll eventuallly split this out into `apache-mod-passenger` and `rails-app` so that `rails-app` can attach to apache, nginx, unicorn, etc... but for now, it's usable as-is so should be in the store.

[Marco Ceppi (marcoceppi)]

Reviewing now

[Marco Ceppi (marcoceppi)]

Hi Mark!

Got a few things I noticed while going through the app, otherwise seriously sweet charm!

# Items
* config-samples/myapp.yaml uses an insecure protocol
* config.yaml repo_type is ambiguous (git/bzr/...) should likely have an explicit lists of acceptable VCS tools since things like svn, hg, etc are not supported.
* Readme has old paths (etc/sample-config.yaml)
* PostgreSQL ruby is installed, but the libpq-dev package isn't. pg gem won't build without this.
* MySQL db relations fail with the following message: http://paste.ubuntu.com/1159576/ setting HOME to /home/ubuntu should resolve this.

# Discussion
* The charm doesn't allow any flexibility of installing additional packages which might be required for a gem to be installed (imagemagik, rmagic, pgsql, etc). This might be a config option? Or possibly just require the user to fork the charm.
* All of the logic, including the configuration logic, is in the install hook. Is it by design that this charm can only be configured during deployment? If so, then having all the config calls in the install hook makes sense. If this charm will ever be set up to allow for dynamic application switching on the fly (deploy foo app; later, change to baz) then this will need to be changed to the config-changed hook. A warning in the readme about this usage would probably be beneficial

# Future?
* Since pgsql is installed, it would be nice to see it as a relation in future versions of this charm

I installed a few different rails apps, from as basic as one I wrote quickly to as complex as Redmine and the charm seems to cover most of the bases, with the exception of the few items above.

[Mark Mims (mark-mims)]

thanks, I'll update and resubmit

[Mark Mims (mark-mims)]

add newrelic sub relations

[Clint Byrum (clint-fewbar)]

I'm a bit concerned about the heavy use of 'gem install'. It doesn't appear that there is any way to restrict gem install to using https in its dependency resolution/downloads. THis puts users at risk of MITM attacks and is against policy for that very reason.

One way to go is to explicitly download the needed gem files from rubygems.org via https. So

wget https://rubygems.org/downloads/bundler-1.2.1.gem
gem install bundler-1.2.1.gem

But, even better would be if we could just tell 'gem install' to *only* use https.

[Mark Mims (mark-mims)]

I think we can add config to set the security policy for the charm.

Here's a snippet from some docs:

{{{
The culprit here is the security policy. RubyGems has several different
security policies. Let’s take a short break and go over the security
policies. Here’s a list of the available security policies, and a brief
description of each one:

NoSecurity – Well, no security at all. Signed packages are treated like unsigned packages.

LowSecurity – Pretty much no security. If a package is signed then RubyGems will make sure the signature matches the signing certificate, and that the signing certificate hasn’t expired, but that’s it. A malicious user could easily circumvent this kind of security.

MediumSecurity – Better than LowSecurity and NoSecurity, but still fallible. Package contents are verified against the signing certificate, and the signing certificate is checked for validity, and checked against the rest of the certificate chain (if you don’t know what a certificate chain is, stay tuned, we’ll get to that). The biggest improvement over LowSecurity is that MediumSecurity won’t install packages that are signed by untrusted sources. Unfortunately, MediumSecurity still isn’t totally secure — a malicious user can still unpack the gem, strip the signatures, and distribute the gem unsigned.

HighSecurity – Here’s the bugger that got us into this mess. The HighSecurity policy is identical to the MediumSecurity policy, except that it does not allow unsigned gems. A malicious user doesn’t have a whole lot of options here; he can’t modify the package contents without invalidating the signature, and he can’t modify or remove signature or the signing certificate chain, or RubyGems will simply refuse to install the package. Oh well, maybe he’ll have better luck causing problems for CPAN users instead :).

}}}

and also

{{{
Usage: gem cert [options]

  Options:
    -a, --add CERT Add a trusted certificate.
    -l, --list List trusted certificates.
    -r, --remove STRING Remove trusted certificates containing STRING.
    -b, --build EMAIL_ADDR Build private key and self-signed certificate
                            for EMAIL_ADDR.
    -C, --certificate CERT Certificate for --sign command.
    -K, --private-key KEY Private key for --sign command.
    -s, --sign NEWCERT Sign a certificate with my key and certificate.
}}}

[Mark Mims (mark-mims)]

ok, the attached branch is updated to address everything but the security policy and the remaining TODOs in the README.

[Mark Mims (mark-mims)]

just some notes while I'm thinking about it...

to make the story around the rails charm more compelling:
  - stronger integration with capistrano (more than just `jitsu capfile`) and maybe vlad-the-deployer
  - pg relations
  - memcached relations
  - mongodb relations?
  - ability to deploy a generic rack-based app (sinatra)... perhaps this is another charm?
  - ability to swap out unicorn(yes) or mongrel(maybe?) for passenger

[Mark Mims (mark-mims)]

oh, and nginx too

[Juan L. Negron (negronjl)]

Reviewing this now ...

-Juan

[Juan L. Negron (negronjl)]

Thanks Mark for this charm.... this is pretty cool!

This looks good to me ... All of the issues that I considered to be blockers have been addressed. The remaining tweaks are not reason enough to keep this from being promulgated.

-Juan

[Juan L. Negron (negronjl)]

Since Mark has promulgate rights, I talked to him over IRC and he'll promulgate this.

-Juan