Son installation est des plus simple :

$ gem install passenger
$ passenger-install-apache2-module

Ensuite il ne reste qu’a rajouté 3 lignes dans notre fichier de configuration d’Apache pour avoir mod_rails opérationnel. Son utilisation devient alors un jeu d’enfant. Fini l’edition des VirtualHost  avec toute les regles de réécriture et autre contrainte lors de l’utilisation de Thin ou Mongrel.  Il suffit juste de définir le DocumentRoot et le tour est joué

Niveau performance, il est plus rapide que Mongrel et quasiment équivalent à Thin, mais avec une utilisation de la mémoire plus fine. D’apres mes tests, lorsque personne ne se connecte sur l’application, le serveur est coupé et donc ne consomme rien, et lors d’une connection, celui est relancé jusqu’à ce qu’il soit inactif. Cela implique une premiere connexion un peu plus longue mais tout à fait acceptable,  donc pourquoi s’en privé ?

Cependant, Thin et Mongrel reste incontournable lors d’une utilisation plus avancé pour une gestion fine des clusters si on possède des serveurs réparti sur plusieurs machine. De plus Passenger est exclusivement utilisable pour Ruby on Rails, donc Merb et autre framework concurrent ne sont pas compatible.

J’en ai également profité pour mettre à jour certaines Gems installées : mongrel, thin, rmagick, sqlite-ruby

Il semblerait que cette faille permettent à un utilisateur local d’obtenir des droit de super utilisateurs en exécutant un bout de code qui fait un buffer overflow au niveau du vmsplice.

Aprés avoir moi même tester ce bout de code, je dois avouer que c’est bluffant, dans n’importe quel Shell, il suffit d’executer le ptit programme qu’on a compiler, et l’invite de commande passe en root…

Cela fonctionne sur toutes les distributions que j’ai pu croiser, que se soit du x86 32bits ou 64bits, je n’ai pas tester d’autre architectures. Il suffit d’avoir accés à un compte utilisateur d’une machine pour faire ce que l’on veut !

J’ai passer la nuit à fouiller les newsgroup pour trouver un début de solution, qui a été trouvée en début de matinée !

Je post donc ce message à partir du nouveau kernel 2.6.23-r7 patché pour que l’exploitation de cette faille ne soit plus possible

Finalement ce n’est pas le retour d’I Love You, dommage ce genre de Vers sont inoffensif pour un système Unix

Le serveur Mongrel, écrit en Ruby et en C, a donc été mis en place sur Valkyrie. Il permet d’avoir d’avoir une réactivité de l’application tout à fait agréable. Mais la charge mémoire reste toujours importante. Donc après quelques recherches, je suis tombé sur le serveur Thin.

Thin regroupe les 3 librairies suivantes :

• Mongrel parser, la base de la vitesse et sécurité de Mongrel.
• Event Machine, une librairie d’I/O réseau de très bonne performance, stable
• Rack, l’interface minimale entre un serveur web et les framworks Ruby

Thin est extremement pratique à l’usage, et la charge mémoire réduite. Thin est donc mon serveur Ruby on Rails de prédilection pour le moment, jusqu’au moment où un concurrent se fera remarquer !

Exemple de mise en place du serveur :

thin config -C myapp.yml -s3 -p 5000
thin start -C myapp.yml

Ce qui met en place un fichier de configuration pour “myapp” qui définit le lancement de 3 serveurs à partir du port 5000.

Un rapport est envoyé directement aux admins quotidiennement à l’aide chkrootkit !

Le port 465 est un faux positif, il s’agit du port d’écoute de SMTP en SSL

A étudier comment faire (avec possibilité de reprendre en cas de perte de la connexion ?).

Via :

• apache
• ext+ssh

Essayer de le rendre dynamique via SQL comme le reste de Valkyrie si possible.