# uname -a

Bonjour,

Une note à moi-même et à mes stagiaires pour utiliser xdebug avec un point de montage SSHFS, et PHP FPM.

1. S'assurer que PHP est bien installé sur la machine du développeur, c'est nécessaire pour la coloration syntaxique et la vérification de syntaxe.
2. Installer PHP xdebug sur la machine distante
3. Configurer xdebug pour PHP FPM sur la machine distante. Attention, cela change selon la version de xdebug.
   1. Modifier le fichier de configuration FPM pour xdebug, par exemple pour Debian c'est /etc/php/7.3/fpm/conf.d/20-xdebug.ini
   2. Y placer les instructions suivantes :
      Pour xdebug v3 :

      [xdebug]
      zend_extension="xdebug.so"
      xdebug.mode=debug
      xdebug.start_with_request = yes
      xdebug.client_host=127.0.0.1
      xdebug.client_port="9003"
      

      Pour xdebug v2 :

      
      [xdebug]
      zend_extension="xdebug.so"
      xdebug.remote_enable=1
      xdebug.remote_autostart=1
      xdebug.remote_host=127.0.0.1
      xdebug.remote_port="9003"

   3. Redémarrer PHP FPM.
       
4. Sur la machine du développeur, installer le module PHP xdebug pour Visual Studio : https://marketplace.visualstudio.com/items?itemName=felixfbecker.php-debug
5. Connecter en SSHFS le dossier distant (la machine qui exécute PHP) sur la machine (locale) du développeur : sshfs login@distant:dossier_distant dossier_local
6. Connecter un tunnel SSH pour forward le port xdebug vers la machine locale : ssh -R 9003:localhost:9003 login@distant
7. Ouvrir dans Visual Studio le dossier monté avec SSHFS
8. Ouvrir un fichier, puis le debugger dans les onglets à gauche
9. Cliquer sur "create a json launch file", et vérifier le port de xdebug pour pointer sur le bon port. Ajouter le pathMapping pour mettre en correspondance le chemin local (ouvert dans Visual Studio Code) et le chemin distant (monté en SSHFS) :

   {
       // Use IntelliSense to learn about possible attributes.
       // Hover to view descriptions of existing attributes.
       // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
       "version": "0.2.0",
       "configurations": [
           {
               "name": "Listen for Xdebug",
               "type": "php",
               "request": "launch",
               "port": 9003,
               "pathMappings": {
                   "dossier_distant": "${workspaceFolder}/"
               }
           },
           {
               "name": "Launch currently open script",
               "type": "php",
               "request": "launch",
               "program": "${file}",
               "cwd": "${fileDirname}",
               "port": 9003,
               "pathMappings": {
                   "chemin_distant": "${workspaceFolder}/"
               }
           }
       ]
   }

10. Redémarrer Visual Studio par sécurité.
11. Lancer l'écoute via le debugger, ajouter les breakpoints dans Visual Studio, puis charger la page du site distant via le navigateur. Visual Studio devrait stopper l'exécution au niveau des breakpoints, pour permettre l'affichage de la pile, et le lancement des commandes.

Sources

• https://www.jetbrains.com/help/phpstorm/remote-debugging-via-ssh-tunnel.html#prepare-the-debugging-engine
• https://code.visualstudio.com/docs/languages/php

Admettons que vous ayez une machine avec un programme bugué. Typiquement, un logiciel métier avec une fuite de mémoire, qui va pour une raison inconnue saturer la mémoire vive et provoquer son propre crash ou le crash des autres services sur la machine.

Vous pourriez lui mettre une limite de mémoire via /etc/security/limits.conf mais ça ne fera que planter le programme (segmentation fault) pour protéger les autres, et dans le cas d'un logiciel métier cela veut dire prendre ensuite d'autres actions, manuelles ou automatiques, via un système de monitoring approprié.

C'est vrai, le monitoring est la bonne solution quand on suit un logiciel aussi critique qu'un logiciel métier, mais dans le cas d'un logiciel qui doit "juste tourner", d'une équipe de maintenance réduite ou n'ayant pas la possibilité d'astreintes, une solution simple pour s'assurer que la machine tourne même en cas d'incident, c'est de redémarrer la machine lors d'un incident. Pour cela, on peut utiliser le programme watchdog.

Cela doit être fait avec motivations et circonspection, une analyse "post-mortem" doit suivre chaque reboot, dans le cas d'une tentative d'élévation de privilèges par Buffer Overflow, rien ne dit que l'attaque n'a pas réussie même si le système a redémarré.

Watchdog : Configuration

Watchdog s'installe via les paquets :

apt install watchdog

Il y a ensuite deux choses à configurer : les règles pour déclencher le reboot, et le mode de chargement du programme ("no actions" ou actif).

Dans mon cas, je voulais redémarrer si le serveur avait moins de 20% de RAM disponible, ce serveur tourne en permanence à 50% de consommation de RAM et n'est jamais sensé dépasser, ou alors c'est signe d'un problème, d'où le reboot à déclencher.

La configuration de watchdog se trouve dans /etc/watchdog.conf et fournit deux valeurs à régler : min-memory et allocatable-memory . Attention, ces valeurs sont à renseigner en taille de page RAM.

Pour identifier la taille des pages sur le système, utilisez la commande :

getconf PAGESIZE

Ensuite, un simple calcul permet d'identifier la valeur à mettre dans min-memory et allocatable-memory. Par exemple, pour un PAGESIZE de 4096 (4 kB), 2 GB (2048 MB) de RAM et 20% de ce total :

( 20 % * 2048 * 1000 ) / 4096

Une fois min-memory et allocatable-memory configurés, il convient de tester le trigger avant de le démarrer;

Les options de lancement se trouvent dans /etc/default/watchdog . Modifier watchdog_options pour y renseigner :

watchdog_options="-v --no-action"

Désactivez Watchdog du démarrage automatique, puis démarrez-le :

systemctl disable watchdog
service watchdog start

Vous en verrez la trace dans les logs via service watchdog status ou journalctl -f .

Watchdog : Activation

Si les essais sont concluants, retournez dans /etc/default/watchdog pour activer le module noyau. Cela évitera que Watchdog se fasse tuer par un processus quelconque (oom-killer par exemple) :

watchdog_module="softdog"

Si vous ne voulez laisser aucune chance pour éviter le reboot (par exemple si oom-killer a réussi à baisser la consommation de ram sous le seuil acceptable et que le reboot n'est plus nécessaire), rajoutez nowayout :

watchdog_module="softdog nowayout"

Attention, une fois chargé en nowayout, le module noyau restera actif même si watchdog est stoppé (légitimement ou non), le seul moyen de le retirer est de retirer softdog des modules noyau (via rmmod), ou de rebooter.

Activez ensuite watchdog :

systemctl enable watchdog
service watchdog start

watchdog doit être visible dans les modules noyau chargés :

lsmod | grep softdog

Sources

• Page size check
• Watchdog configuration