Redmine sous Apache avec Passenger

Cet article est le premier d’une série d’article sur l’outil de gestion de projet Redmine.

Ce puissant outil disponible sous la forme d’une interface web permet de gérer les projets de développements en intégrant des roadmap, la gestion des bugs, des demandes dévolutions, un tracker de versionning, un wiki, le tout avec une gestion des droits complète.

Dans cet article nous verrons comment installer Redmine sur un serveur Linux (Debian dans notre cas) en utilisant Apache comme serveur d’application grâce au module “Passenger” qui permet à Apache d’interpréter Ruby on Rails.

Comme d’habitude cet article décrit une suite de manipulations liée à des versions précises. A vous d’adapter vos numéro de versions en fonction des évolutions à venir.

Pour Commencer nous allons installer Apache 2 MySQL 5.0 et d’autres paquets qui nous seront nécessaires.

#aptitude install apache2 mysql-server apache2-prefork-dev libaprutil1-dev libaprutil1-dev libmysqlclient15-dev gcc make subversion

Pensez également à activer le mod_rewrite d’Apache dès maintenant

#a2enmod rewrite

Nous pouvons maintenant installé les près requis lié plus précisément à notre application à savoir Ruby, l’interpréteur, gems le gestionnaire de paquets et d’autres librairies nécessaire pour l’installation de Redmine. commençons donc par Ruby et les librairies disponibles par aptitude.

#aptitude install ruby rdoc irb libyaml-ruby ruby1.8-dev libzlib-ruby ri libopenssl-ruby1.8

Passons ensuite à l’installation de gems

#wget  http://rubyforge.org/frs/download.php/60718/rubygems-1.3.5.tgz #tar xvf rubygems-1.3.5.tgz #cd rubygems-1.3.5 #ruby setup.rb #ln -s /usr/bin/gem1.8 /usr/bin/gem

Pensez également à mettre à jour les paquets et les dépots de Gems

#gem update && gem update —system

Installons aussi le support de MySQL pour Ruby

#gem install mysql

Et nous pouvons maintenant passer aux choses sérieuses et installer Rails en version 2.3.5 comme le recommande Redmine.

#gem install rails -v=2.3.5

Nous aurons également besoin du support imagemagick pour la génération des diagrammes de Gantt:

#aptitude install imagemagick libmagick9-dev librmagick-ruby1.8 #gem install rmagick

Passons maintenant à l’installation de passenger et à la compilation du module passenger pour apache2

#gem install passenger #/usr/lib/ruby/gems/1.8/gems/passenger-2.2.9/bin/passenger-install-apache2-module

Ajoutons le à la configuration d’Apache: Créez un fichier /etc/apache2/mods-available/passenger.load et insérez-y la ligne:

LoadModule passenger_module /usr/lib/ruby/gems/1.8/gems/passenger-2.2.9/ext/apache2/mod_passenger.so

Créez également un fichier /etc/apache2/mods-available/passenger.conf et placez-y les deux lignes suivantes:

PassengerRoot /usr/lib/ruby/gems/1.8/gems/passenger-2.2.9 PassengerRuby /usr/bin/ruby1.8

Enfin Activez le module:

#a2enmod passenger

Maintenant que tous nos pré-requis sont en place, nous pouvons passez à Redmine Commencez par créer un utilisateur et une base de donnée MySQL:

mysql -u root -p mysql> create database redmine character set utf8; mysql> create user ‘redmine’@’localhost’ identified by ‘my_password’; mysql> grant all privileges on redmine.* to ‘redmine’@’localhost’; mysql> exit

Plaçons nous ensuite dans le dossier où nous voulons installer Redmine (/var dans mon cas) et récupérons la dernière version de Redmine depuis le dépôt officiel:

#cd /var
#svn co http://redmine.rubyforge.org/svn/branches/0.9-stable/ redmine
#cd redmine

Il est temps maintenant de mettre en place la configuration de la base de donnée créez un fichier config/database.yml et entrez-y la configuration comme ceci en adaptant à ce que vous avez entrez lors de la création de l’utilisateur et de la base dans mysql:

production:
adapter: mysql
database: redmine
host: localhost
username: redmine
password: my_password
encoding: utf8

Profitons en également pour configurer le serveur d’envois de mails en créant le fichier config/email.yml (ici ma configuration tape directement en local par la commande  ”sendmail” sans passer par un socket):

production:
delivery_method: :sendmail
smtp_settings:
address: localhost
port: 25
domain: lelevier.fr

Nous pouvons enfin passer à l’installation de Redmine en générant l’espace de stockage des sessions, en créant la base de donnée, et enfin en installant la configuration par défaut (utilisateurs, rôles, trackers… recommandé par Redmine):

#rake generate_session_store
#RAILS_ENV=production rake db:migrate
#RAILS_ENV=production rake redmine:load_default_data

Il ne vous reste plus qu’a configurer votre VirtualHost Apache comme n’importe quel virtual host en faisant pointer votre DocumentRoot vers le dossier “public” de Redmine.

<VirtualHost *:80>
ServerAdmin thibaut@my-test.com
ServerName dev.my-test.com
DocumentRoot /var/www/redmine/public/
</VirtualHost>

Configuration d’Exim pour l’envoi externe

La plupart des applications web que nous pouvons être amené à déployer sur un serveur web utilise des fonctions d’envoi de mails.

Afin de gérer soit même les files d’attentes, il peut alors être utile d’héberger soit même un serveur SMTP directement sur la machine qui héberge l’application. Nous allons donc voir comment configurer simplement Exim pour l’envoi de mails vers les domaines externes. Nous utiliserons une distribution Debian stable.

Commençons par installer Exim:

aptitude install exim4

Exim va alors s’installer avec une configuration de base que nous allons modifier avec l’assistant fourni par exim4-config:

dpkg-reconfigure exim4-config

Le premier écran vous expliquera le rôle de cet utilitaire, validez avec “Ok” pour passer à l’écran suivant.

Sur celui si, choisissez “Distribution direct par SMTP (site internet)”.

Ensuite sur l’écran suivant entrez le nom tel que vous l’avez défini dans votre configuration ou tel qu’il a été défini par votre hébergeur.

Deux écran plus loin, l’assistant va vous demander sur quelle adresse il va devoir accepter le courrier. Puisque nous sommes parti sur une configuration simple où le serveur d’applications (php par exemple) se trouve sur la même machine, nous utiliseront donc l’adresse 127.0.0.1 pour limiter les connections au serveur avec lui-même.

L’écran suivant nous demande alors de préciser sur quel autre nom le serveur doit accepter les mails. Nous pouvons ici lui repriser le nom DNS de notre machine.

Vient ensuite, la question des domaines à relayer. Nous l’avons déjà vu, nous n’acceptons les mails entrant que sur l’adresse de localhost: 127.0.0.1. Nous pouvons donc autoriser le transfert vers tous les domaines afin que les mails puissent sortir. Remplissez donc ce champ avec une étoile “*”.

Laissez la liste des machines à relayer vide car nous souhaitons que le serveur transmette lui même les mails sortants.

Deux écran plus loin, répondez “Non” à la proposition de minimiser les requêtes DNS, laissez la distribution du courrier au “format mbox dans /var/mail” et ne séparez pas la configuration dans plusieurs fichiers.

L’assistant va se fermer et va redémarrer Exim et vous pourrez tester sans problème le bon fonctionnement de votre MTA par exemple avec la fonction mail() de PHP.

NSlookup et Dig: surveillez vous mises à jours DNS

Lors de l’achat d’un nom de domaine chez un registar, celui ci fourni généralement des services d’hébergement, de mails, mais aussi les services DNS liés à la gestion de ce domaine. On peux alors modifier directement sa configuration DNS dans l’interface mis à disposition par l’hébergeur et cette configuration sera alors répliquée sur les différents serveurs DNS desservant votre nom de domaine.

Nous allons voir ici comment contrôler la mise en applications de vos modifications via 2 outils en lignes de commande: NSLookup (présent sur tous systèmes) et Dig (présent de base sous Linux et Mac OS X, une version cygwin existe pour Windows).

Prenons un exemple concret, je viens de migrer mon blog sur un nouveau serveur et je souhaite que l’adresse “blog.lelevier.fr” pointe bien sur ce nouveau serveur. J’ai fait les modifications nécessaire dans l’interface de mon registar et je connaît l’adresse ip ou le nom de mon nouveau serveur.

Commençons par NSLookup avec une requête simple:

23:03: tibo@Boudallu ~ % nslookup blog.lelevier.fr Server: 192.168.1.1 Address: 192.168.1.1#53 Non-authoritative answer: blog.lelevier.fr canonical name = rps.lelevier.fr. Name: rps.lelevier.fr Address: 87.98.170.232

Ici c’est mon serveur DNS local qui me répond (192.168.1.1) et bien qu’il n’ai pas autorité sur le domaine (il ne le gère pas directement) il me répond que “blog.lelevier.fr” est un Alias de “rps.lelevier.fr” défini par l’adresse “87.98.170.232” qui est justement mon serveur.

Même si le résultat est ici concluant nous allons partir sur le cas où la modification n’a pas encore été répliquée sur notre serveur local. Regardons alors directement sur les serveur DNS de notre registar pour voir si les modifications ont était prise en compte sur ces derniers. Commençons par trouver l’adresse ou le nom des serveurs DNS faisant autorité sur notre domaine avec Dig:

23:04: tibo@Boudallu ~ % dig NS lelevier.fr ; «» DiG 9.4.3-P3 «» NS lelevier.fr ;; global options: printcmd ;; Got answer: ;; -»HEADER«- opcode: QUERY, status: NOERROR, id: 64451 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2 ;; QUESTION SECTION: ;lelevier.fr. IN NS ;; ANSWER SECTION: lelevier.fr. 86400 IN NS dns11.ovh.net. lelevier.fr. 86400 IN NS ns11.ovh.net. ;; ADDITIONAL SECTION: dns11.ovh.net. 86371 IN A 213.251.188.130 ns11.ovh.net. 86371 IN A 213.251.128.130 ;; Query time: 54 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Wed Aug 19 00:06:38 2009 ;; MSG SIZE rcvd: 107

Nous pouvons lire ici dans la zone “ANSWER SECTION” que notre domaine est gérer par les serveur “dns11.ovh.net” et “ns11.ovh.net”. Retournons alors maintenant sur NSLookup pour vérifier l’état de la résolution sur un serveur précis. Lançez NSLookup sans argument avec la commande “NSLookup”, spécifiez le serveur DNS avec l’option “server” suivit du nom ou de l’ip d’un des serveur trouvé au dessus, et enfin entrez le nom DNS que vous souhaitez résoudre:

23:06: tibo@Boudallu ~ % nslookup > server dns11.ovh.net Default server: dns11.ovh.net Address: 213.251.188.130#53 > blog.lelevier.fr Server: dns11.ovh.net Address: 213.251.188.130#53 blog.lelevier.fr canonical name = rps.lelevier.fr. Name: rps.lelevier.fr Address: 87.98.170.232 >

On peut alors lire ici que le serveur en question redirige encore une fois “blog.lelevier.fr” vers l’hôte “rps.lelevier.fr” dont l’adresse est “87.98.170.232”. On pourra alors vérifier sur le second serveur DNS que les informations concordent et en conclure l’état de notre modification et sa prise en compte par notre registar.

A noté cependant qu’il faut généralement entre 4h et 48h pour que la modification soit répliquée.

Préparer Debian Lenny pour Zimbra

Zimbra 5  ne supporte actuellement pas la nouvelle version stable de Debian : Lenny (alias 5.0)

Avec Debian, il reste cependant facile de “mixer” les sources afin de faire concorder les version de package présentes sur différentes branches de la distribution.

Le premier problème va alors venir du fichier /etc/debian_version qui nous dit clairement que nous sommes sur une version 5.0. Commençons alors par remplacer le 5 par un 4 dans ce fichier afin de laisser penser à Zimbra qu’il se trouve sur une machine sous Debian Etch.

Ensuite, nous allons avoir besoin d’une ancienne version de perl (5.8) uniquement disponible sous Etch.

Pour celà nous devons ajouter les sources de Etch dans la liste des sources de notre serveur pour la faire correspondre à quelque chose dans ce genre (les serveurs peuvent biensur être différents):

deb http://ftp2.fr.debian.org/debian/ etch main deb-src http://ftp2.fr.debian.org/debian/ etch main deb http://security.debian.org/ etch/updates main deb-src http://security.debian.org/ etch/updates main deb http://ftp2.fr.debian.org/debian/ lenny main deb-src http://ftp2.fr.debian.org/debian/ lenny main deb http://security.debian.org/ lenny/updates main deb-src http://security.debian.org/ lenny/updates main deb http://volatile.debian.org/debian-volatile lenny/volatile main deb-src http://volatile.debian.org/debian-volatile lenny/volatile main

Nous devons ensuite mettre à jour la liste des sources:

# aptitude update

Et nous pouvons enfin installer perl 5.8:

# aptitude install perl=5.8.8-7etch6

Nous pouvons maintenant supprimer exim

# aptitude remove exim4

et installer les packages requis

# aptitude install  sudo fetchmail openssl libltdl3 libgmp3c2 libexpat1

Enfin vérifiez que le nom plainement qualifié du serveur pointe vers son IP réel et non pas sur 127.0.0.1 dans le fichier /etc/hosts et récuperez la dernière version de Zimbra 5 sur le site de Zimbra pour l’installer.