# uname -a

Switch

vendredi 28 mai 2021

Configurer Visual Studio Code pour utiliser xdebug avec PHP FPM et SSHFS

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="9000"
      
      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="9000"
    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 9000:localhost:9000 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": 9000,
                "pathMappings": {
                    "chemin_distant":": "${workspaceFolder}/"
                }
            },
            {
                "name": "Launch currently open script",
                "type": "php",
                "request": "launch",
                "program": "${file}",
                "cwd": "${fileDirname}",
                "port": 9000,
                "pathMappings": {
                    "chemin_distant": "${workspaceFolder}/"
                }
            }
        ]
    }
  10. Redémarrer Visual Studio par sécurité.
  11. Lancer l'écoute via le debugger, ajtuer 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

 

vendredi 23 octobre 2020

Configure a 3CX extension with Big Blue Button conferencing bridge (Freeswitch)

Just a quick note for reference.

I managed to successfully configure the phone bridge with FreePBX as a SIP provider for Big Blue Button using this documentation : https://docs.bigbluebutton.org/2.2/customize.html#add-a-phone-number-to-the-conference-bridge . My trunk is connectd to the SIP server running FreePBX and Big Blue Button is registering as a phone extension to receive phone calls and route them to the conference room.

But using a similar architecture with 3CX instead of FreePBX as a provider was failing. Actually, you have to add the AuthID as "auth-username" attribute (see https://freeswitch.org/confluence/display/FREESWITCH/Sofia+Gateway+Authentication+Params )

In Big Blue Button, the profile file would looks like :

<include>
  <gateway name="ANY-NAME-FOR-YOUR-PROVIDER">
    <param name="proxy" value="sip.example.net"/>
    <param name="username" value="EXTENSION NUMBER (for instance 100)"/>
    <param name="auth-username" value="THE AUTHID"/>
    <param name="password" value="PASSWORD"/>
    <param name="extension" value="CALLED-NUMBER"/>
    <param name="register" value="true"/>
    <param name="context" value="public"/>
  </gateway>
</include>

I hope it will help someone stuck with the official documentation.

mercredi 14 octobre 2020

Redémarrer une machine lorsqu'un programme l'étouffe inopinément (Debian 10)

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

 

jeudi 19 mars 2020

Maman, j'ai patché Debian

Un billet en forme de note à moi-même sur ce qu'il faut faire pour correctement :

  • Récupérer un package depuis upstream
  • Appliquer un ou plusieurs patches
  • Le signer et le re-déployer en production

Préparer l'environnement

Pour compiler et signer un paquet simplement il vous faut :

  • Un utilisateur (non root)
  • Une clé GPG
  • Les build-essentials et les devscripts (parce qu'on est feignasse)

Créez un utilisateur non-root et loguez-vous avec. N'utilisez pas "su" à partir de root, parce que sinon GPG ne pourra pas vous demander la phrase de passe (des histoires de droits sur les TTY).

Créez une clé GPG, et paramétrez-la :

gpg --full-generate-key

Récupérez l'identifiant de clé à la fin de la procédure, ou avec gpg --list-keys si vous l'avez loupé.

Modifiez ou créez le fichier ~/.devscripts et ajoutez :

DEBUILD_SET_ENVVAR_DEBSIGN_KEYID=xxxxxxxx

Avec le xxxxxx qui correspond à votre identifiant de clé.

Récupérer le paquet et les dépendances de compilation

Le plus simple c'est quand le paquet existe déjà et qu'il faut simplement patcher. S'il n'existe aucun paquet, il faut créer un nouveau paquet, éventuellement debianizer la configuration, et c'est une autre paire de manches (et c'est pas le sujet ici).

Pour récupérer le paquet upstream :

apt-get source nomdupaquet

Si le paquet est introuvable, ajoutez les dépôts src à votre sources.list :

deb-src http://deb.debian.org/debian/ buster main contrib
deb-src http://security.debian.org/debian-security buster/updates main contrib
deb-src http://deb.debian.org/debian/ buster-updates main contrib

Il faut ensuite récupérer les paquets nécessaires à la compilation. Coup de bol, si vous avez pu avoir le paquet source à l'étape précédente, c'est facile :

apt-get build-dep nomdupaquet

Patcher le paquet

Le format dpatch est obsolète, en principe votre package utilise quilt comme tout paquet récent. Il suffit de télécharger le patch depuis git et le placer dans le dossier debian/patches.

Ensuite, ajoutez le nom du fichier que vous avez ajouté au fichier debian/patches/series . Attention, l'ordre dans series est important.

Déclarer les changements

Ce n'est pas nécessaire la première fois, mais si vous re-compilez un paquet, il faut ajouter un commentaire dans le Changelog. Le plus simple : utilisez la commande dch -i  et modifiez la ligne de changelog, en changeant bien la version du paquet pour qu'elle soit consécutive à la précédente.

Compiler le paquet

Rendez-vous dans le dossier du paquet, et lancez la commande debuild . C'est tout. Rentrez votre phrase de passe pour la clé à la fin de la procédure.

Déployer en production

Pour déployer un paquet, deux solutions :

  • Envoyer le paquet puis l'installer avec dpkg -i lefichier.deb ou un outil d'orchestration
  • Installer un DPA (Debian Private Repository) et l'ajouter au sources.list

L'installation du serveur DPA fera l'objet d'un autre billet (un jour).

Sources

jeudi 23 janvier 2020

Wordpress : la revanche du reverse proxy

Quand un reverse proxy est mal configuré,

Il n'a pas les bonnes variables d'environnement,

Wordpress se croit toujours en HTTP,

Et fait une boucle de redirection en HTTPS.

Heureusement, il y a une autre solution,

Ouvrez wp-config.php, et ajoutez (au bon endroit) :

/* Turn HTTPS 'on' if HTTP_X_FORWARDED_PROTO matches 'https' */
if (strpos($_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false) {
    $_SERVER['HTTPS'] = 'on';
}

Source.

- page 1 de 33