Allez, en bonus, la marche à suivre de mon installation 
Lexique :
Le terme “distribution” représente ce qu’on pourrait résumer par un “style” de Linux. Il y en a des tonnes : Ubuntu, RedHat, Fedora, gentoo, …
(source : http://fr.wikipedia.org/wiki/Distribution_Linux)
Le terme “release” (laché) désigne (chez Debian) ce qu’on pourrait résumer par une version de Debian. Par exemple : Etch, Lenny, Squeez, Wheezy, … Ce sont tout ces grands nom qui marquent l’histoire de Debian 
Le terme “branche” représente ce qu’on pourrait résumer par une étape de développement. Il y en a 5. Par exemple pour Debian :
[ul]stable (l’étape stabilisée réputée fiable)
testing (l’étape de testes où les paquets sont nettoyés au maximum de leur bugs)
sid (l’étape instable où les paquets sont encore en cour d’amélioration)
experimental (l’étpae ou les nouvelles fonctionnalités viennent fraichement d’être développées)
oldstable (l’étape de la retraite où on se pose et on en fout plus une rame… )[/ul]
Seuls deux branches sont nommées. Actuellement en 2012, la branche stable s’appelle Squeeze, et la branche testing s’appelle Wheezy. Cette dernière passera probablement d’ici la fin de l’année dans la branche stable.
Comme les release voyagent de branche en branche, et que chaque release représente aussi une version de la distribution Debian, tout ces termes sont abusivement mélangés, secoués et utilisés à toutes les sauces. Même dans les page du MAN. Et c’est parfois un peu déconcertant… au point que lorsque le sujet de la discussion traite de paquets et de dépôts-sources, si l’on parle de version, on est vite amené à se demander si l’auteur parle d’une version de Debian (release : Lenny, Squeeze, Wheezy, …) ou de la version d’un paquet (8.4, 9.0, 9.1, …
Ajouter les dépôts backport et Wheezy (la prochaine version stable)
Cela permet d’utiliser des paquets de la branche testing (Wheezy) tout en utilisant la branche stable (Squeeze).
On en a besoin, car squeeze ne permet ni d’installer une version de Postgresql supérieur à 8.4 ni d’installer une version d’apache2 qui soit compatible avec la version de la librairie libpq5 utilisée par PostgreSQL 9.1.
Modifier le fichier contenant la liste des dépôts /etc/apt/sources.list de manière à ce qu’il corresponde à ça :
[code]# STABLE en 2012 : Squeeze
deb http://ftp.ch.debian.org/debian/ squeeze main contrib non-free
deb-src http://ftp.ch.debian.org/debian/ squeeze main contrib non-free
STABLE de sécurité en 2012 : Squeeze
deb http://security.debian.org/ squeeze/updates main contrib non-free
deb-src http://security.debian.org/ squeeze/updates main contrib non-free
STABLE volatile en 2012 : Squeeze
squeeze-updates, previously known as ‘volatile’
deb http://ftp.ch.debian.org/debian/ squeeze-updates main contrib non-free
deb http://ftp.ch.debian.org/debian/ squeeze-proposed-updates main contrib non-free
deb-src http://ftp.ch.debian.org/debian/ squeeze-updates main contrib non-free
deb-src http://ftp.ch.debian.org/debian/ squeeze-proposed-updates main contrib non-free
Pour utiliser des paquets considérés comme suffisamment stables de la version testing ou sid
deb http://backports.debian.org/debian-backports squeeze-backports main
deb-src http://backports.debian.org/debian-backports squeeze-backports main
TESTING en 2012 : wheezy
deb http://ftp.ch.debian.org/debian/ wheezy main contrib non-free
deb-src http://ftp.ch.debian.org/debian/ wheezy main contrib non-free
TESTING de sécurité en 2012 : wheezy
deb http://security.debian.org/ wheezy/updates main contrib non-free
deb-src http://security.debian.org/ wheezy/updates main contrib non-free[/code]
L’intérêt d’utiliser Wheezy plutôt que Testing comme mot-clé, c’est que, même si pour l’instant, ca représente la même chose, dans quelques mois ce ne sera plus le cas.
Pour l’instant la branche testing(wheezy) est relativement stabilisée : on est proche d’un gèle de la branche et de son passage en branche stable.
Par contre dés que Wheezy passera en stable, la branche testing deviendra un véritable foutoire avec plein de paquets instables provenant de la branche sid et expérimentale. Alors, si vous faite un aptitude install /testing à ce moment là, je ne donne pas cher de la stabilité de votre paquets et ses dépendances. Evitez d’allez piocher dans testing à la sortie du release stable. Au besoin utiliser plutôt le dépôt debian-backports avec aptitude install /debian-backports.
En utilisant un dépôt nommé comme Wheezy, vous êtes au moins sûr que lorsque Wheezy passe dans la branche stable, au pire, vous installer des paquets qui sont stabilisés sur votre release Squeeze.
Ajouter une ligne dans le fichier /etc/apt/apt.conf afin que stable soit la branche par défaut lors des mises à jour (si il n’existe pas, créer le fichier). (Commande à taper depuis la console) :
echo ‘APT::Default-Release “stable”;’ >> /etc/apt/apt.conf
Cette façon de vous permet d’éviter d’avoir à vous coltiner une fichier /etc/apt/preferences relativement lourd à gérer. Et surtout ça évite d’avoir à installer à la main la trentaines de paquets dépendants du paquet apache2-dev que je vais vous faire installer plus bas.
Tout ce qu’il vous faut c’est lire en détails les paquets qui vous sont proposés à l’installation à chaque fois que vous tapez la commande “aptitude install /wheezy” qui permet d’installer un de la source wheezy et un peu de jugeote pour savoir si les paquets installé sont pertinents (d’ailleurs vous êtes déjà un éclairé si vous lisez ceci).
(A la place de APT::Default-Release “stable”; vous pouvez aussi mettre APT::Default-Release “squeeze”;
Si vous préférez que Debian n’installe pas automatiquement les paquet de Wheezy lorsqu’il passera dans la branche stable)
Au besoin usez et abusez de l’option -s qui permet de simuler une installation sans rien installer même si vous répondez oui (exemple : aptitude -s install apache2/wheezy )
Utilisez aussi la commande "aptitude why " ou "aptitude why-not " qui vous permettent de demander à aptitude, respectivement : “pourquoi” (why) un a besoin de rester installé, et “pourquoi” (why-not) un cause un conflit. Aptitude vous affichera les dépendances, et les causes de conflit.
Installation de PostgreSQL 9.X
Desinstallez PostgreSQL 8.4 si il est présent (aptitude show postgresql).
Cette étape est superfule, mais je ne peux pas vous garantir que vous aurez les même réponses aux questions que aptitude vous posera lors de l’installation si vous ne vous trouvez pas dans le même état où j’étais lors de mon installation (je parle des même paquets installés pas du nombre de bières que j’ai bu ^^).
Desinstallez apache2 si il est présent (aptitude show apache2).
Essayer la simulation dans un premier temps :
Répondre non à la première question si aptitude ne veut rien installer.
Accepter (Y) le second choix avec installation des paquets :
- libpq5 (squeeze-backports)
- postgresql-client-common (squeeze-backports)
- postgresql-common (squeeze-backports)
Valider avec Y.
Refaites la même chose pour de vrai :
Installez Apache2/Wheezy
Rebelote :
Répondre non aux trois questions jusqu’à ce que aptitude propose d’installer apache2-mpm-prefork:
Accepter (Y) le troisième choix avec installation des paquets :
- apache2-mpm-prefork (testing)
- apache2-utils (testing)
- apache2.2-common (testing)
- libd5.1 (testing)
et mise à jour :
- apache2.2-bin (testing)
- etc…
Valider avec Y encore une fois.
Une fois que vous sentez que vous avez compris ce qui se passe, allez y pour de bon (sans l’option –s) :
Installer les headers de développement de Apache pour plus tard (voir plus loin avec Passenger)
Répondez non la première fois, Y ensuite.
Observez la quantité de paquets à installer et repensez au cauchemard que ça aurait été en ayant paramétré votre fichier /etc/apt/preferences avec des priorités inférieurs à 100.
Refaites l’opération pour de vrai :
Installation de Git
Installation de CURL
Installer RVM
(Source : https://rvm.io/rvm/install/ )
Vérifez les prérequis
Normalement svn (subversion n’est pas installé). Procédez à son installation :
Sortez de votre console en mode root !
Loguez vous sur un terminal avec un compte d’utilisateur standard !
N’installez pas RVM avec l’utilisateur root ou la suite de l’installation ne fonctionnera pas
- Télécharger RVM et l’installer :
Si vous avez plusieurs utilisateurs sur votre système et que vous voulez que tous aient accès à rvm, il faut ajouter votre utilisateur au group sudo du fichier /etc/group, puis ajoutez sudo devant la commande bash pour l’exécuter (curl -L get.rvm.io | sudo bash -s stable). Procéder ainsi sans savoir gérer le UMASK ouvre une faille de sécurité importante sur votre serveur. Je déconseille donc.
-
Modifier les préférences de votre fenêtre de terminal pour qu’elle s’exécute en login shell :
Depuis le menu Edition > Préférence du profile, aller dans l’onglet “Titre et commande”, cocher l’option “Lancer la commande en tant que shell de connexion”.
Cela permet d’exécuter le script /etc/profile qui, à son tour, exécutera le script rvm.sh contenu dans /etc/profile.d/. Ce dernier charge RVM en mémoire, ce qui vous permet de l’utiliser.
Si vous ne faites pas ça (ains que l’étape ci-dessous), vos commandes rvm ne fonctionneront pas.
-
Fermez et rouvrez le terminal de l’utilisateur standard
-
Vérifier que tous les prérequis sont remplis :
-
Ouvrez une fenêtre terminal d’administrateur pour lancer vos commandes aptitude
-
Installer les paquets manquants pour Ruby (et pas pour JRuby ou IronRuby, etc…).
Copiez et collez ce qui affiché sur la ligne “apt-get install” retournée par la commande “rvm requirements”.
Usuellement :
- Vérifiez la version de rvm
- Mettre à jour RVM
rvm get stable
rvm reload
Installer Ruby version 1.9.3
(source : http://ruby.railstutorial.org/ruby-on-rails-tutorial-book#sec:install_ruby )
Vérifiez la version de ruby
Vérifiez la version de gem (optionel)
Mettre à jour Gem (optionel)
Pour afficher les dépendances de chaque version de Ruby
Pour afficher les version de Ruby disponibles (optionel)
Utiliser (use) un gemset qui rassemble ruby 1.9.3 et votre futur environnement Rails
Le lien ci-dessous explique les avantages d’utiliser rvm et les gemset.
(source : http://jeremy.wordpress.com/2010/08/13/ruby-rvm-passenger-rails-bundler-en-developpement/ )
Par exemple chez moi : 1.9.3@rail3dev20120606
Explication des options :
use : définit quelle version de ruby utiliser avec le gemset qu’on va créer
le numéro avant le @robase correspond à la version de ruby à utiliser.
–create : créer le gemset s’il n’existe pas
–default : définir comme gemset utilisé par défaut par les shell (terminal)
Pour afficher l’aide de rvm
Quelques commandes utiles :
Pour lister les gemset de la version courante de l’interpréteur Ruby :
Pour lister tous les gemset de toutes les version d’interpréteur ruby :
Pour utiliser un autre gemset :
Plus de détails sur les commandes gem ici : http://rvm.beginrescueend.com/gemsets/
Installer Rails
Installer la dernière version de Rails
Vérifier la version de Rails
N’oubliez pas que la suite de l’installation se poursuit sur votre fenêtre terminal [u]administrateur /u.
Installer Passenger à l’aide de RVM
Apache 2 ne communique pas par défaut avec Ruby et encore moins avec Ruby on Rails.
Passenger va vous faciliter la vie en installant et configurant pour vous les modules apaches et paquets nécessaires pour gérer Ruby et Rails.
Installer passenger
Si vous lancez le configurateur de passenger
passenger-install-apache2-module(appuyez deux fois sur Enter)
, celui-ci vous dira qu’il manque des paquets et vous donnera les commandes aptitudes à taper. Cela ne fonctionnera pas, car Debian a besoin d’autres paquets. Il faut installer à la place le paquet apache2-dev depuis le dépôt wheezy.
(Source locale : section 6.2.2 sur votre /usr/local/rvm/gem/… le lien est affiché à la fin de l’exécution de la commande passenger-install-apache2-module
Aussi ici : http://www.modrails.com/documentation/Users%20guide%20Apache.html)
C’est pour ça que je vous les ai fais installer en même temps qu’Apache et pour que vous compiliez rvm avec la bonne librairie libc6-dev.
Donc pas besoin de faire :
Installer le dernier paquet manquant :
Répondez non 2 fois jusqu’à ce qu’aptitude ne supprime plus aucun paquets mais au contraire en installe de nouveau, puis appuyez sur Y)
Refaites l’opération pour de vrai :
Configurer Apache2
Lisez attentivement les instructions à la fin de l’exécution : Passenger vous explique tout ce que vous devez faire pour paramétrer votre apache et déployer une application Rails.
Copiez-coller ces instructions dans un fichier pour vous en souvenir.
Paramêtrer Apache2
Aller dans le dossier des modules disponibles :
Ajouter les lignes affichées par passenger dans un fichier de chargement de module (passenger.load) créé à cette occasion.
Ci-dessous, par exemple, les lignes que Passenger m’a dit de copier :
echo ' LoadModule passenger_module /usr/local/rvm/gems/ruby-1.9.3-p194@rail3dev20120606/gems/passenger-3.0.12/ext/apache2/mod_passenger.so' >> passenger.load
echo ' PassengerRoot /usr/local/rvm/gems/ruby-1.9.3-p194@rail3dev20120606/gems/passenger-3.0.12' >> passenger.load
echo ' /usr/local/rvm/wrappers/ruby-1.9.3-p194@rail3dev20120606/ruby' >> passenger.load
Explication de la commande : echo dit d’affiche le texte entre apostrophes sur l’écran (sortie standard 1), puis >> redirige ce qui s’affiche à l’écran (sortie standard 1) dans un fichier passenger.load en l’ajoutant à la fin du fichier (si le fichier existe pas, ça le crèe automatiquement).
On relèvera dans ces lignes l’apparition du gemset que nous avons créé plus haut (je l’ai appelé 1.9.3@rail3dev20120606, et gem a ajouté le numéro du patch 194 de la version 1.9.3).
Explication sur le chargement de modules apache : En fait si on regarde vers la ligne 239 du fichier de config principal d’apache : /etc/apache2/apache2.conf, on remarque ces deux lignes :
Include mods-enabled/*.load
Include mods-enabled/*.conf
Ca signifie que apache va lire les fichier se terminant par .load et .conf pour exécuter les lignes qu’ils contiennent.
L’usage veut que l’on place ces fichiers dans le dossier /etc/apache2/mods-availble/, et qu’on crée des liens symboliques (les raccourcis fameux raccourcis de windows) dans /etc/apache2/mods-enabled/ qui pointent vers leur fichier respectif dans /etc/apache2/mods-available/.
Si vous vous amusez à regarder ce que contient l’un de ces fichiers, vous verrez qu’il y a presque rien dedans si ce n’est quelques lignes de commande pour apache, et qui ressemblent furieusement à celles que Passenger nous a donné.
Concernant cette histoire de création de liens symboliques dans /etc/apache2/mods-enabled/ , ne vous en faites pas, il y a un script livré avec apache qui fait ça très bien pour nous, il s’appelle “a2enmod”.
Activer le module proprement avec l’outil idoine :
Relancer apache2 :
Oui, oui, plus besoin de se décarcasser avec la vielle commande /etc/init.d/apache 2 restart
Voilà en espérant que cela sera utile à certains.
Si ce tutorial vous a aidé, pensez à poster un “merci” si vous voulez m’encourager à en faire d’autres 
