Blog de dada

DevOps, bidouilleur et routard plein de logiciels libres

Aide

Contrôler son GPU avec radeon-profile

Rédigé par dada / 05 octobre 2020 / 3 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.


Récupérer ses flux RSS dans Firefox

Rédigé par dada / 02 janvier 2019 / 12 commentaires


Avec les dernières versions de Firefox, Mozilla a supprimé le support des flux RSS dans son navigateur. C'est un choix qu'on apprécie, ou pas, avec lequel il faut faire. J'ai décidé de configurer mon navigateur pour lui redonner la possibilité de jouer avec les flux RSS à travers l’application Want My RSS.

Installation

Pour l'installation, passez par ce lien pour télécharger et installer l'extension.

Utilisation

L'outil est assez simple. En naviguant dans le Web, vous verrez apparaître l’icône des flux RSS dans la barre d'adresse. Cliquez dessus et admirez la liste des flux disponibles.


Chez moi, après avoir cliqué sur le flux des articles, ça donne :


Configuration

Want My RSS permet d'afficher les flux RSS mais aussi de les ajouter à son lecteur préféré. Chez moi, c'est FreshRSS qui tient le haut du pavé. Pour vous permettre d'ajouter un flux, configurez l'extension pour aller directement taper dans votre lecteur :


Si vous cherchez le lien qui va bien de votre FreshRSS, retrouvez-le dans Gestion des abonnements -> Outils d'abonnement.

Et voilà, les RSS sont de retour dans Firefox !

Kubernetes en multi-master sur du baremetal avec HAProxy

Rédigé par dada / 20 décembre 2018 / 12 commentaires



Quand on joue avec Kubernetes, on se rend compte que c'est aussi puissant que fragile. L'orchestration, ça ne s'improvise pas. Il faut vraiment passer des heures à se casser les dents sur des clusters de tests qui finiront toujours par s'écrouler. Que ce soit à cause d'un souci côté hébergeur, entraînant une indisponibilité de votre master ou une configuration laxiste permettant à des pods de consommer plus de ressources que ce qu'il y a de disponible, en massacrant chaque node disponible, méticuleusement, les uns après les autres, jusqu'à vous laisser sans rien.
Je ne parlerai pas ici du meilleur moyen pour contrôler la consommation des pods. On va s'attaquer au premier souci : votre unique master configuré en SPoF.

Le multi-master, ton ami

Pour éviter de voir un cluster HS à cause de l'absence de son maître, on va le configurer avec un quorum de... 3 masters. Tout simplement.

Pourquoi HAProxy ?

Mon environnement de test est basé sur des serveurs dans le cloud de Hetzner. J'ai essayé d'attendre aussi longtemps que possible des infrastructures abordables supportant k8s loin des AWS, GCP ou encore Azure, en vain. Il y a bien OVH et DigitalOcean mais le côté "abordable" n'y est pas. Le premier ouvre son infrastructure à partir de 22€ le serveur, et l'autre 20$ (node unique + LB). On est loin des 6€ par machine chez Hetzner.

L'idée

Comme l'indique la documentation officielle, HAProxy va faire ce qu'il sait faire de mieux : rediriger les requêtes. Comment peut-on faire croire à 3 serveurs séparés qu'ils bossent ensemble ? En installant un HAproxy sur chacun d'entre eux, configuré pour loadbalancer les requêtes qui seront balancées sur le 127.0.0.1 et le port 5443 (choisi arbitrairement).

En image, ça donne ça :


Configurés comme ça, nos masters vont s'amuser entre-eux sans aucun souci.

L'installation

Je passe sur la configuration de Kubernetes, j'en parle déjà ici. Notez quand même que vous pouvez suivre ce que je raconte jusqu'à l'init du cluster. Pas plus. Pourquoi ? Parce que sur le premier de vos masters, nous allons ajouter un fichier de configuration :
root@k8smaster1:~# cat kubeadm-config.yaml 
apiVersion: kubeadm.k8s.io/v1beta1
kind: ClusterConfiguration
kubernetesVersion: stable
apiServer:
  certSANs:
  - "127.0.0.1"
controlPlaneEndpoint: "127.0.0.1:5443"
networking:
   podSubnet: "10.244.0.0/16"
Ici, on voit bien que j'ai configuré mon k8s pour taper sur le localhost de la machine à travers le port 5443. C'est là que HAproxy prend la relève.
Je me suis permis d'ajouter la configuration nécessaire à Flannel, mon CNI, qui nécessite en CIDR particulier pour fonctionner correctement. C'est la partie networking.

On peut enchaîner sur la configuration de HAProxy :
global
    log /dev/log    local0
    log /dev/log    local1 notice
    chroot /var/lib/haproxy
    stats socket /run/haproxy/admin.sock mode 660 level admin
    stats timeout 30s
    user haproxy
    group haproxy
    daemon

    ca-base /etc/ssl/certs
    crt-base /etc/ssl/private

    ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS
    ssl-default-bind-options no-sslv3

defaults
    log    global
    mode    tcp
    option    tcplog
    option    dontlognull
        timeout connect 5000
        timeout client  50000
        timeout server  50000
    errorfile 400 /etc/haproxy/errors/400.http
    errorfile 403 /etc/haproxy/errors/403.http
    errorfile 408 /etc/haproxy/errors/408.http
    errorfile 500 /etc/haproxy/errors/500.http
    errorfile 502 /etc/haproxy/errors/502.http
    errorfile 503 /etc/haproxy/errors/503.http
    errorfile 504 /etc/haproxy/errors/504.http

frontend api-front
    bind 127.0.0.1:5443
    mode tcp
    option tcplog
    use_backend api-backend

backend api-backend
    mode tcp
    option tcplog
    option tcp-check
    balance roundrobin
    server master1  10.0.42.1:6443 check
    server master2  10.0.42.2:6443 check
    server master3  10.0.42.3:6443 check
La partie global a l'exacte configuration par défaut. J'ai touché à rien.

Dans defaults, j'ai changé le mode de proxy pour le passer de http à tcp.

Les parties frontend et backend regroupent les configurations qui vont bien pour permettre à HAProxy de faire ce que je lui demande. Vous devriez pouvoir recopier tout ça en prenant seulement le soin de changer les IP des masters.

Pour comprendre plus clairement la configuration de HAproxy, je vous redirige vers cet excellent billet de Victor HÉRY.

Une fois configurés, n'oubliez pas de redémarrer les HAProxy sur tous les serveurs et de vérifier qu'ils écoutent bien sur le bon port :
root@k8smaster1:~# nc -v localhost 5443
localhost [127.0.0.1] 5443 (?) open
Astuce : pensez à installer hatop. C'est vraiment super ! Pour le lancer :
hatop -s /var/run/haproxy/admin.sock
Pour le moment, tout sera down, mais une fois le premier master en état, il apparaîtra UP.

On va maintenant initialiser le premier master :
kubeadm init --config=kubeadm-config.yaml
Une fois terminé, vous allez récupérer les informations classiques : le join qui va bien.
kubeadm join 127.0.0.1:5443 --token a1o01x.tokenblabla --discovery-token-ca-cert-hash sha256:blablablablalblawhateverlablablameans --experimental-control-plane
Notez que l'IP de l'API est bien 127.0.0.1 avec le port spécifié à HAProxy. C'est tout bon ! Faites un tour dans hatop et remarquez que le backend du master1 est enfin marqué comme étant UP.

Un get nodes vous confirmera l'arrivée du master1 et un get pods vous montrera les conteneurs de base.

Installons maintenant Flannel, toujours aussi simplement :
kubectl apply -f https://github.com/coreos/flannel/raw/master/Documentation/kube-flannel.yml
Et on aura un premier master en état de fonctionner !

Pour configurer les deux autres masters, il va falloir jouer du SCP. La doc officielle fournit 2 scripts bash que vous pouvez utiliser. Je ne m'étends pas sur le sujet ici et j’enchaîne sur la configuration des autres masters. Pensez quand même à bien configurer SSH et votre user de base.

Une fois que tout est copié, vous n'avez qu'à lancer la commande join sur les masters restant, un par un, et voir le résultat :
dada@k8smaster1:~$ k get nodes
NAME         STATUS   ROLES    AGE   VERSION
k8smaster1   Ready    master   12h   v1.13.1
k8smaster2   Ready    master   11h   v1.13.1
k8smaster3   Ready    master   11h   v1.13.1
Ou encore :
dada@k8smaster1:~$ k get pods --all-namespaces
NAMESPACE     NAME                                 READY   STATUS    RESTARTS   AGE
kube-system   coredns-86c58d9df4-cx4b7             1/1     Running   0          12h
kube-system   coredns-86c58d9df4-xf8kb             1/1     Running   0          12h
kube-system   etcd-k8smaster1                      1/1     Running   0          12h
kube-system   etcd-k8smaster2                      1/1     Running   0          11h
kube-system   etcd-k8smaster3                      1/1     Running   0          11h
kube-system   kube-apiserver-k8smaster1            1/1     Running   0          12h
kube-system   kube-apiserver-k8smaster2            1/1     Running   0          11h
kube-system   kube-apiserver-k8smaster3            1/1     Running   0          11h
kube-system   kube-controller-manager-k8smaster1   1/1     Running   1          12h
kube-system   kube-controller-manager-k8smaster2   1/1     Running   0          11h
kube-system   kube-controller-manager-k8smaster3   1/1     Running   0          11h
kube-system   kube-flannel-ds-amd64-55p4t          1/1     Running   1          11h
kube-system   kube-flannel-ds-amd64-g7btx          1/1     Running   0          12h
kube-system   kube-flannel-ds-amd64-knjk4          1/1     Running   2          11h
kube-system   kube-proxy-899l8                     1/1     Running   0          12h
kube-system   kube-proxy-djj9x                     1/1     Running   0          11h
kube-system   kube-proxy-tm289                     1/1     Running   0          11h
kube-system   kube-scheduler-k8smaster1            1/1     Running   1          12h
kube-system   kube-scheduler-k8smaster2            1/1     Running   0          11h
kube-system   kube-scheduler-k8smaster3            1/1     Running   0          11h
Un dernier tour sur hatop pour admirer la présence de tous vos backends enfin marqué UP.

Vous avez maintenant un cluster k8s en HA ! La suite serait peut-être de vous raconter comment sortir ETCd du cluster pour le mettre en place dans un cluster séparé dédié, mais non. Ce billet est déjà bien assez long.

Si tout ne se passe pas comme prévu, pensez à regarder la documentation officielle. Mon billet n'est qu'un complément qui peut contenir des coquilles. Pensez aussi à bien vérifier la configuration de votre firewall, ou encore de HAProxy, ou encore de Docker, ou encore votre VPN parce qu'on ne laisse pas tout traîner sur le réseau. Bref.