Wiki

We do not recommend that you setup new ChiliProject instances and
we urge all existing users to migrate their data to a maintained
system, e.g. Redmine. We will
provide a migration script later. In the meantime, you can use the
instructions by
Christian Daehn.

ChiliProject should run on most systems as long as Ruby is available on this platform.

Linux — Linux is the preferred plattform for ChiliProject. Specific guides exist for Ubuntu, Debian, OpenSUSE, and CentOS. If you are using Gentoo, you might be interested in this Gentoo bug or Overlay, they both provide a (the same) ebuild for ChiliProject.

It is recommended that you use the latest stable release of ChiliProject for production deployments. Although we work hard on keeping the whole code base stable, the master and unstable branches might break from time to time, so use them only if you are willing to engage very closely with the inner workings of ChiliProject.

Please refer to the release schedule for more information about existing and planned releases.

To begin with, you need to decide on a ruby interpreter. ChiliProject runs best on Ruby 1.8.7 and recent variants of Ruby Enterprise Edition. For a new system you should choose one of those. The default ruby 1.8.7 is available for most platforms while other ruby interpreters might work only on certain systems. Check the respective project website for more information.

Support for Ruby 1.8.6 is deprecated in the 2.x series. If you would like to use Ruby 1.8.6 with 2.x, you may need to make modification to the application code and configuration. For new setups you are advised to use a Ruby 1.8.7 compatible interpreter.

In addition to the basic ruby, you need some required libraries (called rubygems) which provide some of the core functionality offered by ChiliProject. Make sure your system has the exact versions of these components installed. If not specified otherwise the exact stated versions are required.

ChiliProject stores most of its working data inside a database. It supports each the following databases equally well. Choose the one that fits your needs the most.

MySQL 5.x

PostgreSQL 8.x and 9.x

SQLite3

(Making ChiliProject work with Oracle is not impossible, but needs some work, see rob glazers forum post for more details)

For most production deployments, you should choose one of MySQL or PostgreSQL as these are going to be much more performant. For small and sparsely used installations SQLite3 is also sufficient. To later migrate between databases vendors, you can use Taps, YamlDb, or some other database agnostic tool.

To connect ChiliProject to the chosen database you need an additional ruby gem which acts as an adapter. For some databases, there are different libraries available and used. As some of the adapters are not maintained anymore you are advised to use one of the preferred gems from the following table. Preferred database adapters are marked with a star ( ).

The mysql gem exposes a bug in newer releases of Ruby 1.8.6. In order to make it work, you should either use a Ruby version older than or equal to 1.8.6-p388 or a mysql gem version older than or equal to 2.7. Generally, you are advised to run Ruby 1.8.7 if possible.

The mysql database adapter is only available for Ruby 1.8 as it doesn't properly observe string encoding requirements in Ruby 1.9. On Ruby 1.9, please use the mysql2 adapter instead. It provides the same functionality and is even a bit faster.

ChiliProject 1.x note: Please be aware, that Rails 2.3.5 (used in ChiliProject 1.x) has some special handling for the mysql gem. This results in limited functionality for the mysql2 gem. Therefor you will not able to properly execute the following rake tasks:

db:create and db:create:all

db:drop and db:drop:all

db:test:prepare

This should not be an issue in production environments. Also, these issues are fixed with ChiliProject 2.0, with Rails 2.3.12, which solves the above mentioned limitations.

Every Ruby on Rails application runs in an environment called application server. These server components which provide the basic HTTP functionality. There are various choices which heavily depend on your operating system end environmental constraints. See the installation guide of your specific operating system for more information.

The most common choices for production deployments are Phusion Passenger (mod_rails) for Linux / UNIX which is a module for the Apache2 or Nginx webserver or Thin on Windows. Although Rails comes with a basic application server called Webrick it is only suitable for development and tests. Never use Webrick in production deployments!

Run the command bundle install --without test development in the root of ChiliProject. This will download and check that all of the required rubygems are installed.Not all dependencies are required, especially not all database adapters. See our documentation for setting up bundler and chose the settings that are appropriate for you.

Create an empty database and an accompanying user named chiliproject for example.

MySQL < 5.0.2

create database chiliproject character set utf8;
grant all privileges on chiliproject.* to 'chiliproject'@'localhost' identified by 'my_password';

MySQL >= 5.0.2

create database chiliproject character set utf8;
create user 'chiliproject' identified by 'my_password';
grant all privileges on chiliproject.* to 'chiliproject'@'localhost';

Copy config/configuration.yml.example to config/configuration.yml and edit this file for your system's environment. You can check the comments in the file and on Configuration File for all of the options.

Generate a session store secret.

bundle exec rake generate_session_store

Create the basic database structure by running the following command under the application root directory:

RAILS_ENV=production bundle exec rake db:migrate

It will create the database tables and an administrator account.

Insert default configuration data into the database, by running the following command:

RAILS_ENV=production bundle exec rake redmine:load_default_data

This step is optional but highly recommended. It will load default roles, trackers, statuses, workflows and enumerations. If you choose to skip this step, you can later define your own configuration from scratch.

Setting up permissionsWindows users have to skip this step The user who runs ChiliProject must have write permission on the following sub-directories: files, log, tmp, and public/plugin_assets. So assuming you run ChiliProject with a user called chiliproject you need to setup the following permissions:

Once Webrick has started, point your browser to http://localhost:3000/. You should now see the application welcome page.Webrick is not suitable for normal use, please only use Webrick for testing that the installation up to this point is functional. It is not recommended to use Webrick for anything other than development or testing. Use one of the many other guides in this wiki to setup ChiliProject with a real application server like Phusion Passenger (mod_rails), Unicorn, or Thin.

Use the default administrator account to log in:

Login: admin

Password: admin

You can now go to Administration to modify the basic application settings. Have a look at the user guide for information on how to configure your new ChiliProject server.