Gilles Chehade a écrit 36 commentaires

Merci pour cette belle découverte et le travail derrière !

merci <3

Quelle volumétrie peut-t-on adresser avec planka/ptar ?

En terme de volumétrie, la limite théorique pour plakar et ptar est aux alentours de 18EB, même si je pense que d'autres problèmes se poseront avant, il faut que quelqu'un teste :-)

En pratique, on teste jusqu'à du multi-TB, au dessus ça devient compliqué pour nous, mais considérant notre architecture logicielle, il n'y théoriquement rien qui permet de monter beaucoup plus haut..

Comment se comporte le format .ptar à l'ajout de fichier ? Le fichier est massivement modifié ? (Je pense notamment à de la synchro via syncthing par exemple)

Le format .ptar ne supporte pas l'ajout de fichier, il est immutable une fois crée: il s'agit en réalité d'un repo qui a été sérialisé et figé en lecture seule, toute modification produit des erreurs de sommes de contrôle.

Aujourd'hui, l'ajout d'un fichier revient à recréer un nouveau .ptar en utilisant en source un ancien .ptar en mode synchro et le nouveau fichier, avec du coup une réécriture complète. Techniquement, il est possible d'écrire une version un peu différente de l'outil qui sache faire cet ajout de manière un peu plus efficace, mais ce n'est pas le cas présentement.

Le nombre de snapshots est limité ou peut poser problème au delà d'un certain usage ?

Il n'est pas limité et j'ai monté le test à plusieurs dizaines de milliers en ce qui me concerne. Cela n'a aucune incidence sur la création de backup, la restoration et/ou la manipulation/navigation d'un snapshot en particulier.

Le seul problème est sur des fonctionnalités à la marge type "chercher un fichier dans l'intégralité des snapshots" ou "afficher une timeline de tous les snapshots qui possèdent un répertoire" parce qu'il n'y a pas de secret: il faut les ouvrir et ça sera lent.

Il y a un peu de cache là où c'est possible mais sachant que les repo plakar sont "stateless", il n'y a pas de base de donnée pour s'abstraire d'un serveur et pour limiter les pré-requis sur un nouveau poste, donc on est en environnement assez contraint.

Comment le projet plakar se positionne par rapport à borgbackup ou https://dvc.org/ par exemple ? (le format .ptar semble à première vue un gros avantage à mes yeux pour le partage/transfert et peut-être plus "léger" qu'avoir toute une arborescence à synchroniser)

Pas certain de comprendre la question du positionnement, désolé.

Le format .ptar a pour objectif de remplacer le format "repo" ?

Non, pas du tout, il s'agit vraiment du même format mais sous une forme transportable, les deux ont vocation a vivre en parallèle pour des usages différents, sachant que les améliorations apportés à l'un bénéficient à l'autre :-)

Est-t-il prévu d'intégrer un code correcteur d'erreur ? (je pense notamment à des backups sur clé usb plus ou moins fiables …) (oui, oui, 3-2-1-0)

Long débat, on n'est pas encore convaincu de l'utilité:

Les ECC ne permettent de corriger qu'un taux marginal d'erreur pour un overhead qui est significatif… si l'on considère qu'un second dépôt offre une correction totale.

On s'est réservé la marge nécessaire pour pouvoir ajouter si on change d'avis, pour l'instant la conviction est que c'est usine à gaz pour pas grand chose: le seul projet à le supporter à notre connaissance est kopia, en expérimental depuis très longtemps, et ça a plus l'air d'être fait pour dire "on le fait" que par bénéfice réel.

J'aime beaucoup l'ui intégrée également ! (ce que borg ne propose pas de mémoire)

Merci <3

au contraire, cette solution va tout exploser :-p

On ne visait pas ces certifications mais pourquoi pas

haha, crédible néanmoins:

$ kapsule ls -f test.ptar           
2025-06-02T19:43:53Z   ed0f6603    3.1 MB        0s /private/etc

$ kapsule ls -f test.ptar ed:ssl
2025-02-04T16:57:51Z -rw-r--r--     root    wheel   334 kB cert.pem
2025-02-04T16:57:51Z drwxr-xr-x     root    wheel     64 B certs
2025-02-04T16:57:51Z -rw-r--r--     root    wheel    745 B openssl.cnf
2025-02-04T16:57:51Z -rw-r--r--     root    wheel   1.0 kB x509v3.cnf

on a monté une boite et on bosse 100% sur plakar et liés, donc ça fait partie de notre taff de faire ce genre de choses en 10 jours :-p

Je prends notes pour le père noël :-p

Hier, j'ai commencé à écrire kapsule un outil spécifique à .ptar, j'espère avoir quelque chose de publiable dans les dix jours :-p

Oui, les trois projets ont beaucoup de similitudes sur leur fonctionnement (repository de données, snapshot d'un delta avec un algo de CDC, …) mais des approches différentes pour résoudre le problème des sauvegardes et des philosophies différentes sur comment les utilisateurs voient les sauvegardes.

Je peux répondre à toutes vos questions là dessus :-)

Oui il y a quelques similitudes mais dans notre approche le format est verrouillé une fois crée, il n'y a plus d'append possible, l'archive est considérée comme "altérée" et corrompue en cas de modifications.

Pour produire un comportement à la zpaq, en ajout de donnée, il faut prendre en entrée un autre .ptar + le contenu à ajouter pour générer une nouvelle archive:

$ plakar ptar -o nouveau.ptar -k ancien.ptar /chemin/vers/les/donnees/a/ajouter

Hello, auteur de ptar ici.

Je ne connaissais pas Zed, je vais regarder ca pour voir s’il y a un écart a combler en terme de fonctionnalités, mais je pense qu’on est déjà pas mal pratique :-)

Notre code est publie sous license ISC histoire de garantir que le format reste ouvert, je vais publier dans quelques jours une documentation du format pour permettre a quiconque d’écrire sa propre implementation.

Merci pour le partage et le commentaire :-)

Salut,

C'est tout à fait ça :-)

Du coup je pose ca la ? :-)

Mettre en place un serveur de mail avec OpenSMTPD, Dovecot et Rspamd

Je pense que c'est un bon choix.

Gilles (@opensmtpd.org 😁)

Ne t'attaches pas aux 10%, le but n'était pas de faire un benchmark: aujourd'hui le gros stress-test était sur une VM très costaude avec une TONNE de code de debug et de traces, hier c'était sur mon laptop core-i7 avec un peu moins de debug, demain ce sera sur un serveur low-cost de deditruc ou ovmachin, on lance les tests sur des setups différents en fonction des jours, de l'humeur, du lag sur notre connexion, etc…

Ce que je voulais illustrer c'est que malgré une petite taille, il ne faut pas se dire que c'est un mini MTA qui ne sait gérer qu'une poignée de clients dans des petits setups, on s'en sert en vrai dans des setups où c'est sollicité de manière bien plus large que la majeure partie des gens qui l'installeront, aussi bien en émission qu'en réception.

Des gens l'utilisent quotidiennement sur des raspberry, des serveurs cheap et des vieilles machines recyclees, je ne sais pas si elles peuvent gérer efficacement 2k clients, mais à priori je dirais qu'elles ne le feraient pas plus mal qu'un MTA concurrent ;-)

Pas de statistiques/benchmarks non, par contre je peux te donner quelques petits chiffres non officiels ;-)

J'utilise OpenSMTPD en routeur d'envoi en production depuis plus de 2 ans pour router quelques millions de mails par jour vers internet. Dans ces volumes, il n'y a aucun problème de charge, tu tapes les limites artificielles pour ne pas blaster les serveurs en face bien avant de taper une limite du soft en lui meme. Je ne saurais pas dire à quelle charge on satures parceque ca demande un volume d'envoi que je n'ai pas à disposition, seul un spammer ou un ISP pourrait nous renseigner là dessus je pense :-)

Sur nos campagnes de stress-test twitter, sur une release stable, on encaisse tranquillement 2k sessions concurrentes en flux continu qui balancent des messages un peu aléatoires. La limite des 2k est artificielle, si on configurait notre VM pour mettre à disposition davantage de descripteurs de fichier, le logiciel prendrait davantage de sessions concurrentes, un de ces jours je ferais le test mais vu qu'on scale linéairement à priori et qu'on est à 10% de temps CPU pour le process sur 2k sessions super actives, je pense que même en dégradant non-linéairement on devrait pouvoir encaisser 4k/5k de connexions concurrentes super actives tranquillou.

En gros, c'est plus que suffisant pour 90% des gens, pour les 10% restant on est juste dans l'incertitude :-)

Ca désigne surtout les 3 premiers points, le dernier étant plutôt délégué au MDA.

Pas de souci, l'exemple reste correct.
Pour eviter les betises, le comportement par defaut est de considerer que toute omission signifie un comportement local par default:

accept for any relay == accept from local for any relay

et

accept from any == accept from any for local

pour obtenir un open-relay il faut explicitement le demander:

accept from any for any relay

Horreur ! J'ai l'outrecuidance d'avoir un nom de domaine et un nom d'utilisateur trop longs, et ça ne respecte pas la RFC!

Sur les derniers snapshots, la taille acceptée par OpenSMTPD pour les user et domain parts a été augmentée, du coup ton problème est temporaire et il deviendra du passé dans un futur pas trop lointain ;-)

Yop,

Je n'utilises pas spamassassin mais si tu peux le configurer en mode proxy, comme un clamavd ou un dkimproxy, tu peux le faire simplement.
Tu fais tourner ton proxy spamassassin sur le port 80826 et tu le fais relayer vers le port 80825, ensuite tu configures OpenSMTPD comme suit:

listen on all
listen on 127.0.0.1 port 80825 tag SPAMASSASSIN

accept tagged SPAMASSASSIN for domain example.com deliver to maildir
accept from any for domain example.com relay via smtp://127.0.0.1:80826

Une envelope provenant de la première interface n'est pas tagguée, elle ne matche pas la première règle accept. Elle se retrouve relayée vers ton proxy spamassassin qui la réinjecte dans ta deuxième interface qui elle applique un tag sur chaque enveloppes ce qui les fait matcher la première règle.

Il y a peut-être d'autres solutions, mais celle ci est celle que j'utilise pour dkim-proxy et elle marche plutôt bien :-)

Eric Faurot à mis ses slides en ligne:

https://poolp.org/~eric/asiabsdcon2013-smtpd/

Oui, ça peut faire du load-balancing IP sortant et ça peut faire correspondre un HELO-name.

listen on all
table addrs { x.x.x.x, y.y.y.y }
table names { x.x.x.x = "mx1", y.y.y.y = "mx2" }

accept for any relay source <addrs> helo <names>

Ici les tables sont statiques, mais si elles utilisaient une source différente (sql, db, fichier, ldap, …) il deviendrait alors possible de les modifier en runtime.

Et bien, on est loin derrière Postfix: on a pas encore …

On a pris le parti de ne pas faire de modification du contenu depuis le daemon: le rewrite de contenu, d'en-têtes, ou encore de sender/recipient sur l'enveloppe sera fait depuis un filtre… mais le support des filtres est prévu pour la release stable 5.4 (et dans les snapshots !stable à venir).

Les filtres pourront traiter les mails entrants / sortants différemment, ils sauront si un utilisateur est authentifié et ils devraient être plutôt simples à utiliser ET à écrire. En fait, je peux d'ores et déjà le dire parce que le code est en grande partie déjà écrit et juste désactivé ;)

Petite question, dans la forme from any for domain alias : si je n’ai que cette directive, que l’utilisateur demandé n’est pas listé dans les aliases mais existe localement, le mail est-il transféré à l’utilisateur local ou rejeté ?

Il sera transféré a l'utilisateur local, les aliases sont optionnels.

Même question en remplaçant alias par virtual.

Il sera rejeté, le mapping contient la liste exhaustive des utilisateurs du domaine virtuel.

De plus, l’articulation entre alias et deliver to ne me semble pas totalement claire : si j’ai un alias de type foo: bar@otherdomain.com dans une règle for … to … deliver to maildir, que fera OpenSTMPD quand il recevra un mail à destination de foo ? De même, entre deliver to maildir et ~/.forward, qui a la priorité ?

En fait, "deliver to" spécifie le comportement par défaut de la règle.
Un alias ou un ~/.forward peut spécifier une méthode différente: adresse pour relai, fichier ou exécution d'un mda alternatif.

Attention, la page en question date de Juin 2012.

La fonctionnalité à été ajoutée fin 2012:

listen on all
table myusers "/etc/mail/myusers" # ou .db, ou sqlite/ldap (experimental)

accept from any for domain example.org userbase <myusers> deliver to maildir

Le projet est très documenté, mais uniquement par le biais de ses pages de manuel.
Il va falloir attendre un peu avant que la documentation en ligne s'étoffe ;-)

Postfix est assez simple oui, la configuration reste assez différente dans l'esprit.

Dans OpenSMTPD, elle se divise en 4 parties:

• Les interfaces d'écoute avec leurs options (local ? ssl ? auth ?);
• les options (temps d'expiration d'une enveloppe dans la queue, …);
• les tables de lookup utilisées pour à peu près tout (aliases, virtual, auth, …);
• le ruleset qui défini les règles que doivent respecter les enveloppes pour être acceptées;

On peut avoir des setups très simples, clairs et qui se lisent "presque" humainement:

listen on all

accept from any for domain example.org deliver to maildir
accept from local for any relay

ou encore:

listen on all
table mesdomaines { example.org, example.com }

accept from any for domain <mesdomaines> deliver to maildir
accept from local for any relay

qui a priori se passent d'explications :-)

Y a pas de mal, et de rien ! :-)