Jean-Luc Petit

MySQL : forcer la suppression

Cela peut arriver aux meilleurs et afin de ne pas trop choquer les esprits les plus sensibles et les plus orthodoxes je vais expédier cet article.

Si vous voulez supprimer une base de données sans grand ménagement pour les clés étrangères et autres joyeusetés, précédez votre requête honteuse par :

SET FOREIGN_KEY_CHECKS = 0;

Si vous vous sentez coupable après votre forfait (n’entrons pas dans les détails, un peu de pudeur voyons !), remettez la configuration en place comme il se doit :

SET FOREIGN_KEY_CHECKS = 1;

Enjoy!

Créer votre clé SSH et l’installer sur un serveur distant

Le but de cet article (aide-mémoire pour moi) est de vous montrer comment créer une clé SSH pour ensuite l’utiliser pour vous connecter à votre serveur distant.

Si ce n’est pas déjà fait, il faut tout d’abord vous installer un client SSH. Sur Debian et ses dérivés :

apt-get install openssh-client

Pour générer la clé nous allons utiliser l’algorithme RSA et une taille de clé de 2Ko (soit 2048 bits). Rappelons que les deux algorithmes les plus répandus pour SSH sont RSA et DSA.

ssh-keygen -t rsa -b 2048

À vous de voir si vous saisissez une passphrase ou pas mais du point de vue sécuritaire, c’est mieux. Deux fichiers ont été créés :

  • le fichier clé publique : ~/.ssh/id_rsa.pub,
  • le fichier clé privée : ~/.ssh/id_rsa.

Maintenant, il s’agit de copier la clé sur votre serveur :

ssh-copy-id -i ~/.ssh/id_rsa.pub utilisateur@domaineouip

La clé sera ajoutée au fichier .ssh/authorized_keys du dossier utilisateur du serveur distant. Vous pouvez à présent vous connecter avec cette clé sans rien ajouter à votre commande de connexion habituelle :

ssh utilisateur@domaineouip

Enjoy!

Git et certificat SSL non vérifié

S’il vous est arrivé d’avoir besoin de passer outre la vérification d’un certificat SSL pour travailler avec Git sachez que c’est assez simple. Il suffit de saisir la ligne suivante après vous être positionné dans votre dépôt :

git config http.sslVerify false

Vous pouvez également le rendre commun à tous les dépôts présents sur votre environnement :

git config --global http.sslVerify false

Pour le réactiver, il suffit de saisir :

git config http.sslVerify true

Vous pouvez revenir à l’état initial, c’est-à-dire que vous récupérerez la valeur par défaut de votre installation git:

git config --unset http.sslVerify

Enjoy!

Git : afficher les commits locaux

Pour afficher les modifications non "commitées" avec Git il suffit de lancer la commande suivante :

git status

On peut même spécifier un chemin de dossier et fichier comme argument à la suite de cette commande.

git status /chemin/dossier

Mais voilà, cela ne permet que de voir les différences non commités sur votre branche (locale soit dit en passant). Pour voir les commits non "pushés" nous allons utiliser git log comme ceci :

git log origin/master..HEAD

Ici, un différentiel sur les logs est affiché entre la branche master du dépôt distant (on peut spécifier une autre branche) et le dernier commit local.

Enjoy!

Twitter Bootstrap, assistant social des développeurs back

Cela fait quelques temps maintenant que j’ai sauté le pas en adoptant Twitter Bootstrap (dans sa version 3). C’est le moment de faire le point.

L’abstinence totale est plus facile que la parfaite modération.

Si une opération est faisable via un terminal, soyez sûr que je préférerais toujours ce point d’entrée à quelque interface que ce soit, aussi belle soit elle. Quoi de plus beau que le premier terminal que l’on ouvre le matin via un Ctrl + Alt + T ? Voilà que je deviens poète…
Un exemple : l’une des premières choses que j’ai appris sous Symfony2, c’est comment créer ses propres commandes afin de les exécuter dans un terminal.

L’enfer c’est les autres.

Mais voilà, il paraît qu’il existe des personnes que la ligne de commande rebute. Que Dieu nous préserve de ce type d’hérésie ! M’enfin, comme on vit dans le monde réel et qu’il faut bien créer des applications, notamment à destination interne de l’entreprise pour laquelle je travaille, il faut habiller les interfaces.

Mon binôme vous dirait qu’une page Web sans feuille de style ça marche très bien (il n’est pas aussi extrémiste que moi sur les interfaces graphiques malheureusement) mais je pense que ce n’est pas l’avis des utilisateurs lambdas qui eux veulent de jolis boutons, des menus déroulants et si en plus c’est responsive on risque d’atteindre l’extase !

C’est un roc !… C’est un pic !… C’est un cap !… Que dis-je, c’est un cap ?… C’est Bootstrap !

C’est là que Bootstrap entre en jeu, dans mon cas Bootstrap 3. C’est à l’occasion de la sortie de cette version, que j’ai sauté le pas. Et sincèrement je ne suis pas déçu. Il est vrai que je n’ai pas été assidu et que je ne saisis pas encore toutes les subtilités de ce Framework CSS et JS mais le peu que j’en sais me suffit amplement.

Et maintenant mes discussions autour de l’interface de mes applications peuvent ressembler à ceci :

  • Mon interlocuteur : Je veux du menu déroulant !
  • Moi : Tiens !
  • Mon interlocuteur : Les messages d’erreurs, d’avertissement, de confirmation ?
  • Moi : Trop facile !
  • Mon interlocuteur : Un slider, une grille pour la page d’accueil, un tableau bien agencé ?
  • Moi : S’il-te-plaît… Je suis le sensei du CSS avec Bootstrap ! Demandes moi des choses plus compliquées…
  • Mon interlocuteur : Enlever les coins arrondis des champs ?
  • Moi : Heu… Tu peux répéter s'il-te-plaît ?
  • Mon interlocuteur : Modifier la couleur de fond de la page ?
  • Moi : Hé ! Je suis développeur back, moi !

La fin justifie les moyens et tous les moyens sont bons.

Finalement aujourd’hui tout le monde est content : les utilisateurs ont des interfaces, moi je ne me prends pas la tête sur du front. Certains regretteront le manque de diversité dans l’apparence des applications que je développe. Mais moi vous savez, moins je vois de CSS mieux je me porte…

Git : récupérer des informations de votre répertoire de travail

Pour récupérer les informations de votre répertoire de travail, rien de plus simple avec la commande suivante

git config --local -l

Pour le résultat suivant :

core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
remote.origin.url=git@mon.serveur.com:user/projet.git
branch.develop.remote=origin
branch.develop.merge=refs/heads/develop

Si une seule des informations ci-dessus vous intéresse, par exemple l’URL du dépôt :

git config --get remote.origin.url

Enjoy !

Git : désactiver le suivi d’un fichier

En ce moment, je bosse avec Symfony2 et j’utilise un bundle de type sandbox en local. Du coup je veux garder le fichier app/appKernel.php dans les sources mais le figer de façon temporaire, c’est-à-dire exclure les modifications locales lors des commits. Le fichier .gitignore c’est cool mais cela exclut le fichier en question des sources du projet. Pour répondre à ma problématique, on met à jour l’index du projet :

git update-index --assume-unchanged /chemin/du/fichier

Et pour l’opération inverse :

git update-index --no-assume-unchanged /chemin/du/fichier

Enjoy !

La virtualisation en environnement de développement

Tous ceux qui ont travaillé avec moi savent que je suis un adepte des machines virtuelles en environnement de développement. Je fais du PHP quasi tous les jours et cependant sur mes machines physiques personnelles et professionnelles, cela doit faire près de 3 ans que je n’ai installé ni PHP ni même de serveur Apache. Je suis accro aux VM… Oui mais pourquoi ?

Simuler au plus près l’environnement final

En théorie tout se passe bien. Oui mais ça c’est la théorie. Combien de fois n’ai-je pas entendu : « ouais mais sur mon PC ça marchait bien » ! Là on se dit que notre interlocuteur connaît un peu son métier, on commence donc à chercher dans le code source et au bout d’un quart d’heure (dans le meilleur des cas) on se rend compte que le gars bosse sur du PHP 5.4 en local et que son serveur fonctionne en version 5.2.

Un autre exemple qui m’est arrivé récemment. J’avais besoin de créer des fichiers CSV avec des caractères non latins. L’environnement d’exécution du script final était en PHP 5.3.3. Or il se trouve qu’avec certains encodages (dans mon cas en_US.UTF-8), la fonction fputscsv() n’arrive pas à écrire les mots uniques (où il n’y a pas de caractère d’encadrement). Je n’ai constaté ce bug qu’avec des mots utilisant l’alphabet cyrillique et l’alphabet arabe.
DotDeb est venu à ma rescousse : j’ai upgradé la version de PHP (de souvenir 5.3.26) et cela a fonctionné. Outre Dotdeb, ce qui m’a permis de prévenir cette anomalie c’est d’avoir utilisé un environnement similaire à l’environnement d’exécution du script final.

Partez toujours du principe qu’il faut parer à toute éventualité et donc plus votre environnement sera identique à l’environnement final moins vous rencontrerez de surprises.

La multiplicité des projets

C’est encore plus vrai aujourd’hui du fait du nombre de projets qui passe sur mon PC. Une partie non négligeable de mon temps professionnel est consacré à faire de l’audit de code quant à son caractère multilingue. Il y a quelques mois, il m’est arrivé d’avoir à auditer les sources de 4 projets en moins d’un mois, projets qui se chevauchaient au gré des retours des différents interlocuteurs, sans compter les projets internes. Bref, sans organisation et délimitation des environnements on court à la catastrophe.

Qui dit différents projets dit différents besoins. Et tout ne peut être résolu par un fichier de configuration Apache ou autre. Au fil du temps, je me suis fait mon petit parc de machines virtuelles vierges de tout projet que je clone (car il faut générer un nouvel UUID) au besoin.

Gérer les ressources de la machine physique

Rappelez vous de ce projet foireux hyper lourd (souvent pour un résultat médiocre) où vous retrouviez de la redondance de code en veux-tu en voilà, des fichiers CSS et bibliothèques JS incluses 42 fois dans la même version, avec une conception en amont prévue dans le meilleur des cas en post-projet… Tout cela en plus a tendance à faire ralentir non seulement votre navigateur mais aussi toute votre machine physique, du fait que tout tourne sur des ressources partagées : serveur Apache, SAPI PHP, IDE, Navigateur, Photoshop (on m’a dit de la rajouter, pardonnez-moi mes pairs parce que j’ai péché un magicarpe). J’ai souvenir d’avoir bossé sur deux projets mémorables de ce type où certains développeurs saisissaient leurs lignes de code sur leur clavier pour les voir apparaître 5 à 10 secondes plus tard.

En cela, la virtualisation apporte une vraie solution car elle permet d’allouer à l’environnement d’exécution une partie limitée des ressources de la machine physique. Il est vrai qu’il faut tout de même avoir une configuration assez robuste pour se permettre d’allouer des ressources suffisantes à l’environnement virtuel.

Transférer/archiver un projet

Un autre avantage non négligeable de la virtualisation est de pouvoir transférer simplement son projet. Finis les phrases du style :

  • « Tu m’as envoyé les sources de l’application, par contre le dump de la base de donnée il est où ? »
  • « Et la valeur du memory_limit ? »
  • « Comment qu’on fait pour installer Tomcat ? Et Solr ? »

Bref, les machines virtuelles c’est un gain de temps pour transférer son projet d’un poste à un autre ou tout simplement pour l’archiver.

Pour terminer

C’est vrai qu’au début c’est un peu déroutant, il y a une phase d’apprentissage où il faut savoir répondre efficacement : comment accéder à mes fichiers (je préconise sshfs), les types de connexions réseau de la VM, etc… Mais au final, une fois qu’on a pris le coup de main, c’est easy les fois suivantes et c’est plus propre en terme d’organisation.

Debian : Vim comme éditeur par défaut.

Pour avoir Vim comme éditeur par défaut sous Debian (et dérivés je suppose), il suffit de lancer la commande suivante précédée de sudo si besoin.

update-alternatives --set editor /usr/bin/vim.basic

Enjoy!

Cacher la version de PHP et d’Apache des en-têtes

Pour savoir quelles sont les technologies utilisées par des sites Internet, j’utilise Wappalyzer. Très pratique en effet, pour voir d’un coup d’œil si un site est propulsé par Drupal, s’il utilise Apache, etc…

Wappalyzer vous affiche également la version de PHP, celle d’Apache. Ces informations sont situées dans l’en-tête de la réponse HTTP délivrée par votre serveur. En terme de sécurité, je ne trouve pas ça terrible. J’ai donc cherché à cacher ces informations et en fait ce n’est pas si compliqué.

Pour cacher la version de PHP, il suffit de passer la directive expose_php de votre fichier php.ini à Off.

expose_php = Off

Pour cacher la version d’Apache, il faut ajouter/modifier les lignes suivantes à votre fichier de configuration Apache :

ServerTokens ProductOnly
ServerSignature Off

N’oubliez pas de redémarrer Apache et de vous référez à la doc PHP et à celle d’Apache pour en apprendre plus.