Commit 13518e8

For Gem Bundler: include `bundler` or `bundler08` in the gems list. `bundle install` or `gem bundle` will be run before migrations.

For config.gem in environment: `rake gems:install RAILS_ENV=<node environment>` will be run when a Gem Bundler command is not.

"production": {

environment 'RAILS_ENV' => node.app_environment

before_migrate do

if app['gems'].has_key?('bundler')

execute "bundle install" do

ignore_failure true

cwd release_path

end

elsif app['gems'].has_key?('bundler08')

execute "gem bundle" do

ignore_failure true

cwd release_path

end

elsif node.app_environment && app['databases'].has_key?(node.app_environment)

# chef runs before_migrate, then symlink_before_migrate symlinks, then migrations,

# yet our before_migrate needs database.yml to exist (and must complete before

# migrations).

#

# maybe worth doing run_symlinks_before_migrate before before_migrate callbacks,

# or an add'l callback.

execute "(ln -s ../../../shared/database.yml config/database.yml && rake gems:install); rm config/database.yml" do

ignore_failure true

cwd release_path

end

end

end

symlink_before_migrate({

"database.yml" => "config/database.yml",

"memcached.yml" => "config/memcached.yml"

})

node.default[:unicorn][:worker_processes] = [node[:cpu][:total].to_i * 4, 8].min

Chef 0.8.16 or later is required.

Chef 0.9.0 or later is required to use the `chef.init_style` attribute value `init`, in order to have the init scripts available.

If using this cookbook to manage a Chef Server system that was installed from Debian/Ubuntu packages, note that in the packages, the configuration files are split up for server.rb, solr.rb and webui.rb, and the `chef::server` recipe may not work as desired.

We recommend using a recent version of Ubuntu or Debian for the Chef Server.

* Ubuntu 9.10/10.04

* Debian testing/unstable

These versions have newer versions of CouchDB and RabbitMQ packaged.

The `chef::bootstrap_server` recipe uses the following other cookbooks from the Opscode repository.

* couchdb

* openssl

* zlib

* xml

* java

When using the bootstrap recipe, set the desired attributes using a JSON file. See "BOOTSTRAPPING" for examples.

Specifies the init style to use. Default `runit`. Other possible values `init`, `bsd`, any other string will be treated as unknown and a message will be displayed during the Chef run.

If your platform doesn't have a `runit` package or if the cookbook doesn't detect it, but you still want to use runit, set `init_style` to `none` and install runit separately. You may need to configure the runit services separately.

Using the `init` value for this attribute will retrieve the init scripts that are distributed with the Chef gem.

This cookbook does not yet support Upstart for Ubuntu/Debian, but that is planned for a future release, and will be specified via this attribute.

Location where the client will cache cookbooks and other data. Default is `cache` underneath the `chef[:path]` location. Linux distributions adhering to the FHS prefer `/var/cache/chef` instead.

Version of Chef to install for the server. Used by the `server_proxy` recipe to set the location of the DocumentRoot of the WebUI. Automatically determined via ohai's `chef_packages[:chef][:version]` by default.

Version of Chef to install for the client. Used to display a log message about the location of the init scripts when `init_style` is `init`, and can be used to upgrade `chef` gem with the `chef::bootstrap_client` recipe. Automatically determined via ohai's `chef_packages[:chef][:version]` by default.

When `init_style` is `init`, this directory needs to be created. The default is `/var/log/chef`.

These options are deprecated to reduce complexity and potential confusion.

server_url

Full URI for the Chef Server. Used for `chef_server_url` config setting. The default value combines the attributes `chef.url_type`, `chef.server_fqdn` and `chef.server_port`, creating for example "http://chef.example.com:4000". If you are using the Opscode Platform, set this to "https://api.opscode.com/organizations/ORGNAME", where ORGNAME is your organization's simple string name.

SERVER PROXY

The following attributes are used by the `server_proxy.rb` recipe, and are stored in the `server_proxy.rb` attributes file.

doc_root

DocumentRoot for the WebUI. Also gets set in the vhost for the API, but it is not used since the vhost merely proxies to the server on port 4000.

This attribute is now in the `server_proxy.rb` attributes file, as it is specific to that context.

server_proxy.css_expire_hours

Sets expiration time for CSS in the WebUI.

server_proxy.js_expire_hours

Sets expiration time for JavaScript in the WebUI.

BOOTSTRAPPING

The first two recipes described are for "bootstrapping" a system to be a Chef Client or Chef Server, respectively. Only use these recipes with RubyGems installations of Chef.

These recipes are typically used with chef-solo using a JSON file of attributes and a run list, and a solo config file. For more information see [Bootstrap Chef RubyGems Installation](http://wiki.opscode.com/display/chef/Bootstrap+Chef+RubyGems+Installation) on the Chef Wiki.

For configuring a new client to connect to the Opscode Platform:

"server_url": "https://api.opscode.com/organizations/ORGNAME"

For configuring a new client to connect to a local Chef Server:

{

"chef": {

"server_url": "http://chef.example.com:4000"

},

"run_list": "recipe[chef::bootstrap_client]"

}

This is the minimal JSON to use for the client configuration. See the ATTRIBUTES section above for more options.

* Creates the server configuration file `/etc/chef/server.rb` based on the configuration passed via JSON.

Minimal JSON to use for the server configuration:

"chef": {

"server_url": "http://localhost.localdomain:4000",

The recipe itself manages the `/etc/chef/client.rb` config file based on the attributes in this cookbook. When the client config is updated, the recipe will also reread the configuration during the Chef run, so the current Chef run can be dynamically changed.

This recipe does not manage the `chef-client` service. It is assumed to have been set up and started from the `bootstrap_client` recipe above, or from OS / distribution packaging. The `chef-client` service should not be restarted as a result of `/etc/chef/client.rb` changing, as that can cause the current process running the client to be restarted, having unpredictable results.

There is no spoon :-).

Beware if using this on your Chef Server. First copy the validation.pem certificate file to another location, such as your knife configuration directory (`~/.chef`) or [Chef Repository](http://wiki.opscode.com/display/chef/Chef+Repository).

Since the Chef Server itself typically runs the CouchDB service for the data store, the recipe will do a compaction on the Chef database and all the views associated with the Chef Server. These compactions only occur if the database/view size is more than 100Mb. It will use the configured CouchDB URL, which is `http://localhost:5984` by default. The actual value used for the CouchDB server is from the `Chef::Config[:couchdb_url]`, so this can be dynamically changed.

This recipe sets up an Apache2 VirtualHost to proxy HTTPS for the Chef Server API and WebUI.

The API will be proxied on port 443. If the `chef-serer-webui` is installed, it will be proxied on port 444. The recipe dynamically creates the OpenSSL certificate based on the `chef.server_ssl_req` attribute. It uses some additional configuration for Apache to improve performance of the webui. The virtual host template is `chef_server.conf.erb`. The DocumentRoot setting is used for the WebUI, but not the API, and is set with the attribute `chef.doc_root`.

set_unless[:chef][:server_version] = node.chef_packages.chef[:version]

set_unless[:chef][:client_version] = node.chef_packages.chef[:version]

set_unless[:chef][:server_url] = "#{node.chef.url_type}://#{node.chef.server_fqdn}:#{node.chef.server_port}"