• | Home |
• CV |
• Blog |
• Contact |
• Liens |

Faire fonctionner Symfony sur un hébergement mutualisé OVH

Publié le 14/06/10 par Grégori DESAI - Catégorie : Symfony

Symfony est un framework qui nécessite d'avoir un accès au shell de la machine de production afin de pouvoir exécuter des tâches d'administration en lignes de commandes. Mais comment faire fonctionner Symfony sur un serveur mutualisé où l'accès SSH est souvent impossible ?

Nous allons prendre le cas d'une offre OVH mutualisé à bas prix qui ne propose pas cette fonctionnalité. Et vous allez voir qu'il est tout à fait possible de faire fonctionner Symfony dessus ! La preuve, ce site qui utilise Symfony 1.4, tourne sur un hébergement OVH mutualisé perso.

Il suffit de suivre scrupuleusement ces étapes et le tour sera joué !

Intégration dans l'arborescence mutualisée d'OVH

A la racine de votre espace FTP, vous avez un dossier cgi-bin et un dossier www. Vous pouvez commencer par supprimer le dossier cgi-bin. Le dossier www sera en fait le dossier web de votre projet symfony.
Uploadez le contenu de votre projet symfony à la racine de votre espace et placez le contenu du dossier web dans le dossier www (ce dernier n'étant pas modifiable).

Vous devriez avoir une architecture de la sorte :

apps

cache

config

data

lib

log

plugins

test

www

Faire pointer le cœur du framework dans le bon répertoire

Normalement, à cette étape il n'y a pas grand chose à faire. Vérifier que le require utilise bien la fonction dirname pour qu'il pointe au bon endroit indépendamment de l'environnement (par défaut sur la 1.4).
On va en profiter pour redéfinir la variable 'sf_web_dir' qui elle ne doit plus pointer au même endroit. Cette variable, ou plutôt constante est utilisée dans beaucoup de scripts.

//config/ProjectConfiguration.class.php

require_once dirname(dirname(__FILE__)).'/lib/vendor/symfony/lib/autoload/sfCoreAutoload.class.php';



sfCoreAutoload::register();



class ProjectConfiguration extends sfProjectConfiguration

{

  public function setup()

  {

    $this->setWebDir($this->getRootDir().'/www'); //redéfinition de sf_web_dir 

    

  }

}

Modifier la configuration d'accès à la base de données

On modifie le fichier database.yml pour cela.

#config/database.yml

all:

  doctrine:

    class: sfDoctrineDatabase

    param:

      dsn: 'mysql:host=mysql5-xx.xxx;dbname=votreLogin'

      username: votreLogin

      password: passDeLaBase

Vous pouvez aller voir dans le manager OVH pour connaître ces informations. Prendre soin d'exporter les tables de votre environnement de développement dans cette base, cela va de soit.

Le fichier .htaccess

Le fichier est nécessaire au bon fonctionnement des réécritures d'URL et du passage en PHP 5.3 sur OVH. (ce fichier n'est pas de moi!)
Placez-le dans le répertoire www.

SetEnv PHP_VER 5

SetEnv SESSION_USE_TRANS_SID 0

Options +FollowSymLinks +ExecCGI

mod_gzip_on Off

RewriteEngine On

# Permettre a IE de reconnaitre le win_png.htc de retraitement des png transparents

#AddType text/x-component .htc

#RewriteBase /

# we skip all files with .something

RewriteCond %{REQUEST_URI} \..+$

RewriteCond %{REQUEST_URI} !\.html$

RewriteCond %{REQUEST_URI} !\.php

RewriteRule .* - [L]

# we check if the .html version is here (caching)

# RewriteRule ^$ index.html [QSA] # Suppression du "/" pour un sous-dossier

RewriteRule ^$ /index.html [QSA]

RewriteRule ^([^.]+)$ $1.html [QSA]

RewriteCond %{REQUEST_FILENAME} !-f

# no, so we redirect to our front web controller

# RewriteRule ^(.*)$ index.html [QSA] # Suppression du "/" pour un sous-dossier

RewriteRule ^(.*)$ /index.php [QSA,L]

# RewriteRule ^(.*)$ index.html [QSA] # Suppression du "/" pour un sous-dossier

RewriteRule ^index\.php/(.*)$ /index.php [QSA,L]

L'heure du nettoyage

Videz le contenu des répertoires log et cache (idem que ./symfony cc) et mettez les droits 755 sur ces deux répertoires. Si vous vous servez du répertoire uploads, faîtes de même.
Supprimez les fichiers frontend_dev.php et backend_dev.php pour des questions de sécurité.

Problème avec le XHTML 1.1

OVH a eu la bonne idée d'activer la directive "short_open_tag" de PHP sur leurs serveurs mutualisés. En plus d'être une sacrée bêtise à mes yeux, la valeur n'est pas modifiable via un htaccess et fait en plus planter Symfony si vous avez passé le doctype de votre site en XHTML 1.1.
Le fichier layout contient alors une balise ouvrante "<?" de déclaration qui est interprétée comme une balise ouvrante PHP. Du coup, l'interpréteur PHP nous gratifie d'une belle "parse error" (ou d'une page blanche).

//apps/frontend/templates/layout.php

<?xml version="1.0" encoding="UTF-8"?> // Cette ligne doit être supprimée

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"

"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">

<head>

...

Le mot de la fin

Cette procédure est assez facile certes, mais rien ne peut remplacer un petit serveur dédié pour faire des déploiements rapides et sécurisés. Regardez du côté de Dedibox ou Kimsufi, des serveurs à 15 euros par mois viennent tout juste de faire leur apparition.
Lors des déploiements futurs, pensez à ne pas écraser les fichiers que l'on a modifiés ensemble sous peine de se retrouver avec une belle page blanche ou une erreur 500. On peut aussi réfléchir à créer un petit script bash pour automatiser une mise en production (copie des bons fichiers et upload via FTP).
N'hésitez pas à me faire part de vos problèmes ou questions, j'essaierai d'y répondre et/ou de compléter ce billet.

Bonne Symfony à tous !

D'autres billets pourraient vous intéresser :

Automatiser une mise en production de Symfony sur un hébergement mutualisé
Installation du plugin reCAPTCHA sur symfony 1.4


Voir tous les billets sur ce thème ! - Retour au blog

---

Les 11 commentaires

Poster un commentaire

Nom requis
Message requis
Email
URL

Still in developmentGB 2012