- FRsAG - frsag.org

Système de sauvegarde distribué, participatif et souverain.
by CARME Romain 10 Feb '26

10 Feb '26

Bonjour la liste, Avez-vous des retours sur ce produit de sauvegarde distribué, participatif et souverain ? https://www.inspeere.com/sauvegarde-de-donnees/ Cdlt,

16 58

Re: Système de sauvegarde distribué, participatif et souverain.
by Stéphane Rivière 05 Feb '26

05 Feb '26

Bonjour Pierre-Philipp, Xavier Désolé pour la réponse tardive, je ressorts mollement d'une grippe intéressante, la dernière datait de 2016. Il en faut de temps en temps pour maj le SI :) >>> Perso je suis un fan de DRBD et ils ont un module pour les longues >>> distances https://linbit.com/disaster-recovery/ >> Cette option ne semble pas libre, mais c'est intéressant :) > je sais pas si DR est libre ou pas, ce serait dommage car DRBD > lui-meme est bien libre. https://github.com/LINBIT/drbd Linbit a toujours eu un mal de chien à monétiser son travail. DRDB est libre mais tout ce qui tourne autour ne l'est pas... trop. >> J'avais des résultats allant de spectaculaires à plantés (sans >> vraiment comprendre parfois). Bon en local ça marche, mais de DC à >> DC... J'ai trituré toutes les options possibles pour voir, testé DRDB >> 8 et 9 (à l'époque, je ne sais plus où ils en sont). Je dois être >> moins doué qu'AWS ;>>> > > moi j'ai des bon resultats en terme de perf et je pense que j'ecrase > Ceph RBD assez facilement. ce serait normal d'ailleurs, car il n'y a > aucun overhead (pas de hash table ou d'algo de distribution, juste des > configs qui point vers des paires de noeuds variees). en plus c'est > ideal pour un cluster convergent, c'est meme fait pour, alors qu'avec > Ceph RBD faut quand meme se poser la question de savoir si les noeuds > supporteront la double charge (virtu + stockage). Bon et puis CephFS > il n'y a pas le choix, c'est force'ment un autre cluster de'die', mais > c'est un autre cas d'usage. CEPH n'est pas KISS. Ce simple fait suffit à ne pas aller plus loin pour moi. DRDB est KISS, mais... > je joue beaucoup avec. Je fais des cluster XEN et utilisais LVM2 et > maintenant OpenZFS zvol **sous** les resources DRBD. il faut noter > que DRBD v8 inclus dans le noyau nunux fait simplement des mirrors, > alors que DRBD v9 sait aussi faire du diskless, donc un noeud qui n'a > pas de mirroir local peut aussi voir les volumes. Oui. J'ai testé les deux. DRDB9 a plus de possibilités, comme d'avoir n miroirs (1 master 2 slaves, ça peut être bien). Pas testé avec ZFS, je croyais même que ZFS et DRDB étaient incompatibles... > J'ai aussi fait des tests avec les snapshots, c-a-d qu'on peut faire > des templates sur des vdisk normaux (des resources DRBD quoi) et puis > des snapshots soit LVM2 soit ZFS pour obtenir des instances base'es > sur ces vdisks. C'est funky et pas pret pour la prod j'en conviens, > mais bon dans mes PoCs pour l'instant cela marche. J'ai parle' de mes > peurs concernant LVM2 ici: > https://www.youtube.com/watch?v=gUnFc99VfTo&list=PLQMQQsKgvLntZiKoELFs22Mtk… > Ta vidéo est très intéressante et reflète mes propres recherches. Toutefois j'ai appris des trucs aussi, merci ! La salle est très sympa mais il est choquant de voir qu'il y a si peu de gens à t'écouter (i.e à se poser les bonnes questions, même non conventionnelles). J'ai la même impression concernant un langage que je promeus depuis longtemps, Ada. > J'ai pouss'e le vice jusqu'`a tenter la convergence re'seau en plus de > la convergence XEN + DRBD: > https://pub.nethence.com/network/fuck-martinez-part4 Ouah, son site, on dirait (presque) du gopher :> En pratique ? Pour nos use cases ? mmm... Mais j'ai gardé les liens :) >> Comme j'ai pas trouvé d'équivalent sous Linux (dans mon use-case), je >> rêvais à me mettre à FreeBSD/ZFS qui semble avoir ce qu'il faut >> nativement, lui. Mais, une seule vie, pas assez de temps :) > > ah non c'est l'inverse. FreeBSD HAST n'est probablement pas capable > de faire du dual-primaries, ce qui est absolument ne'cessaire lors de > la live-migration d'une instance XEN d'un noeud `a l'autre, ne > serait-ce que pendant une micro-seconde. Je n'ai jamais essaye' HAST > et cela reste `a faire (si un jour vous vous ennuyez, on pourrait > faire cela ensemble en visio). Quant `a ZFS c'est juste un > gestionnaire de volume + filesystem, pas un outils de stockage > distribue' en soit. Ceux qui s'en servent comme cela jouent sur la > fonction re'seau mais il n'y a qu'un seul controlleur, c'est le > client. Un peu comme du RAID ge're' avec un seul controlleur. Avec > DRBD et HAST c'est deux tetes, deux controlleurs. Et en plus > duellement actif avec DRBD si besoin. De la magie pure ! Je n'ai pas été jusque là. Jamais utilisé ZFS, par manque de temps (je suis curieux par défaut) et pragmatisme puisque Xen + GNU/Linux Debian + mdadm + lvm2 forment une stack avec une stabilité qui s'oublie, donc pas cherché plus loin. Ce que je voulais faire, c'était de la migration à chaud. Dans un process automatique, éventuellement avec une prise de décision automatique (ce dernier point étant débattable, je me méfie comme de la peste des "automatismes de décision" fondés sur des conditions). Après plein d'essais, allant de magie noire (quand ça marche, c'est beau) à la migration avortée, jusqu'à la destruction instantanée et inexplicable du volume LVM (et... non ! je ne m'étais pas emmêlé les scripts dans les primaires/secondaires), j'ai enfin admis que c'était overkilled par rapport aux besoins de l'infra. Nos clients peuvent supporter une coupure de quelques minutes (transfert de la VM, maj IPFO, maj routage+FW du node, maj IP de l'instance - pointopoint). Je n'ai pas pu, en boucle, faire tourner ça des dizaines de fois, sans que ça foire à un moment, donc useless pour moi. C'était peut-être le réseau, mais bon, le vrack OVH, ça marche. La lecture attentive des sources de DRDB m'a un peu achevé. C'est comme regarder les sources ISDN (RNIS/numeris) d'Asterisk (expérience d'il y a 15 ans). En regardant le tas de spaghetti, les rustines, toussa, on soupire et on comprend mieux pourquoi c'est chaud et pourquoi la peinture ne sera jamais sèche ; il faudrait tout réécrire. Rien que le bidule à base de volaile (COQ) pour aller faire correspondre la version des sources avec la version du noyau était une horreur. Finalement, j'allais me servir dans les dépôts Proxmox. Au moins, eux, ils avaient la bonne réponse ;) Mais si tu me dis que tu y es arrivé, de façon systématique et récurrente, sans aucune erreur, dans un vrai réseau (pas un lab, en lab ça marche), c'est que j'ai loupé une marche, ce qui est très possible :) -- Stéphane Rivière Ile d'Oléron - France

2 2

Apéro Lyonnais : quel premier lundi de 2026 ?
by Camille Lafitte 02 Feb '26

02 Feb '26

Bonjour Pour janvier, nous avions fait l'impasse pour cause de début d'année et puis l'excuse ou pas du Dry January :) Pour février, nous ne ferons pas d'apéro non plus. La majeure partie des habitué(e)s préfère la couette et un bonne dose de médicament en guise de nourriture... On se retrouvera si le voulez bien le mois prochain, en mars. En attendant pensez à vous couvrir, rester au chaud, ... Et toujours vaguement des infos sur : https://keskonfai.fr/@apero_admin_sys_auvergne_rhone_alpes http://www.agendadulibre.org/tags/araas Km

1 0

syncthing
by Pascal PETIT 28 Jan '26

28 Jan '26

Bonjour, Le mercredi 28 janvier 2026 (17:30), JM par FRsAG écrivait : > > Cet outil a peut-être déjà été cité dans le fil ? Je pense à https://syncthing.net/ > Cet outil peut-il être lancé en tant que service ou faut-il qu'il soit lancé dans le cadre d'une session utilisateur ? J'ai regardé rapidement la documentation et je n'ai pas trouvé de réponse à ma question. cordialement -- Pascal Petit sur Tchap, la messagerie sécurisée de l'état: @pascal.petit-univ-evry.fr:agent.education.tchap.gouv.fr cf https://www.tchap.gouv.fr/ Les courriers qui seraient envoyés en dehors de vos jours et heures de travail ne nécessitent pas de réponses en dehors de vos jours et heures de travail.

3 2

Les namespaces IMAP de Dovecot
by Artur 28 Jan '26

28 Jan '26

Hello ! Je refais une config propre de Dovecot et je personnalise les namespaces dans IMAP. Aujourd'hui une config un peu standard c'est namespace inbox { separator = / inbox = yes mailbox Drafts { special_use = \Drafts auto = subscribe } mailbox Junk { special_use = \Junk auto = subscribe } mailbox Sent { special_use = \Sent auto = subscribe } mailbox Trash { special_use = \Trash auto = subscribe } } Mais je me rappelle qu'il y a quelques années en arrière des clients mail comme Outlook en français n'avaient pas l'air de tenir compte de certains dossiers spéciaux comme 'Sent' par exemple. Un dossier 'Éléments envoyés' était créé par Outlook en parallèle du dossier existant 'Sent' qui n'était alors pas utilisé par Outlook. Ça posait problème car si on utilisait en parallèle Outlook et Thunderbird, par exemple, on avait 2 dossiers pour les courriels envoyés en parallèle. Du coup, le question est assez simple, est-ce que cette situation perdure aujourd'hui ? Et si oui, comment personnaliser les namespaces pour en tenir compte pour la langue française (Outlook en français au hasard). -- Cordialement, Artur

2 3

Re: sysgit versionning config serveur
by Xavier Beaudouin 14 Jan '26

14 Jan '26

Hello David (et la liste) > Le 13 janv. 2026 à 20:00, David M par FRsAG <frsag(a)frsag.org> a écrit : > > Bonjour à tous, > > > Ne trouvant pas chaussure exact pour mon pied <https://forum.chatons.org/t/chercher-outil-versionning-config-serveur/1508> j’'ai fini par m’en faire un : David / sysgit · GitLab <https://framagit.org/kepon/sysgit> Si vous cherchez un outil type etckeeper mais qui ne se limite pas à /etc… > Très intéressant. Je vais tâcher de faire un port FreeBSD, ça pourrait être également intéressant :) Xavier -- Xavier BEAUDOUIN SiamNok Ltd - Smart Solutions for Koh Samui https://siamnok.co.th/ X: @SiamNokCoTh

1 0

Re: sysgit versionning config serveur
by Daniel Caillibaud 13 Jan '26

13 Jan '26

Le 13/01/26 à 14:00+0100, David M par FRsAG <frsag(a)frsag.org> a écrit : > Si vous aimez etckeeper mais que vous voulez versionner /tout/ ce qui > compte sur un serveur (pas juste |/etc|), sysgit est une alternative > légère et pratique. J'ajouterais "pas juste un serveur" ;-) Je vais l'adopter pour mon desktop, pour tracer les rares trucs que je modifie dans /etc ou dans un ~/**/*rc quelconque, puis que je mets des heures à retrouver qq années plus tard quand un truc marche plus, suite à une montée de version de debian par ex. > C’est par ici : David / sysgit · GitLab <https://framagit.org/kepon/sysgit> Merci David ! -- Daniel L’art du prince consiste à faire le bien par lui-même et le mal par les intermédiaires. Machiavel

1 0

Capturer un ndm
by Dge 28 Dec '25

28 Dec '25

Bonjour, J'aimerais récupérer un nom de domaine qui est expiré (donc pas encore renouvelé). On m'a parlé de Namejet qui permet de le récupérer à la seconde où il tombe dans le domaine public, il y a d'autres stratégies (autre que celle de demander au proprio. actuel) ou d'autres sites ? Merci d'avance et bonnes fêtes. -- @++

2 1

[MISC] Des hébergeurs "S3 glacier" certifiés HDS ?
by DUVERGIER Claude 09 Dec '25

09 Dec '25

Bonjour la liste, Je cherche un hébergeur de données pour du long terme (type S3 glacier) qui soit certifié HDS (Hébergeurs de Données de Santé), idéalement français/européen. J'ai survolé la liste des hébergeurs certifiés [1] pour trouver ce qui suit (elle manque d'un petit filtre sur le type de service : compute, storage, etc.) : * AWS * OVH "Cold Archive" : ça fait un deuxième candidat * clever cloud "Cellar" : n'a pas de classe/tarif pour le long terme * Scaleway "Glacier" : ce service là de Scaleway n'est pas HDS [2]: > Glacier class is not HDS-compliant and must not be used by the client > to store healthcare data. Auriez-vous d'autres noms à conseiller ? [1]: https://esante.gouv.fr/offres-services/hds/liste-des-herbergeurs-certifies [2]: https://www.scaleway.com/en/docs/object-storage/reference-content/storage-s…. -- DUVERGIER Claude

2 1

Apéro Lyonnais : lundi 01 décembre 2025
by Camille Lafitte 01 Dec '25

01 Dec '25

Bonjour On se retrouve si le voulez bien ce soir. On clôturera la fin d'année en bravant froid et cie. Merci chocolat chaud, grog et gaufre. Désolé la neige n'est pas au rendez vous, mais est ce si grave que ça ? Et c'est l’occasion de prendre de l'avance sur le January dry pour celles et ceux qui veulent. Ce soir, lundi 01/12 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 01 décembre 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