Un petit retour aux basics de PHP m’a confirmé que la création d’une fonction dans une méthode de classe la rendait globale à tout le programme, même dans la méthodes d’une autre classe. Du coup Symfony déclare « bêtement » (je met entre guillemets car Symfony oblige, ce n’est pas si simple ) ces fonctions dans la méthode d’une autre classe.

Exemple:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

<?php
class MaClasse
{
    public function registerFunction()
    {
        function ma_fonction()
        {
            // Traitement
        }
    }
}
 
// A ce moment, on ne peut pas appeler ma_fonction() car sa déclaration ne s'est pas faite
 
$instance = new MaClasse();
$instance->registerFunction();
 
// Maintenant on peut l'appeler
ma_fonction();
?>

Comme dit précédemment, on pourra donc également appeler ma_fonction() à l’intérieur d’une méthode d’une autre classe ou n’importe où dans le programme.

Attention cependant : PHP n’accepte pas la redéfinition des fonctions déjà déclarées, ce qui veut dire que si on s’amuse à appeler une deuxième fois la méthode registerFunction(), on aura un beau message d’erreur.

Comme quoi, relire les bases de temps en temps ça fait pas de mal

Comme nous l’avons dit, avec Doctrine tout est objet. Nous aurons donc accès à des classes qui vont nous permettre de travailler les données. On appelle ça des composants. Doctrine fournit plusieurs composants. En voici trois essentiels :

• Le composant Record qui représente un enregistrement d’une table
• Le composant Collection qui représente un ensemble de Record
• Le composant Table qui représente notre table et nous permettra d’accéder aux composants Collection et Record

Dans cet article nous allons étudier le composant Table.  Il permet comme son nom l’indique d’accéder à une table de notre base de données et d’interagir avec elle. Pour cela il nous faut une instance de la classe représentant notre table :

1
2
3

<?php
require_once('bootstrap.php');
$table = Doctrine_Core::getTable('Produits');

Vous remarquerez le nom particulier de notre table. En effet, dans notre base de données notre table s’appelle produits et dans Doctrine on l’appellera Produits. Chaque classe commence donc par une majuscule. En fait, chaque mot qui compose le nom de la table commence par une majuscule. Ainsi si on a une table nouveaux_produits on l’appellera NouveauxProduits dans Doctrine.

Cet objet va nous permettre d’accéder à une fonctionnalité très intéressante des Table : les finders.

Les finders sont des méthodes qui nous permettent de faire des recherches dans notre table et qui retournent soit un Record, soit une Collection. Voici un exemple :

1

$record = $table->find(4);

La méthode find() permet d’effectuer une recherche sur la clé primaire de notre table. Dans notre cas la clé primaire de la table produits est produits_id. L’équivalent SQL de ce que nous venons de faire est :

1

SELECT produits_id, produits_name, produits_prix FROM produits WHERE produits_id = 4

En fait find() fait plus que cela, il permet de sélectionner non seulement l’enregistrement mais aussi de rendre accessible les enregistrements des autres tables qui sont en relation avec cet enregistrement. Pour comprendre cela, nous allons étudier en détail le comportement de Doctrine. J’ai également récupéré les logs MySQL afin de voir comment Doctrine travaillait. Soit la base de données suivante :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56

SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0;
SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0;
SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='TRADITIONAL';
 
-- -----------------------------------------------------
-- Table `groupes`
-- -----------------------------------------------------
CREATE  TABLE IF NOT EXISTS `groupes` (
  `groupes_id` INT NOT NULL AUTO_INCREMENT ,
  `groupes_name` VARCHAR(45) NOT NULL ,
  PRIMARY KEY (`groupes_id`) )
ENGINE = InnoDB
DEFAULT CHARACTER SET = utf8
COLLATE = utf8_general_ci;
 
-- -----------------------------------------------------
-- Table `user`
-- -----------------------------------------------------
CREATE  TABLE IF NOT EXISTS `user` (
  `user_id` INT NOT NULL AUTO_INCREMENT ,
  `groupes_id` INT NOT NULL ,
  `user_pseudo` VARCHAR(100) NULL ,
  PRIMARY KEY (`user_id`) ,
  CONSTRAINT `user_groupes_id`
    FOREIGN KEY (`groupes_id` )
    REFERENCES `groupes` (`groupes_id` )
    ON DELETE CASCADE
    ON UPDATE NO ACTION)
ENGINE = InnoDB
DEFAULT CHARACTER SET = utf8
COLLATE = utf8_general_ci;
 
CREATE INDEX `user_groupes_id` ON `user` (`groupes_id` ASC) ;
 
-- -----------------------------------------------------
-- Table `phone`
-- -----------------------------------------------------
CREATE  TABLE IF NOT EXISTS `phone` (
  `phone_id` INT NOT NULL AUTO_INCREMENT ,
  `user_id` INT NOT NULL ,
  `phone_number` VARCHAR(20) NOT NULL ,
  PRIMARY KEY (`phone_id`) ,
  CONSTRAINT `phone_user_id`
    FOREIGN KEY (`user_id` )
    REFERENCES `user` (`user_id` )
    ON DELETE CASCADE
    ON UPDATE NO ACTION)
ENGINE = InnoDB
DEFAULT CHARACTER SET = utf8
COLLATE = utf8_general_ci;
 
CREATE INDEX `phone_user_id` ON `phone` (`user_id` ASC) ;
 
SET SQL_MODE=@OLD_SQL_MODE;
SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS;
SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS;

Voici une représentation schématique de cette base :

Schéma base de données

Comme on peut le voir, on a une table d’utilisateur. Chaque utilisateur ne peut appartenir qu’à un seul groupe (many-to-one), mais peut posséder plusieurs numéros de téléphone (one-to-many). Si je fais :

1

$user = Doctrine_Core::getTable('User')->find(1);

MySQL va faire la requête suivante :

1

SELECT u.user_id AS u__user_id, u.groupes_id AS u__groupes_id, u.user_pseudo AS u__user_pseudo FROM user u WHERE (u.user_id = '1') LIMIT 1

Je vais ainsi avoir accès aux champs de l’enregistrement récupéré grâce aux propriétés suivantes:

1
2
3

echo $user->user_id  .  '<br />';
echo $user->groupes_id  .  '<br />';
echo $user->user_pseudo  .  '<br />';

On va également avoir la possibilité d’accéder aux champs de la table groupes dont dépend notre enregistrement :

1

echo $user->Groupes->groupes_name . '<br />';

$user->Groupes représente un objet Record de la table Groupes. C’est un Record car selon le type de relation définit , un utilisateur ne peut appartenir qu’à un seul et unique groupe.

Sauf que dans la requête effectuée par Doctrine, on ne va pas chercher les informations de la table groupes. En fait la requête sera effectuée uniquement au moment où je demande d’accéder à la propriété $user->Groupes->groupes_name. Ainsi, à ce moment et uniquement lors du premier appel, Doctrine va effectuer la requête suivante :

1

SELECT g.groupes_id AS g__groupes_id, g.groupes_name AS g__groupes_name FROM groupes g WHERE (g.groupes_id = '1')

Doctrine va ensuite mettre ce résultat en cache. C’est à dire que si on demande à nouveau à accéder à une propriété de l’objet $user->Groupes, Doctrine ne va pas refaire la requête.

Tout comme nous avons un objet $user->Groupes, nous avons un objet $user->Phone. Sauf qu’il y a une différence : ici un utilisateur peut posséder plusieurs numéros de téléphone. Ainsi l’objet $user->Phone ne sera pas une instance de Record, mais une instance de Collection. Nous verrons plus loin les collections en détail, mais rapidement voici comment nous accèderons aux éléments de notre collection:

1
2

echo $user->Phone[0]->phone_number;
echo $user->Phone[1]->phone_number;

Au moment de l’appel à l’objet $user->Phone, Doctrine va effectuer la requête suivante :

1

SELECT p.phone_id AS p__phone_id, p.user_id AS p__user_id, p.phone_number AS p__phone_number FROM phone p WHERE (p.user_id IN ('1'))

et récupérer l’ensemble des résultats.

find() est donc bien pratique pour récupérer l’enregistrement d’une table, mais c’est moins glorieux lorsque l’on doit accéder aux relations de cet enregistrement. Même si Doctrine fait attention de ne pas effectuer de requêtes superflues, il fait en deux requêtes ce que l’on aurait pu faire en une seule avec une jointure.

Dans les finders, nous avons vu comment récupérer un enregistrement. Il est également possible de récupérer tous les enregistrements :

1

$users = Doctrine_Record::getTable('User')->findAll();

findAll() retourne donc une Collection qui contient tous les enregistrements de la table user. On peut itérer dans cette collection afin d’extraire les informations :

1
2
3

foreach ($users as $user) {
    echo $user->user_pseudo . '<br />';
}

La requête SQL de Doctrine qui va aller chercher les résultats est la suivante :

1

SELECT u.user_id AS u__user_id, u.groupes_id AS u__groupes_id, u.user_pseudo AS u__user_pseudo FROM user u

On peut également afficher le nom du groupe de chaque utilisateur :

1
2
3

foreach ($users as $user) {
    echo $user->Groupes->groupes_name . '<br />';
}

Là c’est encore pire au niveau de l’optimisation. En effet, nous avons vu plus haut que Doctrine n’effectuait les requêtes des tables en relation que lorsque l’on y accède. Insérons les données suivantes dans nos tables :

1
2
3
4
5
6
7
8

INSERT INTO `groupes` (`groupes_id`, `groupes_name`) VALUES
(1, 'groupe 1'),
(2, 'groupe 2');
 
INSERT INTO `user` (`user_id`, `groupes_id`, `user_pseudo`) VALUES
(1, 1, 'User 1'),
(2, 2, 'User 2'),
(3, 1, 'User 3');

Si nous analysons les requêtes effectuées par Doctrine lors de la boucle qui accède à la table groupe voici ce que l’on voit :

1
2
3

SELECT g.groupes_id AS g__groupes_id, g.groupes_name AS g__groupes_name FROM groupes g WHERE (g.groupes_id = '1')
SELECT g.groupes_id AS g__groupes_id, g.groupes_name AS g__groupes_name FROM groupes g WHERE (g.groupes_id = '2')
SELECT g.groupes_id AS g__groupes_id, g.groupes_name AS g__groupes_name FROM groupes g WHERE (g.groupes_id = '1')

Là ce n’est plus du tout optimisé puisque l’on constate que Doctrine va effectuer une requête pour chacun des enregistrements de la Collection $users, même si certaines sont communes. Si ce n’est pas grave dans notre cas, imaginez sur une table de 10 000 entrées… N’importe qui vous dirait que dans ce cas il faut effectuer une requête sur la table user avec une jointure sur la table groupes pour récupérer les champs du groupe. Cela nous pourrons le faire en DQL. En attendant sachez donc que si findAll() est parfaitement adapté pour récupérer les enregistrements d’une table, il ne l’est plus du tout lorsqu’il s’agit d’accéder aux relations de cette table.

Les finders ont d’autre possibilités assez intéressantes. Par exemple, il est possible d’avoir des finders personnalisés selon notre table. On les appelle les Magic Finders. Imaginons que nous voulions récupérer toutes les entrées de user dont le groupes_id est 1 :

1

$users = Doctrine_Core::getTable('User')->findByGroupes_id(1);

Cette ligne exécute la requête suivante :

1

SELECT u.user_id AS u__user_id, u.groupes_id AS u__groupes_id, u.user_pseudo AS u__user_pseudo FROM user u WHERE (u.groupes_id = '1')

Et renverra une instance de Doctrine_Collection. Ce qui est vraiment top, c’est que ce finder, qui dépend complètement des champs présents dans la table n’a pas besoin d’être codé par le développeur, Doctrine le propose automatiquement, voilà pourquoi on les appelle les Magic Finders.

Il est également possible de ne retourner qu’un seul enregistrement au lieu d’une Collection :

1

$users = Doctrine_Core::getTable('User')->findOneByGroupes_id(1);

Encore une fois il s’agit d’un finder personnalisé qui va effectuer la requête suivante :

1

SELECT u.user_id AS u__user_id, u.groupes_id AS u__groupes_id, u.user_pseudo AS u__user_pseudo FROM user u WHERE (u.groupes_id = '1') LIMIT 1

Les finders personnalisés peuvent aller encore plus loin. Regardez le finder suivant :

1

$users = Doctrine_Core::getTable('User')->findOneByGroupes_idAndUser_pseudo(1, 'User 1');

La requête SQL produite est la suivante :

1

SELECT u.user_id AS u__user_id, u.groupes_id AS u__groupes_id, u.user_pseudo AS u__user_pseudo FROM user u WHERE (u.groupes_id = '1' AND u.user_pseudo = 'User 1') LIMIT 1

On peut donc utiliser les mots-clés And et Or dans les Magic Finders afin de composer notre recherche

Voici donc un petit récap sur les finders :

• findAll() renvoie une Collection qui contient tous les enregistrements de la table
• find() renvoi un Record. La recherche se fera sur la clé primaire de la table
• findBy + le nom du champ commençant par une majuscule : Renvoie une Collection. La recherche se fait sur le champ indiqué après By
• findOneBy + le nom du champ commençant par une majuscule : Renvoie un Record. La recherche se fait sur le champ indiqué après By
• On peut utiliser les mots-clés And et Or dans les Magic Finders afin de composer une recherche sur plusieurs champs

Ces finders sont très pratiques mais retenez qu’il ne faut jamais les utiliser si vous avez besoin d’accéder aux relations des enregistrements à cause de leur manque d’optimisation. Pour cela nous nous tournerons vers le DQL.

Vous trouverez plus d’informations dans l’article de Julien Pauli sur developpez.com.

Ici il s’agit de voir comment l’installer sous Debian. Très facile finalement, il existe un paquet pour ça:

> apt-get install php-apc

Il faudra bien sûr redémarrer Apache.

Le fichier permettant le monitoring du cache est situé dans /usr/share/doc/php-apc et s’appelle apc.php.gz. Il faudra donc le décompresser:

> gzip -d apc-php.gz

Il vous suffit de déplacer ce fichier où bon vous semble.

A noter que le fichier de config d’APC se situe dans:

/etc/php5/conf.d/apc.ini

• Il était temps pour moi de laisser tomber la vieille extension mysql de PHP et de passer à de l’objet.
• Trouver un système qui s’intègre facilement dans un modèle MVC
• Pouvoir faire de l’abstraction de base de données
• Idéalement un système qui va me faire gagner du temps dans mes développements.

Après avoir regardé plusieurs solutions, je me suis donc tourné vers Doctrine:

• Il s’interface avec PDO, donc abstraction de base de données
• Les performances semblent au rendez-vous
• Il génère automatiquement le modèle du MVC
• Support des fonctionnalités récentes de MySQL
• Utilisé par défaut dans Symfony
• Tout est objet

Bref je me suis dis que c’était le top. Et c’est vrai que quand on le maîtrise c’est vraiment sympa. Sauf que la transition s’est quand même un peu faite dans la douleur. La doc est présente mais dans certains cas j’ai quand même perdu pas mal de temps à chercher des solutions à mes problèmes. Je me suis donc dit qu’il était peut-être possible d’apporter quelques compléments d’information.

Comprendre la philosophie Doctrine

Doctrine est un ORM (Object Relational Mapper), c’est à dire qu’il va s’interfacer avec notre base de données afin de nous permettre d’y accéder comme s’il s’agissait d’un objet.  Ainsi il sera possible d’accéder aux données d’une table comme s’il s’agissait de propriétés d’une classe, mais en plus cette classe va nous proposer des méthodes permettant de mettre en œuvre des fonctionnalité comme l’enregistrement, la suppression, la mise à jour etc.

Prenons un exemple simple :  soit la table mysql suivante:

1
2
3
4
5

CREATE TABLE produits (
  produits_id int(11) NOT NULL auto_increment,
  produits_name varchar(255) NOT NULL
  PRIMARY KEY  (produits_id)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8;

Imaginons que nous voulions insérer un nouvel enregistrement, nous pourrons le réaliser comme ceci :

1
2
3

$produit = new Produits();
$produit->produits_name = 'Casserole';
$produit->save();

C’est tout ! Et en bon ORM qu’il est, Doctrine propose une interface objet pour de nombreux éléments comme la connexion à la base, les tables, les enregistrements des tables, etc. ce que nous verrons plus tard.

Doctrine peut également réaliser des requêtes similaires à ce que l’on connaît sous MySQL mais avec son propre langage: le DQL (Doctrine Query Langage). Sincèrement, on s’y fait très vite, voici un exemple de sélection du produit ayant l’ID 4 :

1
2
3
4

$produit = Doctrine_Query::create()
    ->from('Produits a')
    ->where('a.produits_id = ?', 4)
    ->fetchOne();

La documentation officielle sur le DQL est plutôt bien faite et le « langage » est très explicite. Il n’y aura donc aucune difficulté particulière. Cependant nous en parlerons quand même dans un prochain article.

La génération du modèle et le fichier YAML

Pour arriver à tout cela, Doctrine va devoir utiliser des classes qui représenteront nos tables. Ces classes, on ne va pas les créer car Doctrine s’en charge pour nous. Il va donc se charger de générer des fichiers PHP qui seront notre modèle de données. Il y a plusieurs façons de réaliser cela :

• On peut créer notre modèle sur Doctrine qui va ensuite se charger de créer les tables sur MySQL
• On peut créer nos tables MySQL et Doctrine en déduira son modèle.

En ce qui me concerne, je modélise ma base de données avec MySQL Workbench, donc je pars toujours d’une base de données existante pour générer mon modèle Doctrine (je vais considérer que vous ferez pareil). Quelle que soit la solution choisie, il y a un passage qui semble indispensable : le fichier YAML. Il s’agit d’un fichier  de configuration qui va contenir le schéma de notre base de données et sur lequel Doctrine va se baser.

La génération du modèle va donc se dérouler ainsi:

Base de données MySQL existante -> Génération du fichier YAML -> Génération du modèle

Il existe une solution qui permet de générer le modèle directement à partir de la base de données, mais je ne l’ai pas trouvée intéressante car elle manque de fonctionnalités. En effet, nous verrons plus tard que Doctrine propose des fonctionnalités très intéressantes mais qui nécessitent d’être paramétrées dans le fichier YAML et que la conversion directe MySQL -> Modèle va ignorer.

Si vous ne connaissez pas YAML, il s’agit d’un langage de sérialisation de données comparable à JSON. Vous pourrez trouver plus de renseignements sur Wikipédia et sur le site officiel. Bien que je le trouve un peu plus complexe que JSON, YAML reste facilement compréhensible. Il ne sera donc pas compliqué de retravailler le modèle pour Doctrine.

Téléchargement et installation de Doctrine

Les informations qui suivent sont valables pour Doctrine 1.2.1. Il est possible de télécharger le sandbox à cette adresse: http://www.doctrine-project.org/download

On va créer un répertoire doctrine_test. Dans ce répertoire, nous allons créer le répertoire lib/vendor/doctrine dans lequel nous allons copier la librairie.

Nous devrions donc avoir dans le répertoire doctrine_test/lib/vendor/dotrine les éléments suivants:

• Un répertoire Doctrine
• Un répertoire vendor
• Un fichier Doctrine.php

Le bootstrap

Ce que l’on va appeler bootstrap, c’est un fichier PHP qui va contenir le code de connexion à la base de données et que l’on va inclure dans chacun de nos fichiers afin d’activer l’autoload, d’établir la connexion à la base et de définir plusieurs paramètres. Dans le répertoire doctrine_test, nous allons créer un fichier bootstrap.php dont voici le contenu :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

<?php
 
// bootstrap.php
 
/**
 * Bootstrap Doctrine.php, register autoloader specify
 * configuration attributes and load models.
 */
 
require_once('lib/vendor/doctrine/Doctrine.php');
 
spl_autoload_register(array('Doctrine', 'autoload'));
spl_autoload_register(array('Doctrine', 'modelsAutoload')); 
 
$manager = Doctrine_Manager::getInstance();
 
$conn = Doctrine_Manager::connection('mysql://user:password@host/dbname','doctrine');
 
$manager->setAttribute(Doctrine_Core::ATTR_VALIDATE, Doctrine_Core::VALIDATE_ALL);
$manager->setAttribute(Doctrine_Core::ATTR_AUTO_ACCESSOR_OVERRIDE, true);
$manager->setAttribute(Doctrine_Core::ATTR_AUTOLOAD_TABLE_CLASSES, true);
$manager->setAttribute(Doctrine_Core::ATTR_MODEL_LOADING, Doctrine_Core::MODEL_LOADING_CONSERVATIVE);
 
Doctrine_Core::loadModels('models');

Une note très importante si vous avez déjà utilisé Doctrine : vous remarquerez un deuxième autoload qui n’est pas indiqué dans la documentation. En effet cet autoload est nécessaire et n’est pas documenté et j’ai galéré un bon moment avant de trouver la solution sur leur forum.

L’explication de ce fichier est relativement simple :

1

require_once('lib/vendor/doctrine/Doctrine.php');

On inclue la librairie Doctrine

1
2

spl_autoload_register(array('Doctrine', 'autoload'));
spl_autoload_register(array('Doctrine', 'modelsAutoload'));

On déclare les autoloads

1

$manager = Doctrine_Manager::getInstance();

On récupère une instance Doctrine_Manager (singleton) qui va nous permettre de définir certaines options

1

$conn = Doctrine_Manager::connection('mysql://user:password@host/dbname','doctrine');

On se connecte à la base de données avec une syntaxe de type DSN compatible avec PDO

1
2
3
4

$manager->setAttribute(Doctrine_Core::ATTR_VALIDATE, Doctrine_Core::VALIDATE_ALL);
$manager->setAttribute(Doctrine_Core::ATTR_AUTO_ACCESSOR_OVERRIDE, true);
$manager->setAttribute(Doctrine_Core::ATTR_AUTOLOAD_TABLE_CLASSES, true);
$manager->setAttribute(Doctrine_Core::ATTR_MODEL_LOADING, Doctrine_Core::MODEL_LOADING_CONSERVATIVE);

Ici on définit les options de Doctrine au niveau global (on peut définir des options sur 3 niveaux: au niveau global, au niveau d’une connexion en particulier, au niveau d’une table en particulier). Voici la signification de ces options:

1

$manager->setAttribute(Doctrine_Core::ATTR_VALIDATE, Doctrine_Core::VALIDATE_ALL);

Doctrine possède un validateur de données intégré. Si jamais vous essayez par exemple d’insérer une chaîne de caractère dans une champ de type entier, Doctrine va générer une erreur avant même de tenter de l’insérer en base. C’est assez utile et ici on déclare vouloir l’utiliser.

1

$manager->setAttribute(Doctrine_Core::ATTR_AUTO_ACCESSOR_OVERRIDE, true)

l’AUTO_ACCESSOR_OVERRIDE va nous permettre de personnaliser l’assignation de données. J’essaierai de faire un article complet sur la personnalisation des classes car j’ai trouvé la documentation assez légère sur les possibilités offertes du coup je pense moi-même ne pas exploiter cette fonctionnalité à fond.

1

$manager->setAttribute(Doctrine_Core::ATTR_AUTOLOAD_TABLE_CLASSES, true);

Doctrine permet de personnaliser également les classes de table en permettant de créer des méthodes propres à une table. Ce paramètre permet de charger le fichier contenant nos méthodes personnalisées.

1

$manager->setAttribute(Doctrine_Core::ATTR_MODEL_LOADING, Doctrine_Core::MODEL_LOADING_CONSERVATIVE);

Ce paramètre permet d’utiliser l’autoload pour le chargement des classes du modèle.

1

Doctrine_Core::loadModels('models');

Enfin on déclare quel répertoire contient nos fichiers de modèle. Vous en déduirez donc qu’il va falloir créer un dossier models

Base de données de test et génération du modèle

Nous allons commencer avec une base de données simple dont voici le schema :

Voici le code SQL de création des tables (à copier / coller dans phpMyAdmin) :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82

SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0;
SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0;
SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='TRADITIONAL';
 
-- -----------------------------------------------------
-- Table `produits`
-- -----------------------------------------------------
CREATE  TABLE IF NOT EXISTS `produits` (
  `produits_id` INT NOT NULL AUTO_INCREMENT ,
  `produits_name` VARCHAR(100) NOT NULL ,
  `produits_prix` FLOAT NOT NULL DEFAULT 0 ,
  PRIMARY KEY (`produits_id`) )
ENGINE = InnoDB
DEFAULT CHARACTER SET = utf8;
 
-- -----------------------------------------------------
-- Table `tailles`
-- -----------------------------------------------------
CREATE  TABLE IF NOT EXISTS `tailles` (
  `tailles_id` INT NOT NULL AUTO_INCREMENT ,
  `tailles_name` VARCHAR(45) NULL ,
  PRIMARY KEY (`tailles_id`) )
ENGINE = InnoDB
DEFAULT CHARACTER SET = utf8;
 
-- -----------------------------------------------------
-- Table `couleurs`
-- -----------------------------------------------------
CREATE  TABLE IF NOT EXISTS `couleurs` (
  `couleurs_id` INT NOT NULL AUTO_INCREMENT ,
  `couleurs_name` VARCHAR(45) NOT NULL ,
  PRIMARY KEY (`couleurs_id`) )
ENGINE = InnoDB
DEFAULT CHARACTER SET = utf8;
 
-- -----------------------------------------------------
-- Table `produits_having_tailles`
-- -----------------------------------------------------
CREATE  TABLE IF NOT EXISTS `produits_having_tailles` (
  `produits_id` INT NOT NULL ,
  `tailles_id` INT NOT NULL ,
  PRIMARY KEY (`produits_id`, `tailles_id`) ,
  INDEX `pht_produits_id` (`produits_id` ASC) ,
  INDEX `pht_tailles_id` (`tailles_id` ASC) ,
  CONSTRAINT `pht_produits_id`
    FOREIGN KEY (`produits_id` )
    REFERENCES `produits` (`produits_id` )
    ON DELETE CASCADE
    ON UPDATE NO ACTION,
  CONSTRAINT `pht_tailles_id`
    FOREIGN KEY (`tailles_id` )
    REFERENCES `tailles` (`tailles_id` )
    ON DELETE CASCADE
    ON UPDATE NO ACTION)
ENGINE = InnoDB
DEFAULT CHARACTER SET = utf8;
 
-- -----------------------------------------------------
-- Table `produits_having_couleurs`
-- -----------------------------------------------------
CREATE  TABLE IF NOT EXISTS `produits_having_couleurs` (
  `produits_id` INT NOT NULL ,
  `couleurs_id` INT NOT NULL ,
  PRIMARY KEY (`produits_id`, `couleurs_id`) ,
  INDEX `phc_produits_id` (`produits_id` ASC) ,
  INDEX `phc_couleurs_id` (`couleurs_id` ASC) ,
  CONSTRAINT `phc_produits_id`
    FOREIGN KEY (`produits_id` )
    REFERENCES `produits` (`produits_id` )
    ON DELETE CASCADE
    ON UPDATE NO ACTION,
  CONSTRAINT `phc_couleurs_id`
    FOREIGN KEY (`couleurs_id` )
    REFERENCES `couleurs` (`couleurs_id` )
    ON DELETE CASCADE
    ON UPDATE NO ACTION)
ENGINE = InnoDB
DEFAULT CHARACTER SET = utf8;
 
SET SQL_MODE=@OLD_SQL_MODE;
SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS;
SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS;

Votre base de données étant créée, on va commencer par générer notre fichier YAML. Pensez à bien paramétrer le DSN dans le fichier bootstrap.php pour vous connecter à la base. Dans le répertoire doctrine_test, créez un répertoire yaml et un répertoire models accessibles en écriture pour Apache. On va ensuite créer un fichier generate_yaml.php contenant le code suivant :

1
2
3

<?php
require_once('bootstrap.php');
Doctrine::generateYamlFromDb('yaml', array('doctrine'));

Si vous exécutez ce fichier, vous trouverez dans le répertoire yaml un fichier schema.yml. Vous pouvez éditer ce fichier pour voir à quoi ressemble notre modèle. Nous allons ensuite générer les fichiers de classe à proprement parler. Créez le fichier generate_model.php et insérez le code :

1
2
3

<?php
require_once('bootstrap.php');
Doctrine::generateModelsFromYaml('yaml', 'models', array('generateTableClasses' => true));

Si vous l’exécutez , c’est maintenant dans le répertoire models que seront générés les fichiers. On y trouvera un répertoire generated dans lequel on trouvera les classes définissant nos tables, ainsi qu’une série de fichiers qui nous permettra par la suite de personnaliser nos classes.

Nous sommes maintenant fin prêts à utiliser Doctrine. Dans un prochain article nous verrons comment commencer à exploiter notre base de données.

En effet, dans mon framework, j’ai créé une classe d’exception qui hérite de Exception et qui rajoute des fonctionnalités comme par exemple une méthode permettant d’afficher le message d’erreur bien formaté en HTML avec un fond rouge et presque un gyrophare sur le dessus. Oui mais voilà, quand dans un de mes modules j’ai besoin d’utiliser une exception et que j’ai à afficher le message en utilisant une méthode personnalisée de mon exception, cela casse complètement l’indépendance de mon module. Je ne peux plus le sortir de son contexte car il dépend désormais de la classe d’exception de mon framework ce qui est contraire à ce que je veux.

J’ai vu que Zend Framework crée une classe d’exception spécifique pour son module héritée de la classe d’exception du framework, ce qui lui rend à peu près son indépendance puisqu’en changeant simplement la classe parent, on peut hériter directement de la classe Exception.

Par exemple pour le module de cache, on trouve cette classe d’exception:
<?php
class Zend_Cache_Exception extends Zend_Exception {}
?>
En changeant la classe parent on rend le module indépendant:
<?php
class Zend_Cache_Exception extends Exception {}
?>
Oui mais voilà, dans ce cas Zend_Exception qui hérite directement de Exception n’apporte rien de nouveau. Aucune nouvelle méthode, aucune fonctionnalité. Or dans mon cas, si j’utilise cette façon de procéder les méthodes personnalisées de ma classes d’exception ne seront plus disponibles lorsque je changerai la classe parent par Exception. Une seule conclusion m’est venue à l’esprit: je ne doit pas utiliser les fonctionnalités spéciales de ma classe d’exception dans mes modules. Dommage, car j’ai besoin d’afficher mes messages d’erreurs comme je le veux…

Et puis je me suis demandé si c’était vraiment le rôle de mon module de stopper l’exécution du programme pour afficher le message d’erreur. Non finalement. Si je prends pour exemple l’extension mysqli de PHP, elle ne bloque pas l’exécution du programme si la connexion à la base ne se fait pas. Elle se contente de fournir des méthodes pour récupérer les erreurs. C’est dans cette direction que je vais aller.

Tout d’abord, voici une structure de classe pour mon module avec un exemple d’exception :
<?php
class MonModule
{
    private $_error = NULL;

    public function getError()
    {
        return $this->_error;
    }
}
?>
Dans ce code on voir donc que mon module n’affiche pas le message d’erreur. Il se contente de le passer à un membre. Dans mon contrôleur, je vais pouvoir faire entrer ma classe d’exception personnalisée en action:
<?php
try {
    $instance = new MonModule();

    if ($instance->getError()) {
        throw new MyException($instance->getError());
    }
} catch (MyException $e) {
    $e->methodePerso();
}
?>
Ici on travaille directement sur l’instanciation de la classe MonModule(), du coup la valeur retournée par le constructeur est forcément une instance, mais lors de l’utilisation de cette technique sur les méthodes de la classe, on peut améliorer la chose en retournant false :
<?php
class MonModule
{
    private $_error = NULL;

    public function getError()
    {
        return $this->_error;
    }
}
?>
Et dans le contrôleur :
<?php
try {
    $instance = new MonModule();

    if (!$instance->maMethode()) {
        throw new MyException($instance->getError());
    }
} catch (MyException $e) {
    $e->methodePerso();
}
?>
Je ne sais pas si c’est la méthode idéale, mais au moins je suis sûr de conserver l’indépendance de mes classes et de mes exceptions.

Au lieu de faire un backup des données sur ma machine puis les renvoyer sur le nouveau serveur, j’ai décidé de faire directement un transfert de serveur à serveur via SSH. C’est nettement plus rapide car on bénéficie de la bande passante du serveur.

Pour cela nous allons utiliser la commande scp. La procédure est toute simple, on se loggue sur le serveur de destination et on tape la commande suivante:

> scp -pr user@host:/home/user/www/ /home/user/

Quelques précisions:

• -pr : signifie que l’on copie tout le contenu récursivement (dossiers, sous-dossiers et leur contenu) et que l’on veut conserver les options des fichiers
• user@host : le login et l’adresse du serveur sur lequel on va chercher les fichiers. L’utilisateur est bien sûr un utilisateur valide sur le serveur sur lequel nous allons récupérer le contenu et qui a les droits de lecture sur les fichiers et dossiers que l’on veut télécharger.
• /home/user/www : le chemin du répertoire contenant les fichiers à copier. Bien entendu c’est à personnaliser
• /home/user/ : le chemin de destination des fichiers sur notre serveur local. A personnaliser aussi.

Notez que l’on vous demandera bien évidemment le mot de passe de l’utilisateur afin de pouvoir se connecter au serveur distant.

Les fichiers seront copiés en conservant le chmod de chaque fichier. Par contre leur appartenance sera changée selon l’utilisateur sous lequel vous allez faire l’opération. Si vous avez fait l’opération sous root, n’oubliez pas de faire un petit

> chown -R user:group /home/user/www

Ce bug m’est apparu lorsque j’ai créé un menu déroulant en CSS / jQuery impliquant des listes positionnées en relative et absolute et que dans le contenu situé sous le menu j’ai un ou plusieurs éléments positionnés également en relative ou absolute. Dans ce cas j’avais le menu déroulant qui passait sous les éléments du contenu. Problème de z-index semble-t-il. Pourtant malgré le fait de bien paramétrer des z-index sur les éléments du menu et les éléments du contenu, rien à faire, le menu déroulant reste derrière. Grossièrement, le code a cette structure:

<div id="header">
    <div id="div_menu">
        <ul id="menu">
            <li><a href="#">Lien 1</a>
                <ul class="sousmenu">
                    <li><a href="#">Sous-menu</a></li>
                    <li><a href="#">Sous-menu</a></li>
                    <li><a href="#">Sous-menu</a></li>
                </ul>
            </li>
        </ul>
    </div>
</div>
<div id="contenu">
    <div id="element_en_absolu">Le sous menu passe derrière !</div>
</div>

Tous mes z-index avaient été placés sur les éléments #div_menu, #menu, #menu li etc.. ainsi que sur #element_en_absolu.

Finalement j’ai trouvé la solution sur ce blog. J’ai résolu le problème en définissant un z-index le plus élevé sur #header. Ce qui veut dire qu’il faut donc définir un z-index qui soit le plus élevé que tous les autre sur le ou les parents du menu.

L’idéal serait que le serveur A puisse rediriger les visiteurs sur le serveur B le temps de la propagation des DNS. Apache va nous y aider.

Pour cela il faut dans un premier temps activer le module proxy dans Apache. Nous allons ici nous contenter de rediriger le traffic HTTP uniquement.

> cd /etc/apache2/mods-enabled
> ln -s ../mods-available/proxy.conf proxy.conf
> ln -s ../mods-available/proxy.load proxy.load
> ln -s ../mods-available/proxy_http.load proxy_http.load

Ensuite on va modifier le virtualhost du domaine en question:

<VirtualHost *>
    ServerName mondomaine.com
    ServerAlias mondomaine.com www.mondomaine.com

    <Proxy *>
        Order deny,allow
        Allow from all
    </Proxy>

    ProxyRequests Off
    ProxyPass / http://mon_ip_de_domaine/~user/
    ProxyPassReverse / http://mon_ip_de_domaine/~user/
</VirtualHost>

Dans ce schéma, nous voyons que sur le serveur de destination nous avons activé le mod_userdir afin de pouvoir accéder au site par une adresse temporaire.

Un petit

> /etc/init.d/apache2 reload

et votre traffic devrait être redirigé.

Attention cependant pour tous les sites dynamiques utilisant PHP : avec cette méthode, les variables $_SERVER['PHP_SELF'] et $_SERVER['REQUEST_URI'] auront les informations du serveur de destination…

Ce serveur dédié a été choisi chez OVH. J’ai bien sûr demandé une Debian nue mais ça n’a pas vraiment été le cas. En fait, OVH livre une distribution Debian avec un noyau personnalisé et plusieurs outils installés par défaut. Suite à une mésaventure lors du passage de Etch à Lenny sur un de mes dédiés, j’ai décidé de ne plus laisser le noyau d’OVH mais d’installer un noyau standard. Si cette manipulation vous intéresse, voyez ce billet. Sinon ce qui suit fonctionne quand même parfaitement.

Les outils

La première chose que je fais en arrivant sur une installation neuve, c’est de configurer le raccourcit ll afin d’avoir un ls détaillé et en couleur. J’ai déjà fais un billet là-dessus que vous pourrez trouver à cette adresse.

La deuxième chose est de configurer un accès par clé privée ssh. L’article est à cet endroit.

Ceci fait, nous allons faire une première mise à jour du système:

> apt-get update
> apt-get -u dist-upgrade

Vient ensuite l’installation de quelques outils. Chez moi ils étaient déjà pré-installés mais s’ils ne le sont pas, faites-le:

• aptitude (permet de gérer les packages dans un mode semi-graphique)
• vim (qui est une version un peu plus évoluée de vi et qui permet notamment la coloration synthaxique)
• screen (permet de créer des consoles virtuelles supplémentaires, voir ce billet)

Pour activer la coloration syntaxique dans vim il faut taper la commande

:syn on

Si vous voulez qu’elle soit permanente, créez le fichier .vimrc dans votre répertoire utilisateur et insérez la ligne de commande:

syn on

Déplacer le dossier /var

Je pense que la première chose à faire, avant de se retrouver avec des daemons qui tournent de tous les côtés, c’est de déplacer le dossier /var. En effet les partitions système ne sont pas très grosses chez OVH et il arrivera un moment où les logs et les bases de données vont saturer cette partition et amener à un plantage du serveur. Etant donné qu’on a de la place dans /home, on va y déplacer le dossier /var

> cp -Rp var/ /home/
> mv /var/ /var.old/
> ln -s /home/var/ var

Installation de MySQL

rien de plus simple:

> apt-get install mysql-server

Dans la dernière version que j’ai installé, MySQL me propose désormais de paramétrer le mot de passe root du serveur. Je vous encourage fortement à le faire dès maintenant. Si vous ne le faites pas, vous pourrez le faire plus tard mais le plus tôt est le mieux car à ce niveau, ce n’est plus un trou de sécu, c’est la porte ouverte à toutes les fenêtres

Installation d’Apache 2.2

Pareil, trop dur Debian:

> apt-get install apache2-mpm-prefork

Notez que l’on installe ce paquet là d’Apache car le module PHP5 en dépend. Il ne fonctionne pas avec le paquet classique d’Apache 2.2.

Installation de PHP 5

> apt-get install libapache2-mod-php5

On va devoir également installer quelques modules supplémentaires pour PHP:

> apt-get install php5-cli
> apt-get install php5-gd
> apt-get install php5-mcrypt
> apt-get install php5-mysql

sont un minimum je pense. On peut facilement voir la liste des modules dispos en faisant un petit:

> dpkg -l *php5*

A ce niveau on peut déjà faire quelques petits tests. Déjà il faut redémarrer Apache:

> /etc/init.d/apache2 restart

Puis les tests : taper l’adresse du serveur dans votre navigateur web. Vous devriez avoir le fameux « It Works! » d’Apache.

Dans le répertoire /var/www créez un fichier info.php dans lequel vous allez mettre le code suivant:

1
2
3

<?php
phpinfo();
?>

Pareil, dans votre navigateur tapez : http://monserver/info.php. Normalement la config de PHP apparaît.

Configuration

maintenant que l’environnement LAMP est installé, on va faire un peu de configuration.

Tout d’abord pour MySQL, de base il n’y a rien de spécial à toucher. Cependant si vous désirez personnaliser votre installation, vous pouvez le faire en rajoutant un fichier dans /etc/mysql/conf.d. Toutes les options que vous y insèrerez seront prises en compte automatiquement.

Pour PHP, il faut faire la configuration classique de php.ini qui se trouve dans /etc/php5/apache2/php.ini

Ce fichier est configuré de façon très basique. Tel quel il fonctionne, il y a cependant moyen de l’améliorer un petit peu:

Si vous n’avez pas de scripts PHP balisés par <? et ?>, mettez l’option short_open_tag à Off. Cela obligera les scripts PHP à être balisés par <?php et ?>. Pourquoi? A partir de PHP6, le balisage court n’existera plus. Autant se mettre à la norme dès maintenant.

Si vous voulez désactiver certaines fonctions par mesure de sécurité (exec par exemple), vous pouvez les rajouter à l’option disable_functions en les séparant par des virgules.

En production, on conseille de passer l’option display_errors à Off car cela peu donner des indications importantes à une personne mal intentionnée. Par contre on passera le paramètre log_errors à On pour que les messages d’erreur soient enregistrés dans un fichier.

Si vous avez de vieux sites codés en PHP, peut-être aurez vous besoin de passer le paramètre register_globals à On. Si vous pouvez vous en passer ce n’est que mieux, question de sécurité.

Vous pouvez également décommenter la ligne:

;include_path = ".:/usr/share/php"

Cela vous permettra de protéger certains fichiers d’inclusion en les déportant de l’espace accessible par le web.

Passons maintenant à la configuration d’Apache. Tout se passe dans le répertoire /etc/apache2/

La première chose que nous allons faire c’est activer les modules dont nous avons besoin. La gestion des modules Apache à la sauce Debian est plutôt bien foutue: Dans le répertoire mods-available se trouvent tous les modules disponibles pour Apache. Le répertoire mods-enabled contient les modules activés. Si on veut activer un module, on ne va pas copier le module en question du répertoire mods-available au répertoire mods-enabled, mais plutôt faire un lien symbolique dans le répertoire mods-enabled vers les modules que l’on veut activer. Par exemple, pour activer le mod_rewrite, se placer dans le répertoire mods-enabled et taper la commande:

> ln -s ../mods-available/rewrite.load rewrite.load

Faire cela pour tous les modules que vous voulez activer. Si par exemple vous voulez activer le module userdir, n’oubliez pas qu’il y a deux liens à faire: un pour le .load et un pour le .conf

Les autres éléments de configuration se trouvent dans le répertoire /etc/apache2/conf.d. A l’image de ce qui se fait pour MySQL, tout fichier créé dans ce répertoire et contenant des directives sera pris en compte et écrasera la configuration d’origine. De base il y a un fichier charset qui contient une directive

AddDefaultCharset UTF-8

Qui active le jeu de caractère UTF-8 par défaut. Si vous préférez activer l’ISO-8859-1 par défaut, remplacez par:

AddDefaultCharset on

On va également créer un fichier directoryindex contenant la directive suivante:

DirectoryIndex index.html index.htm index.cgi index.pl index.php index.xhtml

Qui permet d’accepter une page index.php ou index.cgi comme page d’accueil pour un site

Si vous voulez accepter les CGI, il faut egalement créer un fichier cgi.conf dans lequel on va mettre:

AddHandler cgi-script .pl
AddHandler cgi-script .cgi

Ce qui va permettre d’accepeter les fichier .pl et .cgi comme CGI

Vous pouvez bien sûr continuer comme ça à paramétrer tout ce que vous voulez.

Installation de ProFTPD

On est presque prêt à accueillir nos premiers sites. Mais pour cela il faut les uploader sur le serveur et pour ça il nous faut un serveur FTP. En voici un : ProFTPD

> apt-get install proftpd

On vous demandera si vous voulez le lancer sous inetd ou indépendamment, choisissez la deuxième option.

Après installation, le serveur est déjà prêt à l’utilisation. Si vous voulez changer la configuration, vous pouvez le faire en modifiant le fichier /etc/proftpd/proftpd.conf, mais on peut déjà exploiter le serveur tel quel.

Il n’y a juste qu’une chose à modifier dans la configuration du serveur. Il faut rajouter les lignes suivantes:

DefaultRoot ~
IdentLookups off
UseReverseDNS off

La première instruction permet de bloquer chaque utilisateur dans son répertoire et évite qu’il se balade sur tout le serveur. Les deuxièmes et troisièmes instructions désactivent des traitements DNS de proftpd et permettent une connexion rapide au serveur (essayez les deux et voyez la différence).

Maintenant, il ne nous reste plus que 2 choses à faire: créer un utilisateur FTP avec son espace, et configurer le domaine associé sous Apache pour qu’il pointe à cet endroit.

Pour créer un utilisateur FTP, rien de plus simple, on va créer un utilisateur système:

> addgroup nom_user
> adduser --ingroup nom_user nom_user

Cela va créer le répertoire personnel de l’utilisateur dans le répertoire /home

Lors de la création de cet utilisateur, vous devrez saisir des renseignements. Le plus important est bien sûr le mot de passe, le reste n’est pas important.

On peut désormais configurer notre client FTP pour se connecter:

host: IP_serveur
login: nom_user
mot de passe : pass_user

Une fois connecté, on crée un répertoire www qui contiendra le site et on peu mettre une page d’accueil quelconque pour faire nos tests.

Tester avec le module userdir

Le module userdir permet de se connecter à l’espace web d’un utilisateur du système sans le nom de domaine. L’url sera de la forme:

http://ip_serveur/~nom_utilisateur/

Pour pouvoir faire cela, il faut dans un premier temps activer le module userdir dans Apache (voir plus haut). Puis dans le répertoire /etc/apache2/conf.d créer un fichier userdir contenant les commandes suivantes:

<IfModule mod_userdir.c>
    UserDir www
    UserDir disabled root

    <Directory /home/*/www>
        AllowOverride FileInfo AuthConfig Limit
        Options Indexes SymLinksIfOwnerMatch IncludesNoExec
    </Directory>
</IfModule>

On relance Apache et normalement si vous faites l’adresse indiquée plus haut, vous devriez voir votre page uploadée tout à l’heure.

Note: Si vous utilisez le module rewrite, je vous déconseille fortement d’utiliser l’option MultiViews de la commande Options car personnellement j’ai eu des interférences entre les deux.

Configuration d’un domaine:

Maintenant, on va configurer Apache pour que mondomaine.com pointe sur /home/nom_user/www.

Dans le répertoire /etc/apache2/sites-available créer le fichier mondomaine.com. Y mettre les instructions suivantes:

<VirtualHost *>
    ServerName www.mondomaine.com
    ServerAlias mondomaine.com www.mondomaine.com
    ServerAdmin webmaster@mondomaine.com

    DocumentRoot /home/nom_utilisateur/www
    ScriptAlias /cgi/ "/home/nom_utilisateur/cgi-bin/"

    <Directory /home/nom_utilisateur/www>
         Options -Indexes
    </Directory>

    php_admin_value open_basedir "/tmp:/var/lib/php5:/home/nom_utilisateur/www"
</VirtualHost>

Vous devez bien sûr encore une fois remplacer les paramètres mondomaine.com et nom_utilisateur par vos valeurs.

Enregistrez, rechargez Apache et le tour est joué.

Note: il est important de ne pas oublier le paramètre open_basedir de PHP, cela empêche les scripts PHP de pouvoir lire n’importe quel fichier du serveur en le cloisonnant dans le répertoire www/

Installation de phpMyAdmin

Forcément, si vous avez installé MySQL, il vous faut phpMyAdmin. Il y a deux écoles:

• Rester à la sauce Debian et installer le package phpMyAdmin
• L’installer à la main

Les deux solutions ont leurs avantages et inconvénients:

Installer le package est simple et la maintenance aussi puisqu’un simple apt-get permet une mise à jour. Par contre les versions ne sont pas à jour. Au moment de la rédaction de ce billet, la version actuelle est en 2.11.9 alors que le package est en 2.9.1. Pour cette raison je préfère une installation manuelle. Par contre cela m’oblige à me tenir au courant des mises à jour et à les faire manuellement.

Généralement j’installe phpMyAdmin dans le répertoire /var/www. Ainsi on peut accéder à phpMyAdmin par l’adresse: http://ip_serveur/phpMyAdmin

L’avantage de cette méthode est qu’il est facile de créer des alias ou des redirections de tous les noms de domaine qui seront installés sur le serveur afin qu’ils aient une url de phpMyAdmin simple. Par exemple une directive:

Alias /phpMyAdmin /var/www/phpMyAdmin/

permet une redirection transparente.

une fois phpMyAdmin installé, la première chose à faire est de s’y logguer afin de paramétrer le mot de passe root de MySQL. Si vous ne l’avez pas fait lors de l’installation c’est le moment où jamais !!

Envoyer des mails avec PHP

C’est la dernière chose qui nous manque avant d’avoir un serveur de production minimal potable. Pour cela on va installer exim4:

> apt-get install exim4

puis pour la configuration:

> dpkg-reconfigure exim4-config

les options:

• séparer la configuration dans plusieurs fichiers -> Non
• Type de configuration -> Distribution directe par SMTP
• Nom de courriel du système -> Mettez le nom de domaine principal du serveur ou laissez par défaut
• Liste d’adresses IP -> laissez 127.0.0.1 pour le moment
• Autres destinations -> Vide
• Domaines à relayer -> Vide
• Machines à relayer -> Vide
• Faut-il minimiser les requêtes DNS -> Non
• Méthode de distribution du courrier local -> laissez « mbox »

Théoriquement, les emails envoyés de PHP fonctionnent désormais.

En fait c’est un noyau préparé par OVH qui contient les derniers patchs de sécurité et qui permet de se passer de modules externes car ils sont embarqués. Problème: quand j’ai voulu upgrader ma distrib de Etch à Lenny, j’ai eu énormément d’ennuis et j’ai dû faire appel à un ami spécialiste pour me dépatouiller.

Le premier problème a été Lilo: il a commencé à me mettre des warnings pendant la mise à jour. Comme je n’étais pas sûr des conséquences que cela aurait au reboot et vu que Lilo commence sérieusement à dater, on a décidé de mettre Grub, et là tout est parti en vrille, ce qui n’aurait pas été le cas si j’avais eu un noyau standard… En effet d’une part Grub se base sur le nom d’un noyau standard pour s’installer, ce qui n’était pas le cas. La config de grub ne n’est donc pas faite correctement. On s’est donc dit que dans ce cas, on allait donner à Grub ce qu’il voulait, c’est à dire un noyau standard. Sauf que la il va aussi falloir gérer les modules à la main. En plus de cela le serveur était en raid1 logiciel, ce qui nécessite une maipulation supplémentaire avec Grub.

On va donc essayer à travers cet article de remettre la distribution droite dès le départ étant donné que le serveur dédié sur lequel je refais cette expérience est neuf.

La première chose à faire est de récupérer toutes les informations nécessaires sur notre hardware, notre architecture, le raid logiciel, etc…

Déjà, grâce au nom du noyau on sait que l’on est sur une architecture 64 bits.

Pour le hardware, on a besoin de savoir quel est le processeur que nous avons, ainsi que la ou les cartes réseaux.  Pour le processeur, on va faire un :

> vi /var/log/dmesg

puis on va faire une recherche sur « Intel ». Déjà je peux noter les infos suivantes:

CPU0: Intel(R) Core(TM)2 Duo CPU     E8400  @ 3.00GHz stepping 0a

Bon, première info… Le truc à savoir avec l’architecture 64 bits, c’est que quel que soit votre processeur (AMD ou Intel), vous devrez installer un noyau AMD64. On peut le voir à cette adresse: http://www.debian.org/ports/amd64/

Le portage se compose d’un noyau pour tous les processeurs AMD 64 bits avec l’extension AMD64 et pour les processeurs Intel avec l’extension EM64T et d’un espace utilisateur 64 bits commun.

Bref, si je fais un

> apt-cache seach 'linux-image'

je tombre sur ce noyau :  » linux-image-2.6.26-2-amd64 – Linux 2.6.26 image on AMD64″

C’est celui-là qu’il nous faut.

En ce qui concerne la carte réseau, dans un premier temps on a besoin de savoir combien on en a. Pour cela un petit

> ifconfig

M’indique qu’il n’y a que et0 et lo (qui est l’interface locale). Donc je n’ai qu’une carte. Pour m’assurer des modules nécessaires à ma carte réseau, j’ai trouvé en parcourant les forums un truc plutôt pas mal. Tapez la commande:

> lspci -n

Et copiez le contenu du résultat dans le textarea de ce site: http://kmuto.jp/debian/hcl/

Il vous donnera le nom des modules à charger. Dans mon cas c’est donc le module r8169 dont j’ai besoin

Enfin on finit par vérifier si on est en raid ou pas. En tapant :

> cat /proc/mdstat

j’obtiens:

md1 : active raid1 sdb1[1] sda1[0]
5245120 blocks [2/2] [UU]

md2 : active raid1 sdb2[1] sda2[0]
970992576 blocks [2/2] [UU]

Donc je sais que je suis en raid1 sur deux disques serial ATA (sda et sdb).

On a tout ce qu’il faut pour se lancer. C’est parti:

On installe grub en premier (en effet notre noyau standard a besoin de grub pour s’installer sinon on a une erreur).

> apt-get install grub

On crée le répertoire de grub dans le répertoire de boot :

> mkdir /boot/grub

On fait une première install de grub. Je suis pas sûr que cette étape soit nécessaire, je vérifierai cela lors de ma prochaine installation de dédié

> grub-install /dev/md1

On installe notre noyau :

> apt-get install linux-image-2.6.26-2-amd64

On installe grub :

> grub-install /dev/md1

On demande une mise à jour de grub

> update-grub

Le problème maintenant c’est qu’on est sur du raid logiciel. Notre disque /dev/md1 n’est donc pas physique mais virtuel. Et le souci c’est que notre grub-install ne va pas s’inscrire sur le secteur de boot de sda et sdb. Il faut donc faire cette manipulation manuellement :

> grub
grub> root (hd0,0)
grub> setup (hd0)
grub> setup (hd1)
grub> quit

Il ne faut pas oublier de le faire sur les deux disques dur, ainsi si un des disques crash, le deuxième sera bootable.

Avant de rebooter, ne pas oublier les modules de la carte réseau ! Dans /etc/modules rajouter:

loop
r8169

et sauvegardez..

En demandant conseil à mon pote pour réaliser toutes ces manipulations en sécurité, il m’a dit qu’on avait eu un problème au niveau du package « mdadm » qui est le package gérant le raid. En effet, lors de notre expérience malheureuse, il s’est rendu compte que ce paquet n’était pas installé, le noyau d’OVH embarquant ce dont il a besoin pour le faire fonctionner. En ce qui me concerne sur ce nouveau serveur, le package est bien présent mais n’hésitez pas à vérifier et à l’installer le cas échéant sinon vous aurez une surprise au reboot !

Vous pouvez y aller maintenant.

> reboot

et croisez les doigts…

N’hésitez pas à me faire part de vos expériences sur le sujet, mes connaissances sur le sujet étant modestes, il se peut qu’il y ait des erreurs ou des choses à améliorer.