I have always believed that installation is not just a matter of making an application run, it's much more, as it involves making important decisions which can be hard to change in the future such as:

Of course, the answers to these questions depend on the goals of using Redmine, which in turn, raises other questions such as:

Most people will just go with the officially recommended installation procedure which is, in fact, just the most common. The official procedure does not actually consider platform peculiarities just because it would be too many cases to document. Following this procedure one gets a completely separate subsystem not connected to the host system and to its package management tools. So such subsystem will require manual maintenance, can easily get broken with changes in the host system, can have obscure conflicts, and so on. This often ends up with the subsystem being, in fact, unmaintained and with some fear of touching it. In addition, the official installation procedure is the most complex one.

Therefore under this topic, we will review not only the officially recommended procedure, which is actually a good choice in some cases, but will also check some other common procedures. All these procedures differ in the source they get Redmine from. By source type these procedures can be divided into three categories:

The first category assumes that a Redmine package is available. By package I mean a specially prepared software archive containing not only Redmine itself but also tools for installing Redmine into the system. The best known package formats are RPM (for Red Hat based Linux distributions) and DEB (for Debian based Linux distribution). Actually it's not a big deal to create such a package but another requirement is that such package should be maintained and actively supported! Otherwise using it has no sense.

With a Redmine package, you need to answer just a couple of questions to install Redmine but this is not the only thing which makes packages so attractive. Packages are processed by system package manager, which also resolves conflicts and installs dependencies. Usually a package comes from a repository along with its dependencies and other system packages. And this means that system package manager will be able to update Redmine flawlessly when a new version of its package is released. If no new version is available the package manager won't allow dependencies to be updated if this will break Redmine! This makes maintenance of Redmine much easier.

The problem is that Redmine is not yet available as a package in many Linux distributions. At the time of writing this topic Redmine package is available (and well-supported) in Debian-based Linux distributions such as Debian, Ubuntu, and Mint. Some Redmine package are also available in Mandriva based Linux distributions such as Mandriva and Mageia. As Mandriva uses RPM this package can potentially work for Red-Hat-based distributions such as CentOS and Fedora but I personally, have never tested it.

As you might guess I recommend using the Redmine package if possible mainly due to easy maintenance. However, you should note that usually a packaged software has an older version than the recent one. Thus at the moment of writing these words the recent Redmine version is 2.2.x and the recent version of the packaged Redmine in Ubuntu is 1.4.x, in Debian stable it is even older, that is 1.0.x. So if you want to be up-to-date (just up-to-date, not secure as Ubuntu/Debian guys follow security news and make updates if vulnerabilities appear) you can go with the recent official version. However, be sure to allocate resources for maintaining your Redmine installation and to document your changes to the system (do mention that you installed Redmine without using system package manager).

But do not hurry to leave this text and move to the appropriate topic: there is an even easier way. The third category is about appliances. An appliance contains all you need to run an application. In the case of Redmine the appliance should contain a web server (for example, Apache plus Passenger), a database server (for example, MySQL), Ruby, Rails, and so on. There are two well-known appliances for Redmine, which are TurnKey Linux appliance and BitNami Stack.

As it comes from the name TurnKey Linux Redmine appliance contains a ready-to-use Linux installation which can be run under VirtualBox or VMWare, deployed to VPS (OpenVZ, Xen, or OpenStack based) or Amazon EC2 cloud. It is also available as a Live CD ISO image, which means you can first try it and then install it. The TurnKey Linux is based on Ubuntu so after deploying or installing it you, in fact, get Ubuntu and thus can update and install additional software or security fixes from Ubuntu repositories.

While the idea of the TurnKey Linux appliance is to ease the deployment of a new server the idea of the BitNami stack is to ease the deployment of an application. A BitNami stack contains just software required to run an application (no OS) and, unlike the TurnKey, the BitNami stack also supports Windows and Mac. In addition, you can download an Ubuntu based virtual machine with the BitNami Redmine stack or deploy it to Amazon EC2 cloud.

The problem with BitNami is that it is separate from the rest of the system and so you get all the maintaining issues mentioned earlier. Despite what you could expect updating the BitNami stack is not an easy task (they recommend just to reinstall it). But the good thing is that you can also deploy other BitNami stacks to the same server, for example, you can deploy WordPress along with Redmine.

Taking the above paragraphs into account I conclude that the BitNami Redmine stack is good for development and testing and should not be chosen for production. Another thing which is good for development is that it always comes with the most recent version of Redmine. Of course, it's my opinion and you should come to yours considering everything I have written here. Now let's get Redmine installed in four different ways.

For all the procedures we will be using Apache, Passenger, MySQL, and so on—the most common components—unless others are enforced by package dependencies or ship with an appliance. If, however, having read Chapter 1, Getting Familiar with Redmine, you have chosen different components, not covered under this topic, then you have decided to go with more advanced options and need to find tutorials elsewhere, for example on www.redmine.org. Unfortunately this book just can't cover all the options.