# uname -a

Switch

Mot-clé -

Fil des billets

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

mercredi 22 juin 2016

Debian 8 : Configure Nginx and Passenger to supercharge your PuppetMaster

The Puppet master comes by default with a basic WEBrick server. It allow a quick start for those that are not familiar with Puppet, but when the number of Puppet nodes grows, the performances of the default WEBrick server are going down quickly.

The Puppet documentation show how to configure Apache and Passenger to replace the default WEBrick server, but what if you have a lot of nodes ? What if you want to apply your configuration within minutes, instead of the default half-hour threshold before the agent asks the master if something changed ?

Or you may just want a fancy Nginx instead of your plain-old-reliable Apache.

Here is how.

Lire la suite...

mardi 19 avril 2016

"SQLSTATE[HY000] [2002] No such file or directory" for compiled PHP

Let's say you connect to MySQL using "localhost"

Let's say you compiled PHP

Let's say you didn't specify the --with-mysql-sock= parameter in your configure command when you built mysql

And let's suppose you cannot connect to MySQL using PHP. CLI works fine, but not CGI.

Solution : fix the default sockets in php.ini (use your own working socket paths) :

pdo_mysql.default_socket=/var/run/mysqld/mysqld.sock
mysqli.default_socket = /var/run/mysqld/mysqld.sock

# You shouldn't use mysql_ extension, but if you did:
mysql.default_socket = /var/run/mysqld/mysqld.sock

I suppose that automatically converting "localhost" to an unix socket is done for performance reason on unix systems.

jeudi 18 février 2016

Debian 8 : Limit SSH users to SFTP

Let’s say you want to configure a secure remote file access for you users, but you can’t use FTPS for some reasons (problems with passive mode and commercial firewalls ? Yes !). Your only secure solution is either a VPN, or a SFTP access.

SFTP is great, but it may implies giving full command line access to your end users.  In order to prevent that, you could set-up a jailed SSH access with Jailkit and some bind mount, but it’s not that trivial to configure and to maintain ; and it may not work with software virtualization (Docker, LXCs…). There is a simpler solution.

The solution is : use the native chroot and limitations abilities of OpenSSH. Here is how.

Lire la suite...

- page 1 de 6