PEPS, nouvelle solution libre de messagerie et partage de fichiers

Posté par  . Édité par Nÿco, ZeroHeure et Benoît Sibaud. Modéré par ZeroHeure. Licence CC By‑SA.
Étiquettes :
31
18
fév.
2015
Internet

Une nouvelle solution de communication libre est née : PEPS ! PEPS est développé par la société française MLstate, sous licence AGPLv3. Ce n'est pas forcément un remplacement des serveurs IMAP existants mais cela se place plutôt sur le champ de solutions de communication qui incluent les fonctionnalités suivantes :

  • messagerie (compatible avec SMTP). Voir la capture d'écran
  • partage de fichiers et répertoires. Voir la capture d'écran
  • gestion des équipes
  • gestion du chiffrement côté client
  • soin particulier à l'ergonomie et l'expérience utilisateur
  • extensibilité via API REST
  • fonctions sociales, à commencer par un mur pour les utilisateurs. Voir la capture d'écran

PEPS est avant tout conçu pour la communication interne en entreprise, grâce aux fonctionnalités d'équipe (chaque équipe a un répertoire partagé, et peut recevoir des messages envoyés à tous les membres), l'utilisation d'un protocole interne différent de SMTP qui gère de nouvelles fonctions (garanti d'envoi, accusé réel de lecture, possibilité pour l'expéditeur de modifier un message non-lu), système de classification basé sur des étiquettes de sécurité et du support transparent du chiffrement client pour certaines données.

Le code source est disponible sous licence AGPL et se veut une alternative libre à des solutions SaaS de type Gmail + Dropbox ou propriétaires comme Exchange/Outlook ou de communication dont le code est publié mais qui sont non libres comme Zimbra ou OpenXChange. En particulier, le support des calendriers est prévu dans la feuille de route.

Autre point à mentionner : PEPS est disponible sous forme de composants Docker ce qui permet de déployer un système très rapidement. En particulier, la configuration des composants externes comme Solr pour l'indexation ou Haraka est automatisée.

Aller plus loin

  • # Doublon ?

    Posté par  . Évalué à -9.

    Cela ne suffit pas de l'avoir dans le journal au mois de janvier dernier ?? http://linuxfr.org/users/niceisnice/journaux/peps-une-nouvelle-solution-de-messagerie-et-plus-pour-linux

    • [^] # Re: Doublon ?

      Posté par  . Évalué à 4.

      Tout le monde ne lit pas les journaux !

      • [^] # Re: Doublon ?

        Posté par  . Évalué à 9.

        Et surtout il y a une différence importante entre la dépêche et mon précédent journal : cétaipalibre !

    • [^] # Re: Doublon ?

      Posté par  (site web personnel) . Évalué à -2.

      Cela ne suffit pas de l'avoir dans le journal au mois de janvier dernier ??

      Quelle horreur ces journaux que les modos promeuvent en dépèche, quels doublons, encore pire que des dépèches qui sont une version améliorée d'un journal précédent et contient des nouveautés.

  • # .

    Posté par  (site web personnel) . Évalué à 10. Dernière modification le 18 février 2015 à 16:27.

    (lignes blanches pour que l'indentation de la liste ne soit pas foutue en l'air par l'avatar)
    |
    |
    |

    Quelques remarques en vrac (pour lancer le débat… comme l'autre fois ;-)) avant de les oublier :

    • merci d'avoir écouté les retours ici ou ailleurs et d'avoir fait le choix d'une licence libre et adaptée à une appli destinée à être hébergée !
    • la mise en place sous Fedora nécessite de jouer un peu avec SELinux :
      • avant de faire make run, créer à l'avance /data et /etc/peps sinon peps_mongod ne démarrera pas (cf. plus bas) et peps_server (je crois que c'est lui) ne sera pas créé
      • leur donner le type adéquat : semanage fcontext -a -t svirt_sandbox_file_t "/data(/.*)?" && restorecon -rv /data (et pareil pour /etc/peps)
      • make run dépend de la cible où vous copiez les clés avec cp -a qui donc conserve le contexte, donc peps_server plante (pas grave tout s'initialise quand même); faut refaire restorecon -rv /etc/peps et ensuite ça repart avec make start
    • org.apache.solr.common.SolrException: Document is missing mandatory uniqueKey field: email quand j'ai lancé la réindexation de contacts en admin
    • org.apache.solr.common.SolrException: [doc=14B9D08B894] missing required field: in à l'indexation de message (j'ai pas plus de contexte là tout de suite)
    • initial iconv conversion from us-ascii to UTF-8 failed: Illegal character sequence. quand j'envoie un courriel depuis le terminal avec la commande mail ; mon système est en en_US.utf8 et mon prénom a un accent aigu qui apparait ensuite comme "ÃÂ" dans le message
    • j'ai décoché "only admin can register users"
      • le formulaire d'inscription apparait direct sous celui de connexion ; un petit "… register an account" qui le déplie, plutôt ?
      • les input sont stylés pour une police blanche sur fond blanc ; pas très simple pour se relire :-D
      • quand je soumets le formulaire j'ai une erreur "Registration Failed Insufficient clearance" et le compte n'est pas créé
    • la réponse est par défaut "write above" comme gmail, berk
    • les messages dans un fil sont triès antichronologiquement, berk
    • de manière très générale (mais c'est ptêtre moi qui manque de bouteille sur docker), à moins de se taper un docker exec bash sur chaque conteneur (et se taper leur env minimal avec un less qui marche pas etc.) on voit pas les logs, vous pourriez faire un conteneur de logs dans /data pour les centraliser et les consulter hors docker ? (bon dans l'idéal faudrait suivre la convention de la distro écrire dans /var/log etc… on laissera ça aux empaqueteurs :-D)
    • de manière très générale également, docker c'est cool ça évite de pourrir son système pour installer une appliance, mais du coup ça fait très boîte noire ; comment puis-je configurer le SMTP pour utiliser telle et telle spamlist, pour configurer DKIM… enfin comment je migre depuis mon postfix avec sa conf rafinée aux petits oignons depuis 10 ans ?
    • j'aime pas que ça crée un dossier data à la racine comme si c'était chez soi mais de ce que j'ai vu ça doit facilement se changer dans le Makefile
    • y a-t-il ou y aura-t-il une compatibilité IMAP comme il y a pour SMTP ?

    Bon je crois que c'est tout ce dont je me souviens.

    Je ferai des rapports de bug plus détaillés… enfin j'essaierai d'y penser.

    En tout cas ça m'excite plus que les webmails pas libres du moment qui buzz juste parce qu'ils sont plus flat design que Roundcube et je vais surveiller ça. Bravo et merci !

    • [^] # Re: .

      Posté par  (site web personnel) . Évalué à 3.

      Je savais bien que j'en oubliais un : quand on compose un nouveau message, le div.recipients-list est flottant sans width: 100%; et ne prend pas toute la ligne jusqu'à "Cc Bcc".

    • [^] # Re: .

      Posté par  . Évalué à 4.

      Merci pour le super feedback !

      On va regarder les différents points. Quelques éléments de réponse pour commencer :

      • il y a une commande docker logs [container_name] qui est à utiliser car ensuite c'est intégré avec des plateformes complètes type kubernetes
      • IMAP : oui. Le but est d'écrire un serveur IMAP qui soit client des API PEPS. Par exemple en partant de Hoodiecrow pour rester en Node.js ou alors un backend pour dovecot.
      • solr : oui, il y a plusieurs problèmes avec solr, qui en plus consomme une partie non-négligeable des ressources. Nous envisageons de changer pour bleve.
      • "only admin", effectivement il reste un peu de travail (idem sur le provisioning, complexité du mot de passe, etc.)
      • write above/ordre de tri : oui, il faut rajouter des options dans les préférences utilisateur (par contre, on va probablement garder les choix par défaut comme gmail)
      • configuration SMTP : il suffit de modifier smtpin/config/smtp.ini et smtpout/config/smtp.ini. Par défaut, on peut mieux faire sur l'antispam, pull request bienvenu :)

      • [^] # Re: .

        Posté par  (site web personnel) . Évalué à 4. Dernière modification le 18 février 2015 à 17:42.

        Pour les logs, ça ne marche pas pour tous les conteneurs. Par exemple pour peps_smtpin ça n'affiche que des messages système d'init et de cron ; pour voir les logs SMTP j'ai lancé un bash dans le conteneur pour aller lire /var/log/haraka.log.

        Merci pour le SMTP, je jetterai un œil par curiosité (je suis pas vraiment un gourou de SMTP et postfix, juste qu'à force et par petites touches j'ai un truc qui me convient et donc j'ai peur de perdre ce confort). J'avoue que j'ai pas trop cherché de doc dans le dépôt sur comment configurer les différents sous-systèmes mais je soupçonne qu'elle n'existe de toute façon pas :-P

        Tiens encore une idée mais à voir si c'est faisable : make build prend quand même pas mal de temps et j'ai l'impression que certaines images partent de la même base et installent pas mal de paquets en commun ; pourrait-on faire d'abord une image base qui fait la config et les apt-get install communs à différents conteneurs pour dédoublonner ces install ?

        • [^] # Re: .

          Posté par  . Évalué à 3.

          Ok, il faut qu'on redirige daemon_log_file vers stdout ou un endroit collecté par les logs docker.

          Les images sont déjà factorisées, la seule chose que l'on télécharge en double, c'est la distribution pour solr car l'image Docker utilisée est une branche différente du reste qui utilise phusion baseimage (une bonne chose).

          De toute façon, notre objectif à court terme est de tout stabiliser pour sortir une version 1.0 en mai 2015.

  • # Le look, coco

    Posté par  . Évalué à 2.

    Je me trompe ou ça ressemble au style Office 365? (Nan, je veux dire que, si c'en est inspiré, je suppose que c'est en mieux? Cherchez pas le jeu de mots, c'est pas fait exprès.)

  • # Çay libre !

    Posté par  (site web personnel) . Évalué à 4.

    Bravo pour la mise sous licence libre :)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.