Le blog de llaumgui - MySQL

Du changment dans ma vie

llaumgui — Wed, 30 Apr 2008 08:43:00 +0200

Hier était pour moi un jour particulier puisqu'il s'agissait de mon dernier jour au sein de la société Kaliop. Une société et des collaborateurs avec qui j'ai pris plaisir à travailler pendant près de 2 ans & demi, et où je pense avoir beaucoup appris.

Lundi commencera pour moi un nouveau défi puisque j'intègre la société Logica, la 7^e société de conseil, de services informatiques et outsourcing en Europe (sources Wikipédia) qui est plus connu en France sous son ancien nom : Unilog (Mais où est passé Unilog). Mon titre y est décrit comme "Ingénieur en technologies de l'information" et j'y ferais principalement du php5/MySQL/eZ Publish; bref, je m'aventure en terrain connu ;-).

Autre changement en prévision : un nouveau déménagement ! Ce coup si je n'emménage pas seul vu que je déménage pour habiter avec ma copine ;-).

Petit message à mes anciens collaborateurs : Vengeance : Dark Tyranus | Kakia la coquine | Touche les tétous

Bug MySQL 5.0.51a

llaumgui — Mon, 18 Feb 2008 23:04:00 +0100

Depuis quelques jours on me rapporte des comportements étranges sur les forums de fedora-fr. Les messages récents ne seraient plus triés dans le bon ordre (ni dans aucun autre d'ailleurs)... Étonnant, car je n'ai rien touché au code de notre PunBB depuis un bon petit moment...

Bref un petit vim include/common.php pour passer le PUN_SHOW_QUERIES à 1 et ainsi tracer les requêtes MySQL et m'apercevoir que la requête fait bien un ORDER BY t.last_post DESC:

SELECT t.id AS tid, t.poster, t.subject, t.last_post, t.last_post_id, t.last_poster, t.num_replies, t.closed, t.forum_id

FROM punbb_topics AS t

WHERE t.id

IN ( 14524, 29504, 29192, 29526, 29426, 29358, 29381, 29507, 29512, 29534, 29523, 29531, 29532, 29514, 29469, 28791, 29308, 29141, 20353, 29449, 29505, 28867, 29500, 29495, 29535, 29321, 29478, 29480, 29486, 29499, 29506, 29528, 29529, 29457, 29496, 29533, 28380, 29510, 28969, 29142, 29416, 29454, 29511, 29513, 26116, 29333, 29267, 29455, 29493, 29524, 28420, 29258, 29410, 29418, 29452, 29509, 29491, 29477, 29487, 29492, 29501, 29508, 29515, 29517, 29519, 29520, 29525, 29530, 29527, 27926, 28938, 29231, 29265, 29371, 29440, 29485, 29497, 29502, 29518, 29522, 29521 )

GROUP BY t.id, t.poster, t.subject, t.last_post, t.last_post_id, t.last_poster, t.num_replies, t.closed, t.forum_id

ORDER BY t.last_post DESC

LIMIT 0 , 30

Un café plus tard, je lance directement la requête dans l'interface de phpMyAdmin et je m'aperçois que les résultats ne sont effectivement pas triés dans l'ordre... Mais qu'ai je fais ?! Je trace le log de yum et je constate que je suis récemment passé de mysql-server 5.0.45 à la version 5.0.51a...

root@borsalino ~> cat /var/log/yum.log | grep mysql

Oct 15 20:05:57 Installed: mysql.i386 5.0.27-1.fc6

Oct 15 20:08:09 Installed: mysql-server.i386 5.0.27-1.fc6

Oct 15 20:08:10 Installed: php-mysql.i386 5.1.6-3.7.fc6

Jan 20 18:56:44 Installed: mysql-libs.i386 5.0.45-1.fc6.remi

Jan 20 18:56:47 Updated: mysql.i386 5.0.45-1.fc6.remi

Jan 20 18:56:54 Updated: mysql-server.i386 5.0.45-1.fc6.remi

Jan 20 18:56:54 Updated: php-mysql.i386 5.2.5-1.fc6.remi

Feb 17 13:06:18 Updated: mysql-libs.i386 5.0.51a-1.fc6.remi

Feb 17 13:06:22 Updated: mysql.i386 5.0.51a-1.fc6.remi

Feb 17 13:06:29 Updated: mysql-server.i386 5.0.51a-1.fc6.remi

Dans le doute je contact l'ami Remi qui m'aide et me trouve ce bug : #30596 : GROUP BY optimization gives wrong result order.

Effectivement en virant les GROUP BY la requête se retrouve ordonnée comme il faut...
5 minutes plus tard Remi lance un build de MySQL comportant le correctif que j'installe dans la foulée et tout ce remet à marcher dans l'ordre ;-).

root@borsalino ~> yum --enable remi-test update mysql\*

Remi + Borsalino = php5.2 + MySQL 5 mis à jour

llaumgui — Sun, 20 Jan 2008 18:02:00 +0100

Devant la coupure de service, surement due à une monté en charge de Borsalino, et devant les failles récentes révélées pour php : j'ai décidé de basculer Borsalino sur le dépôt de l'ami Remi Collet qui maintient toujours les packages php et MySQL pour Fedora 6 alias Zod !

On install le dépôt :

root@borsalino ~> wget http://remi.collet.free.fr/rpms/remi-release-6.rpm

root@borsalino ~> rpm -Uvh remi-release-6.rpm

On active le dépôt en passant enabled à 1 :

root@borsalino ~> vim /etc/yum.repos.d/remi.repo

Et on mets à jour :

root@borsalino ~> yum clean all; yum update

[...]

Dependencies Resolved



=============================================================================

 Package                 Arch       Version          Repository        Size 

=============================================================================

Updating:

 mysql                   i386       5.0.45-1.fc6.remi  remi              2.1 M

 mysql-server            i386       5.0.45-1.fc6.remi  remi               10 M

 php                     i386       5.2.5-1.fc6.remi  remi              1.3 M

 php-cli                 i386       5.2.5-1.fc6.remi  remi              2.5 M

 php-common              i386       5.2.5-1.fc6.remi  remi              226 k

 php-eaccelerator        i386       1:0.9.5.2-1.fc6.remi  remi              136 k

 php-gd                  i386       5.2.5-1.fc6.remi  remi              115 k

 php-ldap                i386       5.2.5-1.fc6.remi  remi               33 k

 php-mbstring            i386       5.2.5-1.fc6.remi  remi              1.1 M

 php-mcrypt              i386       5.2.5-1.fc6.remi  remi               28 k

 php-mysql               i386       5.2.5-1.fc6.remi  remi               83 k

 php-pdo                 i386       5.2.5-1.fc6.remi  remi               89 k

 php-pear                noarch     1:1.6.2-1.fc6.remi  remi              400 k

 php-xml                 i386       5.2.5-1.fc6.remi  remi               97 k

Installing for dependencies:

 mysql-libs              i386       5.0.45-1.fc6.remi  remi              1.5 M

 sqlite2                 i386       2.8.17-1.fc6     extras            170 k



Transaction Summary

=============================================================================

Install      2 Package(s)         

Update      14 Package(s)         

Remove       0 Package(s)         



Total download size: 20 M

Pour finir, on peut utiliser mon script pour notifier des mises à jour via yum...

Une petite Dedibox sous CentOS

llaumgui — Wed, 04 Jul 2007 22:57:00 +0200

Comme certains le savent peut être, je suis fan de PaintBall et j'administre avec mon pote Radinus, la plus grosse communauté francophone de paintball scénarisé.

Avec une base de données MySQL qui grandie chaque jour (laisse tomber la manipulation de 200Mo sur un mutu' sans le shell) et les sites satellites qui vont arriver, il fallait se prendre un petit dédié.
Le choix s'est donc porté sur une Dedibox (pas pour rien qu'on l'appel Radinus) et pour le système d'exploitation, j'ai choisis CentOS 5.0, pourquoi ?

Les raisons sont multiples :

Professionnellement, j'administre du Debian, une CentOS me permet d'acquérir de nouvelles expériences et de prendre une bouffée de RPM dans un monde de deb.
C'est la famille (représente le chapeau !).
Autant je kiff Fedora pour du desk, autant son cycle de vie accéléré est moyen pour du serveur. Donc, dans la famille Red Hat, je demande le serveur au support gratuit : CentOS; bonne pioche.

Bref, pour le moment le strict minimum tourne dessus (apache/MySQL/Postfix) et je commence à transférer les petits sites satellites avant de passer au gros forum.

Script de migration de Xoops vers punBB

llaumgui — Sat, 09 Sep 2006 18:28:00 +0200

Suite à ma réflexion ainsi que l'avale des ambassadeurs francophones du projet Fedora, je viens de commencer le script de migration de Xoops vers punBB. Pour le moment, seul les groupes sont convertis (oui je sais, c'est le plus facile), mais cette migration ma permis de construire le script et sa logique.

Quel est la logique de ce script ?

Des requêtes SELECT alimentent un tableau de correspondance des données de Xoops vers celles de punBB. Ensuite, ce tableau est passé à la fonction buildInsert qui va construire la requête d'insertion.

function convGroupe () {

        

                //$this->emptyTable( "punbb_groups" );

                

                $query = $this->query( "SELECT * FROM xoops_groups ORDER BY groupid" );

                        

                while ( $groupe = $this->fetch_array($query) ) {

                        // Convertie les groupid                        

                        $groupe['groupid'] = $this->convertGroupeId($groupe['groupid']);

                        if ( $groupe['groupid'] > 4 ) {

                        

                                $tab =  array(  'g_id'                                                  => $groupe['groupid'],

                                                                                'g_title'                                               => $groupe['name'],

                                                                                'g_user_title'                                  => $groupe['name'],

                                                                                'g_read_board'                                  => 1,

                                                                                'g_post_replies'                                => 1,

                                                                                'g_post_topics'                         => 1,

                                                                                'g_post_polls'                                  => 1,

                                                                                'g_edit_posts'                                  => 1,

                                                                                'g_delete_posts'                                => 1,

                                                                                'g_delete_topics'                               => 1,

                                                                                'g_set_title'                                   => 0,

                                                                                'g_search_users'                                => 1,

                                                                                'g_edit_subjects_interval'      => 300,

                                                                                'g_post_flood'                                  => 60,

                                                                                'g_search_flood'                                => 30,

                                        );

                                $this->buidInsert( 'punbb_groups', $tab);

                        }

                }                                       

        }







        /**

         * Construction de requêtes d'insertion.

         * @author Guillaume Kulakowski <guillaume AT llaumgui DOT com>

         * @since 0.1

         * @TODO Code lourd à optimisé.

         * @param array $tab    Paramêtres.

         */

        function buidInsert( $table, $tab ) {

        

                $_key;

                $_value;



                foreach ( $tab as $key => $value ) {

                        $_key[] = $key;

                        $_value[]       = $value;

                }

        

                $SQL = "INSERT INTO ".$table." (" . implode(", ", $_key) . ") VALUES ('" . implode("', '", $_value) . "')";

                $this->query($SQL);

        }

Le layer de base est minimaliste car le script reste quand même dans un esprit one-shoot mais pourra être repris par toutes personnes voulant réaliser la même opération.

Pré requis du script, lorsqu'il sera fini :

php4 ou supérieur, par contre la base de données de Fedora-France étant assez conséquente, je compte lancer le script en ligne de commande. Il sera donc optimisé pour les gros forums/sites mais pourra ne pas marcher avec un simple appel via un navigateur.

Un roadmap ?

~~Non, le script sera prêt quand il sera prêt et sera sous licence GNU/GPL, vous pouvez déjà télécharger la version en cours de développement attachée à ce billet.~~ Version finale disponible attachée à ce billet

Réflexion sur Fedora-France, Xoops et l'hébergement.

llaumgui — Sat, 02 Sep 2006 19:00:00 +0200

Depuis plusieurs années, Fedora-Fr tourne sous Xoops, un CMS ultra complet mais qui nous enferme dans son univers. Depuis que j'ai pris en charge la partie technique du site, je n'ai pas eu le courage de changer et, je l'avoue, j'ai même freiné ce changement.

A présent je m'interroge...
De par mon travail, j'ai énormément progressé et je suis capable de réaliser une migration de CBB (forum de Xoops) vers punBB sans problème (en fait, j'en étais capable avant, mais comme je n'avais rien fais de tel, j'avais un peu la flemme ;)).
Et, récemment, la réflexion de Damien Durant sur la liste de diffusion des ambassadeurs francophone m'a réconforté dans mon idée qu'il faut envisager le changement.

L'hébergement :

Avant tout, le vrai problème de Fedora France demeure l'hébergement. De plus en plus une solution dédiée s'impose ! Elle permettrait de souffler et de mettre fin au erreur 500 et autre petit problème de l'hébergement communautaire. Mais surtout, elle permettrait au site de prendre son envol.

La question est quel hébergement pour Fedora-France ?

Apparemment le Projet Fedora est hébergé par Red Hat qui n'héberge que du statique ou du Python pour raisons de sécurité.
Avec le trafic actuel et de la publicité nous pourrions nous payer une Dedibox (solution dédiée de Free) sans trop de problème. Mais l'idée de la pub ne va-t-elle pas contre nos idées de liberté ?
La solution serait alors de se monter en association (c'est prévu), de démarcher des fournisseurs (Dedibox en premier) et de leurs faire profiter de notre image de libre en nous soutenant.

La structure de Fedora France et le choix d'un CMS

Damien propose de suivre le projet Fedora dans ses choix et de passer vers une solution Python, mais je pense que l'architecture php/MySQL offrirait beaucoup plus de souplesse, et en plus c'est ma spécialité.

Voici ma réflexion :

Forum : punBB (scripts CBB -> punBB par moi même).
Wiki : DokuWiki, intégré à punBB (étude de la faisabilité d'un script wiwimod -> DokuWiki qui soit correct).
Planet : DotClear 2 et son plugin planet visible ici.
Page d'accueil : Faites maison.

Je sais, certain dirons que cette structure ressemble pas mal à un autre site... Mais à problématique proche, solution proche.

Bref, le travail que j'aurais à faire pourrait être découpé en plusieurs étapes :

Migration de Fedora France.
Installation du planet.
Migration du forum.
Migration de la home page.
Migration du wiki.

Cette réflexion n'engage que moi et nullement Fedora-francce. Elle est juste là pour aider un éventuel webmaster/administrateur qui se retrouverait face à une solution historique et serait effrayé par l'obstacle d'une migration.

Monter une base MySQL en ligne de commande

llaumgui — Sat, 12 Nov 2005 17:51:00 +0000

Je travail actuellement sur un projet où la base de données MySQL est assez conséquente (85Mo). Il va de soit que phpMyAdmin est dépassé avec un tel poids et tournant sous Linux je ne peux utiliser MySQL-Front :-(.
Mais heureusement que la ligne de commande et un accès SSH permettent de monter 85Mo en moins de 5 minutes

mysql -u nom_utilisateur -pmot_de_passe -h localhot nom_base < fichier.sql

A noter que le -p et le mot de passe sont accolés.
En cas d'erreur(s) dans la base de données, l'option --force peut s'avérer utile.

MySQL 5.0 et la cohabitation de scripts php

llaumgui — Fri, 28 Oct 2005 19:27:00 +0000

Le bridge (appellations tout ce qui a de moins officielle) est un pont permettant à 2 scripts php de communiquer entre eux. Le meilleur exemple est, à mon sens, Coppermine qui est une galerie en php avec son propre espace membre mais qui sait utiliser une autre table membres que la sienne afin d'être parfaitement intégrée à une structure déjà existante.

Un exemple concret peut être donné via Scenario-PaintBall qui utilise IPB et Coppermine avec le bridge adéquate pour n'avoir qu'un seul compte membre pour les 2 scripts.

Auparavant, soit ce système de bridge été incorporé en natif, soit il fallait toucher au code d'un voir des 2 systèmes en places.
Par exemple, faire en sorte que l'inscription à IPB soit couplée avec celle de Coppermine (Modification des source d'IPB) et utiliser le système d'identification d'IPB sous Coppermine (Modification des source de Coppermine).
Bref le travail était fastidieux, mais les mise à jour était pires.

MySQL 5.0 introduit un point très intéressant, que les utilisateurs de solutions telles que SQL Server ou Oracle connaissent : Les triggers. En vulgarisant, ce sont des réactions à des actions bien spécifiques.
Un exemple pourrait être une requête d'insertion dans la table membre de Coppermine suite à une requête d'insertion dans celle d'IPB et vice versa... On a donc automatisé l'inscription aux 2 scripts sans modifier une seul ligne de code...

Malheureusement, et oui, il y a toujours un "mais", MySQL 5.0 n'est officiellement stable que depuis quelques jours et des incompatibilités apparaissent déjà avec certain scripts très utilisés (IPB pour ne citer que lui). A mon avis, et les copains de Celeo sont d'accord avec moi, une réelle utilisation en production de MySQL 5.0 ne se fera pas avant 1 an, mais on peut s'y préparer.

NB : Comme me le fais remarquer Dash sur IRC au moment de la rédaction de ce billet : cette vision est simpliste et ne pourrait bien entendu pas fonctionner avec n'importe quel script. Par exemple, le cryptage d'un champs via un algorithmes compliqué ne pourrait être exécuté via le serveur MySQL mais seulement récupéré à partir de la première requête... Les systèmes utilisant un cryptage de mots de passe différents pourraient donc poser problèmes.

Bien débuter le développement d'une application web niveau sécurité

llaumgui — Sun, 01 May 2005 23:02:00 +0000

Suite à une discutions sur les forums d'IPBR-Fr initiée par Darken, et à la critique émise lors de mon précédent billet : je me demande, comment bien partir dans le développement d'application web (Ou mod IPB) du point de vu sécurité ? En effet, la question de la sécurité doit être pensé lors du développement et non après coup.

I. Ne plus utiliser de fonction dévaluées :

php est un langage en perpétuelle évolution. Certaines vieilles fonctions sont toujours supportées dans les dernières versions mais sont fortements dévaluées... Pour des raisons de sécurité et de compatibilité dans les futures versions, éviter de telles fonctions se révèle une bonne chose.
Ainsi, par exemple, on préfèrera $_SESSION['TOTO'] à session_register().

II. register_global = Off :

L'un des point de sécurité les plus important celon moi.
Depuis php 4.2, register_global prend la valeur off et php.net préconise de le laisser comme ça. Malheureusement trop de script ne tourne pas en environnement register_global = off, ce qui fait que les serveurs professionnels tourne sous On. Cela n'est pas grave en soit si vous avez développé votre application en Off car elle sera sécurisée.

Imaginez que vous utilisiez une variable $login pour identifier un visiteur de votre site et que vous n'ayez pas travaillé dans un environnement registerglobal = On. Si $login n'est pas présent dans la session, php ira le chercher dans le cookie puis dans les supers variables POST et GET... Comment savoir d'où est affectée cette variable dans ce cas là ?

La réponse est simple, si vous devez chercher cette variable dans la session, faite $_SESSION['login'], dans un cookie : $_COOKIE['login'] et dans $_POST et $_GET pour les autres supers variables. Ainsi, vous saurez exactement d'où provient la valeur prise par une variable et pourrez la contrôler.

III. Typage de variable :

Le point fort de php est d'être facile à apprendre et entreprendre. De ce fait, il n'y a pas de typage des variables à proprement parler...
De cette facilité, née une faille de sécurité dont l'une des principales conséquences sont les injonctions SQL (Objet d'un prochain billet).
Forcer le typage des variables issues notamment de $_GET et surtout celle qui ne sont pas des chaînes de caractère se révèle donc indispensable.
Ainsi si notre variable $login représente un identifiant entier nous la récupèrerons ainsi :

$login_id = intval(@$_GET['login'])

La sécurité dans le domaine du web est devenue un point primordial de tout développement. Au risque de me répéter, cette question doit être abordée lors de l'analyse/conception de votre application.
Quel variables dois je récupérer à partir de super variables ? Comment dois je passer certaines informations de page en page ? Cookies ou sessions ? Sont autant de question non négligeable.