Aide

Bloquer la version de NodeJS pour Mastodon 4.2.0

Rédigé par dada / 28 septembre 2023 / Aucun commentaire

La toute dernière version de Mastodon s'accompagne d'un petit souci d'administration si vous utilisez Debian 12 (Bookworm) comme système d'exploitation pour votre serveur : NodeJS.

En effet, la version de NodeJS officiellement supportée est, malgré ce que dit la documentation, la 16.x et pas plus alors que Debian 12 embarque la version 18 dans ses valises. Pas de 18, pas de 20, donc. Enfin, pas exactement. Il est possible de les utiliser au prix d'une bidouille officiellement diffusée dans les réponses aux différents soucis relayés dans Github.

Enfin, si comme moi, vous n'avez pas envie de vous embêter plus que ça, voici comment faire pour être tranquille.

Installer le dépôt NodeJS 16 pour Debian 12

On commence par les keys :

sudo apt-get update
sudo apt-get install -y ca-certificates curl gnupg
sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://deb.nodesource.com/gpgkey/nodesource-repo.gpg.key | sudo gpg --dearmor -o /etc/apt/keyrings/nodesource.gpg

On ajout le dépôt :

sudo echo "deb [signed-by=/usr/share/keyrings/nodesource.gpg] https://deb.nodesource.com/node_16.x bookworm main
deb-src [signed-by=/usr/share/keyrings/nodesource.gpg] https://deb.nodesource.com/node_16.x bookworm main" > /etc/apt/sources.list.d/nodesource.list

On fait le pinning qui va bien :

Dans /etc/apt/preferences.d/nodejs-mastodon ajoutez :

Package: nodejs*
Pin: release o=Debian*
Pin-Priority: -1

Package: *
Pin: release o=deb.nodesource.com
Pin-Priority: 99

Vous pouvez maintenant supprimer la version NodeJS de Debian et installer la version des dépôts que vous venez d'ajouter :

apt update
apt purge nodejs
apt install apt install nodejs=16.20.2-deb-1nodesource1

Un apt-cache pour vérifier tout ça :

nodejs:
  Installed: 16.20.2-deb-1nodesource1
  Candidate: 16.20.2-deb-1nodesource1
  Version table:
     18.13.0+dfsg1-1 -1
        500 http://deb.debian.org/debian bookworm/main amd64 Packages
        150 http://deb.debian.org/debian unstable/main amd64 Packages
 *** 16.20.2-deb-1nodesource1 500
        500 https://deb.nodesource.com/node_16.x bookworm/main amd64 Packages
        100 /var/lib/dpkg/status

Vous êtes tranquille maintenant ! Du moins, tant que NodeJS 14 est maintenu, ce qui commence à devenir un souci.

De l'alerting à base de logs v2

Rédigé par dada / 06 novembre 2020 / Aucun commentaire

À l'époque, mi-février 2020, je découvrais les pipelines de Promtail, une façon rudimentaire de parcourir des logs, d'y chercher ce qu'on veut et de déclencher une alerte si besoin. C'était ma v1 de l'alerting à base de logs.

Dans les faits, ça marche bien, mais ce n'est pas vraiment simple à mettre en place et ça demande des bidouilles pas possible quand on commence à vouloir trifouiller dans des choses plus complexes, comme Docker.

Il y a quelques semaines, j'ai découvert qu'il y avait un moyen encore plus simple et mieux intégré pour faire de l'alerting avec Grafana / Loki / Promtail : Loki lui-même.

Configurer Loki comme Datasource de type Prometheus

Si vous avez l'habitude de jongler avec toute cette stack, le titre de cette partie devrait vous faire tilter. C'est pourtant ce qu'il faut faire : pour Grafana, Loki va se la jouer Prometheus.

En version texte :

Name : ce que vous voulez
URL : http://localhost:3100/loki

Dans la partie Explore de Grafana, vous deviez maintenant avec PromLoki comme Datasource :

Et c'est à partir de maintenant qu'on peut commencer à jouer !

Créer un panel lié à une alerte

On va s'amuser à créer un panel pour analyser les logs qui nous intéressent.

Notez qu'on a bien choisi PromLoki comme datasource.

Dans mon exemple, ce sont les logs de Pixelfed que je veux parcourir pour pouvoir agir en cas de production.ERROR :

count_over_time(({hostname="pixelfed"} |= "production.ERROR")[1m])

Maintenant qu'on sait ce qu'on cherche, on va configurer les règles qui déclencheront les alertes.

Dans les Rules :

- Choisissez un nom.
- On évalue toute le 10s

Dans les conditions :

- When : on fait la moyenne en choisissant avg()

- Of : cliquez sur les variables entre les virgules pour préciser vos réglages

- Above : ici, j'attends plus de 3 occurrences pour déclencher une alerte

Si vous avez le coup d’œil, vous avez remarquez que les deux captures d'écran présentées ci-dessus ont une ligne rouge : c'est la limite de tolérance de l'alerte. En dessous, tout va bien, au dessus, c'est la fin du monde.

Recevoir les alertes

Maintenant que vous avez la possibilité de déclencher alertes, il faut les recevoir d'une façon ou d'une autre. Grafana peut se brancher à un paquet d'outil, de Telegram à Elements en passant par Discord et l'Alert Manager de Prometheus voire Grafana llui-même: faites votre choix !

Perso, je me sers de mon AlertManager, il me noie sous les mails en cas de souci et c'est très bien comme ça !

Contrôler son GPU avec radeon-profile

Rédigé par dada / 05 octobre 2020 / 4 commentaires

Contexte

Parmi mes dernières mésaventures, il y a l'incapacité de mon Ubuntu 20.04 à correctement gérer la ventilation de ma RX 590 XFX. Il s'agit d'une carte graphique plus ou moins récente de chez AMD.

J'avais jeté mon dévolu dessus lors d'une promotion quelconque après la lecture d'un papier racontant que, maintenant, sous GNU/Linux, c'est AMD/ATI qui fonctionne le mieux avec - en bonus - des pilotes libres.

Enfin, c'était avant qu'elle achève ma vieille alimentation sous-dimensionnée et que je précipite la fin de vie de mon ancien CPU avec un coup de tournevis fort mal placé lors de l'installation du système de refroidissement sensé lui permettre de survivre encore quelques années au poids des applications modernes.

Bref, des mésaventures, je vous dis.

Radeon-profile, c'est quoi ?

Déjà, il s'agit d'une application libre que vous pouvez trouver par ici.

Elle permet :

de monitorer sa carte graphique (fréquence, voltage, température, vitesse des ventilateurs, etc).
de contrôler les ventilateurs.
d'overclocker son matériel.
de définir des profiles en fonction des éléments cités précédemment.

En gros, ça fait le café.

Installation

Si vous êtes sous Ubuntu, vous allez être contents, il y un PPA :

sudo add-apt-repository ppa:radeon-profile/stable

sudo apt update

sudo apt install radeon-profile

Si vous utilisez une autre distrib', je vous redirige vers la doc pour compiler la chose.

Mon usage

Mon Ubuntu n'étant pas foutu de correctement contrôler les ventilo de la chose, j'utilse radeon-profile pour définir une vitesse de rotation en fonction de la température de la bête. Ça donne ça :

On peut voir que j'ai créé 9 paliers qui me permettent de garder la carte au « frais » en fonction de la température. Joli, non ? Je ne vous cache pas que je n'ai pas encore trouvé de cas dans lequel ces paliers sont pertinents.

En fait, je passe souvent du « elle ne fout rien » à « elle est utilisée à fond ». Y'a pas vraiment d'étape entre les deux, ou rarement.

En vrai, vous pouvez simplement vous servir de la configuration par défaut de l'appli et ça roulera tout seul. Vous passerez juste d'un bureau silencieux aux environs de la BA 113, sans profiter de la « douce » augmentation du volume.

Bref

Cet utilitaire m'a clairement sauvé la mise. Avant de tomber dessus, je commençais à tristement me dire que le sort s'acharnait et que j'allais devoir ravaler les velléités de joueur occasionnel.

Sortir d'un /boot débordant

Rédigé par dada / 11 septembre 2020 / 2 commentaires

Vous avez déjà souffert devant un /boot plein ? Oui, je le sais. C'est arrivé à tout le monde. Pas la peine de se cacher.

Fallait passer LVM ou Btfrs, vous me direz. J'entends bien. Des fois, les planètes s'alignent mal et faut faire avec. Je vous propose d'utiliser une solution radicale pour vous en sortir : supprimer la partition /boot pour la remplacer par un répertoire /boot à la racine.

1. Faire une sauvegarde

On va toucher à ce qui permet à votre serveur de démarrer. Faire une sauvegarde semble être une excellente idée.

2. Sauvegarder /boot

On va commencer par mettre de côté le contenu de la partition /boot :

root@ubuntu:/ mkdir /boot_bkp && cp -R /boot/* /boot_bkp/

On s'en servira plus tard.

3. Commenter le fstab

Comme on en n'a plus besoin, on va dégager l'entrée de /boot dans le /etc/fstab. Les lignes de conf ci-dessous sont des exemples, retenez seulement que les lignes contenant /boot doivent avoir un # devant.

root@ubuntu:/home/user# cat /etc/fstab 
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda3 during installation
UUID=392d55fd-d4e5-4a67-8834-5d29c7toto42 /               ext4    noatime,errors=remount-ro 0       1
# /boot was on /dev/sda2 during installation
#UUID=1b7533ec-96c2-4eef-9eac-b117c0toto42 /boot           ext4    noatime         0       2
# /home was on /dev/sda5 during installation
UUID=7545673f-5c08-4201-9e30-f56d32toto42 /home           ext4    noatime         0       2
# swap was on /dev/sda4 during installation
UUID=9ad39928-283d-43d6-8ee5-98e296toto42 none            swap    sw              0

De cette façon, la partition ne sera plus montée en cas de redémarrage.

4. Démonter la partition

On va maintenant umount /boot :

root@ubuntu:/home/user# umount /boot

On peut vérifier la disparition de l'ancienne partition avec un simple grep :

root@ubuntu:/home/user# mount | grep boot

Si quelque chose apparaît, c'est que vous n'avez pas démonté la partition. Pensez à sortir de /boot sous peine de vous voir lire un truc du genre « blabla is too busy ! ».

5. Refaire un /boot à la racine

On va maintenant se servir du /boot_bkp créé plus tôt :

root@ubuntu:/home/user# mkdir /boot && cp -R /boot_bkp/* /boot

Ainsi, on se retrouve avec un /boot inutile mais à sa place.

6. Réinstallation de grub

On va lancer la procédure d'installation de grub sur votre disque comme s'il n’était plus là :

root@ubuntu:/home/user# grub-install /dev/sda
Installing for i386-pc platform.
Installation finished. No error reported.

L'installation de grub prend quelques secondes et n'est pas très bavarde. Vous pouvez ajouter l'option -v si vous êtes curieux.

À ce moment précis, tout est en ordre. Vous devriez pouvoir relancer votre machine et mamailler vos kernels comme bon vous semble. J'ajoute tout de même une dernière étape, sait-on jamais ?

7. Mettre à jour grub

On n'est jamais assez prudent, on va donc mettre à jour grub :

root@ubuntu:/home/user# update-grub
Sourcing file `/etc/default/grub'
Sourcing file `/etc/default/grub.d/init-select.cfg'
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.4.0-47-generic
Found initrd image: /boot/initrd.img-5.4.0-47-generic
Found linux image: /boot/vmlinuz-5.4.0-45-generic
Found initrd image: /boot/initrd.img-5.4.0-45-generic
done

Et voilà ! On se retrouve avec un /boot placé à la racine, avec les répertoire grub/ contenant le grub.cfg qui va bien et tout le reste.

Vous n'avez plus qu'à redémarrer, après avoir fait des backups.

Ajuster le Nextcloud de son Turris Mox

Rédigé par dada / 12 août 2019 / 3 commentaires

Un Turris Mox ?

Pour celles et ceux qui ne sauraient pas ce que c'est, je vous redirige par ici. Je vous balance directement le lien vers la description de sa version cloud parce que c'est celle que j'ai prise. L'objectif ? Arrêter d'héberger mes données sur des serveurs tiers et revenir à un vrai auto-hébergement pour toute ma partie données perso. Ce blog et les autres outils resterons dans les nuages.

Nextcloud

L'intégration de Nextcloud dans le TurrisOS, la variante d'OpenWRT présente dans le Mox, ne vient pas avec toutes les petites configurations qui vont bien. Voici une rapide liste des choses à modifier ou corriger pour que tout se passe au mieux.

Remarque

Notez que le Mox est un petit appareil aux performances modestes. Il comblera sans trop de problème mes besoins perso, en tant qu'utilisateur unique de mon instance, mais n'espérez réussir à gérer convenablement plusieurs utilisateurs actifs en même temps.

Les modifications

Variables d'environnement

vim /etc/php7-fpm.d/www.conf

Vous y trouverez ces variables commentées, enlevez le point-virgule qui traîne devant :

env[HOSTNAME] = $HOSTNAME
env[PATH] = /usr/local/bin:/usr/bin:/bin
env[TMP] = /tmp
env[TMPDIR] = /tmp
env[TEMP] = /tmp

PHP Memory limit

La configuration de PHP-FPM vient avec un memory_limit de 384M quand Nextcloud en réclame 512 pour bien fonctionner. Pour corriger le tire, allez modifier la valeur dans /etc/php.ini pour remplacer 384 par 512 :

memory_limit = 512M

Et redémarrer le PHP-FPM :

/etc/init.d/php7-fpm restart

Opcache

Ajoutez la conf Opcache qui va bien dans /etc/php.ini :

opcache.enable=1
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.memory_consumption=128
opcache.save_comments=1
opcache.revalidate_freq=1

Lighttpd

Le serveur web choisi par TurrisOS est Lighttpd. Sachez qu'il est possible d'installer Nginx pour le remplacer mais comme c'est la configuration par défaut, j'ai décidé de le laisser là.

Pour corriger les erreurs de well-known, ajouter les lignes qui manquent dans /etc/lighttpd/conf.d/nextcloud.conf :

alias.url += ( "/nextcloud" => "/srv/www/nextcloud" )

$HTTP["url"] =~ "^/nextcloud/(build|tests|config|lib|3rdparty|templates|data)" {
     url.access-deny = ("")
}

# Redirect Cal/CardDAV requests to Nextcloud endpoint:
url.redirect = (
    "^/.well-known/caldav"  => "/nextcloud/remote.php/dav",
    "^/.well-known/carddav" => "/nextcloud/remote.php/dav",
    "^/.well-known/webfinger" => "/nextcloud/public.php?service=webfinger"

)

Et redémarrez le service :

/etc/init.d/lighttpd restart

Memcache

Pour le moment, je n'ai pas trouvé comment faire pour mettre en place un système de cache honorable pour améliorer les performances générales de Nextcloud. Il n'y a pas, dans les dépôts officiels de TurrisOS, de paquet php-redis ou encore php-memcached. Du coup, pas de cache.