jtimberman

The Chef-branded distribution is still built from the same open source repositories that the CINC project is built from; it isn't proprietary. It has an additional EULA that requires people to accept and thus [presumably] pay for.

It's basically the same model as Red Hat. Except Chef never had the market penetration and brand recognition as a trusted source that Red Hat has.

Signed, someone who worked for Chef for almost 13 years.

With Chef 11 Server, the CouchDB component is removed for PostgreSQL. RabbitMQ is still there. Opscode provides a single package with everything above libc required to run the server.

http://www.opscode.com/chef/install - "Chef Server" tab.

If you'd like to build your own:

https://github.com/opscode/omnibus-chef https://github.com/opscode/omnibus-software https://github.com/opscode/omnibus-ruby

Cheers, Joshua Timberman, Technical Program Manager, Opscode, Inc.

"ruby_block" is a Chef resource that allows you to execute your favorite ruby code as a separate resource.

You can always drop to regular, plain Ruby, anywhere you like.

What the generated rayburst.sh script does:

1. Writes out configuration for the chef client.

2. Generates a node on the chef server with the specified "run list" (recipes selected in the rayburst site).

3. Install Ruby and Chef RubyGem

4. Runs Chef with the node that was created on the chef server.

You can download and preview everything before it runs as root on your system.

For example, if you choose the normal stack, you get this run list:

recipe[nginx], recipe[passenger], recipe[postgresql::server], recipe[rails], recipe[ruby]

When you run this on a system, like a throwaway VM or EC2 instance, it will download the cookbooks required for this run list, which you can review what they're going to do after the synchronization step of Chef is complete. With rayburst, the cookbooks will be synchronized into /var/cache/rayburst.

If you write such awesome well tested code you won't mind being primary on-call to support it, since it won't break and you won't get paged.

I never said this is a security vulnerability in Rails.

I said it is a bug (and a serious one).

A bug, as you may be aware, is a mistake, fault, failure, problem or other unintended or surprising behavior in software.

See updates to my post for some additional clarification. I hope that helps. Thanks for reading!

My point is that Rails does not take the high road of providing better, sane, secure defaults for people to build their applications.

While the proposed solutions in the issues I linked to were denied, it doesn't mean there shouldn't be some solution added to Rails. This is definitely a case of convenience favored over security.

1. Yeah, the stop-gap "solution" is to white list a number of attributes in order to reduce the data set, because in the most common use case we see, there's only a few attributes that people actually care about in the chef-client context. The node's run list, its IP address or FQDN. Really. That is the most common. For like, 90%+ of the use cases out there. Everyone has a unique snowflake and thats cool, but really, not that much.

2. There's no assumption that systems are correctly configured other than they start from a baseline configuration in the most common use case. We have worked with several customers managing existing infrastructures of running systems that had an unknown baseline and Chef was able to automated the pieces they cared about.

Again with "most common use case."

Cookbooks are accessible via your private key, which Opscode Hosted Chef does not have a copy.

You can choose to encrypt the contents of a data bag using a locally generated (on your hardware, nothing we control) key.

1. We are working on making the search more performance and use less memory.

2. Chef definitely does not discourage declarative configuration. Chef recipes include declarative resource for configuring your infrastructure. Since recipes are an internal ruby dsl, there may be nondeclarative code in them.

3. Chef itself doesn't have a remote trigger mechanism because the. Her run is all about configuring the local node. Nothing prevents you from using the ruby language in a recipe to hook up some kind of remote trigger though. People in the chef community are doing this with projects like Noah and Pylon.

Github.com/lusis/Noah Github.com/fujin/pylon

(disclosure, I work for Opscode.)

To be clear, those dependencies are required for running your own open source chef server.

You can use chef without the server, as chef-solo, or let Opscode run it for you in the form of Opscode Hosted Chef. We do make it easy to install Chef Server through Chef Solo itself, or with our Ubuntu/Debian apt repository.

Hi!

Actually in an upcoming release of Chef, you'll be able to do exactly that - manage Rackspace cloud nodes with the knife command-line tool. What that means is, you can launch new RS Cloud servers with knife, passing in the validation certificate and a run_list of recipes.

For EC2, Opscode provides a reference AMI with Chef pre-installed on Ubuntu 9.10 with a special configuration file that can parse EC2 metadata through Ohai to automatically validate and run a set of recipes. See:

http://wiki.opscode.com/display/chef/Amazon+EC2+AMIs+and+Che...

One of Chef's benefits for managing a dynamic environments is the Search Index feature, which can be used to search for other nodes that have particular roles or attributes set. That is part of what the application cookbook does to dynamically deploy and connect with other systems running services like memcached or mysql.

As for the learning curve and getting up to speed, that varies by person.

Sincerely, Joshua Timberman - Opscode, Inc.