Conseils pour utiliser Ruby, RVM, Passenger, Rails, Bundler, … en développement

Cet article existe en anglais. Ma propre traduction n’est probablement pas la meilleure, donc si vous avez des améliorations à suggérer, je suis preneur.

Dernière mise à jour le 3 mars 2011 : Rails 3 et Bundler sont en version stable, et les versions de Passenger et REE sont actualisées.

Intro : Pourquoi ces conseils

L’équipe de dev dans laquelle je travaille est composée de 3 personnes qui bossent avec Ruby.
À part moi qui ne fait presque que ça et qui suis de fait un peu le “référent” sur ces questions, mes 2 très chers collègues n’utilisent pas Ruby toute la journée et utilisent donc d’autres environnements de travail (Objective-C/iPhone et PHP/Symfony principalement).

J’ai choisi d’utiliser un certain nombre de technologies un peu “bleeding edge” pour des vraies (j’espère des bonnes) raisons de performance, de fonctionnalités, de confort, … mais leur nature “beta” ne les rend pas toujours faciles à comprendre et à manipuler, …
C’est surtout le cas quand il y a des bugs, des changements fréquents de fonctionnement, des incompatibilités (temporaires), … et qu’on n’a pas envie (et c’est normal) de se prendre la tête à tout comprendre. Des fois il faut juste que ça marche.

Je vais donc vous présenter rapidement ces différents outils et comment les faire fonctionner ensemble avec le minimum de souffrance et le maximum d’intérêt.
Je précise que je présente ici un usage de ces outils en environnement de développement. Je n’ai pas utilisé RVM en production, bien que ça soit tout à fait possible, et même conseillé.

Les outils du boucher

Ruby

“Ah bon, Ruby n’est pas encore stable ?”

Si si, mais Ruby est dans une phase de transition entre la version 1.8 et la 1.9 (la 1.9.2 est sortie il y a quelques mois). Et puis il y a plusieurs implémentations (notamment JRuby et Rubinius). Il est donc intéressant de pouvoir facilement tester son code dans ces différentes implémentations, via RVM.

RVM – Ruby Version Manager

Le principe de RVM est de permettre d’installer plusieurs versions de Ruby sur une même machine, dans un environnement hermétique à une éventuelle version installée sur l’OS et de pouvoir basculer de l’une à l’autre facilement.

Il permet aussi, pour chaque Ruby, d’avoir des ensembles de gems bien séparés (Gemset) pour éviter les conflits de versions entre différents projets.

L’outil est très riche et fonctionnellement très puissant, mais il introduit des concepts et des outils pas si simples que ça.
Si on n’est pas complètement en phase avec, on a vite fait de se tromper de version de Ruby et/ou de Gemset.

Heureusement la doc est très bien faite et l’équipe de dev (@wayneeseguin et @Sutto) est super disponible sur IRC.

Ruby on Rails

Je ne présente pas plus en détail Ruby on Rails : c’est un framework de développement d’applications web, écrit en Ruby.

Depuis sa version 3, il apporte énormément de nouveautés, mais aussi certaines incompatibilités par rapport à sa version stable précédente (2.3), surtout au niveau des commandes “rails” et scripts dans les applis. Il n’est donc pas simple du tout d’utiliser Rails 2 et Rails 3 sur une même machine sans utiliser RVM.

Cette version 3 apporte aussi un nouveau système de gestion de dépendances : Bundler, sous forme d’une gem requise.

Bundler

Bundler est une Gem écrite en Ruby, permettant de gérer les dépendances d’un projet écrit en Ruby, par exemple une application Rails.
Beaucoup plus efficace que l’ancien procédé au niveau de la gestion de l’arbre des dépendances il est surtout excellent pour installer rapidement les gems nécessaires à un projet dans un espace limité à ce projet, sans que les éventuelles autres gems installées sur le système ne puisse le perturber.

Sa version stable actuelle est la 1.0 (1.0.10 exactement).

Phusion Passenger

Phusion Passenger sert à connecter des applis Rack ou Rails avec Apache (ou Nginx), permettant d’héberger ces applis presque aussi facilement que des applis/scripts en PHP.

C’est un composant logiciel maintenant bien stable, mais son usage en conjonction avec RVM et Bundler n’est pas toujours évident, surtout si on veut qu’il utilise un Gemset (et les gems qui sont dedans) différent pour chaque applis.

Les difficultés rencontrées

Ces derniers mois, on a surtout rencontré des difficultés avec le suivi des versions et les incompatibilités que ça a révélé. Alors que j’arrivais à peut près à suivre le rythme des changements, … mes collègues avaient mieux à faire. Des modifs que je mettais en commun rendaient certaines fois les projets inutilisables pour les autres, ou en tous cas difficile à remettre en ordre. Ça débouchait sur des cheveux arrachés, des insultes aux outils :-), …

Recommandations

Je vais décrire une situation de poste de développement (donc pas de production), sous Mac OS X. La situation sous Linux sera probablement très proche, à la différence près que les certains composants ne seront pas pré-installés. Pour Windows, c’est tout autre chose, mais je n’ai aucune info fiable sur ce qui marche ou pas dans cet univers assez hostile au développement web (Ruby en particulier).

Apple fourni Ruby en standard depuis Leopard (peut-être même avant). Cette version pré-installée ne nous sera pas utile, mais il est bien de savoir qu’elle existe, ne serait-ce que pour la différencier des autres qui seront installées via RVM. Actuellement, sous Mac OS X 10.6.4, c’est Ruby 1.8.7-p174 qui est installé.

Si on part d’un système “vierge” au niveau de l’utilisation de Ruby, je conseille de n’installer aucune gem particulière et de ne pas toucher à ce qui est présent. On va tout confier à RVM.

Installer RVM

La procédure d’install de RVM est assez simple et bien documentée. Suivez la, c’est plus sûr que si je la recopie ici.

Un fois cette install faite, vous pouvez commencer à installer d’autres “rubies”. Je conseille particulièrement l’utilisation de Ruby Enterprise Edition :

$ rvm install ree

Je conseille aussi d’en faire la version par défaut, et celle pour Passenger.

$ rvm use ree --default --passenger

Dorénavant, tout nouveau shell utilisera cette version de Ruby et un script “wrapper” permettra à Passenger de l’utiliser.

Pour mettre à jour RVM, il suffit de faire :

$ rvm get latest

Pour utiliser la dernière version Git de RVM plutôt que la dernière version publiée :

$ rvm get head

Utilisation des Gemsets de RVM

Concept des Gemsets

Pour rappel, un Gemset est un environnement hermétique dédié à l’installation et l’utilisation de gems.
Chaque version de Ruby connue de RVM dispose d’au moins 2 Gemsets : default (sans nom, en fait), et global. Par défaut on est dans le Gemset sans nom. Le Gemset global permet de rendre disponibles les gems qui y sont installées dans tous les autres Gemsets de la version courante de Ruby.
On peut ensuite créer autant de Gemsets que l’on souhaite, par exemple 1 pour chaque projet de dev.

Voilà une tentative de représentation visuelle :

/--------------------------|------------------|------------------\
|           Ruby EE        |     Ruby 1.9.2   |    autre Ruby    |
|--------------------------|------------------|------------------|
|           @global        |      @global     |     @global      |
|--------------------------|------------------|------------------|
| @default | @app1 | @appX | @default | @appX | @default | @appX |
\--------------------------|------------------|------------------/

Un Gemset par projet

Pour chacun des sites sur lesquels je travaille, je crée donc un Gemset. Ça permet d’isoler les gems qu’il a à disposition et ainsi de simuler un environnement spécifique à ce projet. Pour les projets qui utilisent Bundler l’intérêt est légèrement moindre, mais pour les autres (Rails 2, autres frameworks ou pas de framework) le bénéfice est immédiat.

Une des fonctionnalités de RVM est de reconnaître la présence d’un fichier .rvmrc dans un répertoire lorsqu’on s’y rend (avec cd par exemple). Si ce fichier de config indique qu’il faut choisir un Ruby et un Gemset, il bascule tout seul.
Chacun de mes projets dispose donc d’un fichier .rvmrc contenant au moins cette ligne :

rvm --create use default@projetX > /dev/null

En résumé, il va utiliser la version par défaut de Ruby (définie plus haut, mais modifiable à tout instant) et le Gemset “projetX” s’il existe. S’il n’existe pas, il est créé automatiquement. Le renvoi sur /dev/null permet que cette opération ne génère aucune sortie, ce qui est le cas sinon et c’est vite casse-pieds lorsqu’on navigue beaucoup via le terminal.

Depuis la version 1.0 (sortie le 22 août, 1 an exactement après le premier commit), RVM va demander confirmation la première fois qu’il rencontre un fichier .rvmrc dans un répertoire. C’est une précaution de sécurité.

Des gems dans le Gemset global

J’installe un certains nombre de gems dans le Gemset global pour les avoir toujours sous la main, quelque soit le projet dans lequel je travail ou si je suis simplement dans un shell hors projet.

  • passenger
  • capistrano + capistrano-ext
  • bundler
  • git_remote_branch
  • awesome_print
  • wirble
  • g

Ces gems seront donc dispo pour tous les Gemsets de la version de Ruby associée au Gemset global en cours.

Couplage harmonieux de RVM et Phusion Passenger

Dans son fonctionnement normal, Passenger utilise une version définie de Ruby et les variables d’environnement “normales” pour savoir où trouver les gems, …

Lorsqu’on install Passenger, on doit indiquer au serveur web (ici c’est Apache mais il y a une variante pour Nginx) ces 3 directives :

LoadModule passenger_module /usr/lib/ruby/gems/1.8/gems/passenger-3.0.4/ext/apache2/mod_passenger.so
PassengerRoot /usr/lib/ruby/gems/1.8/gems/passenger-3.0.4
PassengerRuby /usr/bin/ruby1.8

La clé est d’indiquer à Passenger la bonne version de Ruby et l’emplacement des modules, … Voilà ma propre config :

LoadModule passenger_module /Users/jlecour/.rvm/gems/ree-1.8.7-2011.03@global/gems/passenger-3.0.4/ext/apache2/mod_passenger.so
PassengerRoot /Users/jlecour/.rvm/gems/ree-1.8.7-2011.03@global/gems/passenger-3.0.4
PassengerRuby /Users/jlecour/.rvm/wrappers/ree-1.8.7-2011.03/ruby

En l’état, Passenger utilisera donc le module présent dans la gem installée dans le Gemset global et la version de Ruby définie par le wrapper passenge_ruby.

C’est bien, mais comment va-t-il utiliser le bon Gemset selon l’application ?

Avec un Passenger >= 2.2.14 et RVM >= 0.1.42 il est désormais possible d’utiliser (en Ruby) une API interne à RVM et forcer les variables d’environnement pour l’application lancée et qu’elle sache où chercher les gems dont elle a besoin. Le procédé est détaillé dans l’article The Path to Better RVM & Passenger Integration.
En résumé, au chargement de l’application Ruby, on demande à RVM quelques sont les variables à utiliser.

Pour le moment, Passenger est limité à un seul interprêteur Ruby. Voir la doc pour plus d’info.

Pour une appli en Rails 3, avec Bundler, voilà mon fichier config/setup_load_paths.rb :

if ENV['MY_RUBY_HOME'] && ENV['MY_RUBY_HOME'].include?('rvm')
  begin
    rvm_path     = File.dirname(File.dirname(ENV['MY_RUBY_HOME']))
    rvm_lib_path = File.join(rvm_path, 'lib')
    $LOAD_PATH.unshift rvm_lib_path
    require 'rvm'
    RVM.use_from_path! File.dirname(File.dirname(__FILE__))
  rescue LoadError
    # RVM is unavailable at this point.
    raise "RVM ruby lib is currently unavailable."
  end
end

ENV['BUNDLE_GEMFILE'] = File.expand_path('../Gemfile', File.dirname(__FILE__))
require 'bundler/setup'

Pour une application Rails, sans Bundler, il suffit de supprimer les 2 dernières lignes.

De cette manière, j’arrive à héberger avec Passenger des applis Rails 2, Rails 3 et Rack sur le même serveur web, sans conflit de version.

Utiliser Bundler pour la gestion des dépendances

Je résume une fois de plus ; Bundler permet de spécifier les gems (et leur version) nécessaires à un projet, de les installer (avec prise en charge des dépendances) et de ne “proposer” au projet en question que ces gems là. Le résultat est donc : facilité d’installation, confiance dans les versions utilisées, absence de conflits.

Si vous avez utilisé une version de Bundler <= 0.9.6, je ne peux que vous conseiller de désinstaller les version actuelles (sauf si vous en avez explicitement besoin), installer la version 1.0.rc puis recalculer les dépendances.

$ gem uninstall bundler
$ gem install bundler
$ bundle install

La version 1.0 (même depuis sa première beta) a apporté de gros changement, dont certains sont incompatibles, mais elle simplifie la gestion des déploiements en production, …

Lorsque dans un terminal, à la racine d’un projet géré avec Bundler, on fait un bundle install, le fichier de config Gemfile est analysé pour déterminer l’arbre des dépendances et un fichier Gemfile.lock est créé. Il est ensuite utilisé pour connaître l’exacte version de chaque gem à installer/utiliser.
Tant que ce fichier n’est pas modifié, le projet d’utilisera que ces gems là, ce qui garanti une cohérence entre l’environnement de développement (y compris d’un développeur à l’autre) et ceux de test, pre-production, production, …

Un développeur qui souhaite mettre à jour une gem ou en installer une nouvelle doit modifier le fichier Gemfile en conséquence, puis faire un bundle install. Il peut enfin versionner ces changements pour les rendre disponibles aux autres développeurs.

Un développeur qui ne veut pas gérer les changements de version de gems du projet en cours ne doit juste pas toucher aux fichiers Gemfile et Gemfile.lock. Pour s’assurer qu’il dispose en local des gems nécessaires à l’exécution de l’application ou bien si après une mise à jour du code il rencontre un “plantage” indiquant une erreur de gem, le 1er réflexe doit être de faire un bundle install depuis la racine du projet. Ainsi il s’assure d’être à jour au niveau des gems et de leur version.

L’utilisation de RVM rend ces processus encore plus faciles, rapides et fiables. En effet en mode normal, Bundler va installer au niveau système les gems nécessaires, mais comme le niveau système qu’il voit est en fait un Gemset, il ne pollue pas les autres projets.
En mode déploiement, il installe les gems dans un dossier de cache au sein de l’application, ce qui revient à peut près au même qu’un Gemset. Il est possible d’optimiser cette phase avec Capistrano.

Bundler et Capistrano pour un déploiement rapide et facile

Une appli gérée avec Bundler n’utilise plus les mécanismes classiques de require pour charger ses gems, c’est Bundler qui s’en charge à l’initialisation de l’appli. Il faut donc que les gems soient installées et accessibles à Bundler sur le serveur d’application. Il faut donc vérifier que tout est OK après chaque déploiement, et si possible mutualiser les gems d’une fois sur l’autre pour éviter des téléchargements et une consommation inutiles.

Depuis la version 1.0.0.rc.5, Bundler dispose d’une tache pour Capistrano (en réalité c’est depuis la rc.4 mais elle contenait des bugs). Il suffit d’ajouter require 'bundler/capistrano' dans sa recette de déploiement (deploy.rb). On peut éventuellement spécifier l’emplacement d’installation des gems, mais par défaut, c’est dans shared/bundle.

Autres paquets majeurs

Pour la gestion courante des paquets additionnels non fournis par Apple, je conseille d’une manière générale l’utilisation de Homebrew. Contrairement à MacPorts, il ne réinstalle pas toutes les dépendances systématiquement. S’il trouve son bonheur dans les paquets et librairies installés par Apple, il va les utiliser. Ça assure une plus grande cohérence, rapidité d’install et légèreté d’ensemble.

Homebrew installe aussi tout ce qui lui est nécessaire dans l’environnement utilisateur, sans nécessité d’utiliser sudo. C’est un peu déroutant pour un sysadmin, mais dans un contexte de développement, c’est plus pratique et plus simple.

J’ai utilisé Homebrew sur mon Mac pour installer MySQL, Git, ImageMagick, MongoDB, … et nombre de petits outils tels que tree, wget, ack, …, avec beaucoup de satisfaction.

Crédits

En priorité, je souhaite remercier les développeurs de ces outils géniaux et l’armée de contributeurs qui a participé.

Merci à Wayne E Seguin et John Mettraux pour une méticuleuse relecture, Thibaut Barrère et Sébastien Gruhier pour leur soutien et des astuces additionnelles

Cet article, publié dans Informatique, Mac, PLUG, est tagué , , , , , . Ajoutez ce permalien à vos favoris.

23 commentaires pour Conseils pour utiliser Ruby, RVM, Passenger, Rails, Bundler, … en développement

  1. fstephany dit :

    Chouette post !
    De notre coté (agilitic.com) nous utilisons Vlad pour déployer (http://rubyhitsquad.com/Vlad_the_Deployer.html). A notre humble avis, il est super sympa et moins lourd que Capistrano.

  2. J’ai aussi de bons échos à propos de Vlad.
    Pour ma part, j’ai été séduit par Cap dès le début et il m’a toujours très bien rendu service, donc j’ai pas ressenti le besoin de changer.

  3. Bien écrit ton article! C’est un bon contrendu des outils à adopter pour avoir un environnement bien d’aplomb dès le départ.

  4. Ping : Advice on using Ruby, RVM, Passenger, Rails, Bundle, … in development « Jérémy Lecour

  5. Alain Régnier dit :

    Je me félicite tous les jours d’avoir trouvé votre blogue! Encore des questions naïves : 1) comment savoir quels sont les gems dont on a besoin pour un projet particulier? 2) Peut-on vérifier quels sont les gems déjà installés sur une machine et pour un projet déjà en cours? 3) les gems sont-ils spécifiques d’un compte d’utilisateur dans MacOSX? (Je travaille sur une machine dont j’ai hérité d’une personne qui a tristement disparu, et il y a une version de Ruby (1.8.6) et de Rails (1.2.5) déjà installés au moins dans un des anciens comptes d’utilisateur).

  6. Alain

    Si vous avez apprécié cet article, il en existe une version française qui sera peut-être plus facile à comprendre.

    1) En premier lieu, il faut savoir ce que l’application doit faire, étudier si certaines parties sembles génériques et/ou relativement compliquées puis chercher si des gems existent pour ça. Certains sites sont pratiques pour ça : http://rubygems.org/, http://railsplugins.org/, http://rubyfoge.org/, et surtout http://github.com/

    2) Si Ruby est installé, le système dispose d’une commande `gem`. Elle permet de lister les gems installées avec `gem list` ou encore `sudo gem list`. Par défaut, il n’y a qu’un seul emplacement pour les gems, au niveau global pour le système et donc il faut utiliser `sudo` pour avoir le droit d’y accéder.

    3) Je me répète, mais par défaut, les gems sont installées globalement, donc de la même manière pour tous les utilisateurs du système (d’où la nécessité de `sudo`). L’idéal est probablement d’installer RVM dans votre environnement utilisateur et tout ce qu’il va gérer se fera dans votre environnement, de manière hermétique.

    Sinon, petit conseil général, indépendant de Ruby, … ; lorsqu’on récupère un ordinateur, il est bon de le re-installer complètement, sauf s’il contient des réglages et logiciels trop difficiles à restaurer ensuite. Ça permet de repartir sur quelque chose de propre, qu’on connait bien car on sait où sont les choses et pourquoi elles y sont.

  7. Ping : Ressources Rails | Le bazar de Nicolas

  8. Daniel dit :

    merci beaucoup pour ce post, je galère un peu pour apprivoiser bundler, capistrano, rvm, …

    Tes explications vont me simplifier la vie :)

  9. edap dit :

    Good article,
    Probably I did not understand all cause, I don’t speak french, but my mother language (IT) it’s quiete similar to yours. so….welcome in my feeds!

  10. Aina Anjary Fenomamy dit :

    great article!!

  11. Ping : Let's see where this leads...

  12. Deogracia dit :

    Merci pour cet article! ça a éclairci pas mal d’endroits ^^
    Bonne continuation!

  13. Julien dit :

    Bonjour à tous,

    j’ai un soucis car j’ai beau installer bundler (gem install bundler) mais impossible de taper la commande « bundle install » car le système me dit qu’il ne la connait pas.. j’ai donc créé le fichier  » bundle » dans /usr/bin/ et copié les lignes de l’original, car en effet l’installation avait fonctionnée sur mon autre machine virtuelle. A présent je fait un bundle install et ça marche (j’ai les lignes vertes qui me disent que ca a fonctionné).
    Cependant lorsque je lance le programme il me sort un tas d’erreurs, (alors que sur lautre machine ça marche nickel) donc comment résoudre le problème du « gem install bundler » s’il vous plait ?

    Merci

    • Salut Julien,

      Je suis bien désolé que tu rencontres ce genre de difficultés. Malgré les quelques éléments que tu indiques, je ne vois pas ce qui est la cause du problème.

      Ce qui est sûr c’est que copier manuellement des bouts de code ne peut pas rendre l’ensemble fonctionnel ; il faut trouver la vraie cause.

      Déjà, peux-tu dire sur quelle plateforme tu es, quelle version de Ruby tu utilises, si tu utilises RVM ou pas, …

  14. Julien dit :

    D’ailleurs quoi que j’installe avec « gem install », l’exécutable ne se crée pas ..

  15. Julien dit :

    Jeremy,

    Mon problème est résolu, en effet j’ai trouvé une commande qui est la suivante :

    gem install rubygems-update

    puis

    /var/lib/gems/1.8/bin/update_rubygems

    Je ne me souvenais pas avoir fait cette manipulation
    mais maintenant tout marche.

    Merci quand même, et surtout merci pour ton article.

  16. Lionel FELICITE dit :

    Hello,

    Ça fait un moment que je me sert de cet article et j’ai toujours oublié de te remercier : Merci pour ton article qui a débroussaillé pas mal dans ma compréhension.

    Bonne continuation !

  17. zatmania dit :

    Merci pour cet article !

    Je ne connais pas du ruby & co mais j’ai besoin de le mettre en place sur un de nos serveurs pour pourvoir utiliser chiliproject (fork de redmine). Cela va me permettre d’enrichir mes connaissances.

    zat

  18. Stéphane Morin dit :

    Bonjour trèes bon article ! Félécitation très bien écrit.
    Je me demande si tu peu éclairer mes lenternes mais je suis débutant, je vient de terminer un cours de développement de site web et j’ai un CMS fait maison qui utilise wamp server ainsi que ruby et compass, je programme en javascript et php et je suis en local alors a la création d’un nouveau projet via un portail que je me suis fait, une copie de ma bd ainsi que des fichiers du projet se créer et je me sert du cmd pour l’intégration avec compass watch. Je me suis installer un ordi avec ubuntu pour un server web sur IP dynamique ainsi que virtualhost pour l’hébergement de mes projets en local et j’ai peu être l’ambition de faire l’hébergement en externe (internet) pour mes clients. Donc voila, je travail sur window 8 et mon server est sur linux. Ce que j’aimerais c’est que quand je me log sur mon portail web de gestion de projet et que je créer un projet pour l’intégrer dans dreamweaver,avec compass le tout soit automatiser, c’est à dire création de la bd, copie des différent modules du projet dans un répertoire au nom que je lui donne et compilation du projet à chaque changement via ruby avec compass watch. Présentement, tout fonctionne sauf la création des hotes virtuels et le compass watch. Désolé mais j’ai eu un peu de difficulté à te présenter le projet et les probleme qui lui sont relier.

  19. Marc Maurer dit :

    Bonjour,
    J’ai installé rvm sur ma machine sous Mageia 3 laquelle dispose en propre ruby 1.9.3
    Ayant une appli sous ruby 1.8.7, j’ai installé rvm. L’installtiojn dedifférentes vesions de ruby se fait sans problème. Cependant, je me heurte à un problème : l’installation de la gem mysql2 échoue pour la version ruby 1.8.7 alors que lorsque j’était sous Mageia 2 avec son ruby 1.8.7 natif, l’installation de cette gem ne posait aucun problème et que cette même gem s’installe normalement pour ruby 1.9.3 (version native et version installée via rvm)
    Je précise que les librairies de dev de mysql sont installées.
    J’ai noté une différence dans l’arborescence des répertoires des « rubies » installés par rvm ; les versions 1.8.7 (p374 et ree 2012-2) sonr dépourvues d’un répertoire include présent sur les versions 1.9.3 ou 2.0.0
    J »ai laissé des fils sur différents forums de discussion mais sans résultat pour l’instant.
    Cordialement,

  20. cedric dit :

    Bonjour, je rencontre un problème au cour de l’instalation de passenger. quand je relance apache j’ai cette erreur:

    (apache2: Syntax error on line 210 of /etc/apache2/apache2.conf: Syntax error on line 1 of /etc/apache2/mods-enabled/passenger.load: Cannot load /var/lib/gems/1.8/gems/passenger-4.0.5/ext/apache2/mod_passenger.so into server: /var/lib/gems/1.8/gems/passenger-4.0.5/ext/apache2/mod_passenger.so: cannot open shared object file: No such file or directory
    Action ‘configtest’ failed.
    The Apache error log may have more information.
    …fail!)

    aparament le fichier mod_passenger.so n’exite pas. que dois-je faire?.
    merci de m’aider.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s