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

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

Many people go with the officially recommended installation procedure, which is in fact the most common one. But this procedure does not consider platform peculiarities (otherwise, there would be too many cases to document). So eventually, by following this procedure, you get an isolated subsystem that is not connected to the package management tools of the host system. Such a subsystem will require manual maintenance, can easily be broken by changes in the host system, can create obscure conflicts, and so on. This often ends up with this subsystem being, in fact, unmaintained, as administrators have some fear about touching it. In addition, the official installation procedure is the most complicated one.

Therefore, in this chapter, we will review not only the officially recommended procedure—which is actually a good choice in some cases—but also some alternative ones. All of these procedures differ in the source from which they get Redmine. So, they can be divided into three categories by the source type:

The first category assumes that a Redmine package is available. Here, by "package" I mean a specially prepared software archive that contains not only Redmine itself but also instructions and possibly tools for installing it in the system. The best known package formats are RPM (for Red Hat-based Linux distributions) and DEB (for Debian-based Linux distributions). Certainly, such packages should be maintained and actively supported! Otherwise, there is no sense in using them.

To install Redmine as a package, you just need to answer a couple of questions, but this is not the only thing that makes packages so attractive. They are processed by the package manager, which also resolves conflicts and installs dependencies. Also, a package is usually associated with a repository where its dependencies and other system packages are stored, and that repository is updated periodically. So this means that the package manager will be able to update Redmine flawlessly when a new version arrives. Moreover, it won't allow the dependencies to get updated if this would break Redmine. Certainly, this makes its maintenance much easier.

Additionally, the packaged application is usually modified to conform to the standards of the operating system it is intended for. Thus, its configuration is located with other applications' configuration files (for example, in /etc/). The application itself is stored at the same location as other similar applications (for example, under /usr/share/). Its cache is stored under the system cache directory (for example, /var/cache/). Its logs are written to the system logs. And so on. This means that any administrator who is aware of the system standards—even if he/she is not aware of Redmine—will be able to understand the Redmine file structure and find or manage what he/she needs. Moreover, system tools (for example, log analyzers) will be able to pick up and process Redmine files if needed.

Unfortunately, Redmine is currently not available as a package for all Linux distributions. Thus, at the time of writing this section, Redmine packages are available (and well-supported) for Debian-based distributions such as Debian, Ubuntu and Mint, and some Red Hat based distributions, such as Fedora (through the RPM Sphere repository) and Mageia.

Generally, I recommend that you use a package whenever possible, mainly due to the ease of maintenance. However, you should remember that packaged software usually comes with an outdated version. At the time of writing this section, the recent Redmine version is 3.2.x and the recent version of packaged Redmine in Debian stable distribution is an intermediate between 2.5.x and 3.0.x. In Ubuntu LTS, it was even older: 2.4.x. So, if you want to be up to date (just up to date and not secure, as Ubuntu/Debian guys follow security news and make updates when necessary), you should go with the recent official version. However, in this case, be sure to allocate resources needed to maintain your Redmine installation and to document changes made to the system (do mention that you installed Redmine without using the system package manager). Also remember that plugins are most likely not going to be available right away for the recent version of Redmine.

But don't hurry to leave this section and move on to the (appropriate) next one, as there is even an easier way.

You can use special appliances that contain Redmine along with everything that you need to run it: a web server and an application server (for example, Apache plus Passenger), a database server (for example, MySQL), Ruby, Rails, and so on.

Some appliances also come with the entire operating system (usually Linux) and can easily be deployed on a server or a cloud. The advantage of using such appliances is that you preserve the possibility of upgrading the application (as well as the rest of the system). However, these kinds of appliances can't be used to deploy Redmine on an existing server.

There are also appliances that don't include the operating system and are to be installed on existing servers. Their advantage (compared to normal installation) is that you don't need to spend time configuring the application, as this is done by the installer (which may ask you a couple of questions). However, after using such appliances, the installed application will be separate from the rest of the system, what means that you may experience issues while upgrading it. Moreover, an upgrade of the operating system may accidentally break your application. Therefore, these kinds of appliances are recommended only for development and testing.

Now, let's have Redmine installed in two different ways. For all installations, we will use Apache, Passenger and MySQL, that is, the most common components. However, if you've chosen different components after reading Chapter 1, Getting Familiar with Redmine, and have decided to go with a more advanced option, then you will need to find a tutorial elsewhere (for example, http://www.redmine.org/). Unfortunately, this book can't cover all the options.