PROJET AUTOBLOG


Le blog de Seboss666

Site original : Le blog de Seboss666

⇐ retour index

Un mois de Juin calme côté blog, moins calme IRL

mercredi 5 juillet 2017 à 18:30

Nouveau mois, nouveau résumé rapide du mois précédent. Peu riche en écriture, en tout cas d’écriture terminée, peu riche en manipulations techniques personnelles, et du coup, peu riche en visiteurs. Le fait est que j’ai passé peu de temps hors du travail derrière un ordinateur alors…

Une chute drastique de visiteurs

Eh oui, la lente fuite de visiteurs continue. En tout cas celle enregistrée par Piwik. J’ai remarqué que de nouveaux filtres étaient parus dans  le filtre EasyPrivacy pour bloquer l’URL de l’image de Piwik (qui est au final un script PHP). L’insistance à vouloir bloquer un outil de statistiques qui de toute façon respecte le Do Not Track est pour moi une aberration, mais bon. Le script JS semble épargné, donc il va falloir trouver une astuce pour l’image. Et non, je n’ai pas encore trouvé l’outil qui me permettra de faire proprement une analyse comparée des logs bruts d’Nginx.

D’ailleurs si vous avez des conseils pour que je fasse une analyse sur mettons les six derniers mois, je suis preneur. Si possible quelque chose d’agréable à l’œil, j’ai un souvenir violent d’awstats.

Concernant les parutions, c’est un poil moins chaotique, mais ça reste compliqué. Le titre du billet résume bien, j’ai pas passé beaucoup de temps devant un clavier (virtuel ou physique), compliqué d’avancer les brouillons. Je viens d’ailleurs d’en dégraisser trois/quatre qui au final ne me plaisent pas et pour lesquels je n’ai pas la motivation de recommencer ou retoucher.

Technique : Y’a quoi de pire que RAS ?

Je ne me suis pas occupé du disque, et rien n’a évolué côté code ou fonctions du blog. Et pour couronner le tout, pour l’instant j’ai pas de planning. Donc je plaisante pas en disant qu’il n’y a rien à signaler. J’ai même été tellement lent à réagir que j’ai raté les soldes Online qui proposaient un petit serveur Avoton avec du SSD pour à peine 7 balles par mois au lieu de 20, histoire de bricoler des trucs à part (ne serait-ce que pour faire un vrai comparatif des performances du CPU avec d’autres solutions). De toute façon la première étape de mes services déportés sera du stockage « gros » pour les backups que je dois remettre en place en local (et pour lesquels je n’ai toujours pas de NAS, les soldes pourraient aider).

Pour en revenir au disque, comme il y a dans l’idée de faire le ménage sur l’héritage ISPconfig, et que Debian 9 est maintenant de sortie, il est possible que je fasse l’impasse et qu’on bascule directement sur une VM flambant neuve.

Un brouillard qui devient « Brume »

Je ne sais pas si tout le monde saisira la référence (vous pourrez en cultiver certains avec les commentaires), mais c’est clair que ça ne s’éclaircit pas pour l’instant. Non pas que je n’ai rien à proposer, mais que je ne sais absolument pas dans quel ordre ça sortira, ni parfois sous quelle forme. A la fatigue des soirs de semaine s’ajoute des weekends chargés loin du clavier, que ce soit pour pratiquer/expérimenter ou partager mes expériences ou mes pensées.

Une seule chose est sûre : ne lâchez pas le flux RSS (ou le compte Twitter, ou autre), parce qu’il n’est pas question d’arrêter.

Debian 9 Stretch : ce que j’en retiens

dimanche 2 juillet 2017 à 10:30

Ça y est, la nouvelle version de Debian est sortie. Bien que les modifications visibles soient plus légères que lors de la bascule de 7 à 8, il est quand même nécessaire de faire le tour, surtout pour ceux qui vont s’aventurer dessus pour la première fois et passer leur temps à chercher des infos sur le net qui pourraient ne plus être correctes.

Tout d’abord, Debian 8 Jessie nous a apporté systemd, et nous avons droit à la dernière mouture stable dans cette version Stretch (enfin presque, la version 233 est trop récente pour avoir été incluse). Le gestionnaire d’init/de services/whatever Lennart wants tant décrié par la Devuan (qui a mis deux ans à sortir une Jessie sans systemd, alors que Stretch sort maintenant), propose masses d’améliorations qu’il serait trop long de lister ici. Pour l’utiliser sur CentOS au quotidien depuis plus d’un an maintenant, sans parler de Manjaro, c’est un outil aux possibilités multiples sur lesquelles il faut s’attarder. Vraiment.

Avec systemd vient inévitablement udev, qui sont liés depuis quelques années maintenant. udev peut être vu comme un gestionnaire de périphériques, dans le sens qu’il définit un nom et un point d’entrée pour toute une série de périphériques (webcam, cartes sons, disques durs, cartes réseaux…). La plus grosse nouveauté qui risque de déstabiliser les longs habitués de Linux, et ceux qui bricolent beaucoup de scripts réseaux, concerne le nommage des cartes réseaux. L’équipe de Debian a décidé de profiter d’une des fonctionnalités qui permet de s’assurer qu’une carte réseau dispose du même nom quelque soit les circonstances : Predictable Network Device Names. Cela permet de ne plus se poser la question de savoir si d’aventure le noyau décide de détecter les cartes dans un ordre différent et donc de changer leur nom. Comme je l’ai dit ça peut être un inconvénient si vous disposez de scripts utilisant le nom de l’interface comme base de travail, il faudra faire des adaptations.

Le support UEFI s’améliore, et permet l’installation de la version 64bit avec des UEFI 32bit, une chimère qui est arrivée sur plusieurs appareils comme certains netbooks, qui ont grandement besoin d’un OS qui ne les étouffe pas comme Windows sait très bien le faire — rassurez-vous, un mauvais choix de distribution Linux aussi, notez bien. Toujours pas de Secure Boot évidemment, la faute aux constructeurs qui ne veulent toujours pas jouer le jeu et continuent de se réfugier derrière Microsoft. M’enfin on peut pas non plus tout avoir.

Un peu plus haut dans les couches logicielles, Apache est maintenant dans une version qui permet d’activer le support d’HTTP2. Comme dirait l’autre, y’a plus qu’à, bien qu’il y aurait certainement des choses à dire sur l’utilité d’un tel support si derrière vous utilisez un système intermédiaire comme Varnish, ou un intermédiaire (CDN, WAF) qui ne supporte pas ce protocole. Dans le même domaine ou presque, PHP 7.0 est maintenant de service ce qui élimine le besoin de recours à Dotdeb au moins pour ça, MariaDB remplace définitivement MySQL, et est donc implémenté en version 10.1. PostgreSQL est pour sa part en 9.6 (avec améliorations de performances, de la recherche full-text, de fiabilité sur la réplication), et si des langages évolués vous intéressent Python est livré dans sa saveur 3.5.3, Ruby en 2.3. OpenSSL 1.1 désactive d’emblée pas mal de vieux ciphers et protocoles faillibles, ce qui n’est pas du luxe il faut le reconnaître.

Changeons de domaine pour passer à celui dont Cyrille et Frédéric pensent qu’il va mourir dans quelques années : le desktop, ou bureau en français. Firefox et Thunderbird font leur retour officiel (ils étaient toujours là, mais avec un nom différent), après que Mozilla aie cédé à propos de la protection de la marque. Les versions ESR sont privilégiées pour des raisons évidentes de stabilité, bien qu’ils aient un peu de retard de ce côté-là (les ESR seront mises à jour, mais le freeze a mécaniquement retardé le travail). LibreOffice pour sa part en « Still » 5.2, ce qui garantit, en tout cas pour cette année, un bon niveau de support de différents formats. Une autre absence notable est celle de VirtualBox. Oracle à décidé qu’il ne fournirait plus les patches de manière indépendante ce qui rend impossible le maintien d’une version figée incluant les corrections, et a donc contraint l’équipe Debian à ne plus le proposer.

Les principaux bureaux sont dans une version pas mal récente, Gnome 3.22, MATE 1.16, les composants « KDE5 » ne sont pas trop anciens, dans l’ensemble c’est du frais et ça fera plaisir aux amateurs. Au moins pour cette année.

Pourquoi je mentionne souvent « cette année » ? Si côté serveur on s’en contentera et qu’on connaît la musique (et que Dotdeb permet de s’armer côté serveur sur la durée),  côté « graphique », on a affaire au sempiternel problème d’un freeze prolongé et donc à l’inévitable obsolescence, ou en tout cas un manque flagrant de certaines fonctions pratiques qui seront disponibles chez les Rolling ou les fixed en cycle court bien plus tôt. Ça concerne aussi bien les fonctionnalités que le support matériel. Je pourrais très bien installer Debian sur mon laptop et je n’aurai pas de problème de reconnaissance. Mais avec une machine plus récente la situation serait certainement différente, comme je l’ai moi-même expérimenté avec le laptop LDLC qui a du attendre un an et quelques mises à jour du noyau pour ne plus déconner sur certains points (consommation, gestion de la mise en veille…).

C’est donc une distribution tout à fait viable selon moi, pour les appareils un peu ancien (plus de deux ans), et pour les personnes qui ne courent pas après les dernières fonctionnalités à la mode. Du style de celles que ça ne dérange pas d’avoir 15 versions de retard d’Android sur leur téléphone, sans espoir que le constructeur propose les mises à jour. Même si dans le cas de Debian, si les mises à jour sont suivies la sécurité sera au rendez-vous.

Côté serveur c’est différent, on est souvent sur une optique de niveau technique de l’utilisateur permettant le cas échéant de contourner ce problème de versions. La compilation manuelle ou l’ajout de dépôt tiers (voire même la gestion de son propre dépôt additionnel) n’est souvent pas un problème pour un administrateur système averti. Ça l’est plus pour les pseudo devops qui ne savent pas toucher une ligne de Bash ou déployer un serveur sans un outil tiers comme Ansible ou plus récemment Terraform.

Bref, ça semble être un très bon cru, avec les mêmes faiblesses qui sont au final liées à la philosophie de Debian (la totalité des logiciels sur une dizaine d’architecture matérielles, notamment celles dont ne se préoccupent pas les développeurs upstream, ça coince forcément), mais des  faiblesses historiques pour lesquelles des solutions existent. J’attends encore un poil (après l’été) et je pense que je vais mettre les mains dedans sérieusement. Après l’été probablement, il semblerait qu’il y aie pas mal de problèmes de finition à dégrossir.

Une unit systemd pour le Solr embarqué dans EzPublish

vendredi 30 juin 2017 à 18:30

EzPublish est un CMS open-source basé sur Symfony, qui traîne ses guêtres depuis quelques années déjà. Via son extension ezfind, il embarque un moteur Solr pour servir de moteur de recherche externe (plus rapide que la base de données). Si des scripts de démarrage sont proposés pour différents OS, il ne sont pas exploitables sur CentOS 7, et il a fallu pondre une solution alternative. Je me suis reposé sur systemd. L’occasion de voir une de ses forces.

Le client veut utiliser Solr : soit. Malgré le fait que c’est du Java, si l’on sait où on va c’est un outil puissant et performant pour les recherches et l’indexation sur le site. En plus il est déjà fourni avec EzPublish, pourquoi se priver ? Sauf que l’extension commence à dater et les options pour le démarrer ne sont pas super pratiques. En l’occurrence voilà le script qu’utilise le client (enfin, plus précisément l’agence web) :

#!/bin/bash

for JAVA in "$JAVA_HOME/bin/java" "/usr/bin/java" "/usr/local/bin/java"
do
if [ -x $JAVA ]
then
break
fi
done

if [ ! -x $JAVA ]
then
echo "Unable to locate java. Please set JAVA_HOME environment variable."
exit
fi

# start solr
exec $JAVA -jar start.jar

Ça va à l’essentiel, pour le lancer en arrière plan il fallait jouer avec du nohup et de l’esperluette, et c’est pas pratique pour en faire un script de démarrage/extinction automatique. Il se trouve cependant qu’il y a un script dans un sous-dossier d’ezfind pour le démarrage, dédié à RedHat et dérivés (donc CentOS), et il a cette tronche :

#!/bin/bash
#
# eZ Find init script for RHEL and CENTOS.
#
# Usage:
#
# Set the correct SOLR_HOME value, and copy this file to /etc/init.d, then
# - either run chkconfig --add solr, or
# - symlink to /etc/init.d/solr to /etc/rc3.<n>/S70solr and /etc/rc5.<n>/k70solr
#
# Example:
# cp solr /etc/init.d/solr
# cd /etc/init.d && chmod 755 solr
# cd /etc/rc3.d && ln -s ../init.d/solr S70solr
# cd /etc/rc5.d && ln -s ../init.d/solr S70solr
# cd /etc/rc3.d && ln -s ../init.d/solr K70solr
# cd /etc/rc5.d && ln -s ../init.d/solr K70solr
#
#
# chkconfig: 2345 64 36
# description: SOLR indexing server
# processname: solr
# pidfile: /var/run/solr.pid

DESC="Solr indexing server"
NAME=solr
SOLR_HOME= # Set solr home here (example: /var/www/ezpublish/extension/ezfind/java)
JAVA_HOME= # Set java home here if java is not available in /usr/bin/java or /usr/local/bin/java

source /etc/rc.d/init.d/functions

for JAVA in "$JAVA_HOME/bin/java" "/usr/bin/java" "/usr/local/bin/java"
do
if [ -x "$JAVA" ]
then
break
fi
done
if [ ! -x "$JAVA" ]
then
echo "Unable to locate java. Please set JAVA_HOME environment variable."
exit
fi

RETVAL=0

d_start() {
CURRENT_DIR=`pwd`
cd "$SOLR_HOME"
daemon --check "$NAME" --pidfile "/var/run/$NAME.pid" nohup $JAVA -jar start.jar > /dev/null 2>&1 &
cd "$CURRENT_DIR"
sleep 1 # Sleep 1 second, to make sure java is registered.

# Using pidof is not good, as there might be other java processes as well.
# Replaced this by calling ps. Still, this is somewhat awkward.
# 2014-10-10 alex.schuster@ez.no
#pid=`pidof java`
pid=`ps ax | grep '[/]usr/bin/java -jar start.jar' | grep -v nohup | awk '{ print $1 }'`
if [ -z $pid ]
then
echo "Error starting $NAME!"
return 1
fi
echo $pid > "/var/run/$NAME.pid"
touch "/var/lock/subsys/$NAME"
return 0
}

d_stop() {
killproc -p /var/run/solr.pid "$NAME" >> /dev/null 2>&1
RETVAL=$?
[ $RETVAL -eq 0 ] && rm -f "/var/lock/subsys/$NAME"
return $RETVAL
}

d_restart() {
d_stop  > /dev/null 2>&1
sleep 1
d_start > /dev/null 2>&1
}

d_reload() {
killproc -p /var/run/solr.pid "$NAME" -HUP > /dev/null 2>&1
RETVAL=$?
return $RETVAL
}

d_status() {
status -p /var/run/solr.pid "$NAME" > /dev/null 2>&1
return $?
}

case "$1" in
start)
echo " * Starting $DESC ($NAME)"
d_status
if [ $? -eq 0 ]
then
echo "   ...already running."
else
if d_start
then
echo "   ...done."
else
echo "   ...failed."
RETVAL=1
fi
fi
;;
stop)
echo " * Stopping $DESC ($NAME)"
if d_stop
then
echo "   ...done."
else
echo "   ...failed."
RETVAL=1
fi
;;
restart)
echo " * Restarting $DESC ($NAME)"
d_status
if [ $? -ne 0 ]
then
echo "   ...not running."
RETVAL=1
else
if d_restart
then
echo " * ...done."
else
echo " * ...failed."
RETVAL=1
fi
fi
;;
reload)
echo " * Reloading $DESC ($NAME): "
d_reload
echo "   ...done."
;;
status)
d_status
if [ $? -eq 0 ]
then
echo " * $DESC ($NAME) is running"
else
echo " * $DESC ($NAME) is not running"
fi
;;
*)
echo $"Usage: $0 {start|stop|restart|reload|status}"
RETVAL=1
esac

exit $RETVAL

Là au moins on a la structure d’un script de démarrage qui a de la gueule. J’ai tenté de l’exécuter, systemd a pris le relai, et a échoué. Après coup, et en analysant le fichier, ça ne risquait pas de fonctionner, et ce n’est pas la faute de systemd : la commande daemon présente dans le script n’existe plus sur CentOS 7. Après quelques tergiversations, des recherches Google, et un ou deux fails dont j’ai le secret, j’ai fini par pondre une unit systemd que je me permet de partager avec vous :

unit final

[Unit]
Description=Apache SOLR
After=syslog.target network.target remote-fs.target nss-lookup.target
[Service]
PIDFile=/var/run/solr.pid
WorkingDirectory=/home/sites_web/client/www/solr
ExecStart=/usr/bin/java -jar start.jar
User=www-data
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s QUIT $MAINPID
PrivateTmp=true
[Install]
WantedBy=multi-user.target

Attardons-nous sur les directives :

Si on compare la taille de ce fichier avec le script d’init « à l’ancienne », on comprend l’une des forces de systemd. La ligne de lancement est également réduite à l’essentiel, à comparer avec les bricolages à base de nohup et d’esperluette pour obtenir un processus qui ressemble à un service. Le nombre de lignes est beaucoup, beaucoup plus petit et c’est une bonne chose pour la lisibilité. systemd s’occupe tout seul de la journalisation, de la construction des dépendances, tout ce que vous avez à faire est de définir s’il doit démarrer ou pas avec le reste des services.

En tout cas, vous pourrez tenter de réutiliser ce script pour construire vos propres services. Pour ma part j’ai dans l’idée de reprendre de zéro le développement de l’API pour la refonte de ma base de données de films, toujours en Python, avec Flask, Bottle n’ayant pas bougé d’un pouce depuis quelques années. Je pense qu’il sera mis à contribution pour gérer son lancement.

Ma première Nuit du Hack, c’était cool

mercredi 28 juin 2017 à 18:30

Je vous présente le tableau : une journée de conférences autour de la sécurité, des stands de présentation de sociétés, certains qui sont là pour recruter des talents, des sponsors reconnus, et le soir, des ateliers, et le « wargame », à savoir une séries de challenge sur différents sujets; saupoudrez la journée d’un CTF privé et de différents bug bounty. L’occasion parfaite pour faire quelques rencontres, apprendre à quel point on est mauvais, mais quand même apprendre deux/trois trucs. Je vous raconte un peu.

J’ai beau avoir parlé de sécurité, au point d’avoir fait une série de billets sur le sujet dans le cadre d’un serveur, je suis loin d’être un cador dans le domaine, mais c’est un domaine qui m’a toujours intéressé. La philosophie « hacker » me plaît, elle est souvent teintée d’autodidaxie et vous savez maintenant ce que j’en pense. J’adore le fait d’emmerder ceux qui imposent un usage ou une obsolescence sur le matériel ou le logiciel, le fait de les contourner pour continuer à s’en servir. Il s’agit également de sensibiliser sur le fait de penser intelligemment la sécurité des produits et services connectés dès le départ, ce qui arrive trop peu souvent.

Et pour être honnête, mon mauvais niveau ne me destinait pas spécialement à me rendre à un tel évènement et me plonger complètement dans le bain. Mais je suis un faible, après les multiples appels du pied de Djerfy, je me suis rendu avec lui à l’évènement (c’est aussi lui entre autres qui m’a attiré vers Telegram). Le programme des conférences me semblait un poil limite pour moi, et que dire des challenges.

Reprenons dans l’ordre : la Nuit du Hack est un rassemblement annuel d’experts en sécurité, techniciens passionnés ou amateurs avertis, pour échanger sur différents sujets : futur de la sécurité, évolutions des méthodes d’attaque, état d’un marché (pour info, la sécurité des objets connectés est définitivement une catastrophe), partage d’expériences ou réflexions de société. Car dans un monde particulièrement connecté, ces problèmes de sécurité finiront inévitablement par influencer notre pensée et donc le fonctionnement de la société dans son ensemble (on voit déjà l’influence des réseaux sociaux sur nos rapports à l’autre). Ce n’est pas une spécificité française, les allemands ont le Chaos Communication Congress et les américains ont la Defcon. Et fait notable, non seulement certaines sociétés étaient présentes, mais également l’armée française (qui annonçait recruter des cyber-combattants, rien que ça), ainsi que l’ANSSI. Preuve que dans un domaine où l’on flirte souvent à la limite de la légalité, certaines instances sont conscientes des enjeux à soutenir cette communauté.

Bref, en résumé, et après avoir mangé mes premières conférences, on est définitivement pas dans la vulgarisation. Certaines présentations étaient d’un niveau très élevé, je n’ai pas pu tout suivre, et de toute manière tout ne m’intéressait pas non plus. Petit bémol, comme il y avait également des stands dans la grande salle de conférence, les présentations subissaient un bruit de fond conséquent qui n’aide pas toujours à la concentration, en particulier quand l’orateur est anglophone.

Il y avait aussi un coin kids, pour les enfants donc, difficile d’en dire plus, en voulant m’intéresser à ce qu’ils proposaient aux gamins on m’a gentiment refusé l’accès, à croire que j’ai une tête de pédophile. Je vous laisse lire la description sur le site.

Si certaines sociétés ont pu proposer des défis durant la journée (Intrinsec avec ses 7 challenges, Qwant, gros sponsor, qui finançait un bug bounty), c’est vraiment à partir de 20h que les choses sérieuses ont débuté. Ateliers et wargame se sont déroulés toute la nuit, et vraiment toute la nuit : nous somme partis un peu avant 7h du matin le dimanche, et ce n’était pas encore fini.

Parmi les ateliers, celui de lock picking (crochetage de serrure) à tenu la plus grande place physiquement parlant. J’en ai profité pour acheter un kit d’initiation, avec finalement plus d’outils que prévu (petite bourde du vendeur en ma faveur). Que fait le lock picking dans un évènement majoritairement dédié à la sécurité informatique ? Le même principe : montrer qu’il n’y a aucune serrure infaillible, et que beaucoup d’éléments de sécurité n’en sont au final pas vraiment. Après avoir dormi, dimanche après-midi un cadenas que je gardais spécialement pour l’occasion, qui est fabriqué par la boîte où je bossais avant LinkByNet et mon changement de vie, a tenu 20 minutes au premier essai sans même lire le bouquin.

Et puis, le wargame. Débuté en retard à cause de problèmes d’alimentation, il s’agit d’une série de challenges, opérés sur un réseau privé, ayant pour sujet différents aspects : cryptographie, steganographie, web… Toutes les épreuves étaient classées par niveau, et certaines ont été ajoutées au fur et à mesure. En fonction de la difficulté des scores sont attribués. Avec un petit 200 points pour 3 challenges validés, nous avons fini en milieu de classement sur un peu plus de 500 inscrits, les plus balaises étant des équipes plus entraînées et plus nombreuses (ce qui permet d’additionner les expertises). Je ne vais pas m’attarder plus, certains ont pu décrire les challenges mieux que moi. Je vous mets quelques liens pour référence :

Un gros MERCI à tous ceux qui partagent les solutions qu’ils ont trouvées pour résoudre ces défis 🙂

 Au final, j’en pense quoi ? J’ai adoré, même si je suis rentré salement crevé et que j’ai mis deux jours à récupérer. Ce fut l’occasion de rencontrer quelques personnes, et même d’être interviewé par Jérôme Keinborg pour la chaîne YouTube NowTech (qui va probablement être ma première contribution Tipeee). Je sais pas encore si je vais survivre au montage final, mais bon, c’était cool de le rencontrer 🙂 Bref, si le calendrier le permet, il est certain que j’y retournerai. En espérant avoir trouvé le temps de m’entraîner un peu, histoire d’être moins démuni. Pour ceux que ça intéresserait, il y a le site Root-Me, sur lequel je pense que je vais m’inscrire histoire de me pousser au cul. C’est une bonne entrée en matière.

PS : l’équipe du podcast NoLimitSecu était présente et a enregistré un épisode qui décrit bien l’ambiance et la qualité des conférences. Je vous laisse chercher les noms des intervenants pour comprendre qui ils sont, c’est du cador. Je vous met aussi un lien vers Twitter, certaines personnes ont partagé des photos qui vous permettront de découvrir un peu plus cet évènement.

Follow-up du 14/07 : D’autres participants commencent à partager leur propre expérience de cette édition de l’évènement. C’est le cas de benzo, par exemple. Et c’est plus détaillé que moi en fait.

 

Explication du php slowlog

vendredi 23 juin 2017 à 18:30

J’ai déjà abordé certaines méthodes de furieux pour analyser des problèmes avec PHP, notamment personnels avec ce blog suite à mon passage sur PHP 7. Un autre cas qu’on évoque rarement, c’est quand l’exécution est simplement trop lente. MySQL et MariaDB ont leur « slowlog » (journal lent, haha), PHP et surtout FPM propose également ce mécanisme pour nous permettre de mieux cerner le problème. Petite explication.

Je n’ai pas souvent l’occasion d’y jeter un œil, mais c’est une donnée pratique pour identifier un problème. Ce journal est en fait généré par FPM lorsqu’un appel à un script prend plus de temps, le seuil étant géré par un paramètre de configuration au niveau du pool. On récupère alors une « stacktrace », c’est à dire le cheminement de fonctions qui ont amené le script où il en est.

Le journal s’active dans le fichier de configuration de votre pool. Par exemple, pour le mien, sous Debian 8 donc avec les paquets PHP7 de Dotdeb  (/etc/php/7.0/fpm/pool.d/web1-blog.seboss666.info.conf) :

slowlog = /var/www/blog.seboss666.info/log/php_slow.log
request_slowlog_timeout = 60s

Dans l’exemple, j’ai pris une valeur de 60 secondes, mais vous pouvez choisir de bourrer une valeur plus faible, un client m’a sorti une valeur de 2 secondes, c’est à déterminer en fonction de la quantité d’information et du niveau de performances que vous cherchez à atteindre. Vous serez peut-être même amené à modifier plusieurs fois cette valeur pendant une investigation.

Le résultat aura la forme suivante :

[04-Jun-2017 12:31:05]  [pool web1] pid 25539
script_filename = /var/www/blog.seboss666.info/web/wp-cron.php
[0x00007f3461613c90] curl_exec() /var/www/clients/client0/web1/web/wp-includes/Requests/Transport/cURL.php:162
[0x00007f3461613bc0] request() /var/www/clients/client0/web1/web/wp-includes/class-requests.php:379
[0x00007f3461613ab0] request() /var/www/clients/client0/web1/web/wp-includes/class-http.php:371
[0x00007f3461613910] request() /var/www/clients/client0/web1/web/wp-includes/class-http.php:630
[0x00007f3461613850] head() /var/www/clients/client0/web1/web/wp-includes/http.php:112
[0x00007f34616137a0] wp_safe_remote_head() /var/www/clients/client0/web1/web/wp-includes/functions.php:643
[0x00007f34616136f0] wp_get_http_headers() /var/www/clients/client0/web1/web/wp-includes/functions.php:602
[0x00007f3461613510] do_enclose() /var/www/clients/client0/web1/web/wp-includes/comment.php:2450
[0x00007f34616133f0] do_all_pings() /var/www/clients/client0/web1/web/wp-includes/class-wp-hook.php:298
[0x00007f3461613300] apply_filters() /var/www/clients/client0/web1/web/wp-includes/class-wp-hook.php:323
[0x00007f3461613280] do_action() /var/www/clients/client0/web1/web/wp-includes/plugin.php:515
[0x00007f34616131a0] do_action_ref_array() /var/www/clients/client0/web1/web/wp-cron.php:117

La première ligne indique évidemment le script en cause dans l’enregistrement de la trace. La suite de la stack se lit à l’envers : de bas en haut, on décrit la série des fonctions qui ont abouti à la lenteur, la dernière (et donc la première affichée), étant généralement la fautive. En l’occurrence, ici c’est un curl_exec() qui semble être problématique. A tel point que le pool FPM est finalement tellement occupé qu’il ne pouvait plus traiter de nouvelles demandes. Et on indique la ligne à laquelle le curl_exec() en question est appelé, ce qui permet éventuellement d’identifier la destination dudit curl, et donc d’analyser plus finement pourquoi il échoue ou est trop lent (webservice surchargé, ou qui limite à un certain nombre de connexions/requêtes dans le temps). Ça peut également pointer un problème de paramétrage de la fonction, je pense notamment à un timeout qui manquerait ou qui serait trop long, laissant empiler les appels qui attendent une réponse qui n’arrive jamais; je pourrais vous raconter l’histoire d’un client qui avait ce problème à cause d’une Google Mini vieillissante et parfois plantogène. Pour les plus courageux, histoire de pas morceler l’article, je vous raconte l’histoire de cette machine à la fin de l’article.

Les sources de ralentissement peuvent être variées, les plus courantes étant probablement le cas évoqué plus haut ou une lenteur au niveau de la base de données. Très récemment, un client qui passe bientôt en production a vu son test de montée en charge décevant, le slowlog m’a permis de déterminer un goulet d’étranglement sur une génération de PDF (un appel externe à wkhtmltopdf pour être exact). J’apprends qu’au final, la page s’appelle elle-même pour envoyer son rendu à wkhtmltopdf (ce qui finalement prend plusieurs secondes). Avec 80 utilisateurs simultanés, même sur 6 vCPU, les performances s’écroulent, sans il peut encaisser 500 utilisateurs. Il est donc prévu que le client revoit son workflow pour réduire ce goulet.

Bref, un outil de plus à vous garder sous le coude pour vos investigations 😉

PS : Je vous raconte la Google Mini ?

Pour son site grand public, un client utilise une Google Mini pour son moteur de recherche. La Google Mini, où Google Search Appliance, est un matériel vendu à une époque par Google qui embarquait ses algorithmes et était chargé d’indexer un site en particulier (ou plusieurs, bref, c’était votre mini Google, d’où son nom). Cette machine est proche de la boîte noire, le snmp est vraiment ridicule (en gros les différentes sondes remontent « OK, attention, cassé »), pas de ssh, et donc il arrive parfois, surtout arrivé à un certain âge, que la boiboite soit capricieuse.

Dans ce cas, deux niveaux généralement : la boîte accepte encore des connexions mais n’y répond pas, et c’est la situation que j’explique au-dessus : le pool se remplit de requêtes en attente qui n’aboutissent pas. Sauf que le moteur de recherche du site est une de ses principales fonctions. Dans le deuxième cas on est plus tranquille parce que tout simplement ça n’accepte plus les connexions, et là la réponse est immédiate : 0 résultat. Mais là ça se complique. La GSA est un appareil qu’on installe en Datacenter, et donc qu’on s’attend à pouvoir administrer  à distance sous une forme ou une autre. Mais point D’IPMI (Intelligent Platform Management Interface), de KVM (Keyboard Video Mouse), ni d’alimentation contrôlable. Pire, impossible d’utiliser un PDU (Power Distribution Unit), à savoir une prise contrôlable à distance pour simuler un débranchement /rebranchement de prise. Mais, la GSA n’est pas prévue pour redémarrer seule, il faut l’intervention d’un humain pour appuyer sur le bouton. On comprend mieux pourquoi ils n’en ont pas beaucoup vendu et qu’ils ont arrêtés les frais.