# uname -a

Switch

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 19 octobre 2017

Setup Letsencrypt certificates on Gitlab and Mattermost

The new versions of Gitlab are embedding the Mattermost server. Here is how to setup the certificates for these instances.

1. Install certbot

Read the docs here (choose Nginx on the appropriate system) : certbot.eff.org

2. Make a webroot

mkdir -p /var/www/letsencrypt/.well-known

3. Configure Gitlab and Mattermost to answer /.well-known to this webroot

Edit /etc/gitlab/gitlab.rb and add :

nginx['custom_gitlab_server_config']="location ^~ /.well-known/ {\n alias /var/www/letsencrypt/.well-known/;\n}\n"
mattermost_nginx['custom_gitlab_mattermost_server_config']="location /.well-known/ {\n alias /var/www/letsencrypt/.well-known/;\n}\n"

And reconfigure Gitlab :

gitlab-ctl reconfigure

4. Create the certificates

Run the certbot command :

certbot certonly --staging --webroot --webroot-path=/var/www/letsencrypt/ -d gitlab.your-domain.com
certbot certonly --staging --webroot --webroot-path=/var/www/letsencrypt/ -d mattermost.your-domain.com

5. Tell Gitlab to use the certificates

Edit /etc/gitlab/gitlab.rb again, and add :

nginx['redirect_http_to_https'] = true
nginx['ssl_certificate']= "/etc/letsencrypt/live/gitlab.your-domain.com/fullchain.pem"
nginx['ssl_certificate_key'] = "/etc/letsencrypt/live/gitlab.your-domain.com/privkey.pem"

mattermost_nginx['redirect_http_to_https'] = true
mattermost_nginx['ssl_certificate'] = "/etc/letsencrypt/live/mattermost.your-domain.com/fullchain.pem"
mattermost_nginx['ssl_certificate_key'] = "/etc/letsencrypt/live/mattermost.your-domain.com/privkey.pem"

6. Done

Reconfigure Gitlab again :

gitlab-ctl reconfigure

mardi 10 octobre 2017

Elasticsearch, Kibana : mapper [hits] cannot be changed from type [long] to [integer]

Every time I upgrade my ELK stack, it breaks. This time, it was the Kibana index with this obscurous errors :

[DEBUG][o.e.a.a.i.m.p.TransportPutMappingAction] [logs] failed to put mappings on indices [[[.kibana]]], type [timelion-sheet]
java.lang.IllegalArgumentException: mapper [hits] cannot be changed from type [long] to [integer][DEBUG][o.e.a.a.i.m.p.TransportPutMappingAction]

[DEBUG][o.e.a.a.i.m.p.TransportPutMappingAction] [logs] failed to put mappings on indices [[[.kibana]]], type [timelion-sheet]
java.lang.IllegalArgumentException: mapper [version] cannot be changed from type [long] to [integer]

Here is how to fix it. You will have to re-create an index with the correct mapping, and then reindex it.

Lire la suite...

- page 1 de 12