- FRsAG - frsag.org

Recherche support NextCloud
by SIMANCAS Hugo [Humans Connexion] 04 Nov '25

04 Nov '25

Bonjour, Nous avons une instance pour un client avec plusieurs utilisateurs. Leur principale utilisation est de la synchro de fichiers avec de l'ouverture de fichier en local sur les PCs. Les PCs sont en Windows 11 Pro (antivirus débrayé au minimum pour les tests) NextCloud server : 32.0.1 Client NC : Dernière version Reverse Proxy Le problème est que par moment, la synchronisation se bloque sans avertissement. Le déblocage se fait en relançant le client NC ou en faisant pause + resume sur la synchro. Avez vous une idée ? Est ce que quelqu'un aurait une belle expertise ou un lien avec le support ? Merci Hugo

2 1

Discard/trim sur RAID1
by Frederic Dumas 03 Nov '25

03 Nov '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 7

Apéro Lyonnais : lundi 03 novembre 2025
by Camille Lafitte 03 Nov '25

03 Nov '25

Bonjour On se retrouve si le voulez bien ce soir. On bravera le début de l'hiver avec une bière ou une limonade bien fraîche, voir un chocolat chaud. On continue avec nos bonnes ou mauvaises habitudes en se retrouvant devant un verre avec toute boisson désaltérante. Ce soir, lundi 03/11 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 03 novembre 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

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

Recherche d'un job d'administrateur système / ingénieur système
by Jeremy Tomasi 29 Sep '25

29 Sep '25

Bonjour à tous, Suite à la fin de mon Master Réseaux et Télécommunications que j'ai obtenu à l'université Savoie Mont Blanc, je suis à la recherche d'un emploi en tant qu'administrateur système ou en tant qu'ingénieur système. Je recherche cet emploi dans la partie nord de la France (Hauts-de-France, Grand Est, Normandie, ...). Je joins également mon CV si jamais et je suis disponible par téléphone ou par mail. Cordialement, Jérémy Tomasi

1 0

ansible avec structure non-orthodoxe des dossiers
by Pierre-Philipp Braun 28 Sep '25

28 Sep '25

Salut, j'ai deux problèmes différents avec Ansible, donc je fais deux threads séparés. je suis de la veille école et utilise vi, et non pas vscode. donc la hiérarchie standard des roles Ansible (roles/x/tasks), en divisant un playbook en multiples petits fichiers ne me convient pas. moi j'aime bien avoir un gros playbook avec tasks + handlers dans un seul fichier. disons playbook "old-school ci-après. c'est ce que je faisais jusqu'à présent *1 mais j'arrive aux limites de ce schéma, car dans les pipelines CI/CD je dois faire une multitude de conditions afin de lancer tel ou tel playbook old-school depuis le script ci/cd. donc j'ai exploré un peu comment faire de beaux playbooks inclusifs avec: - include_tasks - import_tasks - roles: // include_role bah le résultat n'est pas fameux. avec include_tasks et import_tasks, cela bloque évidemment à `handlers:` puisque ce n'est pas une tâche. Et avec include_role + `from_tasks: ../old-school-role/tasks-old-school-role.yml`, comme tentative d'éviter la hiérarchie de répertoire standard des roles, j'obtiens cela: ERROR! Failed loading '[...]/dehydrated/tasks/../tasks-dehydrated.yml' for role (../dehydrated) as it is not inside the expected role path: '[...]/dehydrated/tasks' voila, je suis donc résigné et n'ai pas le choix. je vais devoir faire comme tout le monde, accepter la modernité et utiliser la hiérarchie standard des roles Ansible. si toutefois vous avez une idée de comment détourner Ansible pour garder une structure de dossier non-orthodoxe, tout en bénéficiant des playbooks inclusifs (pas de blagues svp, aucun rapport), faites moi signe... -- Pierre-Philipp Braun

3 2

ansible one-shot vs routines de maintenances avec structure standard
by Pierre-Philipp Braun 28 Sep '25

28 Sep '25

Yop, je vais probablement devoir passer à la hiérarchie standard des roles Ansible, mais je veux absolument continuer à séparer les one-shot des routines de maintenance, comme Nicolas @work (vu dans le thread alternatives à Salt) pour éviter les pipelines interminables, les crises de nerfs et la perte de cheveux causé par l'automatisation. En principe c'est sensé nous faciliter vie de sysadmin/devops, pas nous la rendre insupportable. Je refuse d'attendre 30 minutes parce que le playbook at 10 000 choses en trop qui sont pas dutout en rapport avec le schmilblick. je prévois donc de faire ainsi dans le script de CI/CD: 1. si je détecte un nouveau noeud dans l'inventaire, one-shoot (install+config) 2. si je détecte le changement d'un rôle, j'applique à tous les noeuds concernés par ce rôle et pour cela, pointer sur des playbook différents: pour 1. une simple liste de rôles à l'aide de `roles:`, avec des `main.yml` qui incluent install+config pour 2. une liste personnalisée à l'aide de `tasks: include_role` + `from_task: setup.yml` afin de l'actionner que la routine de maintenance. c'est le plan. une idée, tout va bien ou je raconte des bêtises ? je suis pas le seul dans ce cas de figure je suppose. -- Pierre-Philipp Braun

1 0