site web forum documentation

On sera en vacances en Picardie avec @nicolas du 4 au 15 août et je me disais que ça pourrait être l’occasion de plancher sur ce projet que je trouve toujours aussi séduisant.

J’ai envie de réfléchir à comment intégrer d’autres membres dans la création de ce service. C’est pas évidement car il y a une grosse partie technique. Mais je pense qu’il y a aussi d’autres aspects plus accueillants. Par exemple en faisant des retours utilisateurice (bug, incompréhension, suggestions), mais aussi dans les choix de design de ce service (nomenclatures, fonctionnements, etc…).
Ça pourrait être l’occasion de découvrir un peu la CLI et en apprendre plus sur le fonctionnement du serveur.

Pour mettre ça en place concrètement, je me dis qu’on pourrait caler des réunion en visio de temps en temps, voir faire du partage d’écran lorsque l’on bosse dessus pour permettre aux gens de passer dire coucou.
C’est une idée dont on a déjà parlé et qu’on à aussi testée l’autre jour avec @malinlevaud . Et ça rentre dans la famille « visibiliser le travail technique » qui est fait sur le serveur.

19 jours plus tard

Avec @nicolas , on est arrivé à ces parti-pris de design :

  1. une newsletter par compte CLUB1, qui serait envoyée forcément depuis l’adresse USER@club1.fr
  2. fonctionnelle par défaut. C’est déjà activé : pas besoin de contacter un·e admin, ni de faire des installations. Il n’y a plus qu’à personnaliser les textes (pied de page, etc…)

Le premier point permet le second : Si on autorise plusieurs adresses, ça demanderait des mises en places plus compliqués. Ici on s’est dit qu’il valait mieux prioriser la simplicité de mise en place et ainsi la spontanéité plutôt que les cas complexes et plus rares.

Aussi, on a l’impression que la plupart des personnes utilisateur·ice·s de CLUB1 ont déjà plusieurs compte par activités (compte perso, pro et collectifs), ce qui permet d’avoir des newsletters par domaines.

On souhaite également que cet outil soit utilisable par d’autres serveurs ayant une configuration proche du notre.

Implémentation technique

Comme prévu, on tire partit des sous-adresses :
Chaque membre se voit attribué trois sous-adresses par défaut:

  • +subscribe pour l’inscription à la newsletter
  • +unsubscribe pour la désinscription
  • +confirm pour la confirmation d’inscription

Il est toujours possible de les écraser via les fichiers .forward.

On utilise l’option de Postfix mailbox_transport_maps pour intercepter ces trois sous adresse et les rediriger vers le script de gestion de la newsletter.

La configuration et le stockage des adresses email se fait dans un dossier définit par défaut dans chaque espace personnel des membres.
Ce dossier pourrait être créé lors de la création du compte, grâce au skeleton.

15 jours plus tard
5 mois plus tard

Je me suis replongé sur ce petit programme.

Modifications :

  • utilisation du dossier ~/.config/newsletter pour la configuration.
  • utilisation d’un fichier JSON pour les quelques métadonnées. (le titre de la newsletter et le nom d’affichage dans le from)

Pour info, toutes les modifications son dans une nouvelle branche du repo multi-user-newsletter :
https://github.com/club-1/newsletter/tree/multi-user-newsletter

Les questions que je me pose :

  1. C’est pas hyper intéressant ces trois fichiers dans le Home que sont .forward+subscribe, .forward+confirm et .forward+unsubscribe vu qu’ils ne contiennent aucun paramètre personnalisable. Est ce que ça ne pourrait pas être des mot clefs de « plus adresses » réservés au niveau du serveur et donc bloqués à cet usage ? Je ne suis pas sûr que ça soit faisable techniquement. Mais bon au pire c’est pas si grave non plus.
  2. Est ce que c’est pas chelou ce fichier JSON pour deux métadonnées au milieu d’autres fichiers. J’ai pas mis la signature là dedans en me disant que ça pouvait être à plusieurs lignes et donc que ça serait plus sympa de pouvoir éditer dans un éditeur de texte.
  3. Est ce qu’on mettrait pas des extensions .txt après le fichier email ou le fichier signature pour que ça aide les personnes moins à l’aise avec la technique ?

Une autre idée pour dé-dupliquer les options passées en CLI serait d’utiliser :include: dans les fichiers .forward+..., et d’avoir un seul fichier avec la commande et toutes ses options.

Par contre ça demande de changer un poil la config de postfix: https://www.postfix.org/postconf.5.html#allow_mail_to_commands

Mais en vrai je trouve vraiment pas ça un problème de recopier les options de LCI dans 3 fichiers, surtout qu’ils pourront avoir exactement le même contenu et qu’il suffit de les copier coller.

24 jours plus tard

yo !
je suis également très intéressé par le fait d’avoir une newsletter pour mon blog.

j’ai regardé le code sur le repo et la branche multi-user-newsletter, et après la lecture de ce sujet du forum, j’ai quelques retours :

pour moi ça ne pose pas de problème d’avoir trois fichiers .forward+... avec quasi la même ligne, d’autant plus qu’ils sont courts donc faciles à créer

actuellement les fichiers sont nommés emails et signature.txt dans le dossier de config, ça me semble ok, il faut juste indiquer signature.txt et non signature dans le README.md

le code semble ok pour les newsletter de chaque compte. quant à la newsletter globale de Club1, je suppose que c’est compatible en créant des .forward personnalisés ? à moins que la newsletter globale passe également à un fonctionnement en nouvelles+..., ce qui serait plus facile à gérer

nl.sh ligne 110 : il faudrait ajouter une vérification de l’existence de signature.txt avant de le cat

et pour settings.json, c’est un format de fichier pratique, facile à gérer en code avec la commande jq, et flexible si on décide d’ajouter de nouvelles options à l’avenir.

pour finir, je suis volontaire pour tester et rédiger la doc !

merci pour ce petit projet sympa, concret et utile !

EDIT : est-ce qu’on ajouterai pas juste une ligne de code pour forcer l’envoi de la newsletter à $USER@club1.fr en supplément des abonné’es ? ça permet juste une confirmation d’envoi qui serait bien pratique haha.

    Hey trop cool que ça te parles ! Franchement je pense qu’il ne reste plus grand chose à régler pour que ça marche.

    Aussi je me dis qu’il faut pas non plus trop se stresser de partir sur une façon de configurer. Ça sera facile d’accompagner le changement vu que c’est du logiciel pour de l’interne club1.

    Jirsad Cassam actuellement les fichiers sont nommés emails et signature.txt dans le dossier de config, ça me semble ok, il faut juste indiquer signature.txt et non signature dans le README.md

    Yes ok ! bah letzgo pour le .txt.

    Jirsad Cassam nl.sh ligne 110 : il faudrait ajouter une vérification de l’existence de signature.txt avant de le cat

    Ok je note ! Si as la déter, n’hésites pas à faire de la Pull Request ! Tu peux assez facilement cloner le repo et l’utiliser sur ton espace perso. C’est ce que je fais pour tester le développement.
    EDIT: c’est fait ✅

    Jirsad Cassam quant à la newsletter globale de Club1, je suppose que c’est compatible en créant des .forward personnalisés ? à moins que la newsletter globale passe également à un fonctionnement en nouvelles+…, ce qui serait plus facile à gérer

    Pour l’instant, on utilise un fichier largement en amont de tout ça :

    /etc/aliases

    Qui permet de router n’importe quoi n’importe où avec la même syntaxe que les .forward.

    Mais actuellement, j’ai fait un truc où la config doit forcément à un endroit spécifique dans le home d’un utilisateur.
    En fait là je me dis qu’il pourrait y avoir un deuxième paramètre au script qui permet d’override l’emplacement du dossier de config. Un peu comme c’est dans la branche master quoi 😅.
    En plus ça fait un bonus pour les power user de club1 qui pourront mettre leur dossier de config où iels le souhaitent !

    Jirsad Cassam EDIT : est-ce qu’on ajouterai pas juste une ligne de code pour forcer l’envoi de la newsletter à $USER@club1.fr en supplément des abonné’es ? ça permet juste une confirmation d’envoi qui serait bien pratique haha.

    Pas bête ! Mais je pense qu’il faudrait l’indiquer au moment de l’envoi qu’on fait ça pour pas que ça ressemble à un bug.

            Ok il reste un paramètre optionnel à rajouter pour que ça fonctionne avec la newsletter officielle de club1 :

            un nom custom pour l’adresse email.

            Mais je sais pas ce qu’il va se passer si des utilisateurices utilisent ce paramètre haha.

            EDIT: ça casse le fonctionnement vu que ça demande de répondre sur une adresse email qui ne correspond plus.

            En fait c’est pas mal !

            Ok,

            J’ai un petit soucis : dans le fichier /etc/aliases, lorsque je veux router les emails depuis une adresse comme celle ci : nl+subscribe, je reçois ce message d’erreur :

            <nl+subscribe@club1.fr>: host mail.club1.fr[private/dovecot-lmtp] said: 550
5.1.1 <nl+subscribe@club1.fr> User doesn't exist: nl@club1.fr (in reply to
RCPT TO command)

            Donc j’ai l’impression qu’il ne prend pas la priorité.

            Chouette de faire avancer tout ça !

            Le plus facile ça m’a l’air de créer un utilisateur « nouvelles » pour la newsletter officielle. Ça ne me semble pas trop choquant sachant que les serveurs ont souvent des utilisateurs techniques comme apache par exemple.

            Ça permettrait une sécurisation de l’accès via le système de fichier, pas le code du script qui est copiable et modifiable librement. Concrètement, un user nouvelles aurait dans son .config/newsletter/emails la liste des abonné’es à la newsletter globale. Ce fichier serait en user=nouvelles group=mail chmod=0640 –> l’user nouvelles est automatisé et est le seul à écrire dans le fichier ; les users humains du groupe mail peuvent lire la liste pour effectuer un envoi depuis leur shell SSH sans se connecter en tant que nouvelles, mais ne peuvent pas modifier la liste des inscriptions.

            Avec ton code @vincent ci-dessous, tout ça est très facile !

            https://github.com/club-1/newsletter/blob/41605293950538fa6537e5c3687b7e3cab6930d7/nl.sh#L92

            Une dernière suggestion dans ce cas : il faudra vraiment documenter (voire automatiser ?) le fait que le chmod doit être 0600 pour les fichiers des users humains, et 0640 pour ceux de l’user nouvelles.

            Vous en pensez quoi ?

              Jirsad Cassam Le plus facile ça m’a l’air de créer un utilisateur « nouvelles » pour la newsletter officielle. Ça ne me semble pas trop choquant sachant que les serveurs ont souvent des utilisateurs techniques comme apache par exemple.

              Eh bien c’est un peu ce que je m’imaginait au début. Après là j’ai essayé de voir si je pouvais changer le moins possible la config actuelle, mais avec le petit blocage dont je parle plus haut.

              Donc carrément d’accord avec ce que tu présentes au dessus.

              Qu’en penses tu @nicolas ?

                  Jirsad Cassam Une dernière suggestion dans ce cas : il faudra vraiment documenter (voire automatiser ?) le fait que le chmod doit être 0600 pour les fichiers des users humains, et 0640 pour ceux de l’user nouvelles.

                  Je ne pense pas que ça soit la peine de faire un traitement différencié. 640 pour tout le monde ça sera très bien puisque le groupe par défaut est le groupe personnel de chaque utilisateur·ice.

                    Jirsad Cassam Le plus facile ça m’a l’air de créer un utilisateur « nouvelles » pour la newsletter officielle.
                    vincent Qu’en penses tu @nicolas ?

                    Je dirais que ça serait cohérent, on a déjà fait ça plusieurs fois. Simplement, j’essaie en général de mettre le home des utilisateurs système autrepart que dans /home en général. En partie pour ne pas polluer le dossier, mais aussi parce que le dossier /home correspond à un autre disque physique, et aussi à une autre dépôt de sauvegardes.

                          nicolas j’essaie en général de mettre le home des utilisateurs système autrepart que dans /home en général.

                          Du coup, c’est bien que je garde l’argument optionnel permettant de délocaliser le dossier de configuration ? Ça permettrait de garder la config au même endroit que maintenant.

                          Par contre, le troisième argument optionnel (qui permet de changer le préfixe) devient caduc, vu que le script sera toujours utilisé par un user qui porte le bon nom.

                          Je viens de faire un petit test, quand le compte existe, ça fonctionne bien de rediriger depuis /etc/aliases.

                              vincent

                              nicolas j’essaie en général de mettre le home des utilisateurs système autrepart que dans /home en général.

                              Du coup, c’est bien que je garde l’argument optionnel permettant de délocaliser le dossier de configuration ? Ça permettrait de garder la config au même endroit que maintenant.

                              C’est toujours pratique de pouvoir indiquer où se trouve la config, mais peut-être pas en argument, peut-être plus avec un flag.

                              Ce que je voulais dire c’est que l’utilisateur en question aurait bien un home mais juste pas dans le dossier /home. Ça ne pose pas de problème pour ton script à partir du moment où il utilise ~ ou $HOME. Donc pouvoir indiquer où se trouve la config n’est pas nécessaire.

                                    11 jours plus tard

                                    Bon, alors du coup j’ai retiré les deux arguments optionnels. En fait si c’est pas nécessaire pour l’instant, autant aller au plus simple.

                                    nicolas C’est toujours pratique de pouvoir indiquer où se trouve la config, mais peut-être pas en argument, peut-être plus avec un flag.

                                    Si je fait un flag, ça voudra dire qu’il est devant le premier argument positionnel (si j’ai bien compris). Mais ça fait un peu bizarre car le premier argument positionnel c’est le nom de la sous-commande. Genre ça donnerait ça :

                                    nl -c ~/perso/confignl/ subscribe

                                    c’est un peu moche non ??

                                      Hey, je passe prochainement à Paris du 28 février au 7 mars. Est ce que ça vous tente @nicolas et @Jirsad Cassam (et d’autres personnes intéressées ?) de se caler un moment IRL pour finaliser et installer cette v2 sur le serveur ?

                                      21 jours plus tard

                                      J’ai fait une nouvelle session de travail sur ce script et Nico m’a filé un coup de main ! Ça avance bien, je pense que c’est même presque fini ! 😀

                                      Voici le menu d’aide en avant première :

                                            __    __          __   /   __  _/_  _/_    __    __
    /   ) /___)| /| /  (_ ` /  /___) /    /    /___) /   `
___/___/_(___ _|/_|/__(__)_/__(___ _(_ __(_ __(___ _/____v2.0___

This will send a newsletter to every mail addresses listed in the emails
file in config folder.

Usage: newsletter [-c CONFIG_PATH] [-n EMAIL_NAME] SUBJECT [CONTENT_FILE]

  -c CONFIG_PATH    override the default config path
  -n EMAIL_NAME     override the email name
  -h                print this help

SUBJECT: the main subject of your newsletter.
(Use quotes for multi words name ex: 'La grande fête du morbier')

CONTENT_FILE: path to the file that store the content of your newsletter.

Alternatively, you can pipe the content through STDIN.

The default From address will use your club1 username like this:
USER@club1.fr, but can be overidden using -c argument.