Ça fait déjà plusieurs mois que l’utilitaire 3dm2 qui surveille les volumes RAID de mon serveur proxmox m’envoie des alarmes de temps en temps pour indiquer qu’un de mes disques (toujours le même) commence à avoir des secteurs difficiles à lire. Dernièrement j’ai reçu une nouvelle alarme de ce genre, avec cette fois-ci plusieurs secteurs d’un coup, signe que le disque commence vraiment à fatiguer. Dans ce genre de situation, la solution est simple : remplacer le disque par un nouveau de même taille, et reconstruire le volume RAID dessus. Ici, je vais plutôt en profiter pour faire une double manipulation, dont le but sera le remplacement des disques système de mon hyperviseur proxmox et le passage à des SSD.
Tout ceci à chaud, sans aucune interruption de production.
C’est la deuxième partie de mon plan de montée en débit de mon réseau local. En effet, si je veux profiter du 10 gbps dans mon réseau local, il m’est nécessaire d’équiper mon hyperviseur d’une carte réseau adéquate, car il contient mon pare-feu, qui est en cœur de réseau. Il serait donc inutile d’installer des commutateurs 10 gbps si le trafic interne, à 100% firewallé, est limité à 1 gbps par mon pare-feu. Il va donc falloir procéder à l’ajout d’une carte 10 gbps dans mon hyperviseur.
Il y a par contre un petit défi : mon hyperviseur n’a plus de slot pci-express de taille suffisante disponible.
Cette aventure fait partie de la première étape du plan de montée en débit de mon réseau domestique. Elle consiste à remplacer le vénérable commutateur qui est derrière ma TV par un modèle disposant de ports gigabits et 10 gigabits. C’est aussi l’occasion de procéder à la découverte de routerOS avec le switch Mikrotik CRS326-24G-2S+RM que j’ai choisi pour remplacer mon cisco catalyst 2950.
J’avais déjà lu pas mal d’excellentes réactions sur ce fameux routerOS, et c’est une des raisons pour lesquelles j’ai choisi de partir sur ce modèle de commutateur.
Mais le mieux pour se faire un avis est quand même de tâter la bête soit-même.
L’équipe du projet Debian a publié le 14 août 2021 la nouvelle mouture de sa distribution, la version 11 nommée Bullseye. Je ne suis pas très en avance, et pour l’instant je n’avais mis aucune machine de mon infra à jour vers cette version (même si j’ai quand même déjà préparé un modèle de machine en version 11, je n’en ai pas déployé de nouvelle entre temps). On va donc corriger le tir, en procédant à la mise à jour de Debian Buster vers Bullseye de ma machine de supervision.
Comme je suis chaud, on en profitera pour mettre à jour zabbix que j’utilise pour ma supervision, de la branche 5.2 que j’utilise actuellement, à la branche 5.4.
C’est rigolo, je réalise qu’il y a un an pile, j’avais fait le même article, mais dans l’autre sens : j’avais procédé à une grosse montée de version de zabbix, et j’en avais profité pour monter la version de Debian sur ma machine de supervision 🙂 .
Vouloir s’auto-héberger peut paraître un peu à contre courant des modes actuelles. En effet, une écrasante majorité des personnes utilise massivement les plateformes cloud des grandes entreprises de l’internet. Pour les quelques autres qui souhaitent disposer de leur propre cloud personnel, les plupart se tournent vers des serveurs dédiés ou mutualisés chez de grands fournisseurs. Cet article n’a pas pour objet de discuter du pourquoi il faudrait héberger (ou louer) son cloud perso (de très bons articles en parlent déjà) mais de donner un exemple de comment auto-héberger son cloud perso. La solution logicielle qui sera utilisée est Nextcloud.
Comme évoqué dans cet article présentant quelques unes des principales distributions Linux, arch linux est l’une des plus populaires. En plus de rassembler une large communauté d’utilisateurs enthousiastes et de disposer d’un wiki riche et de grande qualité, le nombre important de distributions en étant dérivées (Manjaro étant probablement la plus célèbre) suffit à convaincre de la grande qualité et de la solidité du projet. En revanche, de par son orientation « utilisateurs passionnés » , arch linux n’est probablement pas la plus facile à installer. Voyons un exemple de comment installer arch linux.
Le défi du jour (ou de la semaine…) : passer mon serveur Zabbix de la version 4.4.10 à la version 5.2. Dans la mesure où il y a une version intermédiaire entre les deux, la 5.0 (une LTS), je vais passer par celle-ci avant de monter en 5.2. Les raisons sont que je vais en profiter pour vérifier que tout va bien en 5.0 avant de continuer la montée de version, mais aussi que les notes de montée de version 4.4 -> 5.0 comportent plusieurs mises en garde (comme nous allons le voir plus loin) , alors que la mise à jour 5.0 -> 5.2 semble n’être qu’une quasi-formalité.
Si on questionne un moteur de recherche pour trouver des informations sur internet pour mettre en place un boot PXE depuis un dépôt géré par un serveur TFTP, on trouve des tas de résultats probablement tous super pertinents. Cependant, aucun howto rencontré lors de mes recherches ne proposait un système permettant de démarrer clonezilla en PXE en utilisant la liste suivante d’ingrédients:
En voici donc un, un tantinet quick and dirty, mais qui peut servir de point de départ. Le but recherché ici étant de mettre en place rapidement une petite infrastructure de création / déploiement d’images disque, pour cloner facilement des lots de PC sans avoir à multiplier les CD de boot ou autres clés USB.
En effet, dans un annuaire openldap, il n’existe pas pour un objet de classe posixAccount d’attribut listant les groupes auxquels il appartient. Ce sont les objets de type posixGroup qui eux, par l’intermédiaire de l’attribut memberUid, listent leurs membres. Il n’est par conséquent pas possible de lister les groupes auxquels appartient un utilisateur directement et en une seule requête à partir de son objet dans l’annuaire. On peut corriger ça avec le fait d’implémenter l’overlay « memberof » avec Openldap.
Dans l’optique de migrer l’instance de nextcloud 15 de mon petit auto-hébergement perso vers la version 16, afin de maximiser les chances de réussite, il est préférable de corriger tous les avertissements remontés dans le panel administrateur. Parmi ceux-ci, il peut y avoir le message suivant, demandant de changer le charset des tables avec mariadb.
MySQL est utilisée comme base de données mais ne supporte pas les caractères codés sur 4 octets. Pour pouvoir manipuler les caractères sur 4 octets (comme les émoticônes) sans problème dans les noms de fichiers ou les commentaires par exemple, il est recommandé d’activer le support 4 octets dans MySQL.
Il semble que ce message aurait du apparaître depuis longtemps, mais il se trouve que sur cette instance il n’est apparu que récemment.
