FRsAG October 2025

frsag@frsag.org

17 participants
5 discussions

Discard/trim sur RAID1
by Frederic Dumas 31 Oct '25

31 Oct '25

Bonjour à tous sur la liste, [à tort j'ai posté vers frsag-tech(a)frsag.org. Second envoi, il y aura peut-être un doublon.] sur un serveur de fichiers Ubuntu en service depuis des années, normalement mis à jour, et où sont assemblées plusieurs grappes RAID1 logicielles, celles d'entre elles dont un des volumes physiques est un SSD, présentent une propriété surprenante: - md assemble la grappe sans incident, elle est clean; - lvm utilise cette grappe comme volume physique et active le volume logique existant; - fsck.ext4 -f ne parvient à trouver aucune corruption du système de fichiers sur le LV; On devrait donc être bons. Mais cependant; - cmp --ignore-initial=0x8100000 (pour commencer après les métadonnées RAID) /dev/sda2 /dev/sdc1 identifie des dizaines de gigaoctets divergents entre le HDD et le SSD de la même grappe. On est en RAID1, donc ça fait un peu accélérer le rythme cardiaque, est-ce une corruption massive? Comment ça pourrait reste sans conséquence dans le système de fichiers ?!? Inutile de descendre dans les valeurs SMART des disques physiques, elles n'apprennent ici rien d'utile. cmp n'est pas super adapté pour attraper une vue d'ensemble de bloc devices en centaines de giga, et hexedit aide à peine mieux. Après une exploration très partielle, il semble que: - quand un octet diverge entre les membres de la grappe RAID, c'est toujours parce que des zéros apparaissent sur l'autre disque; - le disque sur lequel apparaissent les zéros semble toujours être le SSD. L'hypothèse pour laquelle j'espère vos commentaires est celle formulée par Gemini: d'après le LLM, l'option discard/trim serait activée, et c'est elle qui est à l'origine des valeurs nulles sur le SSD. Le LLM suppose que ces divergences de données entre les deux membres de la grappe RAID1 apparaissent probablement sur tous les blocs où des fichiers ont été effacés. L'autre hypothèse est que le LLM hallucine. Avant de me lancer dans l'écriture d'un script pour confirmer l'hypothèse des seuls zéros sur le seul SSD, et explorer la grappe raid systématiquement, existe-t-il un outil plus adapté que cmp, dd, hexedit pour "survoler" un disque et visualiser des patterns ? Et si l'hypothèse de Gemini est valide, quelle est la bonne pratique pour une grappe dont l'un des membres est un SSD ? Bien vérifier partout (fstab, systemd, ?) que rien sur le système n'émet de commande ATA Trim ? Dans cette configuration, en écriture la grappe RAID1 est déjà contrainte par les performances du HDD (il est marqué en writemostly), donc on peut peut-être se passer de trim sur le SSD ? Dans l'état actuel incohérent de la grappe RAID1, même s'il n'y avait réellement aucune corruption des données utiles, en pratique on ne peut plus forcer de vérification manuelle utile avec mdadm, et ça, ce n'est pas vraiment une conséquence acceptable. Merci pour vos avis. -- Frédéric Dumas f.dumas(a)ellis.siteparc.fr -- Frédéric Dumas f.dumas(a)ellis.siteparc.fr

7 6

Quelle alternative à Salt ?
by Jonathan Leroy 21 Oct '25

21 Oct '25

Hello, (Désolé par avance pour le pâté...) Depuis des années je gère la configuration de mes serveurs grâce à Salt (SaltStack). J’aime beaucoup ses concepts (States, Pillar, Grains, templates Jinja...) qui permettent de créer une « formule » pour telle ou telle chose et de la déployer avec des paramètres différents en fonction des environnements, des hébergeurs, des clients... Mais il y a toujours eu quelques problèmes : - Pendant longtemps le moyen privilégié de déployer Salt était de déployer un « master » (serveur) auquel les « minions » (clients) se connectaient. Il y a eu un certain nombre de failles graves sur le master qui permettaient à n’importe qui d’exécuter n’importe quel code arbitrairement sur tous les minions. Alors ça peut arriver, le master est de toute façon censé être derrière un firewall, mais ça s’est reproduit quelques fois. Avec les parc à mettre à jour en catastrophe à chaque fois. Ce qui nous amène au point suivant. - Je ne sais pas où ça en est aujourd’hui, mais pendant longtemps la couverture du code par des tests était ridicule. D’où les mêmes bugs et failles qui reviennent sans arrêt. Plusieurs fois je me suis retrouvé à mettre à jour mon parc pour échapper à un bug qui n’aurait jamais dû pouvoir arriver jusqu’à une release dite stable, pour au final tomber sur un autre bug bloquant. - En 2020, VMware a racheté SaltStack, dans le but de baser dessus son produit VMware Tanzu. Comme beaucoup j’étais moyennement enthousiaste, mais après tout si ça voulait dire des développeurs payés pour bosser sur Salt, tant mieux. - En 2023, Broadcom, bien connue pour sa spécialisation dans le rachat / essorage / dépeçage / revente de boîtes de la tech rachète VMware. Les derniers anciens de la team SaltStack sont parties, les moyens semblent avoir été réduits au strict minimum et Salt est plus en maintenance qu’autre chose. Les bugs et PR n’avancent pas, certaines fonctionnalités sont cassés (notamment la gestion des configurations réseau qui est catastrophique). Bref, ça sent le début de la fin. Je ne suis pas très enthousiaste à l’idée de réécrire toutes mes formules mais j’ai bien peur qu’il faille y passer. Le problème est que la concurrence ne fait pas franchement rêver : - Puppet a été rachetée par Perforce en 2022, qui a tuée la version open-source. La communauté a crée un fork (OpenVox) qui semble vivoter. La doc redirige sur celle de Puppet. J’ai jamais été trop fan de la syntaxe Puppet. - Chef a été rachetée par Progress en 2020. Vague de licenciements dans la foulée. Changement de licence et création d’un faux fork (CINC) par des employés de Progress eux-mêmes (?) qui distribuent des binaires uniquement. Menaces à peine voilées de poursuites aux distribs qui continuent de le packager (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959981). - Ansible : semble être devenu la référence, open-source, développé par Red Hat. Pas mal d’issues et de PR ouvertes sur GitHub, mais ça ne me semble pas anormal vu le nombre d’utilisateurs. Et les tickets n’ont pas l’air d’êtres laissés à l’abandon pour le coup. Mais je n’ai jamais vraiment accroché. Contrairement à Salt qui est très organisé, Ansible me donne l’impression d’un tas de fichiers YAML jetés dans un répertoire. Il a la réputation d’être très lent. De plus, j’ai besoin de m’assurer de l’intégrité de mon système : lorsque j’execute Salt, j’ai la garantie que toutes mes formules configurées sur ce serveur seront exécutées. Je ne vois pas comment faire ça avec Ansible (j’ai survolé la doc j’avoue). - J’ai trouvé une myriade de trucs alternatifs : certains qui débutent, certains abandonnés, certains proprios... Bref, je suis preneur de vos avis, conseils, expériences avant de me lancer dans un grand chantier de réécriture... :) Je précise que j’administre uniquement de serveurs Debian. Merci -- Jonathan Leroy

15 18

Apéro Lyonnais : lundi 06 octobre 2025
by Camille Lafitte 06 Oct '25

06 Oct '25

Bonjour On se retrouve si le voulez bien ce soir. On aura l'occasion de profiter du début de l’automne et d'être ravi de ne pas faire de politique de comptoir. On peut donc continuer avec nos bonnes ou mauvaises habitudes en se retrouvant devant un verre avec toute boisson désaltérante comme une bière, une limonade, un blanc-cass, un thé. Ce soir, lundi 06/10 on se retrouve pour notre apéro mensuel. Vous êtes attendu(e)s pour un apéro lyonnais et ses environs au : Malting-Pot 263 Grande Rue de la Guillotiere, 69007 Lyon soit ce lundi 06 octobre 2025 dès 19h. Et toujours vaguement des infos sur : https://keskonfai.fr/@apero_admin_sys_auvergne_rhone_alpes http://www.agendadulibre.org/tags/araas Km

1 0

Office365 - pièce jointe
by Jeremie 06 Oct '25

06 Oct '25

Bonjour, A mon travail tous les sites de partage de fichiers sont bloqués. Nous avons à échanger avec une une autre entreprise qui est sous Office365. Quand ils nous envoient des mails, ce ne sont plus des pièces jointes, mais des liens dans le nuage de Microsoft, qui est bloqué. Vu que l'autre entreprise a vraiment besoin de nous, ils cherchent s'il y aurait une solution pour pouvoir nous envoyer de vrais pièces jointes dans les mails, et non de liens. Est-ce possible ? Si oui, comment faire ? Bien à vous, J.

5 7

Quels SSDs pour une prod-perso ?
by Nathan MALO 01 Oct '25

01 Oct '25

Hello la liste ! Premier post ici, j'en ai presque des frissons. Topic qui sort un peu du cadre pro mais je pense trouver des retex intéressants ici. Je possède aujourd'hui une prod perso basée sur la config suivante: - Dell R320 hébergé en DC par des potes - 64Go de DDR3 - Intel(R) Xeon(R) CPU E5-2430L v2 - Contrôleur de stockage Perc H310 Mini en mode JBOD - 3 Disques de 4To 7200rpm en softraid5 (1xToshiba HDWQ140, 2xToshiba HDWG440) pour le système - 1 Disque de 2To utilisé en tampon de backup (Seagate) Ce serveur héberge une trentaine de conteneurs LXC, principalement des webapps avec DBs, dont un Nextcloud qui grossit bien et une stack ELK pour la collecte de logs. Ces deux derniers font bien gratter les disques. Sur le plan CPU et RAM rien à redire, j'ai largement ce qu'il me faut. Mais en HDD, j'aimerais plus d'IOPS pour fluidifier les performances. De plus, mes backups se basent sur des snapshots LVMs pour créer les tarball master et incrémentales, ce qui ralentit fortement encore les IOs lors du backup. Et un apt upgrade c'est bien lent aussi. J'aimerais aujourd'hui remplacer mes disques plateaux par du SSD SATA. Afin de pouvoir migrer sans casser mon RAID, il me faut des disques au moins aussi gros que mes HDDs (donc 4To). Vu le prix des SSDs SATA 4To, va falloir être très gentil avec le Père Noël, et les modèles entreprise sont exclus. Avez-vous des RETEX sur la fiabilité de SSDs grand publics utilisés pour de la prod dans des serveurs de ce type ? J'ai toujours entendu du bien des Samsung (870 EVO etc) mais j'aimerais être sûr. Preneur de vos avis, pistes, trucs et astuces ! Merci de m'avoir lu ! Nathan

12 17

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

FRsAG October 2025