Catégorie: "MySQL"

Hébergement PHP & MySQL: misère...

Le journal du net publie une sorte de comparatif sommaire des hébergeurs PHP/MySQL soit gratuits, soit low cost…

L’info a retenir, c’est que globalement tout le monde est à la traine. PHP est ultra stable en version 4.4 (ou au moins 4.3.10) et MySQL est utra stable en version 4.1 … et pourtant, quasiment aucun hébergeur ne propose ces versions à jour.

En gros, si vous voulez faire tourner une application critique qui nécessite une fiabilité élevée, il vous faut un serveur dédié… et encore, pas n’importe lequel, parce que sur les serveurs dédiés mid-cost – ceux qui sont fournis avec panneau d’administration – il est quasiment impossible d’upgrader PHP & MySQL sans tout casser…

Médiocrité, médiocrité… XX(

Crypter les fichiers sur un serveur XP

Attributs avancés

Crypter les fichiers sur le disque dur, ça a pour unique but que si on vous vole la machine on ne puisse pas lire vos données (mots de passe ou autre) en analysant le disque dur. Windows XP intègre un système pour celà: propriétés du fichier > attributs > avancé... > cochez la case "crypter". C'est gratuit et ça marche. Pensez-y avant de partir en vacances! :P (Pensez aussi à faire un backup! ;D)

Le problème c'est que ça ralentit aussi l'accès aux fichiers puisque Windows doit en permamence crypter/décrypter à la volée. Un peu le même problème qu'avec les antivirus qui scannent tout en permanence...

Alors pourquoi faire ça sur un serveur plutôt que de mettre le serveur sous clef... et pui surtout déjà: pourquoi avoir un serveur sous Windows XP!? :!::?:

C'est simple: ici (au bureau) on a des serveurs web (Apache/PHP/MySQL) sur les machines de développement, et on s'en sert pour tester les modifications en temps réel. Mais évidemment, ces machines de développement sont plus exposées au vol que les serveurs. (Et je vous parle pas des portables...)

Et on ne voudrait pas donner nos codes sources à n'importe qui, n'est-ce pas? :roll:

A partir de là, crypter les bases de données et les fichiers PHP pose deux problèmes...

Tout d'abord, une fois les fichiers cryptés, les services Apache et MySQL ne peuvent plus y accéder! Solution: changer la configuration des services en question pour les faire tourner sous le nom de l'utilisateur qui à crypté les fichiers. Moi, ou vous, en l'occurrence! :P [ Service > Propriétés > Connexion ].

Ensuite, il y a un problème de performances assez ahurissant. Crypter le fichier InnoDB de MySQL semble avoir un impact limité. En revanche, crypter l'ensemble des fichiers PHP peut (par le jeu des include) multiplier le temps de génération des pages web par 6 ! :(

La seule solution que j'ai trouvée à ce problème pour l'instant, c'est de ne crypter que des fichiers choisis. Les fichiers de config en particulier (ceux qui contiennent des mots de passe en premier lieu) ainsi que d'autres fichiers stratégiquement choisis pour qu'on ne puisse pas faire grand chose sans eux.

Une solution qui serait peut être plus intéressante serait d'avoir un script qui crypte l'ensemble des codes sources le soir en partant et les redécrypte le matin en arrivant... en partant du principe que les PCs ont moins de risques de vol aux heures de bureau qu'en dehors. Je me demande s'il existe des solutions élégantes pour ça... :?:

Pour finir, une petite astuce pour avoir l'option Crypter/Décrypter directement dans le menu contextuel du fichier: avec RegEdit, il faut aller dans HKEY_LOCAL_MACHINE\ SOFTWARE\ Microsoft\ Windows\ CurrentVersion \Explorer\ Advanced puis créer une Valeur DWORD nommée EncryptionContextMenu et lui assigner la valeur 1.

Quelques ressources supplémentaires:

PowerDesigner/AMC est en train de me pourrir mon aprem :(

J'utilise le module Physical Architect ("Développeur SQL" en VF) pour générer une base MySQL 4.0. Je mets plein de références dans tous les sens et ensuite je génère le script de création de la base. PowerDesigner fait ça très bien, il crée bien toutes les contraintes de clef étrangère etc.

Mais, car il y a un mais: il semble vérifier poru chaque clef étrangère, si le champ référençant fait partie d'un index. Si c'est le cas, tout va bien. Si ce n'est pas le cas... PowerDesigner insiste pour créer un index sur ce champ alors que je ne lui ai rien demandé à ce bougre!!!

Et le pire de tout, c'est qu'il le crée avec un erreur de syntaxe! (CREATE index_name au lieu de CREATE index_name ON table_name). Résultat, mon script de création est pourri de création d'index aussi gênantes qu'inutiles.

Si vous avez compris ce que je viens de dire, vous êtes très fort. Si en plus, vous savez comment reconfigurer la défition mySQL de PowerDesigner pour qu'il arrête de déconner, alors vous êtes un Dieu!

Bon, voilà, j'ai râlé un ptit coup, je peux retourner me prendre la tête :P

Isolation Levels in mySQL

Comparison with other DBMS' (via Bruno Vernay)